7 ms·

Perl 6 – Getting beyond static vs. dynamic [pdf]

91 points by lelf 12y ago

buster 12y ago
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 12y ago
  A number of IDE's these days have spell checkers (JetBrains comes to mind).
  - espadrine 12y ago
    Those spell checkers are easier to make if the language already includes tooling to support that functionality.
    - giancarlostoro 12y ago
      I guess, but a lot of IDE's are not even made in the same language the person is programming in, the spell checker is independent from the language. PyCharm is evident of this, a Python IDE coded in Java (and portions in Python, but mostly Java).
    - rurban 12y ago
      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.
- kbenson 12y ago
  I humbly suggest that you may have missed the point. That was simply an example to illustrate the point, which is on slides 20-22. The rest of the talk expounds on this.
- draegtun 12y ago
  The moroning example gets caught at compile time in perl6 and also in perl5... $ perl -Mstrict -M"feature 'say'" -c morning.pl Global symbol "$moroning" requires explicit package name at morning.pl line 7. morning.pl had compilation errors.
- raiph 12y ago
  > It's likely such a surprise for him because perl5 was pretty much not even parseable to tell such things. Jonathan got an honors degree from Cambridge University in CS specializing in compilers etc. If you pay attention to his slides you'll see he's paid to train others to use a variety of languages (all kinda boring ones, except P6 imo, but still). Imo you are underestimating his expertise and the import of what he's saying in his presentation. The bit that I'm still confused about is how the interleaving of run-time inside compile-time inside run-time inside compile-time etc. contributes to the imposition of compile-time type checking via run-time code and how far that paradigm can go. I'd appreciate you (or anyone else) carefully explaining that bit to me. :)
xiaq 12y ago
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 12y ago
  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.
  - mmphosis 12y ago
    Time, random, user input, self-modifying self-compiling code, undetermined function results, ... I agree that there are no absolute rules. A fixed system is boring, and often very inefficient depending how you look at it. Sure my system is static, but inside the black box there is a lot of "dynamism" that I can't change without a recompile. The development environment is dynamic. Writing code, creating the rules, and creating the locked down static types are all dynamic actions. There is no need for a separation between developer/user. User can set the rules, create the workflow, compile the code on the fly. There is no need for a separation between compile and run time. GHC is itself written in Haskell (utilizing a technique known as bootstrapping), but the runtime system for Haskell, essential to run programs, is written in C and C−−. I don't know much about C--, but C, what Haskell's runtime is written in, is fairly dynamic.
    - maxlybbert 12y ago
      http://www.cminusminus.org/ http://www.cminusminus.org/ . It's meant as a compiler target, say, a portable assembly code.
_pmf_ 12y ago
Every time I read something like this about Perl, I'm amazed at how much it got right.
agumonkey 12y ago
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 12y ago
  How about why use Common Lisp? Lay out some reasons and convince us. That sounds like an interesting discussion.
  - agumonkey 12y ago
    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 12y ago
      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 :-)
      - lispm 12y ago
        Line noise added to CLOS.
      - agumonkey 12y ago
        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 12y ago
        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/
estava 12y ago
Seems kind of sweet. Except for the prefixing symbols.
rurban 12y ago
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.
esaym 12y ago
This looks awesome!

91 points by lelf 12y ago

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 12y ago
A number of IDE's these days have spell checkers (JetBrains comes to mind).
- espadrine 12y ago
  Those spell checkers are easier to make if the language already includes tooling to support that functionality.
  - giancarlostoro 12y ago
    I guess, but a lot of IDE's are not even made in the same language the person is programming in, the spell checker is independent from the language. PyCharm is evident of this, a Python IDE coded in Java (and portions in Python, but mostly Java).
  - rurban 12y ago
    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.
kbenson 12y ago
I humbly suggest that you may have missed the point. That was simply an example to illustrate the point, which is on slides 20-22. The rest of the talk expounds on this.
draegtun 12y ago
The moroning example gets caught at compile time in perl6 and also in perl5... $ perl -Mstrict -M"feature 'say'" -c morning.pl Global symbol "$moroning" requires explicit package name at morning.pl line 7. morning.pl had compilation errors.
raiph 12y ago
> It's likely such a surprise for him because perl5 was pretty much not even parseable to tell such things. Jonathan got an honors degree from Cambridge University in CS specializing in compilers etc. If you pay attention to his slides you'll see he's paid to train others to use a variety of languages (all kinda boring ones, except P6 imo, but still). Imo you are underestimating his expertise and the import of what he's saying in his presentation. The bit that I'm still confused about is how the interleaving of run-time inside compile-time inside run-time inside compile-time etc. contributes to the imposition of compile-time type checking via run-time code and how far that paradigm can go. I'd appreciate you (or anyone else) carefully explaining that bit to me. :)

xiaq 12y ago

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 12y ago
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.
- mmphosis 12y ago
  Time, random, user input, self-modifying self-compiling code, undetermined function results, ... I agree that there are no absolute rules. A fixed system is boring, and often very inefficient depending how you look at it. Sure my system is static, but inside the black box there is a lot of "dynamism" that I can't change without a recompile. The development environment is dynamic. Writing code, creating the rules, and creating the locked down static types are all dynamic actions. There is no need for a separation between developer/user. User can set the rules, create the workflow, compile the code on the fly. There is no need for a separation between compile and run time. GHC is itself written in Haskell (utilizing a technique known as bootstrapping), but the runtime system for Haskell, essential to run programs, is written in C and C−−. I don't know much about C--, but C, what Haskell's runtime is written in, is fairly dynamic.
  - maxlybbert 12y ago
    http://www.cminusminus.org/ http://www.cminusminus.org/ . It's meant as a compiler target, say, a portable assembly code.

_pmf_ 12y ago

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

agumonkey 12y ago

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 12y ago
How about why use Common Lisp? Lay out some reasons and convince us. That sounds like an interesting discussion.
- agumonkey 12y ago
  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 12y ago
    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 :-)
    - lispm 12y ago
      Line noise added to CLOS.
    - agumonkey 12y ago
      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 12y ago
        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/

estava 12y ago

Seems kind of sweet. Except for the prefixing symbols.

rurban 12y ago

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.

esaym 12y ago

This looks awesome!