
Why Perl 6 is Different (2010) - brudgers
http://blogs.perl.org/users/leon_timmermans/2010/04/why-perl-6-is-different.html
======
ceronman
> Perl 6 is Lisp with a perly syntax

Lisp syntax is super simple. But this simple syntax can hide an enormous
complexity. Metaprogramming is complex. Lisp is so powerful, but it's not so
widely used as other languages because of this complexity.

Now, Perl 6 claims to have the same power as lisp, only that instead of using
a simple syntax, it is using a complex one, and a complex way of modifying
that syntax. This is complexity wrapped in more complexity.

I'm sorry but I don't think Perl 6 will ever be a very widely used programming
language as its predecessor was. It might however amuse a small group of
hackers who want to test new ideas in programming languages.

~~~
thesz
The problem of Lisp is _the_ side-effecting nature of it. There's nothing
complex in metaprogramming, if you do it in pure setting. The problems arise
when you combine two differently side-effecting pieces of software and Lisp
does nothing to prevent that or help there.

I won't stop repeat that mantra that side effects and program state are an
_implicit_ information channel in a program. This channel is shared by many
parts (or parties) inside program and it has some specific _implicitly
specified_ protocol of use. Add a piece of software that uses the channel with
slightly different protocol as assumption, get ready for all sorts of
problems.

~~~
junke
Of course there are side-effects. This is the whole point of a dynamic
_system_ where (almost) everything can be redefined at runtime.

------
grabcocque
One of Perl 6's original design goals was that it should "still be Perl". In
that sense, I think it's a failure. Aside from a superficial syntactical
resemblance, it really doesn't feel much like my beloved Perl 5 at all. Its
semantics are very different.

It also seems to suffer from an advanced (possibly fatal) symbolpasta
diarrhoea. Perl 5 was not pretty, but Perl 6 at times can be downright
hideous.

If Perl 6 is a Lisp, that's great! You know, I am deeply and madly in love
with Clojure at the moment. But that manages to be a Lisp without falling even
deeper into the line noise trap than P5 did. But, you know, syntax is just
syntax.

~~~
crncosta
I like P6 syntax and semantic more them P5.

My only one problem about P6 is the fact they dropped the effort of having the
specification so others can implement the language too. Looks like they prefer
a conformance test instead of a formal/complete specification.

While that is perfect fine, I would say having both the test and the spec is
even better, for those trying to learn and implement the language.

A good, formal and complete specification will make my learning process much
better, IMHO.

~~~
chrisseaton
I've recently been implementing a language based on a conformance test instead
of a spec, and it's really hard. I often have two tests that do different
things with seemingly similar inputs, and I struggle to find the underlying
reason behind what is going on and what the cause of the difference in output
is.

------
simgidacav
This post sounds a bit like trolling :D

However, I believe the real power of Perl, besides the obviously awesome regex
handling, is the "huffmann" principle of making common things super-quick.
Sure this is the major cause of read-only code, but it's also the reason why I
use perl every time I just need things to be done.

In Perl6 they kept this principle in mind, and this is the important part
IMHO.

~~~
otoburb
>>Sure this is the major cause of read-only code

Did you mean "write-only" code? Read-only code would be a much touted language
feature and cause for celebration!

~~~
eCa
(But productivity would suffer.)

------
mback00
It is still... A language for the quick hack, but not for the reader (or
author) to understand a day or even an hour after the writing.

~~~
realusername
That's the number one reason I don't code in Perl, I can't even read my own
code 6 months later... Perl is not a programming language, it's closer to real
languages and you can sort of invent stuff and it works...

~~~
melling
Is it the for loops? The if statements? The function calls? I've written lots
of Perl. It doesn't have to look that much different than any other language.
If you find a terse 1 liner on the Internet and use that as a solution, you
might not be able to read it a week later.

~~~
tyingq
I suspect it's the wide range of special operators, variables and default
arguments. Knowing, for example, that shift() shifts @_ by default. That <>
iterates over @ARGV. That chomp chomps $_. Messing with @INC changes library
search paths, etc.

Or, perhaps the syntax for dealing with elements in a somewhat deep data
structure, like: push(@{$TV{$family}{kids}},"anotherkid");

Sometimes, people are just griping about regex syntax though, which seems
disingenuous, since many languages use the exact same pcre expressions.

I like perl, but if it's been a while, there's definitely some back and forth
with books to decipher something I wrote some time ago.

~~~
Mithaldu
It largely depends from whom you learn. Most people google and run with the
first thing google throws up and perl has many, MANY (due to its age) really
_shitty_ learning resources. Even the most popular one, the book Learning
Perl, has as of its 6th edition (2013), grave flaws and miseducates newbies
severely.

Some comment from the position of someone familiar with Modern Perl, which is
largely what's practiced on CPAN:

> shift() shifts @_ by default

This is discouraged, precisely because it messes with @_. It has valid uses,
but people tend to make sure it's clear from the code why it's used. (Mainly
in OO helper stuff.)

> <> iterates over @ARGV

Almost nobody uses that, precisely because it's very unreadable. It only
exists for compatibility reasons and was made to serve people used to sed/awk.

> chomp chomps $_

I haven't seen code use chomp in ages. I've never used it myself.

> Messing with @INC changes library search paths, etc.

This is rarely used as well. Mainly only when doing release engineering. It's
also most often done via `use lib 'whatever';`.

    
    
        push(@{$TV{$family}{kids}},"anotherkid");
    

That is an outdated way to write that. In a decent modern style it would be
written like this:

    
    
        push @{ $TV{ $family }{kids} }, "anotherkid";
    

And with a more modern Perl, this:

    
    
        push $TV{ $family }{kids}, "anotherkid";

~~~
Estragon
Yes, I think the biggest issue with perl was the devil-may-care culture around
it. That was far from the only issue, though. It had (has?) some gratuitous
features which are bound to cause hard to find bugs, like implicit conversion
of numeric strings to numbers in certain contexts. That particular feature was
the reason I chose to learn python in the mid 90s, rather than perl.

~~~
raiph
> implicit conversion of numeric strings to numbers in certain contexts.

In Perl 6 at least, and to a large degree Perl 5 too, context only "causes"
bugs if coders make assumptions that are invalid in Perl.

For example:

    
    
      say $foo + $bar
    

adds two numbers. So the context for $foo and $bar is numeric. So Perl coerces
them to be numbers. If you didn't mean to add two numbers, don't use a numeric
operation such as `+`.

If you want Perl 6 to make sure $foo and $bar are numbers already, then add a
type to their declaration:

    
    
      my Int ($foo, $bar);

------
brudgers
Past:
[https://news.ycombinator.com/item?id=1279238](https://news.ycombinator.com/item?id=1279238)

