
Why Perl 6 is different - fogus
http://blogs.perl.org/users/leon_timmermans/2010/04/why-perl-6-is-different.html
======
jerf
There's a presentation that Larry Wall gave at Google that has a lot to do
with the internals of Perl 6: <http://www.youtube.com/watch?v=JzIWdJVP-wo>
Actually, to be honest, I don't recommend it, I found it surprisingly dull in
delivery (sorry, Larry), but the contents were very interesting.

I actually think describing Perl 6 as "having macros" is accurate, but gives
the wrong impression. It doesn't "have" macros, it's _made_ of macros. The
whole language is made of macros and you are nearly begged to extend it with
more grammar. Or you can throw theirs away and write your own for something.
Or you can throw theirs away, take some of it as a base, and extend it.

It's a wild, wacky experiment that needs to be done. Whatever happens, we'll
learn a lot. My intuition says "collapses under its own complexity"
(especially after trying to add a few grammar-modifying CPAN modules) is the
most likely result, but I fully support with no sarcasm someone trying this
out in case my intuition is wrong. It's not just Lisp redux, it's something
new.

~~~
gaius
_The whole language is made of macros and you are nearly begged to extend it
with more grammar. Or you can throw theirs away and write your own for
something. Or you can throw theirs away, take some of it as a base, and extend
it._

And people wonder why Perl is known as a "write-only" language!

~~~
mst
Because it's a powerful language and during the dot com boom was used by a lot
of very poor programmers.

Rails is running into the same problem with overuse/abuse of monkey patching,
method_missing etc. that perl ran into with overuse/abuse of rich syntax.

It's sad. But it's really nothing to do with either language. They just handed
a large chunk of power to a developer community that grew too large too fast
for most of the membership to have learned how to use that power responsibly.

~~~
pellicle
So, do you think the key to Perl 6's success is to avoid that? That is, do you
think it's better for Perl 6 to have a smaller, more seasoned developer
community in the beginning (to establish some best-practices before the rest
of us join in)?

~~~
chromatic
Unless you manage to pull every novice, dabbler, and new developer into the
community and teach those best practices from the start, you won't solve the
problem on a large scale. Programming -- especially the realm of informal, ad
hoc programming so well served by dynamic languages -- rewards individual
exploration. You don't have to write elegant Python or Ruby or PHP or Perl to
get your job done, and you don't have to learn a lot of theory to accomplish a
task. You may make a mess, but it's not clear that novices care about that.
Why should they?

Perl 6 has an advantage in that most of the tutorials and examples aren't full
of bad examples and muddled thinking like most of the Perl 5 tutorials and
examples are. I don't expect that to last, but hopefully some thoughtful
language design will make abusing the language much more difficult.

------
prog
I use Python as my primary scripting language but I spent some time looking at
Perl 6 in the context of Parrot and it really has a lot of good ideas that
post mentions:

    
    
      - multi-methods
      - rules (builtin parsing capability)
      - macros
      - and a whole bunch of other good stuff.
    

I really made me want to use Perl6 and Parrot. That said the only reason I
couldn't what perhaps the same reason I use Python over Perl5. I somehow
couldn't get myself to go with such a _rich_ syntax. But if Perl5 is your
thing then Perl6 is something that you will definitely like.

~~~
stcredzero
The industry as a whole errs too much on the side of _syntax as the focus of
the community_. Syntax should fade out of the way. It should be
infrastructure, not features. _Libraries_ are the proper object of focus.
Libraries can be modified, forked, debugged without dividing a language
community. Doing that to a programming language syntax weakens and divides
such communities. In contrast, those actions on libraries actually strengthen
programming language communities.

~~~
loup-vaillant
Syntax has two problems: (1) it is the most visible thing in programming
languages, and (2) there is only one per language.

I believe we should be able to modify, fork, or debug syntax the same way we
do libraries. So what about a syntax meant to be read by computer instead of
by humans?

    
    
        # Factorial example, machine syntax
        fac
          -> int int
          \
            0 -> 1
            n ->
              *
                n
                - n 1
    

It could be displayed in human readable form by an IDE or converted back and
forth by suitable preprocessors:

    
    
        -- Factorial example, Haskell syntax
        fac :: int -> int
        fac 0 = 1
        fac n = n * fac (n - 1)
    
        // Factorial example, C syntax
        int fac(int 0) { return 1; }
        int fac(int n) { return n * fac(n - 1); }
    

No more quibbling over prefix vs infix, curly braces vs indentation,
familiarity vs terseness… That would take a flame war away from language
design and put it where it belongs: the IDE.

~~~
jerf
I've seen some people try this. It has problems once you extend past Ye Olde
Factorial Example. Try converting larger chunks of syntax and it rapidly
develops that you are quite obviously just putting different skins on the same
semantics and it also quite rapidly becomes clear that having multiple skins
is a disadvantage, not an advantage. All putting a new language in a skin that
looks more "familiar" to you does is fool you into programming Old-Language-
in-New-Language; you really _need_ the syntactic differences to remind you
that you are _not_ in OldLanguage.

