Slashdot Mirror
Perl 6 In Time For Next Christmas?
An anonymous reader writes Larry Wall has reportedly announced at Fosdem that "Perl 6 Developers will attempt to make a development release of Version 1.0 of Perl 6.0 in time for his 61st Birthday this year and a Version 1.0 release by Christmas 2015." From the article: "There is going to be the inevitable discussions, comments and probably some mileage from detractors to come. However ever were it so, for us in the Perl Community these are quite exciting times. We have two strong languages and a strong community, I think there is a lot that binds us together so here's looking forward to Christmas."
Perl's strength is that it's expressive. It's not a language which is easy to learn or which generates heavily optimized code.
In the demo phase, you're not really worried about performance. The goal is to have something showing as quickly as possible, and not worry too much about how fast it runs, or how much memory it takes. Overspec your demo system for the time being (ie - make it really fast and install lots of memory), and once you have a reasonable interface go back and recode it in a simpler language which can be more easily optimized.
Languages which are simple to learn (c++, for example) are generally not very expressive. You end up spending tons of time debugging issues of memory allocation, library interface details, and datatype conversion.
Expressive languages are harder to learn, but any individual line in the expressive language does a lot more. Since you are writing fewer lines, and since the fewer lines do more, you end up making programs more easily and in less time.
Yes, the programs will execute a little slower, but as mentioned, this is not important in the demo stage. Your productivity will be much higher. And there are lots of places where performance simply doesn't matter. Scripts usually fall into this category.
Perl was designed by a linguist, not an engineer. As such, it's harder to learn (it's got tons more keywords and context), but once you get the hang of it coding is much more efficient. The following single line:
@Lines = sort { $a->{Name} cmp $b->{Name} } @Lines;
unfolds into several lines of C++, plus a subroutine definition with datatype definitions. The following line:
@Files = <c:/Windows/*.exe>;
can be implemented using one of over a dozen possible library calls in C++, but is builtin in perl. You don't have to look up the library call interface specific to your system.
And note that writing unreadable/unmaintainable code is an aspect of the *coder*, not the language. If you disregard perl because "other people use it to write poorly" you are probably one of those people, in which case you should avoid coding altogether.
Also I'll be enjoying (really, not sarcastically) years of using Perl5 and Perl6 in the same file due to the easy integration between the two, replacing that part of Perl5 that was ugly at my leisure, or not, and still having things work.
I really like this language a lot.
Someone had to do it.
... replacing that part of Perl5 that was ugly at my leisure, or not, and still having things work.
I actually did that about 15 years ago. I switched to Python, then transliterated all of my Perl code into it.
BTW, it was remarkable to me at the time that in every case of transliteration, the resulting Python files were smaller in terms of both number of lines and number of bytes. Then I realized that since the two are semantically similar in so many ways, Python's lack of braces was a big advantage in terms of code compactness. To be fair, though, I never was one to pack as much code into a single line of Perl as possible. Which is, of course, why I prefer Python: it was never designed for that sort of thing.
I actually find Python 2.6.x to be nearly perfect. The fact that it won't be getting any new features, only bug fixes, is actually one of its very best features for me.
In contrast, Python 3 has always seemed to me to be Guido indulging himself in whittling down the "Python warts" list. Although Python 3 is objectively better in many ways, the improvements don't seem compelling enough to me to bother to really learn, and porting code to it - even with the help of the automatic conversion tool - likewise doesn't seem worth the trouble. And I still kindda like "print" as a statement.
I do take some satisfaction, though, in the fact that Python 3 became the sort of technical success that Perl 6 never was, and never will be. To be fair, I think Guido drew some important lessons from the Perl 6 debacle, the most important of which was to make changes around the edges rather than try to totally reinvent the language. See Gall's Law:
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
Then again, there was much less need to reinvent Python.
To be clear, what I meant to say is, I only have to rewrite those portions I feel like rewriting: you can use Perl 5 from inside a Perl 6 file pretty painlessly these days, as long as you aren't looking for heavy performance or too much complex async. Perl 5 and Perl 6 are considered more "sister languages" than a necessary upgrade, with Perl 5 continued to be maintained and even developed.
Someone had to do it.