in reply to Perl6 syntax being too much complex? How we will teach and read that?!
As you point out, perl5 has a complex syntax when compared to many other languages, which makes for a steep learning curve when you start out. but, if you persist long enough to get over the initial hump, the dividends are immense.
As you also point out, for many (most) programming tasks, a program that takes hundreds of lines and days to write in C, C++ or Java, takes only a few lines and a few hours (if that) to write in perl 5.
The question you have to ask yourself is why? Why is perl so productive when compared to those other languages with their simpler syntax?
I've personally thought about this a great deal. The conclusion I have reached is that the reason is totally down to that complex syntax, and more to the point, the design of that syntax. The syntax of nearly every other computer language was designed from the point of view of making it easy to parse. That is to say, easy for the compiler/interpreter to parse. This makes the process of writing the compiler easy for the developers, and means that they can produce great statistics of how many 100s or 1000s of statements they can compile per second. But it also means that each statement is only capable of doing very little work.
That means for any given task, the programmer must construct more statements. More statements means more opportunities to make mistakes. It means longer programs, with the active life of each variable in the program stretching over a greater physical distance within the source. I've read several studies that claim to show that the average human being can hold just 7 concurrent thoughts or ideas in their head at one time. With longer source files, and bigger physical distances between a variables instantiation and it's last use, the room for the programmer to forget a detail or loose sight of the direction of the code grows.
IMO, the power of perl 5 is that it's complex syntax means that each statement does more, and therefore requires less statements. Whilst each individual statement may require more thought to construct correctly, because in many cases, each statement, or closely grouped set of 3 or 4 statements completes an entire, complete part of the overall program, the programmer is able to concentrate on that without needing to scroll back and forth or dive off to lookup the syntax of yet another obscure API. That means that when he has finished or line, or a group of lines, another complete part of the program is finished. And that is the source of perl 5's productivity.
When you learn Perl 5's complex syntax, you are also learning a vast part of what other languages defer to their runtime libraries or API sets. If you never installed or used one CPAN module, you can still write a huge number of useful, productive programs. CPAN is the icing on the cake. Most other languages require their (usually extensive) libraries to be able to do anything useful at all.
The complex syntax, and the careful design that went into it is in large part exactly why perl is so productive. Moreover, when I say careful design, I don't mean "complying with some overarching, elegant master plan of orthogonal purity". I mean careful design in the sense that "Many programs and algorithms call for the programmer to do XYZ, so lets ensure that doing XYZ is not just possible, but as painless and concise as possible".
In other words, Perl 5 was design for the programmer, not the compiler.
If you can accept that the complexity and learning curve involved in getting up to speed with perl 5 is a huge part of why you like using perl 5, then look again at the Apocolypsies, Exogesies and Synopsies that have come out for perl 6 and look at the care that is being taken to ensure that each part of the language, both the completely new stuff, and the revisions and re-working of the old stuff all meld together to produce a syntax that will continue the p5 traditions of letting you do what you need to do, as concisely, and with as little syntax as possible--once you get over the learning curve.
I'm not one for going on faith, nor of accepting something as good, just because someone tells me it is so. There are still areas of p6 that worry me somewhat. But each time I read one of the documents, I try to look at how it would change the way I write code to perform tasks that crop up in many of the programs I write. So far, with the minor exception of the new format stuff which I have barely ever had occasion to use what it replaces, I've seen how what is being proposed would simplify, clarify or otherwise enhance stuff that I currently write in p5. I watch as, one by one, each of the annoyances that crop up regularly when writing p5 code are being addressed.
So, faced with the choice between learning say, Java's "simple syntax" and various (incompatible) and huge libraries, or (re-)learning Perl's complex syntax that is going to allow me to do even more in each statement; write even less lines of overall code; and never have to learn to fight my way through the a huge "Standard Library" before I can write powerful, useful programs; I opt for the latter.
|
|---|