
Perl 6 – Getting beyond static vs. dynamic [pdf] - lelf
https://fosdem.org/2015/schedule/event/perl6_beyond_dynamic_vs_static/attachments/slides/724/export/events/attachments/perl6_beyond_dynamic_vs_static/slides/724/2015_fosdem_static_dynamic.pdf
======
xiaq
This is the best part of Perl 6. I am not familiar with the terminology, but
it seems "not just" gradual typing to me.

I always it puzzling that to avoid the tedious parts of static type systems,
people throw away static checking entirely. As demonstrated by Perl 6 and
other gradual typing systems, the whole dualism is imaginary.

I wish that the "runtime dynamicity with as much compile-time staticity as
possible" idea will be the norm in the dynamic language community. I wish that
someday when we talk about the days of 100% dynamicity with no static
checking, we can remark that we have luckily passed that dark age.

~~~
pekk
I always find it puzzling that people throw away dynamic typing entirely. You
can't make decisions about what's best for me based on rules of thumb like "as
much static typing as possible," your use cases probably don't match mine if
you don't understand why anyone would want dynamic typing.

~~~
sparkie
The reason is simple: Using a statically typed language (particularly one with
reflection capabilities), it's trivial to do pretty much anything a dynamic
language is capable of doing without extra tooling, perhaps with just a bit
more verbosity in code. On the other hand, attempting to simulate static
typing with an entirely dynamic language doesn't happen without extra tooling
around the compiler.

Even languages with strict type systems like Haskell don't entirely throw away
dynamic typing. It has `unsafeCoerce` which can attempt to cast a value at
runtime, and fail if it's not the right type like any dynamic language would.
However, when combined with Data.Typeable, storing type information in
addition to the values you're interested in allows you to turn `unsafeCoerce`
into something much safer: `fromDynamic`, which doesn't cause the runtime to
fail, but instead returns a Maybe type - one that either contains a
successfully coerced value or Nothing - and the language forces you to check
this before you can use the value. You have the best of both worlds now - the
ability to write whatever dynamic typed code you want, but with the ability to
fall back to a strict type system to keep things in check.

~~~
cbd1984
> unsafeCoerce

This is the exact opposite of dynamic typing. Dynamic typing doesn't throw
away type information, it uses it to perform _safe conversions_ , not _unsafe
coercions_.

~~~
tel
Haskell does safe coercions. That was the point of the op's argument,
actually, but he mistakenly introduced it first through it's implemenation
which, after confirming safety, uses a function called 'unsafeCoerce'.

The module is called Data.Dynamic and it is a complete dynamic type system
embedded inside Haskell at runtime.

It's not very popular. Read into that whatever you like. There are some
reasons to use it, perhaps, but most, to my understanding, see it as opaque
and difficult to reason with.

------
_pmf_
Every time I read something like this about Perl, I'm amazed at how much it
got right.

------
rurban
It might be worth mentioning that I'm working on a similar type system for
perl5 for quite some time, which is efficient like perl6. In contrast to
Moose, which is inefficient and more about the MOP. Types there are only used
to slow things down, not to speed it up. All these things were developed
around 2002, just forgotten and then partially destroyed with 5.10 and
ongoing.

Perl5 hates it, but they haven't seen it and they have generally no idea. It
is entirely doable in perl5 only. I got 2-6x speedups in prototypes. But then,
perl6 has so much more features worth switching over.

------
agumonkey
Questions ? Projects[1] stepping onto Meta-Objects territory, why not using
Common Lisp ?

[1] There were a few talks on youtube about "advanced python programming" who
were about similar ideas.

~~~
kbenson
How about _why_ use Common Lisp? Lay out some reasons and convince us. That
sounds like an interesting discussion.

~~~
agumonkey
Because they've been investigating MetaObjects (and MetaObject Protocols)
since the 80s. Sorry for the smugness, my argument boils down to "Don't
reinvent the wheel too much".

~~~
perlgeek
FWIW the Perl 6 MOP is heavily inspired by the Common Lisp MOP. Or to put it
another way, it steals the good parts.

But for many people, it also has nicer syntax :-)

~~~
agumonkey
They forgot to steal the syntactic part then ;)

Do you have links about influnce of CLOS MOP in Perl6 ? For what it's worth I
do love Perl6 efforts like first class grammar/rules.

~~~
kbenson
I can't seem to locate definitive sources at the moment, but it's mentioned
often[1]. My general understanding of it is that the MOP is heavily influenced
by CLOS, and the object system heavily influenced by the Smalltalk traits
paper, which may itself have heavy CLOS influences. The easiest way to figure
out just how similar they are may be to look at the Perl 6 docs on both the
MOP[2] and Objects[3]. There's also the synopsis[4] documents which guide the
design.

In addition, Perl 5's Moose[5] object system (and relatives Moo, Mouse, etc)
are also heavily influenced by Perl 6, CLOS and Smalltalk.

1:
[http://irclog.perlgeek.de/perl6/search/?nick=&q=clos](http://irclog.perlgeek.de/perl6/search/?nick=&q=clos)

2: [http://doc.perl6.org/language/mop](http://doc.perl6.org/language/mop)

3:
[http://doc.perl6.org/language/classtut](http://doc.perl6.org/language/classtut)

4: [http://design.perl6.org/](http://design.perl6.org/)

5: [http://moose.iinteractive.com/en/](http://moose.iinteractive.com/en/)

~~~
agumonkey
Ha.. googling perl6 mop never led me to doc.perl6.org. Thanks a lot for the
history!

------
esaym
This looks awesome!

------
estava
Seems kind of sweet. Except for the prefixing symbols.

------
buster
I can see how he can be amazed by simple stuff, like typos etc. The moroning
example would be catched by python tools like pyflake, or compilers in case of
C or rust or whatever... Still he reserves several slides for something i
consider most basic, even in other dynamic languages through tooling (truth be
told it wouldn't be caught by the interpreter at "compile time"). It's likely
such a surprise for him because perl5 was pretty much not even parseable to
tell such things..

~~~
giancarlostoro
A number of IDE's these days have spell checkers (JetBrains comes to mind).

~~~
espadrine
Those spell checkers are easier to make if the language already includes
tooling to support that functionality.

~~~
rurban
Exactly. Normally the debugger or repl provides reflection capabilities to be
used by the editor to support warnings, errors and hints, and restructuring
tools.

Such a typo catcher would be a written (I'm thinking of a lisp or lua here) on
the editor side, having the information about the variable and being able to
query the namespace or locals visible or not visible. The things jonathan did
was just to put this into the compiler for the thrills, but it can be easily
extracted, extended and customized from the outside, in emacs, vi, eclipse,
... such as jonathan did with his perl6 debugger.

