Hacker News Reader

Comment by UncleOxidant | Hacker News Reader

"As far as I know, Perl is one of the only languages that can evolve via 3rd party modules."

Ummm... What?!

There's a long tradition creating DSLs in the Ruby community. Lisp/Scheme/Clojure have macros. OCaml has campl4. I'm sure there are many others.

View on HN

Not the same thing. DSLs are not the same as extending the functionality of the interpreter. And it's basically the flexibility of perl as a procedural/functional/declarative/OO language (i.e. lack of assumptions of how you want to work) with its roots in practical natural linguistics (as opposed to theoretical as with lisp) that makes this possible. Yes, that does mean coding with some discipline (Perl::Critic and Moose & friends helps here), and some things are more of a pain in the arse than with a more opinionated language, but it seems a reasonable trade off to me.

I'll give you macros, but if you define DSLs as "chained methods", many languages have DSL supports. The author's talking about Perl's support for mangling the language itself through third party modules.

Exactly. MooseX::Declare is a good example.

What does Perl have in that regard that Ruby hasn't? Ruby also has open classes and you can chain and modify any of the base classes, be it "String" or "Object".

I don't know anything like "MooseX", but that might be because Ruby actually has a somewhat working object system.

Perl lets you add new language keywords which take effect during the parse phase.

So, basically, Perl has macros? REAL macros? Like, say, in Lisps? Could I, for example, make fully inlined merge sort, as demonstrated a couple days ago here by a post from Racket blog? Now I'm curious.

Sort of. Perl has support for something like reader macros. See http://search.cpan.org/~zefram/Devel-Declare-0.006011/lib/De... for details.

One could, in theory, build something like Lisp macros using it, but I don't think that anyone has.

Perl 5's parser manipulation doesn't go as far as manipulating an AST, yet. I would like that, but Lisps still have a strong advantage there.

Sure, but the intent of the author seems to be to say that the language can be molded in ways that make it easy to apply in specific domains. Whether that's with macros or with a DSL-ish approach you're pretty much achieving the same end result. Ruby's blocks make it fairly easy to create DSLs that look like you've actually changed the underlying language in some way - Rails makes heavy use of these features, for example.

Reply on news.ycombinator.com