Apocalypse 5 Released 253
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."
Regex (Score:4, Insightful)
Re:Regex (Score:3, Insightful)
Re:Regex (Score:5, Informative)
Furthermore, 80% of your existing Perl5 regexps will work unchanged in Perl6. *, +, *?, +?, (), ?, all unchanged. Most of the backslash-letter character classes, unchanged. Dot and ^ and $ are the same for most purposes, trivial to port when they aren't. 80% of the remaining cases can be ported by changing [] to <[]> and escaping spaces or replacing them with \s or \h (which they often should have been anyway).
I'd rather spend half an hour every fifteen years to learn something new than put up with the inferior old scheme for another decade or more. Unreadability of regexps is one of the biggest complaints people have about Perl, and this addresses those concerns head-on.
(Incidentally, people made all these same complaints the last time Perl changed regexps, when Perl5 came out. And now virtually every other popular language has recognized that the Perl5 design is better than its predecessors, and has adopted a Perl-compatible regular expression syntax or library. Larry's got a pretty good track record here.)
(BTW, the preceding incomplete post was a slip of the mouse. Mods, please kill it.)
Breaking expressions (Score:4, Funny)
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
Re:Breaking expressions (Score:2)
Re:Breaking expressions (Score:2, Funny)
I know a rather..ahem...well-endowed woman who often says "talk to the face 'cause the boobs aren't listening"
Apocalyptic numbering (Score:4, Funny)
More movie references... (Score:2)
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
New regexes (Score:5, Insightful)
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.
Re:New regexes (Score:2, Insightful)
Hate Perl. Hate it!
Re:New regexes (Score:3, Funny)
Re:New regexes (Score:2, Interesting)
* Ultra-good awk replacement, for one-liners
* excellent language for scripting, going where m/[ba|c|k]?sh/ can't go.
* (since perl5) nice OO-language for building GOOD programs, acessing databases, generating XML, HTML, and any-other-format stuff.
* it's got GOOD huffman encoding (things you do often are concise), and I hope it will become even better in perl6.
* it's NOT AT ALL write-only. take a look at the CPAN modules. they are readable. i can read AND understand them, easily. try it out.
regards,
--H.
Re:New regexes (Score:2)
Perl gives you (Score:4, Interesting)
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.
Just what Perl needs (Score:3, Funny)
Re:Just what Perl needs (Score:3, Interesting)
Perl's had it's day - It's become like COBOL (Score:3, Interesting)
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.
People use COBOL (Score:2, Interesting)
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
Re:People use COBOL (Score:3, Insightful)
Java's not mature, (Score:2, Interesting)
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)
i wish I had moderation points... (Score:2)
Re:People use COBOL (Score:2)
Right. So all of the following companies are just about to fall down:
CIBC
Bank of America
Standard Bank
Sallie Mae
And that was just part of the client list from the first hit that came back when I typed in "Java Banking."
Bunch of failing loser companies, aren't they?
-jon
Re:People use COBOL (Score:2)
Re:Perl's had it's day - It's become like COBOL (Score:3, Interesting)
Sometimes, it's just a matter of environment: the places I host my websites have Perl available, (sometimes Java, but it's more of a pain) so that tends to be my first choice.
There's a lot to be said for the convenience of Perl. Edit code, save, and run has benefits greater than you'd expect by just seeing that edit, save, compile, run is one extra step. (And pushing that one step further, the sheer # of files is one of the things that's a huge drawback to EJBs...)
And of course there's what the language makes simpler. I know there are Java classes that give it full Perl regexes and the like, but somehow they seem evil to me. I don't like to go crazy with the Perl syntax shortcuts, but being able to so easily open up files and the like, and not have to jump through hoops to read a line at a time...there's a lot to be said for that.
On the other hand, OO in Perl is pretty disgusting to anyone who grew up with objects in C++ and Java. It even makes PHP's object syntax look normal.
So, in the end, I don't know. It certainly seems easier to sell my Java skills in today's ugly jobmarket, and it certainly seems easier to update my personal websites in Perl. For now, I guess I'll be keeping up my skills in both.
Re:Perl's had it's day - It's become like COBOL (Score:2)
For example, I was reading some Java2 1.4 docs, where they were gushing over the new regex libs.
In perl, you'd say something like:
$s = "howdy partner";
if ($s =~
In Java:
String s = String new("howdy partner");
Regex r = r new;
r.compile("/howdy/");
if ( r.match(s) ) {
System.out.print("nay to java!");
}
Christ, that's ugly.
I'm not a Java or perl programmer, so this won't compile, but the gist of it is there.
Re:Perl's had it's day - It's become like COBOL (Score:2)
I am a Python fan and I can readily admit to some Python weaknesses, but overall Python feels cleaner and predictable. For instance, Python already has changed regexes; but because they don't come built in to the main language syntax (as they shouldn't; not everything is about text), it was a painless transition for everybody involved. I am sure that if Perl6's regexes gain acceptance, there will soon be a new Python module to accommodate them.
Re:Perl's had it's day - It's become like COBOL (Score:3, Insightful)
perl is the practical extraction and reporting language. that's what it was originally designed for, and it's still extremely useful for that. just the other day i had to rip some statistics out of the debug output of a program, and average it together over multiple tests, outputting it into comma separated values. perl was incredibly useful for that. not everything is about text, but perl is designed for the cases where it IS about text.
perl only really starts to fail when you consider it a panacea. it will not do everything for you, and there's some things that it just plain sucks at. all languages are the same way -- they have strengths and weakness. perl will extract your data, and it will act as a quick scriupting engine, for when shell scripting just isn't powerful enough. just don't try to write an officew suite or anything in it.
Re:Perl's had it's day - It's become like COBOL (Score:2)
Arguably that's what it was designed for, but that's a "backronym" (hey, how do i create e2 links in slashcode?). perl was "pearl" in larry wall's mind, but through some weird quirk of the library filing system, he only had four letters, so he called it PERL (all uppercase then, I think). Which was helpful since there was another language at the time called "pearl" (which never took off anyway).
Re:Perl's had it's day - It's become like COBOL (Score:2)
However, 'text parsing' is a limited domain; in that domain awk is almost as capable as perl (and, often, faster). You won't see any awk-powered websites though. The reason, I believe, is that dynamic websites are not in the 'text parsing' domain, even if at at the user-end of the system you're just pushing html.
There's data management, permissions/authorization, delegation, flexibility, and a myriad other issues to think about that pretty much move dynamic websites to a GUI-app domain more than a report-creation domain. Think of
That's a much closer analogy to the web app domain than generating old-fashioned reports out of a SQL backend on a mainframe --where arguably perl excels at.
I am not saying perl is a bad language or that you can't build good applications with it. You certainly can, and people do. But, for some problems, and certainly for web apps, there are better tools out there, and I believe python is one of them.
Re:Perl's had it's day - It's become like COBOL (Score:2)
Perl is in the same position. It's coming of age. People are realizing what it's good for and what it's not. Perl is NOT IN ANY WAY like COBOL. COBOL is an anachronism that stays around because of inertia. Perl is a language that is just going through growing pains.
While I applaud LW's ideas for Perl 6, I'm not sure that I would make such wholesale changes. There are going to be LOTS of people that stay on 5.x because they don't want to port, which may cause a maintenance nightmare.
Ben
Re:Perl's had it's day - It's become like COBOL (Score:2)
Re:Perl's had it's day - It's become like COBOL (Score:2, Interesting)
Re:Perl's had it's day - It's become like COBOL (Score:5, Informative)
Most languages stick around through inertia (Score:2)
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....
Re:Most languages stick around through inertia (Score:2)
ajm isn't talking about dumping perl to use C/C++/Java. You're right in your comparison of perl to them, but I say dump all but C, which you use to write the better languages until said better languages are completely self-hosting.
Re:Most languages stick around through inertia (Score:2)
How do you mean? If you mean "security through obscurity", then that isn't security at all...
Re:Most languages stick around through inertia (Score:2)
CPAN is way cool, but it does open new doors for people to waltz right through.
Re:Perl's had it's day - It's become like COBOL (Score:2)
Re:Perl's had it's day - It's become like COBOL (Score:2)
There is in fact a difference. Unfortunately, you're really not on the right side of it. For example: "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." That's not provocative, that's just insulting to those who like perl and who think that there are many jobs for which it is the right tool.
You see, provocotive is bringing up ideas that people have not thought of before. Everyone having once been five years old has thought, "does this suck" before, about prettymuch everything. Thus posting "consider that perl sucks" is not provocotive. Noone who learns a programming language doesn't consider, at some point fairly early on, "does this suck".
So while you would prefer to think of your post as provocotive, really it's just a flame. It's also fairly wrong, too, as perl is quite far from irrelevant. It's also most certainly not a universal solution, but then nothing is.
And besides all of this, Perl 6 is going to be a language which learned from Perl 1-5, so it's still one to be compared even if one slavishly follows your post.
Re:Perl's had it's day - It's become like COBOL (Score:2)
I've used perl extensively myself in the past and I use it today for knocking up quick scripts. I certainly didn't state that perl sucked, I don't think COBOL sucks either. For what they are useful for they are very good, unfortunately for them the number of things for which they are better than the alternatives is getting smaller and smaller as time goes by.
As for provocative, it means to provoke, in this case a discussion, and it did that. To flame is different.
You still missed the point (Score:2)
Re:You still missed the point (Score:2)
Also, to get any attention for a posting on slashdot it helps to have a "provocative" title and just saying "I think language X better serves the purposes Perl addresses" is as likely to provoke a flamewar as anything. With your user number you should know that. People here have their itchy trigger fingers on their flamethrowers all the time. The only advantage over kuro5hin is the larger audience (perhaps you'll take that as a flame also
Re:You still missed the point (Score:2)
I do still wish there had been more subject matter in the original post that people could consider... free response to an ambiguous post is a two-edged sword...and on slashdot, that ambiguity is likely to result in getting cut with both sides of the sword
Re:You still missed the point (Score:2)
I used to use perl a lot but even with the best of intentions I ended up with code that I found hard to maintain. My bias is now towards more verbose languages where there is only one way to do things, certainly for "mixed ability team corporate projects". Btw that's one of the things I dislike about
For perl alternatives I'd probably pick python these days for simple and not so simple scripting, java for corporate programming or open source where you want lots of contributers, scheme/lisp for fun, and standard ML or Haskell for new perspectives.
Re:You still missed the point (Score:2)
I've used Ada for school projects, JavaScript and Perl in corporate environments (I've only been out for a couple of years), and had classes in C, C++, Lisp, Scheme (there *is* a difference), x86 ASM, and (theoretically) Java. (I could include Apple Basic in the list, but it really doesn't apply).
The JavaScript was used in both server- and client-side applications (my last company was a BroadVision shop), and I certainly appreciated the OO, one-way approach it offered. It was also considerably easier than my experiences trying to learn Java. Maybe it's just me, but I found that compared with Ada (another strongly-typed language) that Java was a real pain to learn. I've heard all the arguments about its robustness, built-in OO, etc., but I find it difficult to justify using it as an all-around tool, and even have trouble with the idea of using it for CGI applications.
I've forgotten a lot of my C/C++ syntax (writing too much Perl code
I still don't quite get the Lisp and Scheme obsession. Yes, it is certainly novel to be able to have a program recurse on itself and create its own anonymous routines, but the code is nearly unmaintainable and unless you take drastic measures, quite unreadable.
I haven't used Python, but from what I've heard, it could probably do good service in some of the same areas Perl does. I guess my biggest point is that Perl is so flexible that it saves you from having to know a dozen different languages to do a dozen different things. It certainly isn't an end-all language; there are limits to anything, even to a language that tries to do (almost) everything.
You did mention that you disliked Perl because you ended up with code that was difficult to maintain. However, that isn't a Perl limitation. It is a design limitation. If you carefully write readable Perl code and leave plenty of comments...and you use a well-thought, easily extensible design to begin with, the code won't be such a beast to keep up. This is why they have Software Engineering courses at University
Re:You still missed the point (Score:2)
1. Macros: especially in scheme. Fantastic way to extend the language and meta program
2. Tail call elimination in scheme: Using recursion instead of looping can often make the intent clearer and tail call elimination makes it cost the same as looping.
3. Closures: call/cc is amazing
I agree that unmaintainability is mostly a design issue (otoh you say lisp/scheme is unmaintainable, isn't that the same situation) but some languages help it and some hinder it. I feel that perl hinders it by providing different syntax for things with insignificant semantic difference.
Lisp/scheme readability is also a design issue but is greatly helped by auto indenting editors.
Re:You still missed the point (Score:2)
Perhaps part of my bias against Scheme and Lisp is due to a lack of intimate understanding, therefore what appears unmaintainable to me really isn't, but I'm not sure of that. It seems far easier to maintain code written in a language where you have discrete graspable constructs than code written in a language with almost none.
Re:You still missed the point (Score:2)
Personally, I like having 1 main syntax rule over having 200 little annoying ones. It means I have to learn less to get the same amount of work done. Some people like a fruitless challenge like learning an obese syntax, and that's fine. Not me, though.
Re:You still missed the point (Score:2)
I still don't quite get the Lisp and Scheme obsession. Yes, it is certainly novel to be able to have a program recurse on itself and create its own anonymous routines, but the code is nearly unmaintainable and unless you take drastic measures, quite unreadable.
Like most other languages they are only nreadable if you don't know how to read it. Grok a language and reading it isn't difficult.
I prefer functional languages over any others when writing code. Functional languages in general are best suited to situations where you want to be as far away from the details of coding as possible and concentrate soley on the algorithms and Computer Sciencey aspects of what you're doing. At work, I prefer the mixture of Perl, C, and Java, depending on the application, because more people know them (not exactly a good reason) and they tend to work the best on the kind of things I do at work. In general the power of LISP (and other functional languages) just isn't needed at work.
Re:Perl's had it's day - It's become like COBOL (Score:2)
It would have been provocative had you given us some examples of languages that might replace Perl for sysadmin and CGI tasks, but you didn't, you just flamed Perl.
So please list these languages I should be using for CGI. And no, I won't use PHP, the glorified mix of Perl and HTML.
Mason? (Score:2)
Re:Perl's had it's day - It's become like COBOL (Score:2)
Re:Perl's had it's day - It's become like COBOL (Score:2)
Why should everyone put up with Python or PHP just because you've deamed perl old news? How do python, ruby or php do what perl does better? They don't. They do a few things differently, but they're all very similar and very much in the same mindspace. If you're going to abandon perl, you're not going to find anything revolutionary in those languages. Useful like perl they are, but they're nothing new.
Frankly, I'm not much of a perl fan, and I only use it when I have to do so to keep from being forced to use something like C, C++, Java, Pascal, Python, or PHP. But it still can be quite useful, still has it's place and fans. So does COBOL, which is a good thing, because there are 6-million-odd lines of COBOL still running businesses, and it'd be a shame if at least some of those those stuck maintaining it didn't enjoy it.
Re:Perl's had it's day - It's become like COBOL (Score:2)
Re:Perl's had it's day - It's become like COBOL (Score:2)
I like Scheme because it's consistent. But it's so spartan, which can be a pain for real work. Common Lisp all the way.
Still, there's not much of a difference between perl, ruby and python. Some syntax, even less semantics. Ruby seems definately the nicest out of them, but if you know perl, why bother learning it for almost no benefit? Rather, you'd take a hit in functionality, due to fewer libs Ruby has compared to perl.
Re:Perl's had it's day - It's become like COBOL (Score:2)
On common lisp and scheme I prefer the simplicity of scheme "syntax". otoh I've not done commercial lisp or scheme and in that situation availability of libraries may be the deciding factor.
Hey, are you dissing emacs, emacs rules, I love emacs/elisp
Re:Perl's had it's day - It's become like COBOL (Score:2)
Nah, I'm not dissing emacs. Just comparing myself to one of those people that do everything out of emacs. Except Squeak is a little more "normal" as far as UI is concerned. You know, windows, widgets, a mouse and all.
Squeak can be a little hard to get into, especially considering how it doesn't integrate into the host environment much at all. That is, no native widgets, &c. But once you do, it's like the shackles of so-called "modern" operating systems have been taken off, and you're free to change anything in your environment. Sure, you could do so in Linux, but making a comparible change in C/GTK+ would probably take 10 times more time and 15 times more code. And at that point, why bother?
Elisp is ugly (compared to Scheme and CL), but I'd rather have most of my editor written in elisp over C/C++ anyday.
Re:Perl's had it's day - It's become like COBOL (Score:2)
Enjoy it.
Re:Perl's had it's day - It's become like COBOL (Score:2)
Re:Perl's had it's day - It's become like COBOL (Score:2)
Point 2 is arguable: what do you mean by reusable? what do you mean by "it"?
If "it" is:
- Perl: that's what a programming language is. Of course you can use it again and again. Applies to any programming language.
- X_Module: that's what a module is. Of course you can use it again and again. Applies to any other decent module.
- Your_Code: do you mean reusable by you, or reusable by everyone else? The main criticism of Perl is that code is hard to read and maintain, which makes it hard to reuse by someone else.
If your code is being reused only by yourself, the advantage is meaningless. Anyone with a decent familiarity with their own code (any coder with good memory) will reuse their own code in any language, even BASIC.
Point 1: Valid point, but only if it does not interfere with Point 2. You see, part of what makes Perl "fun" is because it's "neat" in the figurative sense. It's a language that encourages cleverness over intelligence.
Cleverness may be welcome ocassionally in programming, but having it as the constant culture in a programming language is problematic to say the least. If cleverness gets in the way of solving the problem, it may be as welcome as a practical joker in an overworked hospital's emergency room.
Geez. (Score:5, Funny)
Re:Geez. (Score:5, Funny)
Larry Wall and linguistics (Score:2, Insightful)
That said, I can suffer through Wall's writing style if it means I can learn how to do new regular expressions.
So much for Mr. Linguistics... (Score:2)
Not a typo on his part either, it's repeated several times, so I guess he's just not very observant about words and stuff, is he? Yep, a really reliable linguist you got there.
it was originally spelled "pearl" (Score:2)
People who wish to disparage perl and rile up its zealots will often spell it "pearl". It looks like the author succeeded here.
For the lazy.. (Score:3, Informative)
The most common metacharacters have been preserved, so for the most part, you won't have to learn a new syntax for your regexs.
If you're lazy ... wait for the exegesis (Score:2, Interesting)
Great (Score:5, Insightful)
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.
Re:Great (Score:2, Insightful)
Why should Perl have forced upgrade incompatibilites like Microsoft Word? Arrgh.
Re:Great (Score:2)
It's been made clear from the get-go that Perl 6 is going to be breaking things. The idea is to fix a lot of the issues in the language and hopefully move it out of the "write only language" category that it's been relegated to.
Re:Great (Score:2)
And in case you need backward compatibility, I would be very surprised if you can't import a "perl5" module to get back to something more similar to perl5 syntax and semantics.
Perl5 will be the default (Score:2)
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
Re:Great (Score:2)
5 years after it's released, every regex library in existence will be compatible with the Perl 6 way of doing things, so you might as well start learning them now.
Re:Great (Score:2, Interesting)
In most ways, regexen will be less complex than ever, yet more powerful. Read Larry's rationale for changing them and let us know how he's wrong -- his reasons made a lot of sense to me.
The problem is that there is a shitload of utility and cgi perl that will be broken if the perl on the server is upgraded. In some cases, like at ISPs, the code belongs to lots and lots of people that are totally unconnected from the administration of the site, so updating it becomes a nightmare. It's probably going to mean running two versions of perl (fortunately, perl doesn't take up a lot of space in /usr :-P ) and having to invoke it with version numbers... the normal messy drill.
I'm sure that the changes will be great, but it's hard to get too excited since, I must confess, the current system didn't seem so horrible to me.
5 years after it's released, every regex library in existence will be compatible with the Perl 6 way of doing things, so you might as well start learning them now.
Obviously I will learn the new syntax. And I will update my scripts to work with perl6. Etc. Etc. The thing is, it looks like perl is going to be taking back a lot of the time it saved me in the past. Once I've paid that cost I may be able to forget about it, but at this point I'm looking at having to add something really tedious to my to do list. And it's not like I have a lot of thumb-twiddling time I can steal from...
And here I thought Solaris was backward for not having embraced perl earlier than Solaris 8. Maybe it will turn out that they were [unintentionally, I'm sure] smarter than I thought...
One thing that I'd like to hear about with this... (Score:5, Funny)
Doesn't anyone else find it ironic... (Score:3, Funny)
Free the regexes! (Score:3, Funny)
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!
Will perl6 = ruby? (Score:3, Insightful)
Re:Will perl6 = ruby? (Score:2)
Re:Will perl6 = ruby? (Score:2)
First impressions (Score:2)
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.
Assignments (Score:2)
# 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.
Larry has jumped off the deep end (Score:2, Interesting)
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.
Re:Larry has jumped off the deep end (Score:2)
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.
I'm not trying to start a flame war, but regular expressions, both in theory and in practice are simple concepts. Perhaps you're in the wrong line of work? I'm betting that you are completely lacking in theory, which is odd, because in my experience the older a coder the more Computer Science they were exposed to, but I'm sure there are exceptions. Go pick up a book on finite state machines, actually you don't even need that, go read the FSA bits of the Dragon book.
Re:Larry has jumped off the deep end (Score:2)
I'm glad I'm not the only one who thinks this... I absolutely HATE the idea of making
Now perl6:
or:
or:
is <sp> # sentence's verb
a <sp>
sentence/ # YUCK!
or:
Maybe it's just my personal bias, but I think comments, newlines and whitespace should be left OUT of regular expressions.
Shayne
recursive regular expressions (Score:3, Interesting)
this guy [perl.org] has been doing some interesting work [perl.org] 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.
Perl parsing Perl (Score:4, Interesting)
Dammit Larry ... (Score:3, Insightful)
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.
Re:Dammit Larry ... (Score:2)
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
Hmmm, I want, I want, I want. Maybe you try changing to: I'll write, and create your own language.
This will kill Perl (Score:2, Insightful)
A good language can introduce new features without changing the basics. This is why PHP got so popular so fast.
It will not. (Score:2)
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.
Re:This will kill Perl (Score:2)
Does PHP have inheritance yet? Or let's start simpler: has it stopped dumping every new function into a global namespace? This bugs me in elisp, and it bugs me in php. Actually, it's the fact that PHP passes objects by value (and that they removed the declaration syntax for byref and saddled you with the ugly syntax at call time) that caused me to stop using PHP.
That and PHP perpetuates the perlism nonsense of:
$foo->bar(baz,mumble);
As opposed to a much more sensible:
foo.bar(baz, mumble)
Or, when you think long and hard about about it, by using the logical start of the line as a statement beginner, the end of the line as a terminator, and that most args don't have whitespace in them or have other good logical delimiters if they do:
foo bar baz mumble
Only Tcl does anything like this, though lisp comes close (but I shouldn't need the top level of parens if I have other delimiters). It's just a shame that Tcl's runtime is so brain damaged, and that it's become irrelevant as a language these days.
perl 7 (Score:2, Funny)
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. :-)
what about embedded perl? (Score:2)
Anyone have any clue as to it's progress?
We've slashdotted perl.com (Score:2)
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.
Re:I just started learning Perl a two months ago.. (Score:2)
Re:Changing regular expressions? (Score:3, Informative)
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.
Guess you haven't seen txt2regex [sourceforge.net]? It doesn't support Perl 6 yet - but it supports about 20 languages at this point so I think you can reasonably expect to see more in the future :-)
Cheers,
Toby Haynes
Re:Changing regular expressions? (Score:2, Interesting)
Quote from Apocalypse 5:
Phil
Re:Regex request... (Score:4, Informative)
m!<a\s+href="([^"]*)">(?:[^F]|F[^O]|FO[^O])* </a>!x
i had to add the x on the end, because
if you want to figure out how to do this on your own, get a decent book on automata, and read about DFAs. when you can start thinkin about DFAs and regexes interchangably, your regex voodoo becomes so much more powerful. remember, regular languages are closed over complementation, so there is always a regex to make sure that a string DOESN't match a regex.
or, if you want to do a simple, not-quite-so-regular expression, do what the other guy said, and look into negative lookahead assertions.
Re:Larry Wall thinks he is Turing (or not). (Score:4, Interesting)
I don't believe that what Larry's talking about should strictly be called "Regular Expressions". But hey, what Perl 5 already has hardly fits that bill, especially with the embedded code atoms we have in 5.005 and above. You're right - what Larry's proposing is more like the pattern matching rules of Caml and Prolog. But Perl has always been about pragmatism rather than pedantry - I bet "regular expressions" is what most people will end up calling them, and what will most efficiently help most people understand the concepts involved.