Exegesis 7 Released (Perl 6 Text Formatting)
chromatic writes "Perl.com has just published Exegesis 7, Damian Conway's explanation of how text formatting will work Perl 6 (and now, Perl 5, thanks to his Perl6::Form module) will work. Think of it as Perl 1 for the 21st century. Also, Parrot 0.1.0, the virtual machine for Perl 6 and several other dynamic languages, released on Leap Day -- ever wanted to program in an object oriented assembly language?"
I just couldn't wrap my brain around Perl.
I ended up giving up and learning Python instead.
Background: 28/M/Bi-Sexual; Owner of a Linux company; MBA Harvard 2003; B.S. Comp Sci MIT 2000
lots of lame jokes about Perl code being incomprehensible despite the fact it can be the most readable.
One of the reasons I love Perl (cut my teeth with Perl 4, now write a lot of Perl 5 code) is that it is a virtual swiss army knife of programming languages. There is a lot of power in there, but you can choose to use only as much as you might need. The "TMTOWTDI" ethos also appeals to me. And, in reading the updates on Perl.com, I see that this exact same spirit is going into the creation of Perl 6.
.NET announcements and said, "Hmmm...multiple programming languages that all compile down to the same bytecode and execute in the same virtual machine...sounds like a reasonable idea to me!" The Parrot VM is a neat idea, that goes even further than .NET since it's multi-platform, and definitely will be very nice when it's finished. But I feel like it's going to delay Perl 6. And as nice as Perl 5 is, languages like Python and PHP are beginning to surpass it in feature set and ease of use. I don't want Perl 6 to be irrelevant when it finally shows up.
So why am I worried? Well, it feels like Larry saw Microsoft's
Also, like a very impatient, immature kid on December 23, I want my Perl 6 now, damnit!
But, I trust the Perl 6 team. They're smart people. Read the newsgroups and the forums, and you'll agree. When Perl 6 and Parrot are ready for prime-time, I am pretty sure that I won't be looking over at Python and PHP and feeling guilty anymore.
Ah well, back to coding...
Blogging Weight Loss, Distance Education, and more at verlin.com
You know, I'm not very big on perl coding, but I do really like the language. Your point about never having gone with the best methods of coding is something I noticed however.
I too wouldn't put perl as a "technically" best way to code ANYTHING, but it is however an intensely easy and powerful set of hacks, joined together quite well, and with a consistency that matches my own disorganised brain!.
I'm good for that. Getting something technically 'correct' in the coding world seems to me to be revolved around far more efficient use of resources and cpu speed than perl does. In my job however we have thousands of fast PCs, and only so many good coders. I go for whatever supports the coders, and for many of us that's perl
webalizer stats. thousands served monthly
I am sure something is coming down the pike, but making a huge announcement like a major rearchitect puts a lot of developers in suspended animation - unwilling to invest more time mastering and extending the "end-of-life'd" perl 5. Many of those people are now looking at other options.
As an aside, I'm not sure where the consensus is coming from for the new language proposals - the code samples in Larry and Damian's writings are becoming more and more cryptic. I wonder if they are making perl 6 to unapproachable by new coders.
I know you are trying to be humorous and all... However, I feel this needs to be said...
:)
With Perl, you can make the script/program/module as beautiful as you want, or as ugly as you want. Just to contrast with Java, Java forces you to be verbose -- very verbose. People claim that it makes them productive and it leads to maintainable code, but too much verbose code can be very confusing. With Perl, you have a choice of coding style, but there is no choice with respect to verbosity in Java.
There are places where clear, concise expression is useful. The tradeoff is that the readers have to have the vocabulary to comprehend what is written. Very few people complain "Gee, that guy writes in complex language, it is unreadable." Likewise, reading well written Perl code requires some familiarity with Perl.
Regarding how things look to unfamiliar people, try to look at a screenful of the most beautiful poetry (just pick a language that you are not familiar with -- may be Chinese, some Indian language), and then look at Perl code
S
Then there are the practical issues - will Parrot be fast enough and mostly bugless in time for Perl 6 to sit on top of it? I am concerned that we will need eighteen months of point releases and we haven't even had an alpha yet. Meanwhile people are looking at Ruby, Python, Mono/C# etc.
I recommend they just wrap up whatever concepts they have now and start moving toward an alpha. If we don't see one in 2004 I think most people will have moved on.
... ever wanted to program in an object oriented assembly language? ...
God no. It's bad enough when a high level compiler attemps to guess what you want (C++, etc)... it'd be horrid if ya had to have something supposedly machine level guess...
That's what Parrot is. Python and Ruby (as two examples) WILL be able to target parrot and run in the parrot VM.
Those are the promises of Parrot developers. It is however not that hard (but less wise) to get excited about promised values. It is better to get excited about delivered promises...
.net is barely limping along. Maybe there is more to this high failure rate...
Parrot is not the first try at this "execution machine" model, and I suspect not the last one either. The only ones that survived (so far) are the ones that target a single language. Python, Java comes to mind, while mono and
At the same time it would be really exciting to see the birth of the first SUCCESSFUL cross-platform execution machine...
Code poet, espresso fiend, starter upper.
Perl is the most beautiful language I've had the pleasure of learning. Lots of folks complain that perl must be ugly since it's so easy to write really butt-ugly code in it; but it's also very easy to write mindblowingly powerful, clear code. Enough thought has been put into the language design that you can abuse most aspects of the language and still get what you wanted.
It's easy to forget, when using perl, just how, well, tedious, it is to work in C (let alone C++) or shell or Java or even, yes, Python.
The exegeses so far have been full of fabulous goodies to use and abuse. The main problem, as others have pointed out, is that perl6 is still largely vaporware.
After reading through a lot of this article and being blown away by the genuinely powerful and, dare I say it, awesome abilities that have been given to the form function, I'm left asking myself:
... that's all it is, some geek's personal project that doesn't really seem to have much relevance to the real world.
"Who gives a crap?"
Most the projects I've worked on for the last few years have predominately displayed text in web pages. Almost all the reports produced have been generated as HTML and then printed as necessary. The only text output done has been generally into log files, where you really don't need a lot of formatting.
While this is obviously a really great, well thought out piece of coding,
Maybe I'm just missing a huge community of people who spend most of their time looking at command lines and printing out reports in fixed width fonts.
The new Perl "form" stuff sure seemed familiar for some reason, but I couldn't figure out why. Then I figured it out .... anyone else remember the "print using" statement in BASIC ????
Are books confusing to you? What does it mean that verbose is confusing, verbose can not be confusing. That's why AppleScript is not confusing, it is designed for new programmers and extremely verbose.
The reason why perl is confusing is partly because of the $, @ etc... and partly because you use regular expressions all the time even though it is not needed. Regular expressions can be useful sometimes, but in general it makes the code unreadable. In addition, the variables like $_ $: $; $] $[
Trying to defend the perl even though these obvious problems may be good on slashdot, hovewer if you look at people in the industry and education, many people don't consider perl to be a serious language. That's a scripting language, like VB and VBA and people use it for that purpose only.
Just because you say that perl is easy to read or write on slashdot will not change the problems. So even though you don't realize, what you are doing is actually hurting perl.
(missing a huge community etc.) many, many projects need the ability to write in fixed-width fonts to a printer, p.ex. the output of your supermarket cashier ticket / credit card ticket. This is a real world-class application to formats (because those little printers are best suited to the job and they write in monospaced). There are others, many, many others.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
> Java is boring, but uniform, and much more suited to large projects.
Agreed. Of course this makes Java the new Cobol... am I the only one that thinks this?
Yes, it's dependable. Yes, it's good for large scale projects. But God yes, it's boring.
With Perl, you can make the script/program/module as beautiful as you want, or as ugly as you want. Just to contrast with Java, Java forces you to be verbose -- very verbose. People claim that it makes them productive and it leads to maintainable code, but too much verbose code can be very confusing. With Perl, you have a choice of coding style, but there is no choice with respect to verbosity in Java.
Other than your suggestion that Java code's "verboseness" makes it confusing, what you describe is exactly how things should be.
Java is highly maintainable precisely because it doesn't employ a "there's more than one right way to do it" approach. That is why it is so suitable to distributed projects, multi-programmer projects, and in fact, why it is used in a lot of large open-source projects.
Perl is a glue language designed to be used for short programs that perform useful tasks for an individual programmer. For such purposes, archaic structures and code conventions are perfectly acceptable. Can it be used for other things? Sure it can. COBOL can. PASCAL was. Doesn't mean that it is the best tool for the job, by the way.
Maintainable code isn't produced by a desire for self-expression. It is produced by following conventions. Java platform code has been described as "self-documenting" precisely because it lacks shortcuts that create obscurity. Of course, no code is REALLY self-documenting, but Java code comes darn close.
Please note that I am not knocking Perl. I use it myself and it is very useful for the things it does well. You should not, however, compare peas and apples. Perl is not comparable to Java. The languages are designed for different purposes and their structures and means of writing source for those languages reflect those differences. Perl was designed to be a super-shell language. Java was designed to be a net-ready systems and application programming language. Different purposes make for different languages and platforms.
In Perl, the airbag is off by default. You have to type "use Airbag;" at the top of the code to activate it.
You know whats worse than object oriented assember? A large PHP project. Dont you love global() and lack of scope?
Perl is more maintainable, and faster than PHP when comparing apples to apples. Perl has more available modules, and they actually work! PEAR had admirable goals but fails miserably because of the terrible code quality and documentation.
mod_perl lets you write apache modules in perl, thats an unbelievable win over writing PAGES in php. Then again, most web professionals dont seem to understand that distinction.
I think PHP is a dying language, almost everyone I know that worked with PHP when version 3 came out has moved on to other languages. The language is broken by design and everyone realizes it sooner or later.
And you claim that a page of full blown Java code, complete with classes, initializations, templates etc. is easier to understand than a quasi-functional transformation (as it would have been written in Perl). Well, duh.
$a = $b + $c;
Even if you know what + does, the semantics of the above statement are still not defined anywhere. Which of $b and $c is evaluated first, for example? (And yes, it does matter, consider tied variables.)
The fact is, Perl is defined almost entirely by its implementation - there's no way you could start with the current manual pages and write a different implementation that would be compatible with most code. There's far too much DWIM which is not clearly defined anywhere.
-- Ed Avis ed@membled.com
There's far too much DWIM which is not clearly defined anywhere.
Seems to me that this is more of a problem with the language design than a problem with the documentation-- most operations are somewhat ambiguous when used in odd ways (like trying to add two strings even though the manual clearly states that + wants to add two numbers). Do you really expect the docs to attempt to cover every possible thing that might happen as a result of using the + operator? Personally I'd prefer the language throw an error if + isn't a defined operator for the data types in question, but Perl will happily convert your string to a number (which is amusingly bad, because if the string contains digits, you get a number, if the string contains letters, you get nothing).
By the way, the POD page mentioned 'perlop' clearly states that + is performed left to right. There is a whole section at the very beginning that talks about associativity and precedence.
I do not have a signature
Maybe they all go off and become Perl programmers instead of going to grad school?
But seriously: academia has very little room for people with interests like Damian's. Academia does not encourage the kind of research that would make professors better teachers, instead the research should be as esoteric and far from undergrad subjects as possible. And grad students who like to "hack" are told to get over that impulse despite the fact that it would probably make them better teachers.