Try translating at the deeper semantic level and you also discover that you
basically can't. The C-semantic equivalent of the Haskell is closer to a for
loop, and even that isn't an exact match. (An exact match probably involves
"goto".) Non-trivial examples just explode in complexity, and that's long
before you get to _useful code_.

This is in the class of "things that have been possible for decades but
haven't taken off for good reasons", right up there with the purely-visual
languages and other classic "good ideas".

~~~
stcredzero
The "syntax as infrastructure" idea has been around in many moderately
successful incarnations. (Lisp and Smalltalk, to name a couple.) Another way
to think of this: shift Syntax into Meta-syntax, so it gets out of the way of
the libraries.

No need for "syntax skins" in that case.

------
thyrsus
My understanding is that Perl 6 is the polar opposite of lisp, in this sense:
In lisp, the code is always and everywhere already in a parse tree, and can be
manipulated easily by, e.g., macros; Perl 5, on the other hand, is the most
unparsable language possible: see <http://www.perlmonks.org/?node_id=663393>.
What perl 6 does is own the parsing problem, and respond by incorporating
super powerful parsing tools. Unfortunately, I believe that perl 6 retains its
dynamic syntax, so parsing of perl 6 itself is still an uncertain adventure,
and not something one can incorporate unconstrained into one's
metaprogramming. I'd love to be wrong about that; am I? If so, can someone
recommend a tutorial on perl 6 metaprogramming?

~~~
Shorel
Well, I'm just learning Perl (work related) and it certainly feels like they
tried to include a lot of ready-to-use lisp-like macros in an otherwise
traditional syntax when inventing Perl.

And Perl 5.12 has this jewel in its changelog:

New experimental APIs allow developers to extend Perl with "pluggable"
keywords and syntax.

~~~
mst
Which is already doable from CPAN using Devel::Declare, hence
Method::Signatures::Simple, Sub::Curried, MooseX::Method::Signatures etc.

The stuff in core is, however, way, way more elegant than the way
Devel::Declare currently does it - which was rather the point, Devel::Declare
was "retrofit to existing perl5 VMs what will hopefully be core later".

------
pg
I don't know anything about Perl 6 (or much about earlier versions for that
matter). Can someone explain how close it has gotten to Lisp? What macro
facilities does it have? Can you munge the syntax tree after code is parsed?

~~~
jules
Very close from what I gather from the web. It has macros similar to Lisp.
They take an AST and return an AST. <http://perlcabal.org/syn/S06.html#Macros>

Do you think that Lisp style languages with sexps are the end in language
design, or do you think that something better will be invented? (or has been
invented)

~~~
pg
I would never say never, but I haven't been able to think of a better way to
represent programs than s-expressions despite many years of thinking about the
problem.

I wouldn't be surprised if sexprs are the end in the sense that the integers
are. I.e. you might go on to discover new things but they'd ultimately reduce
to sexprs.

Is there a textual representation for ASTs? Could you write programs directly
in ASTs?

~~~
jules
To your question: yes, the Perl syntax (the macro system supports
quasiquotation). This is exactly the same as in Lisp. The difference is that
Lisp syntax looks more like how the data structures are represented in memory.
I think you can also build up your programs with data constructors (i.e. like
doing (list 'lambda (list 'x) (list '+ 'x 1)) in Lisp). But note that I
haven't used Perl6, this is information from the web.

------
rjurney
I love Perl. I am most fluent in Perl. I can hack things together in Perl
using CPAN modules without pausing, without thinking, and I am most efficient
using it. I am happiest hacking Perl at 3AM. I hate whats happened to Perl
because Perl 6 has taken so long to ship. Perl 5 is outdated. Moose helps, but
its gotten so bad for so long that I can't code in Perl and collaborate with
anyone. I write clean Perl, but it doesn't matter - everyone else moved on
years ago and disdains it. So I hack Ruby, Python, etc. because I have to.

I hope Perl 6 changes that. Is it ready to use?

~~~
bad_user
No, but this is a good time to play with it ... Rakudo Star should be released
in the next 2-3 weeks or so.

Problem with Perl 6 was that it's too ground-breaking, without having the
resources of a huge company (like Sun, MS).

But it doesn't matter because you can't find the combination of features it
provides in other languages ...

    
    
      * full OOP
      * optional typing
      * multi-dispatch
      * macros
      * cool pattern matching
      * functional features ... map, fold are at home ;)
      * continuations / coroutines
      * transactional memory
      * eventually it will be compatible with every package on CPAN
    

Personally I don't like Perl (either 5 or 6), I'm more interested in Parrot
because what is widely viewed today as being general-purpose VMs (the JVM /
.NET) are a poor choice for dynamic languages.

