Slashdot Mirror
Apocalypse 5 Released
Simon Cozens writes "The Apocalypses are Larry Wall's explanation of the design of Perl 6. In Apocalypse 5, Larry turns to redesigning regular expressions. He set out to intentionally 'break' a lot of the regular expression culture we're all used to, and these are the results - and they're mindblowing."
Bah, and I've only just got the hang of em.
I hope somebody's going to write some automatic conversion tools because going back to one even a few days later is a hairy experience indeed.
[)amien
Why do we always have to keep changing regex [and many othe things]. Isn't enough that we have to learn one format for almost every language. Sure, there are perhaps easier ways to express certain logic situations, but over all, do we /need/ another regex format?
Well, for those of us who actually like the way Perl 5 does its thing, we can always stick to our old gnat covered camel carcass.
On a completely different note, people have often commented that I look identical to Simon Cozens. I dunno, though. They're basing it off of his picture on the Wrox book.
I have been pwned because my
He set out to intentionally 'break' a lot of the regular expression culture we're all used to
I hope he can break "Don't go there" and "Talk to the hand" There are many others, but this would be a good start
---"What did I say that sounded like 'Tell me about your day?'"---
So, when Perl 6.final is released, will the release notes be called "Apocalypse.Now"?
--
If you moderate this, then your children will be next.
The new perl 6 regexes are crazy. They seem "weird" and awkward compared to the perl 5 ones... but then again I thought the same when I started learning perl (at version 5.6).
/x to allow for easier reading of code and allow for comments inside the regexes. Some of the new features make the regexes a bit longer to type, but in general they are significantly smaller. There's also a much better and more consistent use of different types of brackets. Not having to look at the end of the regex to understand the whole thing is going to be great. I hate having to skip the regex to look a the flags first.
:o) I also wonder what the speed of the interpreter is going to be like compared to perl5. Hopefully faster :o)
A lot of this makes a lot of sense however, especially the default
Brilliant I think. I can't wait for it to come out. I hope they make a perl5->6 translator though
Good job Larry, Damian et al.
Something to make the code that little bit more unmaintainable. That keep those PHP whores on their toes :->
For instance there is now OO COBOL but the only people that use it are COBOL programmers who are stuck, perhaps because of their company's dictates, perhaps by choice, with COBOL. In the same way perl may be heading towards irrelevance wrt "mainstream" language. I've written commercial perl in the past, it was a pain then and it's still a pain now. The thing is that now there are alternative languages in the same space (python, ruby etc., php for web side) that do the "perl thing" better than perl.
Perl was great, it introduced many people to programming, just like COBOL did. But now it's time to move on. To move on to languages that learnt from perl, that improved on it, that don't have to drag around a syntax and culture that values neat tricks and trying to guess what the programmer really meant over providing the needed building blocks and letting you build code that does what you say, not what it thinks it heard you say. Or even, dare I say it, to move on to languages outside the perl family for some programming and choose the right tool for the job for a change.
I'd prefer to think of this as provocative rather than a flame, there is a difference you know.
development.lombardi.com
and I love it. I just hope that Perl6 isn't going to be drastically different or I'll practically be starting from scratch.
Yes, Its true that you should be able to apply the concepts and learn any language, but to be fluent you must memorize a certain amount of the language's syntax. Having to go back to whatever material you learned from in order to get the syntax/function/whatever you want is a real PIA.
Uhhhh, yeah, thath dithgustin. [The lady's man]
Wherre I work I'm almost the only non-cobol programmer. We are developing modern data wharehousing solutions, for huge amounts of data, using mainframes , DB II and COBOL. /Java 1.4 system.
Cobol has been arround for such a long time that it is known good solution, the same thing applies for Perl and CGI.
Would you trust you life on an App writen in VB, or a large C++
C++ is to complex for everyday usage, sure it's got great performance and flexability, but one of it's downfalls.
VB is just a glorified scripting language, with loads of bugs and much crapness, i should know i've been [had to] using it for 7+ years.
Java just insn't mature enough for anything decient.
So were left with Perl, Cobol and the like
thank God the internet isn't a human right.
Can I suggest that you read ...And Now for Something Completely Similar by Damian Conway.
Well, Java is quite an easy language imho. It handles all you memory allocation, no segfaults etc...,
It's just that version 1.4 has just started to add maturity to Java i.e 1.3 java was a bit hmmm.. imature, 1.3 fixed a lot of things, 1.4 has beefed Java up a lot so 1.5 or so would be Matureish. ie. Most of the bugs and incosistancies should be ironed out.
thank God the internet isn't a human right.
It's just that version 1.4 has just started to add maturity to Java i.e 1.3 java was a bit hmmm.. imature, 1.3 fixed a lot of things, 1.4 has beefed Java up a lot so 1.5 or so would be Matureish. ie. Most of the bugs and incosistancies should be ironed out.
The same thing is happening with linux, 2.6 kernel is starting to get maturity features in it, so by that reason 2.8 or 3 should have ironed out the bugs/inconsistancies in the maturity features.
(linux is however great for custom applications)
thank God the internet isn't a human right.
So now Perl regexs are going to be completely different from every other language and more complex than ever... wonderful.
I certainly hope that someone is going to be maintaining Perl 5. I certainly cannot see the Perl community moveing en masse to Perl 6, or whatever they decide to call it.
Conformity is the jailer of freedom and enemy of growth. -JFK
...is if Cmdr Taco is going to upgrade slashcode to Perl 6 and what he thinks of all this re-write of Perl.
The simple truth is that interstellar distances will not fit into the human imagination
- Douglas Adams
...that the active half of this Perl (5) powered site is completely screwed up at the moment? Improve languages all you want, it's still no substitute for decent sysadminning ;)
However, I would like to think that there is some happy medium between those two extremes. Coming from a C background, Perl has historically treated regexes as servants. True, Perl has treated them as trusted servants, letting them move about in Perl society better than any other C-like language to date. Nevertheless, if we emancipate regexes to serve as co-equal control structures, and if we can rid ourselves of the regexist attitudes that many of us secretly harbor, we'll have a much more productive society than we currently do. We need to empower regexes with a sense of control (structure). It needs to be just as easy for a regex to call Perl code as it is for Perl code to call a regex.
We've been discriminating against the poor regexes for too long. We need to represent them who are unable to represent themselves. Stop Regex Exploitation Now!
But hey! They can deploy a team against other teams picked from countries the size of one of their States.
Field Texas, or Califonia, or whoever as a single state in the World Cup and then lets see how you stack up.
You think if the EU fielded a consolodated team you'd stand even the remotest chance of a look-in?
Bully-boy mentality pure and simple.
Do you never stop to consider the size of the countries you're competeing against when they beat you in international competition? Doesn't that cause you even the slightest shame?
I've asked this elsewhere. Ruby was designed with respect to perl, but all the same keeping to the principle of least surprise (which perl does not adhere to). Now, with Perl starting to look like a grown-up, mature language, what will the major differences between Ruby and Perl be?
Stop the brainwash
He seems to be putting a lot of emphasis on embedding Perl inside regexps; while this will make them more powerful and allow you to do more complex things using them, it's increasing coupling between Perl regexp and Perl itself; I don't see the PCRE library and other similar libraries being able to keep up.
Although he mentions he wants regexp to be taken more seriously as a tool for other languages, increasing coupling like this would seem to be a very poor way to go about it.
The new-style regexp's reuse a lot of syntax from the standard regexps; the meaning of many common constructs have changed completely, but I can see it being difficult to actually notice the difference until you've already parsed part of it and gone "Uh?" a few times. And you're not just going to be able to forget about the "old-style" regexps.
Personally I can't help but feel that Larry is the wrong person to make such large changes to the core regexp concepts; they're used heavily in languages other than Perl, but Larry is natuarally doing it in the context of Perl and to hell with any other language. For something so otherwise platform independent, I think this is a bad way to go.
1.what would the purpose be of changing the name of a language. that's like saying, "ok, c++ is now gonna be known as d, because we've decided to rid the ++ operator." 2.let's go changing major parts of html as well. instead of opening a document with the html tag title and body, we'll call it, cow duck and chicken. but, since we did that we have to rename the language to farm. 3.it's not a very good idea to build such a user/fan base of a language and then just go changing it all around. perl (or whatever the hell it's going to be called) is going to suffer severely as a result. 4.the opensource world already lacks something of major importance, and that's the standardization of many things. it's all well and good that we can have 7 or 8 different window managers/environments to choose from. on the other hand it sucks to try to compile one and see that you don't have a specific library it needs. so, unless i'm mistaking and read the article a little backwards, we're going to have a hell of alot of code that is going to have a hell of a time running on the new "perl". 5.so what if this new regex engine is faster. the point is we already have many different rules for regular expressions from languages to programs, now, we're adding one more, and changing a language that has become one of the MOST POWERFUL and USEFUL languages in computing! (arguably) 6.the _ONLY_ way i see this as a benefit is if this breaks off as a totally new language and the perl that is now, continue to be developed along side of this "new" lanugage. Kind of like perl++ if you wanna call it that. 7. i probably am making alot of people mad, so i'll stop now, and apologize.
I write code.
my ($x) = /(.*)/ my $x; / $x:=(.*) /
# may now bind it inside regex
This is a feature that I hope is carried over into the scripting languages I use (PHP, Python).
My first impression was that they may as well embed AWK in the regex engine.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Larry is mistaken if he thinks this is going to be in any way benefitial. All this does is change the syntax and add yet another layer of difficulty to what is already a mess.
1) This isn't any easier to read. I've been programming since 1985 and went through more programming languages and idioms than I can recall, and regex is the only system I have attempted to learn and met with complete failure. If regex is to be redesigned (and despite my inability to learn it, I don't think it should be broken), at least make it comprehensible.
2) This creates a giant rift in regex, with multiple, mutually incompatible versions across operating environments. What works on system A may not work on system B. Some vendors may choose to implement these extentions, and some may not. This is a disaster. Though regex may not have been completely compatible across systems up to now (and to be honest, I have no idea how compatible the various regex implementations are), adding yet another dialect can be nothing but bad.
Lots of things are easy,
C++ is a peice of piss to code in, so easy that you'll probably produce somthing horrific!
Java's easy, it dosn't let you 'worry' about memory allocation (until you need to and then you can't).
I would recomend C++ or Java as the best languanges to use, unfortunatly most programmers arn't the 'Best' programmers to use, there useually easy to hire and not mature enough.
thank God the internet isn't a human right.
Korki......
The last few days have been a disaster for me, and I do not have any zest left.. but I do miss you, and I really want to play with your hair. So if you see this message, reply to it. Okay?
Bye!
Anonymous coward, an extension of Identity 5
this guy has been doing some interesting work on the regex engine. he's added functionality so that you can have recursive regular expressions without the clumsy postponed subexpression ("(??{...})") mechanism. on the one hand, it's far less readable that way, but on the other hand, you don't have to predeclare a variable for every production rule in your grammar.
and the current system is even more convoluted since the postponed subexpressions are evaluated in the environment in which they are checked, not where they were declared. this means that all variables referenced when you built the regex have to be in scope when you use it. that's a restriction i'd like to do away with, although i'd rather see it done by making postponed subexpressions support closures.
as i recall there's also an rfc for perl 6 on the perl site to make a stack-based regex engine rather than stat-machine-based, so that it could support CFGs, but i don't think it specified how it would work syntactically.
#define F(x) int main(){printf(#x,10,#x);}
F(#define F(x) int main(){printf(#x,10,#x);}%cF(%s))
I've read comments by Larry to the effect that Perl is great at writing lexers but not parsers. If you look at some of the later examples (around page 11) it's clear that he's trying to make Perl regexes powerful/clear enough to parse Perl. They remind me of yacc/bison, which makes sense.
Think of Perl 6 regexes as something like a cross between traditional regular expressions and BNF grammars with hooks for good Perl integration.
That makes them weird, but it means that when your problem gets a little bit beyond what is doable with a traditional regular expression, you don't fall off of a complexity cliff. Instead of the current situation where regular expressions are great on small problems, then fall apart when you (say) want to check that parens are balanced (that one is doable in Perl 5.6, but not easily), they will scale anywhere from the kind of tokenizing that people currently do up to and including parsing something as complex as Perl.
And the ability to do this will be tested in the best "eat your own dogfood" manner by actually implementing Perl's grammar as a regular expression!
I still disagree with the parent flame, but I think Mason really does a service handling at least the CGI tasks. On the sysadmin front, I have no idea, since Perl is my hammer :}
What is your Slash Rating?
Yeah, and by the last few Apocalypses, Larry will have shaved his head and gained a lot of weight, and he'll sit in the darkness muttering half-profound, half-obvious statements about language design. And Damian Conway can play the Dennis Hopper role, the drugged-up photographer/court jester :) But who gets to be Marlowe/Willard?
:)...
ObDisclaimer: I really like both Apocalypse Now and Perl, but they seem uncannily similar now that I think about it -- that great epic attempt to render the human condition, that falls well short (but at least tries
deus does not exist but if he does
Provoking a flamewar is still considerably different from provoking thoughtful discussion. Saying "Perl sucks, let's find a new language" is a flame. Saying "I think language X better serves the purposes Perl addresses" is thoughtful and provocative. See the difference? Unfortunately, the parent thread came down on the "Perl sucks" side of things...
What is your Slash Rating?
As a Java geek, I was going to reply to your post much in the spirit of this thread, but you are completely right.
Freedom is the freedom to say 2+2=4, everything else follows...
Why do people love it? It's mad powerful. Sure it can look like line noise, but once you start to "think" in Perl you can do amazing things with only a little code. And for many of us, we already "thought" in Perl anyhow. At least that's how it struck me. Perl's much more like a natural language than a lot of traditional programming languages, and this gives individual coders a lot of freedom in the way they do things. Of course it causes a lot of frustration for beginners and dabblers, too.
(an example)
exit(1) unless $input;
You can do mad powerful things in Perl in just a few lines. Plus, there's CPAN which extends your power even more.
Not that I suggest everybody should code in Perl, but those are the things that I think attract a lot of people to it.
Hmm, from the 'BAD REQUEST' message I get on perl.com, I'd say they set out to intentionally break the Apache web serving culture we're used to also... :)
is competition good, or is duplication of effort bad?
Just get the damn thing written, make it flexible enough for us to rewrite perl in perl, and kick this lazy-ass camel out the door before my grandchildren ask me when perl6 is coming out!
... great, so move on already, regexes are not the final word in pattern matching.
I don't want more powerful regular expressions. I want a more powerful pattern-matching syntax, one I can compile down to an opaque object with a bit of syntactic sugar, then use in place of a regex. I want a parser sub-language like SML or parsing primitives like haskell. Regular expressions are now turing complete thanks to perl
And what's more -- all this you're doing Larry, it's anti-hacker. It's top-down, it's engineered, it's ivory-tower theory that might sound neat and no matter how zany your presentation is, you are living in the rareified atmosphere of a language designer, and now you are starting to think that way, dispensing wisdom on The Right Way To Do Things from on high. Yes, inventing Just The Right Way to give people 1E+255 ways to do things is still looking for the perfect that's the enemy of the good, because once we have the foundations to improve on perl6, we will do it, but only if we have something to work with. It doesn't all need to be done up front.
Your extended regexes can be done as a library solution. Stop ending the world and start living in it.
I've finally had it: until slashdot gets article moderation, I am not coming back.
If Perl 6 isn't backwards compatible, they do the same Microsoft does with Visual Basic .net: make programmers switch to other tools.
A good language can introduce new features without changing the basics. This is why PHP got so popular so fast.
Off-topic, but great signature.
What's the point? Java, C, C++, COBOL, Mantis, VB, you name it...even Ada. The point is not whether something is bad because it has become such a widely used language that it has legacy code dating back to a few generations, but whether it serves a useful purpose.
/.) will argue that COBOL or FORTRAN or what have you is obsolete because it isn't the latest, sexiest language. That's not a valid argument. COBOL finds uses in every day environments that maintain our IT infrastructure...in places most people wouldn't even notice.
People (especially on
The same thing goes for Perl. It may not have the newness of Ruby, and it may have code dating back to release 4 on web servers the world over, but that doesn't mean it is dated or that it is time to scrap the language.
One of the nice things that Perl has going for it is the modularity. You go to CPAN, download a new module, and all of a sudden, your toolbox has a whole new tray of useful tools that save you from re-inventing the wheel. These tools let you perform system administration tasks, provide CGI applications with ease, or handle back end tasks. It is more powerful than shell scripting and more flexible than C/C++/Java.
As much as I'd like to think you're being reasonable, it seems to me you've made a blanket, baseless statement. If you want to provide some evidence that your point of view has merit, I'm sure we'd all be interested. In the meantime, you're likely to be dismissed as a troll....
What is your Slash Rating?
Offtopic? Let me spell it out for you. I cant wait to go home and get my hands on it (newest version of Perl). Thanks for the mod!
But now it's time to move on... to languages outside the perl family for some programming and choose the right tool for the job for a change.
== Perl sucks (with no new original criticisms)
== (Troll, -1)
So Perl 7 will be the last major revision. In fact, Perl 7 will be so perfect, it will need no revision at all. Perl 6 is merely the prototype for Perl 7. :-)
Bad Request Your browser sent a request that this server could not understand.
Apache/1.3.22 Server at www.perl.com Port 80
Konqueror 2.2.2 w/ junkbuster - what do I do wrong?
The biggest problems with Perl are its uglified, glued-on OO capabilities and its general legibility.
You can do some decent OO with it, yes, but you'll do some language hacking to get there. You can also write some nicely legible Perl code (I try to), but most people don't bother.
Perl5 is going to be around for a long time... a whole lot of code has been written in it, and much of that code is critical due to Perl's usefulness as a glue language and for web programming. So a lot of people are locked into Perl5, at least, for maintaining existing code.
But Perl6 is going to address some of the major problems with Perl5; I expect its adoption rate to be high.
That's not a troll. That could be empirically determined. I can't count the times when I've seen my worst posts modded up as funny and my better ones modded down as flamebait or overated. Unfortunately, there isn't any room for appeal that I've seen....but this is going OT, so I'll stop here.
What is your Slash Rating?
I heard of it back in 2000, and nothing cince.. one of the core developers was working on a mini-perl for embedded systems and I have bee neagerly waitong for it but ..... nothing.. no small perl that takes up very little space...
Anyone have any clue as to it's progress?
Do not look at laser with remaining good eye.
How much of a mess is banking in, quite a bit. most of the java programmers I know who do banking work are writing data pumps &co.
They were also using imature technologies e.g. XML, and a riff-raff of components in various states of hack arround required.
There also using an aufull lot of SUN boxes, which dosn't quite fit with the Java protability ideal.
e.g. Java is a bitch to get working on HP unix
I didn't say Java wasn't good, or usefull but I wouldn't fly in a plain, or launch a rocket if I knew it's systems were written in Java. It's a bit like putting NT on a battle ship!
thank God the internet isn't a human right.
For what I've read in the past, it has always been the plan to ensure backward compatibility by defaulting to parsing Perl5-style syntax. Said another way, one must explicitly specify that a program is Perl6. This is a good thing, and a feature I'm counting on. There's quite a bit about Perl6 I'll probably not use very much. All I really need Perl for is a glue language. In fact, if I were to replace some chomp()'s with chop()'s most everything I've ever written will run under Perl4. I'm not quite as l33t as some although anyone can read my code. Needless to say, I don't post to perlmonks.org very much. :-)
I don't think Wall will make everyone go back and re-write old code. That would be a grievous mistake.
(Note: I haven't read the latest Apocalypse because perl.com seems to not be responding. If Wall has said anything to the contrary, then things have changed from what I've read in the past.)
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
Ruby isn't *just* a python clone with perl syntax thrown in. Ruby IMO is a nice "truer" OO scriping language. It's not like Python in that it's OOP seems to be more smalltalk like. Also, with Ruby you don't have to pass "self" around confusing things. Or maybe it's just me that gets confused with all the selfs. ;)
BTW, I like Python too. I use it with of course, Zope.
It's not that perl is akward. It's a language that lets you code in a number of different styles. It gives you the freedom to code your own way. This does reduce readability, but it greatly increases speed of coding. If others need to read your code, just set up style guidelines.
I use perl for just about all scripting I do on my system. Just a moment ago, I had to read an html file over http, but there were no line breaks. I just needed to get one piece of information, so I did this:Sure it's unreadable, but it did the job. If I'd been writing CGI, I would've been more verbose since terse perl code can be difficult for even the author to understand by reading it.
perl gives you lots and lots of freedom. This is not a bad thing, but it is dangerous. Other languages force you to work in one way.
Think of a bike. A bike w/ trainig wheels makes it hard to fall over, but your agility is reduced. perl has no training wheels by default. You can write really nasty code that works but is unreadable. Perl is anything but limiting.
If you want more structure to protect you from yourself, try running perl the -w option and put "use strict" in your scripts. If you want pretty built-in identifiers, try "use English"
I've been coding for so long that the restrictions built into many other languages just get in my way most of the time. I like the way perl never gets in my way.
t'nera semordnilap
There are no vendors, Perl is open source and the regex engine is inside the perl source. If the code compiles at all it will compile to a regex engine that is OS independent.
You fools, you've migrated to perl6 too soon!
"What thou shalt not, I shalt did!" -Bart Simpson
I can't get to the apocalypses, or anything on perl.com, from two different sites. Is there a mirror anywhere? Is nothing sacred?
Ahem. *cough* There's nothing useful in this Apocalypse. Go read something else, so I can read it.
Maybe the state's highest function is to grind out insoluble problems. (Zelazny, Hall of Mirrors)
Perl 5 is not broken, why try and "fix" it ? Perl 6 is not recognizably perl. Wall should re-name it something else, to avoid confusion.
And that was supposed to be one of the comforting parts of the article. :-P
I guess I need to start making a list of all the perl scripts we have here in case we decide to upgrade... fortunately, that was something I always wanted to do. Oh wait... did I say "always"? I meant "never".
Oh well, in a few years we'll look back on this and laugh. And that makes it all O K. As long as we stop laughing... the ones who don't will be locked up and mdedicated. Then they will be O K, too.
You're totally right, and the perl community agrees with you. For example, on page 3 of the apocalypse, Larry Wall states that perl has too much historical baggage. But that's exactly why they're redesigning it for perl 6.
It's up for debate whether python, ruby, PHP do perl better than perl, but it's true that they all took the good things out from perl5 and left out the bad things. They're doing the same with perl 6. In addition, some extremely bright people are working on it that have had a lot of experience with designing and extending languages. If you read the apocalypse, it's amazing how Larry Wall has shed all of his preconceptions and leanings towards older versions of perl. They're taking the good stuff out of every language and fusing it together in a very colaborative way. And I'm convinced that the resulting perl6 will be a language to be reconed with.
I have fought my way through basic Perl Regexes and for some strange reason have come to like the language for it's sheer obtuseness. The person who made the crack "Perl - $Just @when->$you ${thought} s/yn/tax/ " wasn't joking.
/[bla]*/ or /\Qbla\E*/ or something completely different?).
What I see as a real problem for Perl6 and Larry's vision is that other languages have, as he noted, copied Perl5 Regexes and it has more or less become a standard as it is. Those languages are not going to change their implementations of Regexes in a hurry, especially Java which has just aquired it, and this will lead to a schism because, as powerful as Regexes are, they are not for the faint hearted and no one, and I mean no one, wants to learn two different ways of doing them.(Do I use
I can almost guarantee that this is going to hurt the Perl community because many will simply stay with Perl5's way of doing things because of compatibility and habit and I think Perl6 will have a hard time finding a large audience.
I know it's too late to convince Larry otherwise, but I think he should have left things the way they were in the Regex world. My analogy is to human languages. I learnt German years ago, which is more complex grammatically than English but at the same time much more structured and with far less exceptions. None the less, an amazing amount of people speak English and like it because of it's amazing flexibility and ability to enable even a poor speaker to be understood, despite thousands of exceptions in spelling and grammar.
I consider myself a hard-core Perl regexp user and these changes look pretty cool and very appropriate. They fix a lot of the annoying add-ons in Perl's current regexps (if you've ever written a big fat regexp with lots of (?..) stuff you know what I mean). Being able to easily name captured text is probably the most useful feature. In fact Perl 6 is starting to look pretty nice all around. I'm still going to have a problem with "->" becoming "." and "." becoming "_" but I guess I'll survive.
What would REALLY be cool is if I could use some Unicode characters (for instance from the "General Punctuation Block") as the regexp metacharacters.. I didn't see anything about this in Larry's (very long) document, and I'd imagine it wouldn't be very popular since many of those characters look too much like the ASCII versions, but it would be useful.
One thing that strikes me as interesting: languages like PHP and Ruby have inherited features from Perl (for instance PHP has a "Perl regexps" feature, and it uses "." for string concat).. will these languages change so they can be more like Perl6?? Otherwise I think that would leave PHP as the only language where "." is string concatenation (yeah I'm really hung up on that dot, humor me).
Looking forward to Exegesis 5.
Honestly, how many of you actually made it through 24 pages of regexes? Now, how many did it after lunch?
Well that's the wonder of modern tech, it's so easy to gloss over the anarchy that's happening in the background!
On a serious note, the company i work for holds all the GOD information, thers a lot of it, and a hell of a lot of processing to do, collecting and processing all kinds of crap data from all over the place, and unifying it. Banking sector work is about shunting stuff arround, I worked for a while on a finincial services project that used vb6 (before it was officially relased). it works, just but boy was that a fuckup, and guess how many people know that there electric bills are processed using it!.
thank God the internet isn't a human right.
Reading through this Apocalypse, I gained two strong impressions:
2. It is going to be a lot more manageable for me to program a parser I need in Perl 6 than it has been in Perl 5, because (i) regexes can now be laid out readably and (ii) clean reentry into Perl for stuff that is better done in Perl than in regex.
1. For all the common little applications of regexes things are going to be much the same or easier.
I suspect a lot more than me struggled to really get into some of the kludges added in Perl 5 in an attempt to provide useful functionality, so the Perl 6 approach of being willing to break backwards compatability where appropriate is going to produce a language which is much better while still being unmistakably Perl.
One key to all this is that Perl 6, through its regex parsing power as much as anything else, will be able to seamlessly deal with Perl 5 syntax when you need it to.
-- Our systemic servants do not good masters make.
Probably simpler to look at it as:
/foo/i
Ruby is a pure object-oriented language. Everything is an object, everything that occurs is the result of a method of some class or instance method. Yes, it's similar to SmallTalk in that purity of concept, but pragmatically, it draws more from Eiffel, in my experience.
Python is an object-oriented language as well, but it also mixes in functional programming ideas. Methods are not exactly methods, but rather functions bound to a class or instance. That's what the "self" is about. Python automagically passes in that first argument, but you can "detach" the method from its class and call it like a function, providing self manually.
Python's weakness is the Huffman coding Larry talks about. As an example, regular expressions...
Ruby:
reObj =
Python:
import re
reObj = re.compile("foo", re.I)
And yes, I do like Python. There are things it does that I can't as easily do in Ruby. In particular, I like functions being treated as objects.
- Macros: In a sense, that's what Apocalypse 5 is paving the way for; the ability to manipulate the current grammar and add new language features is a small step. Okay, so they're not going to be as clean as lisp/scheme macros, in part because Perl itself is nowhere near as clean as lisp/scheme.
- Tail call optimization: According to discussions on perl6.language it looks like it's going to be possible to have at least some (I'm hoping for lots) tail call elimination.
- Continuations: (I assume that's what you meant given that you talk about call/cc (personally I prefer let/cc, but hey)). Again, it looks like perl will be getting these (at last), the capability will certainly be there in the underlying VM.
Now, you may not like perl's syntax, but having these capabilities in the language is going to be great. And hell, you can always morph the syntax into scheme if you like, just make yourself a new grammar and a few supporting functions. I'll probably beat you to that, I've already got the makings of a perl6 scheme interpreter, now to make an A5 based parser for it.