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?"
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.
There's no point in questioning authority if you aren't going to listen to the answers.
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?
I have been using Perl for years now, and I have to say, its not been the best language to use.
/me nods his hat to Perl6.
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.
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
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.
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.
Click here or a puppy gets stomped!
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
~Dalcius
Rome wasn't burnt in a day.
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.
See more.
Obviously not.
Check out Amazon. 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.
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.
DO NOT LEAVE IT IS NOT REAL
And don't forget about Ponie, 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.
There's no point in questioning authority if you aren't going to listen to the answers.
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).
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
If there is such a law, Perl 6 will break it. Switch statements force you to use $_ implicitly, for instance.