In Praise of Perl 5
ledgersmbdev.blogspot.com
ledgersmbdev.blogspot.com
At the moment I'm playing with some threaded perl to parse very large text files - part of the code was developed by a C++/Java/js fan, who just realized it was the best tool for the job, and created that after a few days of playing with perl.
Python and Ruby both have a much cleaner syntax, yet still offer very comparable functionality, excellent portability, ample standard and third-party libraries, excellent documentation, supportive communities, great regex support, and basically everything else that Perl offers.
Since everything positive about Perl is also offered by alternative languages today, and those alternatives are themselves much better than Perl in some respects, Perl seems like a less and less enticing option each day.
Yes. Scripting powers of Perl are unmatched.
>>It may have been true in the mid-1990s, but things have changed since then.
Hardly anything has changed. No language has taken scripting that seriously. You are likely confused between dynamic languages and scripting langauges. There is a big difference. If you haven't noticed, well then that's the whole point behind Perl. You really need to use it to see what it is.
>>Python and Ruby both have a much cleaner syntax
Its not about having a cleaner syntax. Making it easy to learn, only means the complexity is left to the programmer to handle now. Either way some one needs to handle the complexity, Its either the programmer or the language. If you make the language simpler, the complexity burden shifts to the programmer.
>>yet still offer very comparable functionality, excellent portability, ample standard and third-party libraries, excellent documentation, supportive communities, great regex support, and basically everything else that Perl offers.
Python takes great care to purposefully avoid offering every thing that Perl offers.
>>Since everything positive about Perl is also offered by alternative languages today, and those alternatives are themselves much better than Perl in some respects
You will have to substantiate that point with some evidence.
>>Perl seems like a less and less enticing option each day.
That is being told since what? 1988?
Can you offer any examples of how that is true?
I started writing a detailed reply, but half way down I realized it might become a booklet project[Which is a very good project idea by the way]
I also realized I may not be able to justice to 3 decades of Perl history in one HN comment.
So the best I can do is point you out to two links.
http://hop.perl.plover.com/ and http://onyxneon.com/books/modern_perl/
Higher Order Perl is one of the best books I've read, but I feel that's much more about software development than scripting, teaching the fundamental techniques in functional programming.
Perl fits the same niche as English does for natural language - used everywhere, easy to learn for simple cases,very tough to master. The way I like to say it is that while most programming languages help you think more like the computer, perl helps the computer think more like you do.
I've read the awk and sed man pages so many times, yet everytime I have to type a command I have to read it again.
It's pretty clear that Perl does not hold the prominence it once held in the 1990s. So, yes, it is clearly becoming a less-enticing option for a lot of people, whether you're willing to admit this or not.
You can use Python for that, but the jump from Unix shell to Python feels bigger; everything is more verbose and less awk-y in Python. Which can be good for maintainability of bigger scripts, but feels heavyweight for some stuff.
Its about how such a feature interplays with rest of the language.
Frankly speaking in Python it looks like added after a lot after thought and a lot of reluctance. Same with regular expressions.
More specifically, Perl has advanced features with which meta-object protocols can be built with. See Class::MOP on which Moose is built.
> That is an example of what the OP is saying with Perl is an extensible language.
I think the difficulty with Ruby and Python is that both are fully object-oriented, which means it is difficult to create something that is truly orthogonal to the object model.
i couldnt find this one simply searching online
http://codefol.io/posts/Does-Ruby-Have-a-Metaobject-Protocol
...except for performance. The GIL is Python's achilles heel; if you throw threads at the problem Python gets slower while Perl actually uses all your cores. C.f. http://yaketyhack.blogspot.com/2010/07/threading-perl-vs-pyt...
BTW, I love Python.
I generally use a graphical debugger in Eclipse. I have used Python and Perl, and can't see too much difference between them. Whats better about the Perl one?
Cleaner syntax than the declarative class mentioned in the article?
> Since everything positive about Perl is also offered by alternative languages today, and those alternatives are themselves much better than Perl in some respects, Perl seems like a less and less enticing option each day.
To my mind though the benefit is in mutability of the language. Yes, there are other languages in this category (rebol, red, lisp), Perl is somewhere between these and Python and Ruby. If I were to order them from most mutable to least, I would go lisp, rebol, red, perl, (python and ruby). This is a powerful thing and of course with great power comes the possibility of misuse.
I've been known to say "perl5 is a lot like ruby except with usable OO" and it's very much a "ha ha only serious" sort of comment.
If you want "no questions asked" in this environment, you need to pick Java ... and as of JavaEE6/7, it's a much more efficient language. Granted that it's not as dense as Perl, but it's also type-safe and with good conventions, readable.
If you're developing SaaS, use what you're most productive with (assuming you're not productive simply because you're creating crap). I've see people who can write in beautiful Perl, and I have no problem reading it. I've also seen people who write whole programs on one line just because they can ... and a couple months later, they can't read it either. Note that I've also seen bad Java, Python, etc programming.
Also, more CPAN libraries seem to be in a state of atrophy these days and I think the long-looming specter of perl 6 has had a depressing effect on that community.
The post talks about Moose, which is a behemoth with huge and varied dependencies and must be be tougher to maintain these days. Every time I've tried to write a project in Moose, I've regretted it in the long run.
However, I've written plenty of big, enterprise-class projects in perl instead of buying them from major vendors. Over the years, we were almost always able to beat the value proposition of Big Software precisely because we had a solid team of perl coders.
If you find Moose too many dependencies, try Moo.
Even if the Perl 5 community has generally admitted that Perl 6 was a failure and has moved on, a lot of people first think about how disastrous Perl 6 was well before they think about anything positive involving Perl 5.
From a practical usage standpoint, sure. But wouldn't you agree that an effective major version freeze has had a chilling effect on the progression of the language?
I'd argue it's had a deleterious effect to varying degrees, even since 2006. It's not enough for a community to be not bothered. They need to be energized, and it's tough to make the argument that the perl6 snafu has been helpful to the perl movement.
> CPAN uploads have been up every year since.
CPAN traffic was down over 10% last year, according to Alexa. In fact, many perl popularity metrics were down at least 10% in 2013. [0]
My experience, admittedly anecdotal, is that CPAN packages in general are not maintained with the same vigor as in years past. But why would they be, if people are moving their focus to other languages?
Regarding Moo, thanks - I'll definitely have a look.
2006 is when the energy around perl5 / new wave of cpan development became palpable to me.
Have a look at Task::Kensho - you'll find a fair chunk of the stuff mentioned in there originates from 2006-2009 or so (and has been actively developed since).
> My experience, admittedly anecdotal, is that CPAN packages in general are not maintained with the same vigor as in years past. But why would they be, if people are moving their focus to other languages?
That or the CPAN packages you've been using have been superceded but you've not found the replacement.
We're fairly terrible as a community at communicating when that happens.
The argument for Java is that there is a wide developer base, and lots of libraries. Perl, with appropriate frameworks, can be remarkably typesafe too (see Moose, etc). It's still loosely typed under the surface, but you have good error handling of invalid type syntaxes as long as you don't break encapsulation.
The big things I am looking at though are:
1. Maintenance and testing.
2. Readability
You can write unreadable crap in any language. What Perl excels at is allowing you to improve readability and maintenance/testing by building mini-dsl's in your framework which reduce testing footprints.
I work on legacy Java code bases every day, where I see thousands of lines of code all to just simply set and read variables.
I'm not sure how that's even remotely described as readable.
Unfortunately, it's productivity gained at a very high cost, which becomes apparent once you try to debug and maintain that piece of software.
Sure, Moose and other modern helpers will fix that to some extent, sometimes with other tradeoffs (performance). But the "malleability" of Perl feels silly at some point where you get a bloated, slow and lacking simulation of a type-safe language when you could use a much faster modern language with real static type checks and great maintainability (like Go) instead.
You can write untestable, unmaintainable software in any language. I will agree with you that the default scoping of variables has some real costs in terms of maintenance and debugging that are not initially apparent to too many programmers though.
> Sure, Moose and other modern helpers will fix that to some extent, sometimes with other tradeoffs (performance).
Moose has performance impacts. If you want something less heavy, use Moo, or Role::Tiny. These offer fewer features and better performance. Also as I recently learned, lexically scoped variables are faster, so use strict can in fact sometimes flag possible performance improvements there.
> But the "malleability" of Perl feels silly at some point where you get a bloated, slow and lacking simulation of a type-safe language when you could use a much faster modern language with real static type checks and great maintainability (like Go) instead.
To be honest, the other languages I really like in this regard are red and rebol, which are, if anything, more malleable. The malleability is important because, done properly, it allows:
1. Better testing
2. Better readability
3. More concise code
4. Code that is more self-documenting.
You need coding standards for all languages. Most (afaik) Perl shops use Conway's "Perl Best Practices" with some local changes. Go read "Modern Perl" etc. Are you not aware of those developments? PBP isn't exactly new.
I don't think there are references of these problems while following good practices? Considering all the trolls which show up when Perl is mentioned, I ought to have seen such a link a long time ago...
But sure, we could assume without support (I don't know) that using Perl forces you to read a few more pages of coding standards. That is, as percentage of work time over a long project, not a problem.
>> [Go preaching]
Today, I don't see much practical difference among the usual scripting languages (they tend to port the successful stuff from each others). Also their niches are partly different compared to the niches for Go. So there is no need to preach.
One big advantage with Perl is that I am not often embarrassed by fan boys and/or language war fanatics, as you find in some other environments...
Edit: Readability.
I've never seen a project that could enforce its coding standards in every case. Things always slipped through. Turns out, machines are much better at enforcing arbitrary coding standards than humans. Maybe we should let the machines do the machines' job, and the humans do the humans' job.
Perl has all the problems of an old language. No commonly-agreed on coding style (you'll get flamed to a crisp in some parts for even talking about Modern Perl), no single object framework (Moose, Class::Accessor, Object::Tiny, Role::Tiny, and plain old "inside out object." References are confusing and unnecessary (neither Python nor Ruby needed to make an artifical distinction between references and non-references). All the various different ways that things can fail at runtime are a huge burden, especially when you combine them with the different modes that perl itself can be run in, like "use strict" versus not.
Just about the only thing Perl did right was regular expressions. That, and avoiding the version hell that Python got itself into.
Perl was fun in the early 90s, but it's time to let go. Only a masochist would use it today. Only a sadist would recommend it to newcomers.
Two points in this. You might not want to ban all 99 in all cases. For example, you may want to do things one way in one aspect of a project and a different way in a different aspect.
This sounds dangerous (and power is dangerous), but done right it allows teams to focus on doing things right with the right interfaces between them.
For example, it's one thing to contribute to Moo, Moose, and PGObject in one way, but have a different coding convention internally for the programs which use these libraries. This is where those other 99 ways really come to be powerful.
> Why would you use a language if you don't agree that the designers did a good job?
I like the design of Perl 5. However, it took a lot to get to the point where I saw the beauty in it, and saw how to use the power properly.
In a larger project however, that's not so much of a problem. Once you get the core code started, people can grow within it. Different levels of the project may handle things differently, and that's fine. People can branch out over time.
> I've never seen a project that could enforce its coding standards in every case.
And sometimes the responsible decision is to let the coding standards violation occur and plan to fix it later. There are times I have done that and regretted it, only to later realize it was a net positive anyway.
> Maybe we should let the machines do the machines' job, and the humans do the humans' job.
Absolutely. Now to tell which is which.
> Perl has all the problems of an old language.
Evidently every 5 years or so we need to all jump on the bandwagon to a new language?
> No commonly-agreed on coding style (you'll get flamed to a crisp in some parts for even talking about Modern Perl), no single object framework (Moose, Class::Accessor, Object::Tiny, Role::Tiny, and plain old "inside out object."
There are lots of object structures but you probably shouldn't list Role::Tiny there. The basic point there is you have Moose, of which Mouse was an attempt to make it smaller for performance sensitive applications (now largely superceded by Moo). Role::Tiny is an attempt at a minimalist piece of Moose aimed at specific applications. Moo/Moose/Role::Tiny are best thought of as aspects of a single object system rather than separate ones. In fact Moo and Role::Tiny were authored by the same individual.
The Perl world has largely gone to Moose and friends. Pretty much everyone that uses anything else does so for legacy reasons or external constraints IME.
> References are confusing and unnecessary (neither Python nor Ruby needed to make an artifical distinction between references and non-references).
And yet I have been bitten by the lack of such a distinction in Python.
> All the various different ways that things can fail at runtime are a huge burden, especially when you combine them with the different modes that perl itself can be run in, like "use strict" versus not.
Meh, my test cases in any language use up more code than my production code anyway. There is no substitute for clear code contracts.
Not only languages, but every other technology as well.
After all, people need to sell:
- tooling
- trainings
- books
- consulting work
- write blogs about cool stuff
- and the most important one, sell certifications
Because the real world comes with edge cases. Just because 99 times out of 100 you're better off with the agreed upon standard, doesn't mean that other way doesn't have it's distinct time and place that it can shine, and clearer, cleaner and or faster. I would much rather be constrained by convention than by capability.
no single object framework
No, but the reason for that's been a good one historically (experiment and see what comes out on top). That ended up being Moose and it's ilk (Moo, Mouse). I can't think of a single case I've heard about where people used something else and it wasn't driven by some external factor.
References are confusing and unnecessary
I've always liked references. It seems to make clear exactly what's going on. Maybe it's just me.
You should have started your comment with this. Then I could have stopped reading there. Are you here to participate in an informed and enlightened discussion or to show everyone how brilliant you are for not liking something?
Perl references combined with its nested list semantics make it extremely convenient to flatten arrays and hashes when you need to. Doing the equivalent in Python and Ruby is verbose and ugly by comparison. I know in Ruby you can get it down to one line, but it lacks the cleanliness of Perl (if you can believe that).
[[1, 2, 3], 4, 5].flatten()
This is also true of C++. People write useful software in it anyway.
You can get it in dead tree from amazon or free (beer) from the author's website http://hop.perl.plover.com/
I am not saying it's not an appropriate tool for anything else. But as a tool to be learnt, it wouldn't be the 'best' tool for a new person to learn from scratch.
Except for parsing text files :)
> parsing text files is literally the only thing Perl is the best tool for
To be honest, Ruby has built-in regexps also and Rebol has built in recursive descent parsing (and has no regexp support at all). So I disagree with you on two counts, the first is that Perl is the best tool always for parsing text files. To some extent it depends on what you are doing.
What I do think that Perl is really good at is building frameworks and the reason here is that what you can do (and what I highlighted in the article) is create mini-dsl's for common tasks which can then be seamlessly worked into the general purpose programming environment. Lisp can do this too, as can Rebol, but these each have other tradeoffs (I found the Lisp learning curve to be rather steep, Rebol 2 is not open source, Rebol 3, though open source, is still in alpha, and has no Linux GUI support yet).
> But as a tool to be learnt, it wouldn't be the 'best' tool for a new person to learn from scratch.
I don't know that there is a best tool for a new person to learn from scratch. One should generally apply tools I think with an intent of doing something with them. IMO, Perl excels at very big projects and very small projects. It's in the middle that things get less than ideal.
Just to note that the first beta version of the Linux GUI for Rebol 3 was released a couple of weeks ago - http://atronixengineering.com/downloads.html
Edit: It looks like that is Saphiron's repo, not the main one, so still waiting on it becoming an official build, I see :-P
Here's the Atronix announcement - http://rebol.info/altme/105/announce#msg0688
I believe you can consider this as the official build for Rebol3 View/GUI because Saphiron took over the RebGUI/R3-GUI project from Rebol Technologies.
But yes some of the Rebol 3 Core stuff that Saphiron/Altronix have done do need merging back into main open source core [1], which itself as moved on from the Saphir codebase (Saphiron Rebol build) [2].
[1] - https://github.com/rebol/rebol
[2] - https://github.com/saphirion/saphir
Also see Rebolsource repo where lot of the community changes go before merging back into [1]. Ref: https://github.com/rebolsource/r3 | http://www.rebolsource.net
PS. I know that you're aware of some of this info. Posting for the eyeballs of others :)
* Some of the best languages for producing an internal DSL (dialects) don't have a "native MOP". For eg. Lisp, Rebol or Forth.
* Python & Ruby don't have native MOP's anyway :)
NB. I wonder what you mean by "native MOP" is baked-in OO? Python & Ruby OO systems do come with MOP like abilities. However for full blown (metacircular) MOP (http://en.wikipedia.org/wiki/Metaobject#Metaobject_protocol) you need to look at things like CLOS & Perl's Moose/Class::MOP.
To clarify things:
* Python comes with a pre-defined OO system with metaclasses/descriptors for dynamically building new Python classes/objects.
* Perl comes with OO lego blocks from which you build you own OO system.
* Class::MOP is a metacircular MOP mainly written in Perl using these lego blocks (it's turtles all the way down).
* A MOP (like Class::MOP) provide an API for building & managing extendable OO systems.
* Moose is an advanced OO system built on Class::MOP.
* Moose provides features like Roles, Method Modifiers, lazy attributes and many more.
There have been two attempts, that I know of, to bring (a subset of) Moose to Python:
https://pypi.python.org/pypi/bullwinkle/0.3.6
https://pypi.python.org/pypi/elk/0.2
For something comparable to Moose/Class::MOP then have a look at CLOS (Lisp).
Why would you say that?
It seems to me that a DSL's function is at least reasonably decoupled from the method it uses behind the scenes, and that there is no real difference between a native MOP (like that in CLOS -- I don't really see an equivalent in Python or Ruby) and a non-native one like Class::MOP in Perl in this regard.
It helps you strip out code that isn't related to the DSL. For example, the mechanisms of class definitions in things like MongoEngine or Django's ORM. You end up with something that looks a lot more declarative.
the additional context involved with knowing Perl isn't enough IMHO to learn Perl just to parse text. I would do that with a 'more popular' language and its regex library, especially for new users.
Why Perl really shines for text file parsing is that you have a fairly large set of tools as appropriate, which fall into largely three categories:
1. regexps (great for some things, lousy for others. DO NOT use these for parsing HTML)
2. Recursive descent parsers. You could write an HTML parser in one of these if you need to.
3. Dedicated format parsers (CSV, XML, JSON, etc).
It's the combination of the three that makes Perl a very good tool for parsing text files. One thing going for Perl is a strong community of people who can help point people to the right tool for the right job.
For example, I am in the process of writing a library to do PostgreSQL tuple parsing and serialization. It is sort of like Text::CSV with some differences. In this case, regexps are the right tool. But if I was writing something else, I would probably go with recursive descent.
Have you tried Haskell?
Anyway, Perl referencing an deferencing syntax is a mess. I regret any time I start a new program on it, as it always lead to a long debugging session where I remove all the parse errors. I use no other language with a syntax as complex (and can't really remember of any).
What a terrible language!
I don't know Python very well. I've worked on some python code but every time I do I have go read the manual for the most basic stuff (what does an "if" statement look like in Python, again?). But I wouldn't ever dare to blame Python for the fact that I don't actually know it!
It's not too bad. It is amusing however to see someone with twelve years of experience doing something like: somefunc(\%$someobject); Um, wtf?
I personally found the reference/dereference syntax close enough to C's I had no trouble with it but far enough away I didn't get references and pointers confused.
These days I'll drop into coding in Perl for the regex syntax and backticks. But the reality is there's not much difference between it and PHP in terms of features. Used to be that it was better than Ruby because of performance and stability but they're about par now. So I don't think there's much point in evangelism or debate about Ruby vs Perl vs PHP or even Java anymore because they all get the job done in pretty much the same way. From a practical PoV I'm more interested in languages that actually do something well that other languages suck at e.g. node. I wrote a FSM/Long Polling web server implementation in Perl using epoll() before Node came along and now I love node more than most (and still wear the scars from a particularly tough hashref autovivification bug).
As an infrequent perl programmer[1], I'm curious about the bug. Googling tells me that perl if($foo->{bar}) will always pass, which is pretty goofy to me. Was it something like that?
[1] Well really, a bad perl programmer. I've occasional had to make minor edits to legacy perl. I don't write perl. And, as the mistake in this post shows, that's probably a good thing :)
# False, key doesn't exist, doesn't print and doesn't create anything at that key location
my $h;
say "foo" if $h->{foo};
# Creates an empty hash ref at $h->{foo}, so $h->{foo} now evaluates to true in boolean context.
$h->{foo}{bar}
# True, prints "foo";
say "foo" if $h->{foo}
# creates empty hash refs at bar and baz.
say "what does this do?" if $h->{foo}{bar}{baz}{quux};
Personally, I find once you understand it, it's fairly easy to guard against (even if it requires more code. e.g. say "foo" if $h->{foo} and $h->{foo}{bar}; # Assuming we know $h is a hash ref already.
Edit: Typo and code block formatting
no autovivification;
One of the things that's always impressed me the most about Perl is the degree to which modules can play with the language. Modules can add control structures (Try::Tiny), introduce new metaprogramming syntax (Moose), add operator overloading (overload)... it's very flexible.
That's exactly the point of the article, btw.
> Modules can add control structures (Try::Tiny), introduce new metaprogramming syntax (Moose), add operator overloading (overload)... it's very flexible.
Technically they add functions, and the language allows you to use imported functions as control structures. This isn't so much to correct you as to clarify it for less familiar readers.
if (exists $foo->{bar}){ .. will not run .. }
if ($foo->{bar}) {...}
if (exists $foo->{bar}){ .. will run .. }
if (exists $foo->{bar}){ .. will not run .. } if ($foo->{bar}->{baz}) {...} if (exists $foo->{bar}){ .. will run .. }
I am certainly a perl novice.
Are the Perl internals as pathological as PHP?
Basically to describe the relation between perl and PHP, take all the good things out of perl 5.005 and you're left with PHP. Perl's internals to my knowledge are insane in a mad genius kind of a way. I would imagine that PHPs internals are pathalogical in a 'tramp smelling of urine' kind of way.
Despite that, it's also a relatively practical and reasonably popular language (else it would end up among esoteric languages).
The very richness, intricate ornamentality, flamboyant conceptual exuberance and non-orthogonality that make it an art object also make it unsiutable [for me] for real development. I like my tools compact and precise.
I don't know what this means
In the U.S., there is no such requirement. Anyone can "be an engineer". Now that I work in the US, I call myself a software engineer or a software developer or a programmer, as interchangeable terms.
If there is an actual distinction here I would really like to know it. I also wonder how much these terms may have different meanings in other countries/regions.
At my company (fairly big - Fortune Global 500) I'm pretty sure they have different meanings in different product teams.
Perl 5 is an abomination.
It helped me enormously in understanding the philosophy behind Perl.
What makes you call it an abomination? I'm not a big fan of the language, but I have no idea why it'd be worse than Perl 4.
First, there are two ways to read that last example:
1. Literally as Perl code: has() and dbmethod() are functions. There is no difference between
has id => (is => 'ro', isa => 'Int');
has(id => (is => 'ro', isa => 'Int'));
2. as language extensions: has and dbmethod define new aspects to the class in a declarative way.
The thing is, these are both simultaneously true, and that means you can read them as #2 when coding and fall back to #1 when debugging.
Since they are simultaneously true, there's no difference between writing new functions and what we do here, except that this allows (and does not require) one to think about the code in additional ways.
As a note, exactly what people I know like about working with Lisp on large projects is the mutability and the ability to create very useful and readable idioms for the project.
That wasn't his own language features, he used Moose in the last example, it is the standard OO environment in Perl. To simplify a little, most new Perl code use Moose.
The author did discuss a bit how Perl is extendable, which is where Moose comes from.
One thing to note is that this was done specifically in the way it was so that it would fit in with Moose-like idioms, so it is more a matter of extending the Moo(se) way than it is creating a whole new idiom.
here are lines from the article to summarize it
"The .. point is that Perl 5 gives you a way to build .. (DSL's) that can be seemlessly worked into a general purpose programming environment."
"Perl is a language many people love to hate. Here's an example .. of sloppy coding"
"It is very hard to modify safely."
"it is possible to do this sort of thing in any language."
"Let's try this newer Perl code"
"This .. is easier to maintain, and is easier to understand."
"The above two examples ..neither one really shows what Perl is capable of doing"
"Perl itself is a highly malleable language and .. allows you to define domain-specific languages for parts of your program"
"Here's a small class for handling currency records."
"Now the code above .. is effectively entirely declarative."
"What differentiates the examples .. is .. readability, testability, and maintainability."
"How does that work?"
"Perl is a very flexible .. you can add functions that behave .. like keywords."
"The example here uses two modules which provide DSL's for specific purposes."
"The first is Moose"
"The second is PGObject::Util:DBmethod"
"Why is this Powerful and Productive?"
"Compare a framework built as a mini-DSL specification language to one built as an object model."
"In an object model framework one .. has to juggle object-oriented design .. with the desire for greater flexibility."
"DSL's .. allow you to define the object model orthogonally to the framework"
"Other Similarly Powerful Languages"
"Lisp"
"Rebol and Red,.. implementations are still very immature"
"Metaprogramming helps to some extent..in Ruby and Python .. but .. makes it much harder to build a framework that is truly orthogonal to the object model."
" Perl isn't just a programming language, but a toolkit for building programming languages inside it. "
To clarify this…
1) Rebol 2 is a very mature product. But while free to download & use it remains closed source with no long term future.
2) Rebol 3 is an alpha/beta opensource rewrite of Rebol 2. While Rebol 3 isn't has mature as Rebol 2, it is robust and does run about 2 times faster than Rebol 2 and with other significant design & implementation improvements. However it is incomplete and missing some Rebol 2 features.
3) Red could be viewed as "very immature" because the implementation was only started in 2011. However it is looking very promising and I believe the aim is to get to version 1.0 by end of this year.
One cool bonus that mojo provides is hot deployments, so there's no need to restart the server process to get new code.
One of the neat things you can actually do in this environment (we do this for old code we inherited from SQL-Ledger due to scoping issues) is preload dependencies, then when a request comes in, fork, execute, and die. This allows you to fairly easily run fcgi-unsafe code in a fcgi environment caching what you can safely cache and disregarding the rest.
This can be a big deal for improving performance of legacy cgi code.