Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
Perl Programming

Exegesis 7 Released (Perl 6 Text Formatting) 319

Posted by michael
from the folding-spindling-mutilating dept.
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?"
This discussion has been archived. No new comments can be posted.

Exegesis 7 Released (Perl 6 Text Formatting)

Comments Filter:
  • by (1337) God (653941) on Thursday March 04, 2004 @07:37PM (#8470749)
    I just couldn't wrap my brain around Perl.

    I ended up giving up and learning Python instead.
  • I predict... (Score:3, Insightful)

    by rokzy (687636) on Thursday March 04, 2004 @07:40PM (#8470775)
    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.

    So why am I worried? Well, it feels like Larry saw Microsoft's .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.

    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...
  • by Saven Marek (739395) on Thursday March 04, 2004 @07:53PM (#8470904)
    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 [67.160.223.119]
  • by Ars-Fartsica (166957) on Thursday March 04, 2004 @07:55PM (#8470924)
    I appreciate Damian's work in clarifying Larry's writings, but the perl 6 project has three years (timed from Larry's first Apocalypse) behind it with nary an alpha in sight.

    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.

  • by Anonymous Coward on Thursday March 04, 2004 @08:00PM (#8470952)
    Anyone that is serious about learning Perl, has already learned it in the three years of waiting.

    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.
  • by sisukapalli1 (471175) on Thursday March 04, 2004 @08:02PM (#8470971)
    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

  • by Ars-Fartsica (166957) on Thursday March 04, 2004 @08:03PM (#8470977)
    Perl 6 is by all accounts a new language. Yes it will detect and parse Perl 5, but we can already do that now. How many coders will follow the new syntax and features? This is no small task, I have read all of the Apocalypse/Exegesis articles end-to-end multiple times and a lot of it still hasn't sunk in. This is a major change.

    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)

    by unfies (754694) on Thursday March 04, 2004 @08:03PM (#8470980) Homepage
    ... 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...

  • by geniusj (140174) on Thursday March 04, 2004 @08:24PM (#8471112) Homepage
    That's what Parrot is. Python and Ruby (as two examples) WILL be able to target parrot and run in the parrot VM.
  • Re:Me either ... (Score:5, Insightful)

    by pbox (146337) on Thursday March 04, 2004 @08:32PM (#8471175) Journal
    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...

    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 .net is barely limping along. Maybe there is more to this high failure rate...

    At the same time it would be really exciting to see the birth of the first SUCCESSFUL cross-platform execution machine...
  • by Dr. Zowie (109983) <slashdot@deforest.oLISPrg minus language> on Thursday March 04, 2004 @09:02PM (#8471410)
    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.

  • by jfdawes (254678) on Thursday March 04, 2004 @09:22PM (#8471531)
    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:

    "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, ... that's all it is, some geek's personal project that doesn't really seem to have much relevance to the real world.

    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.
  • by scrytch (9198) <chuck@myrealbox.com> on Thursday March 04, 2004 @09:28PM (#8471565)
    That said, Parrot sounds like it's going to shake some people up. From what I understand, it's a register based VM as opposed to stack based, meaning that preemption is possible

    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 ... unless the allocator knows ahead of time and allocates different registers for each task, but in that case it's not really preempting.

  • by Anonymous Coward on Thursday March 04, 2004 @09:47PM (#8471680)
    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 ????
  • by Anonymous Coward on Thursday March 04, 2004 @09:57PM (#8471736)
    Here is the main point of the parent.

    but too much verbose code can be very confusing


    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 $_ $: $; $] $[ ... are all meaningless to lots of people. Please don't be an idiot and try to correct me that some of those variables do not exist, I know, but there are plenty of variables that start with $ and ends with another characters. Similarly the same with @. For strings like say $aString you want to be able to use $aString[20] to access the 21th character. Also things like $aString.DeleteAllSpaces() is more intuitive then $aString=~s/\s+//g; In other languages you can still use regular expressions, in perl you must use them.

    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)

    by hummassa (157160) on Thursday March 04, 2004 @10:07PM (#8471840) Homepage Journal
    (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.
  • by Indigo (2453) on Thursday March 04, 2004 @10:15PM (#8471911)
    > 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.
  • by JInterest (719959) on Thursday March 04, 2004 @10:51PM (#8472164)

    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)

    by bunnyman (121652) on Thursday March 04, 2004 @10:54PM (#8472185)
    In Perl, the airbag is off by default. You have to type "use Airbag;" at the top of the code to activate it.
  • by Anonymous Coward on Friday March 05, 2004 @02:30AM (#8473225)
    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.
  • by jadavis (473492) on Friday March 05, 2004 @04:20AM (#8473503)
    I like python and that's what I mostly use where applicable.

    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 " ...\n";
    }

    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.
  • by Wiktor Kochanowski (5740) on Friday March 05, 2004 @04:55AM (#8473595)
    This sample is just wonderful. It uses more than a page of code to implement something that would take at most five lines in Perl. Actually I think word frequency count is one of the little examples in Perl Cookbook.

    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.

  • by TimToady (52230) on Friday March 05, 2004 @07:54AM (#8474072)
    Sure, I remember it. And that's why Perl has formats. Is this a problem for you?
  • by Ed Avis (5917) <ed@membled.com> on Friday March 05, 2004 @11:30AM (#8476037) Homepage
    Binary "+" returns the sum of two numbers. Is that not clear enough?
    No. For a start, it doesn't. What if one of the arguments is a string? Or a reference? Or undef? What if the numbers are quite large - the result will not be exactly their sum but an approximation. The same applies for very small (close to zero) numbers.
    If you're worry about what a number is, you could check: perlnumber - semantics of numbers and numeric operations in Perl
    Fair point. But I wasn't really considering the + operator so much as the statement
    $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.

  • by ichimunki (194887) on Friday March 05, 2004 @12:32PM (#8476690)
    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.
  • by Vagary (21383) <jawarren@@@gmail...com> on Friday March 05, 2004 @12:42PM (#8476786) Journal

    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.

  • by TimToady (52230) on Friday March 05, 2004 @02:12PM (#8477781)
    ...it feels like the language is expanding in every possible direction at the same time, and in the most complex way possible.

    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. :-)

    ...this seems like a classic case of going off and attacking a major problem (a general, high-performance VM), before you really understand what it's for.

    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.

10.0 times 0.1 is hardly ever 1.0.

Working...