Consider that the JVM and .NET are stack-based. Because of that efficient
continuations passing style is impossible on top, and that's a PITA because
you can build any control structure on top ... tail-calls, closures,
coroutines, exceptions, green threads ... can all be implemented efficiently
in terms of CPS.

Another thing against the JVM / .NET is that they'll never earn optimizations
for dynamic languages that could impact the performance of first-class
citizens. You can forget about an efficient tracing-compiler on top of those,
simply because such optimizations are not cheap and can impact the performance
of Java / C#, and those VMs are not low-level enough to implement it at a
higher level.

And for instance, personally I'm skeptic that InvokeDynamic on the JVM will
deliver that much performance. Yeah, it provides a mechanism for a monomorphic
inline cache, and from there the JVM can do stuff like code-inlining of call-
sites.

But it doesn't do tracing of types, which means that code like the following
...

    
    
      sum = 0
      for i in range(1000):
          sum += i
    

will always pay for the price of boxing/unboxing of those primitives, an
optimization that current Javascript VMs and LuaJIT 2 are doing.

So if Parrot delivers, it will be one heck of an alternative. Either way, its
interface is nice and you can use it right now for prototyping new languages.

~~~
colomon
Actually, Rakudo Star is probably about two months off at the moment. Q2 was
the originally announced timeframe, then April was batted about, but the lead
developer has had major family health issues taking up his time, so we elected
to push it back towards the tail-end of Q2.

On the other hand, it's already a pretty good time to play with Rakudo Perl 6.
It's still got some rough edges, and it's slow, but it's also expressive and
powerful.

------
AndrewO

      It has been said that Ruby is Smalltalk with a perly syntax. 
      Perl6 extends on that: Perl 6 is Lisp with a perly syntax.
    

Interesting idea, but I would have loved to see some examples or comparisons.
For all of the mindshare that Perl has, I haven't seen much content
(especially code) about Perl 6 over the last couple of years.

~~~
draegtun
Here are some links showing recent Perl6 content/code:

* Perl6 advent calendar: <http://perl6advent.wordpress.com/>

* Moritz Lenz perl6 blog: <http://perlgeek.de/blog-en/perl-6/>

* Carl Masak perl* blog & github projects: <http://use.perl.org/~masak/journal/> <http://github.com/masak>

* Perl6 planet: <http://planetsix.perl.org/>

* Perl6 book: <http://github.com/perl6/book>

* Perl6 examples: <http://github.com/perl6/perl6-examples>

~~~
AndrewO
Thanks—I'll check those out!

~~~
draegtun
You're very welcome.

This link may also be of interest:
[http://transfixedbutnotdead.com/2010/01/14/anyone-for-
perl-6...](http://transfixedbutnotdead.com/2010/01/14/anyone-for-
perl-6-metaprogramming/)

From the links in the post you can find Perl5, Ruby, Javascript and Python
comparative examples.

Been playing a bit with Io (<http://www.iolanguage.com/>) recently so was
planning to add a comparative post for that as well.

 __Update: __I just copied over my Io example i had brewing into a gist
(<http://gist.github.com/372559>)

------
fogus
I may have missed the point, but it seems to me that the gist of the post is,
"Perl 6 is different because it's the same as Lisp".

~~~
draegtun
Larry Wall himself said that:

 _Perl 6 is Lisp with a decent syntax, and minus a lot of assumptions about
how lists should be represented :)_

ref: <http://irclog.perlgeek.de/perl6/2010-01-15#i_1905210>

He then goes onto to mention that _despite all the trappings of OO, Perl 6 is
fundamentally more in the FP camp_

~~~
plinkplonk
"Perl 6 is Lisp with a decent syntax,"

Calling perl syntax "decent", and by implication better than lisp syntax (such
as there is) is mind bending.

~~~
bad_user
Perl's syntax is designed to be more close to natural language.

Both Lisp and Perl are in the same camp ... I could hardly read an algorithm
written in them before learning and actively working with them.

Either way, I'm tired of languages that can only be extended by adding
functions. Declarative APIs require much more than that.

~~~
vlisivka
> Perl's syntax is designed to be more close to natural language.

s/natural/English/. Some languages can be parsed by computer without problems.
For example, simple 15kb C program can parse 100% of technical text in
Esperanto, 98% of technical text in Ukrainian (my native language), 84% of
technical text in Russian, and so on. Not so simple parser can parse more than
100% of text, i.e. it can fix errors in text.

For me, shell is much closer to my native language than perl or SQL.

PS. AFAIK, there is no natural language in the wild nature. :-/ All human
languages are artificial.

~~~
draegtun
I think bad_user might be referring to Larry Wall's post _Natural Language
Principles in Perl_

ref: <http://www.wall.org/~larry/natural.html>

------
jpablo
_It thankfully steals nothing from PHP_

I love this quote.

