Exegesis 7 Released (Perl 6 Text Formatting) 319
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 tried, but I failed (Score:1, Insightful)
I ended up giving up and learning Python instead.
I predict... (Score:3, Insightful)
Perl 6 is hugely ambitious, and that worries me (Score:5, Insightful)
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...
Re:Finally, a good update. (Score:5, Insightful)
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 [67.160.223.119]
We need an alpha in 2004 (Score:4, Insightful)
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.
Re:We need an alpha in 2004 (Score:2, Insightful)
You don't pick a language because you think it'll be good in a year or two. You pick a language because it fits your current needs, and gets the job done.
Re:A guy walks into his coworker's office.... (Score:5, Insightful)
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
Agreed, this may just be too much, too late (Score:5, Insightful)
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.
Ewwwww (Score:4, Insightful)
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...
Re:Python/PERL users unite! (Score:5, Insightful)
Re:Me either ... (Score:5, Insightful)
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...
Perl remains beautiful (Score:5, Insightful)
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.
Is text formatting relevant (Score:4, Insightful)
"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.
Re:Perl 6 is hugely ambitious, and that worries me (Score:3, Insightful)
The difference between stack and register based has nothing whatsoever to do with preemption, and has to do with reduction in the number of opcodes (adding two numbers becomes one instruction instead of 3 for instance). You still have to save register sets the same way you have to save stacks in a stack-based VM, since the task you're switching to won't know if it's clobbering already allocated registers
Deja vu all over again .... (Score:1, Insightful)
Re:A guy walks into his coworker's office.... (Score:1, Insightful)
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.
Yes you are (Score:2, Insightful)
Re:A guy walks into his coworker's office.... (Score:2, Insightful)
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.
Re:A guy walks into his coworker's office.... (Score:4, Insightful)
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.
Re:Yeah, but... (Score:1, Insightful)
Re:Meanwhile PHP surges ahead (Score:1, Insightful)
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.
Re:I tried, but I failed (Score:3, Insightful)
One thing I've come to realize though is that perl is unique among the languages that I know. Perl is the only computer language I know of that is so complete as a language.
Like a spoken language, perl is highly context-sensitive and one idea can take many different forms. It's deterministic and precise, of course, but it has a much more natural feel.
For example:
while(<STDIN>) {
chomp;
print;
print "
}
is a valid perl program, yet we never go through the details of where exactly we're storing the standard input, nor do we have to explicitly state what we're "chomp"ing, nor what we're printing. It's all obvious, what ELSE would we be chomping or printing? In most other languages, like C or python, we'd have to store them in a variable, or do a complex function call or something.
So perl uses lots of implications and context, like a spoken language does. It's really a marvel in some ways, because it's a group of people agreeing on a real language, rather than simply a set of commands.
I love python, but it really is just a structure, there isn't much language to it. I'm not even saying that it's a weakness.
I'm just saying perl is unique because it's actually a full language that allows very imaginative expression, much like english. Think if Shakespeare was trying to write in python! Nobody would care, Macbeth would be about 12 lines long. I don't know how all this relates to the cost-effectiveness of programmer time, but it's interesting, that's for sure.
Re:A guy walks into his coworker's office.... (Score:3, Insightful)
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.
Re:Deja vu all over again .... (Score:2, Insightful)
Re:The best thing about Perl (Score:4, Insightful)
$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.
Re:The best thing about Perl (Score:3, Insightful)
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.
Academia is Backwards (Score:3, Insightful)
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.
Re:Perl 6 is hugely ambitious, and that worries me (Score:2, Insightful)
No, it's expanding in every possible direction in the simplest way possible. :-)
Seriously, there are pages and pages and pages of rambling explanations for changes to something already solid and useful, like regular expressions (which are already fairly complex as it is).
Yes, and your average regex in Perl 6 will be a lot simpler. Perl 6 is all about throwing out the unnecessary complexity in order to map the complexity of the problem onto the complexity of the solution more efficiently.
There are some gems in there, but do we really need it *all*?
Of course not. Nobody needs it all. I've never even used all of Perl 5. But all the bits we're putting in will make someone somewhere deliriously happy, because we've "matched the impedance" of the solution and the problem. And we're trying really hard to hide the bits that you don't have to know about upfront.
Do you have all the manpages on your system memorized? Do you expect to?
Perl's always been a language you can learn "small end first". That's not going to change.
Perl 6 is already coming across as much more complex than any language I've seen...
Then obviously you've never seen English. :-)
More like digging a tunnel through a mountain from both ends. When two groups are working hard on converging at the same point, they can usually work things out, one way or another. And the Parrot guys do understand pretty much what Parrot is for, or they would have just gone off and used an existing VM.
But Parrot's problems are small compared to the language's, and Perl 6 could come to fruition without Parrot. The Mozilla team seemed way off track for many years, but they eventually pulled together a good product (Firefox), in the end.
Our intent is not to come up with the language you'll use in six months, but the language you'll use in ten or twenty years. To that end, we've intentionally bitten off way more than any one person can chew. And we're just gonna keep gnawing on it till the thing is digested, and easily digestible by others.