Why Perl 6 is different

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.

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

    -- 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); }

The goodness of a java library has little to do with syntax (because clojure can easily call any java library), but semantics. For instance, java commonly uses mutable state. A fundamental principle of Clojure is that data should be immutable. Immutability makes testing easier, it makes parallelization easier. Clojure was built to make pmap easy. If I have a java library where I have to remember that Foos are thread-safe, but Bars are not, that adds to the incidental complexity of my solution, and reduces my ability to bring Clojure's new tools to bear on the problem.

As another commenter pointed out, syntax of a language is heavily influenced by the semantics of the language. A language starts with a few high level principles, and a favorite hammer or two. The syntax of the language is designed around making those common operations easy. Libraries written in that language will tend to follow those same principles.

Having Java libraries available to Clojure is a huge advantage, but it's not the be-all end-all, because the semantics of those libraries may be incompatible with your new language.

Instead, focus on semantics. Figure out which high level principles are good. What abstractions and design principles result in better, easier to understand solutions? From that follows your libraries and syntax.

I do think that there is a healthy focus on syntax -- at least my own experience bears it out. It was the syntax of doing things the python way that allowed me to grok polymorphism and MVC despite programming in an OO language for .Net for years. I find that if I want to learn a concept, the syntax is extremely helpful. I also find that if I have to program quickly, syntax being close to how I think is also helpful, and will get frustrated having to make yet another translation of my thought into a syntax that wasn't well thought out. I would also bet that a lot of people find a different syntax to intuitive, and others counter-intuitive than I do. And I'm fine w/ that! Just because there is difference doesn't mean there has to be division!

* multi-methods: MooseX::MultiMethods and MooseX::Method::Signatures add a lot of overhead to subroutine calls (blogged in http://blogs.perl.org/users/aevar_arnfjor_bjarmason/2010/02/...). Sometimes this doesn't matter, but they're certainly not a replacement for having a native type system. All the magic is done at runtime.

* rules: Perl6::Rules and Regexp::Grammars are both depended on by a grand total of 0 CPAN modules. They're interesting experiments but not something in use, and not a replacement of rules with its "your regex opcodes are a normal method" model.

* macros: Devel::Declare and the B::* modules are usable but they're a long way away from the Lisp model of being able to easily write macros. TryCatch is 800 lines of Perl and C to implement try { ... } catch { ...}. In any Lisp this would be trivially done with a macro in under 50 lines.

As for the other stuff pretty much anything except smart match (which is now in Perl 5 core), Class::MOP and Moose falls under the "neat but some combination of: underused, slow, unstable, epic hack nobody wants to use".

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".

Here is the code example from the docs:

    use XS::APItest::KeywordRPN qw(rpn calcrpn);

    $triangle = rpn($n $n 1 + * 2 /);

    calcrpn $triangle { $n $n 1 + * 2 / }

Also I think the the ability for a program to create a new program (I assume you mean on the fly) is probably inherent in all dynamic languages.

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?

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.

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

I'm no Lisp guru, not even proficient but isn't saying that kind of missing a large point of Lisp in that code is data and data is a list/sexpresion or what ever it's called?