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 rgmoore (133276) * <glandauer@charter.net> on Thursday March 04, 2004 @07:37PM (#8470748) Homepage

    One thing that you really have to love about the people who write Perl is that they have a sense of humor. This kind of document could be extremely boring and bland, but Damian had the good sense to liven it up by using humorous examples, mostly drawn from Shakespeare. He's doing some great work, but he's also obviously having fun doing it.

  • ruby! ruby! (Score:3, Interesting)

    by Anonymous Coward on Thursday March 04, 2004 @07:43PM (#8470799)
    I'm sure Perl 6 will just be the bee's knees, but I have long since switched to Ruby (or Python if I need certain libraries). As I get older, the philosophy behind Perl (more than one way to do it) really gets on my nerves.

    So, I'm interested to see Perl 6 when it comes out, but I sure as hell won't be using it for anything.

    Also I'm looking forward to a common runtime between the three languages so I can use Perl modules from Ruby. Now *that's* the best of all possible worlds, eh?
  • by Fiona Winger (758088) on Thursday March 04, 2004 @07:46PM (#8470830) Journal
    I have been using Perl for years now, and I have to say, its not been the best language to use.

    Being one who's never gone along with the best methods of coding, I've stuck with Perl for the past few years. I deem myself pretty proficient in it, and I find a new plethora of exploration available to me now that Perl6 is out.

    The fact that Perl6 is now a subroutine rather than hardcoded allows me to directly stream the formatting through the test. This is immensely helpful, for it allows me to organize the code more efficiently and get more out of my hard worked code.

    Sure, some parts may seem like a step back, but this new versions is much simpler to use, and has some huge advantages that all coders should get use from. /me nods his hat to Perl6.
  • VM's (Score:2, Interesting)

    by beware1000 (678753) on Thursday March 04, 2004 @07:49PM (#8470861)
    Virtual Machines really seem to be the way of the future. But I am really not sure how I feel about them yet.. Parrot will have to prove itself yet, especially with the aftertaste .net and java have left in my mouth. Sounds like an interesting idea though even if only for a neatly compiling language
  • by Fiona Winger (758088) on Thursday March 04, 2004 @07:52PM (#8470892) Journal
    Next time, you might want to try reading the article a little bit closer next time. ;P

    Perl6 does not assemble to VM bytecode anymore.

    Perl6 now assembles to assembly.
  • by ShatteredDream (636520) on Thursday March 04, 2004 @07:57PM (#8470937) Homepage
    It's too bad that the teams had been only joking about joining forces. If the teams had worked together to create a conceptual clone of .NET wherein Python and PERL could be used interchangeably in the same runtime, the OSS developer base would be very well off right now.

    Think about the possibility. First port PyQT and wxPython to parrot. You write your GUI code with Python and byte compile it to a neutral Parrot format. You need to do complex substring matching so you write some good reusable functions that take advantage of PERL's string handling capabilities and then byte compile them. Load them into the event handling code and you've got a great hybrid.

    What would be really cool would be to see Java and a form of OO BASIC ported to Parrot.
  • by Anonymous Coward on Thursday March 04, 2004 @08:02PM (#8470965)
    I was lucky enough to be lectured by Damain Conway on the fundamentals of programming in C. Easily the best lecturer I have ever met. Of all the lectures in Computer Science he was the only one who managed to pack out the theatre everytime. I swear people came in just for the show.

    A great combination of humour, intensity and analogies created an enthusiasm to listen and in turn learn. He even spent long hours writing applications to demonstrate principles (think virtual C intepreter with GUI).

    Whats more he loved to teach, he wasnt just there to complete his hours required like most lecturers.

    I wish we could find more people as talented as Damian to teach us. The world would be much smarter if we could.
  • Me either ... (Score:5, Interesting)

    by pavon (30274) on Thursday March 04, 2004 @08:12PM (#8471028)
    but Parrot is really starting to excite me.

    The main reason being it's potential use as a generic high level "ABI" of sorts. Look at GTK/GNOME for example. The developers choose to use C as the base language, largely because it was the easiest language to create bindings for - everything can link to C. But the problem is that C only implements procedural concepts. Anything else must be crafted from hand, like gObject. So you end up reimplementing all the features of a high-level object oriented language, in C, and often this implementation isn't even as efficent as the high level language's implementation. On top of that, when create bindings for a high level language, you wrap all of these gObjects inside of a native language object, and end up with double the overhead. So what it comes down to is that you worked four times as hard, and came up with something twice as slow, just to be able to have an object oriented library that many languages can link to.

    Parrot has the oportunity to be for object oriented languages, what the C ABI has become for procudural languages - a common interface for programs of different languages to communicate. Imagine having high level libraries, that can be efficiently used by python, perl, ruby, befunge. Or having scriptable applications that are not just scriptable by one language, but by anything that targets parrot.

    When you add to that they fact that it will be cross-platform, and more efficent then most of these high level languages were to begin with, it's hard not to get excited.
  • I'm scared too... I started my programming days in Perl and am very fond of it's flexibility and ease of use. I wouldn't mind the ability to do some formal class declarations and error handling a la Java, but I'm worried.

    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. Judging from the speed and smoothness gained by using preemption in the Linux kernel, I'm drooling to see what this will be capable of.

    I really hope, though, that they haven't lost sight of what makes Perl great, which is: it's just as easy to write good code as bad. The flexibility is 100% in the hands of the developer, not in an over-engineered and time/overhead consuming rule book. Comparing it to English is a good example.

    Cheers
  • by d00ber (707098) on Thursday March 04, 2004 @08:33PM (#8471196) Journal
    I agree. I was really starting to get worried because - up until a few months ago - it seemed they had also stopped maintaining Perl 5. Then they came out with 5.8.[123] in fairly rapid succession.

    I think the combination of a long ramp to Perl 6 and no Perl 5 upgrades could have made the whole thing moot. Another year could have killed it.

    Anyway, I'm glad to see Perl moving forward. For some reason Perl is the only script language I know (I've done Perl, Python, Ruby, Tcl) that I don't have to relearn. It has this strange ability to stick in my head.
  • by Anonymous Coward on Thursday March 04, 2004 @09:53PM (#8471705)
    Real object assembler is almost twenty years old:

    Object Assembler


    Object Assembler is a set of macros for the Motorola 68000 assembly language that provides easy access to the MacApp class library and to class-definition facilities. It is built on top of the macro assembly language provided by the Macintosh Programmer's Workshop assembler. Object Assembler was developed by Apple expressly for the Macintosh and it will be officially shipped late in 1986. The Object Assembler macros let you define new classes, define method bodies, instantiate objects, easily reference instance variables by name, and invoke methods, incl uding inherited ones.


    See more [byte.com].
  • by Miniluv (165290) on Thursday March 04, 2004 @10:56PM (#8472201) Homepage
    Ever notice html is just a lot of text? Ever notice that tables are what lots of reports are done in? Ever think that instead of some bizarre loop generating nested table elements so the boss can comprehend the data, you could now just use form?

    Obviously not.

  • by daperdan (446613) * on Thursday March 04, 2004 @11:00PM (#8472225)
    Check out Amazon. [amazon.com] The net's largest retail site seems to put a heavy emphasis on Perl. You don't see a whole lot a php in the job requirements there do you? There may not be big growth in Perl but it's still in big demand.

    Judging by the number of sites that depend heavily on Perl I can assure you that it's not going to be sidelined soon.

    It's true that PHP is a fantastic language for small sites. Mod_perl is a hog when it comes to memory but memory is cheap and mod_perl is tried and tested. There's a reason slashdot uses mod_perl to power its site.
  • Re:Me either ... (Score:2, Interesting)

    by MourningBlade (182180) on Thursday March 04, 2004 @11:05PM (#8472253) Homepage

    More than that, parrot gives people the ability to quickly implement experimental or highly specific languages.

    Want a language custom built for the analysis that your lab boys do? Want to use some old code from another language? You can do that quite quickly. Your compiler is written in Perl (or whatever you want), targeting Parrot.

    The speed with which people have been able to implement new languages is astounding (the python-on-parrot project made huge strides in a week or so).

    And since these languages will eventually start out with fully-functional libraries (better than most languages will ever get, in fact: everything Perl has to provide, and possibly Python and Ruby later), they will be usable.

    I think Parrot will see more experimentation with languages than we've seen yet. And that will be a good thing.

  • 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.

    Nah, Parrot isn't the bottleneck. Parrot development has actually moved pretty fast: they quickly came up with a raw-functionality virtual machine, and at this point the Parrot engine seems to meet the basic runtime needs of Perl5, Perl6 [as specced out to date], Python, and PHP.

    Parrot isn't done yet to be sure, but it's already complete enough that, for example, the employer of one of Parrot's main developers is already using Parrot as the runtime engine for their corporate software. [I'd get in to details, but I forget the details -- Dan Sugalski talked about it for the Boston Perl Mongers a month or two ago.] Likewise, there's already a mod_parrot Apache module under development that will allow Parrot targeted code to run, and run very quickly, while embedded in the web server. Longer term, one of the target languages for Parrot is Z-code, so that Parrot will be able to run old text games like Zork and Hitchhiker's Guide To The Galaxy -- with luck, this could lead to Parrot being the embedded virtual machine for portable game machines.

    Parrot is, in other words, being actively developed, and there are big plans for it.

    Parrot is hardly holding Perl6 back.

    The bottleneck with Perl6 seems like the actual design work. Once Larry Wall puts out one of his Apocalypses, it never seems to be long before Damian Conway comes out with an explanation, including working code that can often be experimented with today under Perl5, with his Exegeses. There seems to be a ready pool of people eager to implement this stuff as it becomes available, it's just that the project is so *big* that it's taking a while for people to get anywhere with it in their spare time.

  • by ajs (35943) <ajsNO@SPAMajs.com> on Friday March 05, 2004 @01:03AM (#8472878) Homepage Journal
    No one is joking on the Parrot side. Check out the Pie-Thon [www.hole.fi]

    Parrot will run Python before it runs Perl, *that* should demonstrate how commited Parrot is to not just being Perl 6's back-end.

    You'll be able to create a class in Python as a sub-class of a Perl 6 class which further derives from a Ruby class, and then call a method on such an object which is defined all the way up in Ruby.... no problemo. Parrot is going to change the way we choose programming languages for the tasks at hand....
  • by ajs (35943) <ajsNO@SPAMajs.com> on Friday March 05, 2004 @01:12AM (#8472923) Homepage Journal
    Documentation is far and away the thing that sets Perl apart from other languages. There are some bad things you can say about Perl's documentation, but most of them are criticisms that you can't even begin to make of other programming languages because they simply aren't in the same ballpark.

    I blame POD for this. POD [ualberta.ca] is just a simple set of markup controls you can add to a plain text document to make it easy to translate it into other documentation and markup formats. It's so simple in fact that there's really no mental hurdles to sitting down and writting the docs for your program, module, language feature, etc., and so people do! Just about every peice of code uploaded to CPAN has a full suite of documentation for every module it provides for this reason. What's more, you can type "perldoc Foo" on any system with the "Foo" module installed and get a copy of that documentation ready at your fingertips.

    I even use Pod at work. it's an easy format to teach to people, and what could be simpler than writing a simple text file documenting a procedure you want people to follow. Then it's automatically turned into HTML and added to our internal Web site. Would that the rest of my job was that easy...
  • by rgmoore (133276) * <glandauer@charter.net> on Friday March 05, 2004 @01:33AM (#8473025) Homepage

    It also helps enormously that there are clear expectations of what Perl documentation is supposed to look like. By the time you've read the documentation for four or five modules, it's very clear that there are expected parts. Everyone knows what the format is supposed to be, so everyone uses it. That means that A) you know where in the documentation to find the information you need, and B) it will be there when you look for it.

  • by rgmoore (133276) * <glandauer@charter.net> on Friday March 05, 2004 @02:10AM (#8473162) Homepage

    And don't forget about Ponie [poniecode.org], the project to build a Perl 5 interpreter on top of Parrot. That means that Perl 5 should continue to be useful even if the existing core code is eventually scrapped. This, of course, is one of the principal advantages of having a multilingual VM; any language that can target that VM can be maintained with much less effort.

  • by Anonymous Coward on Friday March 05, 2004 @02:47AM (#8473264)
    Perl made us productive and inspired new languages like Ruby which took some great features from Perl and made a language actually a pure joy to use. http://www.ruby-lang.org

    Perl6 will finally cleanup a lot of baggage to make it more competitive with newer/cleaner/easier languages (like Ruby). If done right, it will recapture the former Perl users who migrated to Python and/or Ruby.

    Parrot will give us an alternative to the single-language Java VM and the multi-language Microsoft CLR. We can only hope that it leverages the mistakes and successes of both JVM and CLR to provide something that is better than both.

    While it shouldn't be limited in a particular CPU, it should take reality into consideration and make it easy to aggressively optimize for AMD/Intel (98% of desktops) and IBM PPC97x (Macs, XBox 2, Playstation 3, future IBM Linux workstations).
  • Re:Me either ... (Score:3, Interesting)

    by jadavis (473492) on Friday March 05, 2004 @04:28AM (#8473530)
    does anyone have information about the perl6 c interface? I use the C interface to python constantly; it's what really got me into python. I remember perl's was clumsier (there's a self-defining word if I ever saw one :) so I'd like to see it improved.

  • by pkphilip (6861) on Friday March 05, 2004 @07:19AM (#8473978)
    Turbo Assembler (later versions) from Borland did support a level of object orientation. It actually shipped with examples of object oriented assembly code.

    OOPs in TASM [mujweb.cz]

  • by TimToady (52230) on Friday March 05, 2004 @07:36AM (#8474010)
    If there is such a law, Perl 6 will break it. Switch statements force you to use $_ implicitly, for instance.
  • by Ed Avis (5917) <ed@membled.com> on Friday March 05, 2004 @07:44AM (#8474034) Homepage
    On the other hand, nowhere in Perl's documentation is it fully documented what

    $a = $b + $c;

    does. Compare this with languages like C or Scheme or (I think) Python that have a formally defined and documented semantics (even if C allows for some cases that are explicitly implementation-defined or undefined behaviour).

The tree of research must from time to time be refreshed with the blood of bean counters. -- Alan Kay

Working...