Slashdot Mirror
Perl Features of the Future - Part 1
Kevin writes "This story
highlights some of the features being included in Perl 6. "There will be substantial changes in the move from Perl 5 to Perl 6. We've been hamstrung for a while by the need to maintain backward compatibility all the way back to Perl 1. There are some things we want to remove, because they seemed like good ideas when they were introduced but they're more trouble than [they're worth] now."
Every time I look at Perl and see all local variables having to be declared as "my $foo" and "my $bar" I think, that must be pretty embarrassing for the language designer.
In serious programming, most variables are local in scope, while few or none are global. Perl variables default to global, so you end up having to fight the default with every variable you create: "my $computer", "my $documents", "my $images", "my $ms_bob", (sorry)....
I hope Perl 6 will turn its back on past booboos and make the things that clearly ought to be default the default, even at the cost of backward compatibility.
And if they really have guts, I hope they'll do what Wayne Gretzky always advocated and "skate to where the puck will be" by making "use UTF-8" the default from now on, and "use bytes" the exception (legacy mode). Windows, Mac, and the major Linux distributions are all converting to Unicode pretty fast now.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
Does this mean that I will be able to parse stuff out like HTML tags, and nested parenthesis?
Or even catching VBScript strings, with the "" inside a string representing a single ", so I'll be ale to parse out something like which currently is incredibly annoying to parse, especially if all you want to do is catch the comments at the end of the line.
here
p ull_quotes.gz .
Can I use Perl regular expressions to match balanced text? toc
Although Perl regular expressions are more powerful than "mathematical" regular expressions, because they feature conveniences like backreferences (\1 and its ilk), they still aren't powerful enough -- with the possible exception of bizarre and experimental features in the development-track releases of Perl. You still need to use non-regex techniques to parse balanced text, such as the text enclosed between matching parentheses or braces, for example.
An elaborate subroutine (for 7-bit ASCII only) to pull out balanced and possibly nested single chars, like ` and ', { and }, or ( and ) can be found in http://www.perl.com/CPAN/authors/id/TOMC/scripts/
The C::Scan module from CPAN contains such subs for internal usage, but they are undocumented.
> "my $computer", "my $documents",
Out of curiosity, are you a MS programmer ?
One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thank you very much).
The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.
Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.
On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this . Does he want Perl 6 to be flex or something?
I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. To put it bluntly, Perl scripts will still look less beautiful than our friend Mr Goatse. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.
Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but BSD^W Perl is dying. Larry is buggering it up the ass without lubricants, just like Shoeboy is doing to Larry's daughter.
There is a section for perl! This doesn't belong "programming"!
Maybe I won't get invited to the PERL hacker parties any more, but I have to agree. PERL 5's hacks for object oriented programming have always seemed unnecessarily complicated and ugly, and I don't see things getting any better in PERL 6.
...)
I too looked at Python. Like you, I decided that basing your language's syntax on differing amounts of whitespace was a really, really bad idea, not because it's ugly, but because I have enough trouble keeping tab damage under control on a single platform.
So I'm looking at Ruby. In fact, the only thing stopping me ditching PERL for Ruby tomorrow is lack of time for re-learning, given all the other new stuff I'm learning right now (J2EE, Objective-C, Cocoa, OpenGL,
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
If it's not hard to read, then why are the designers of perl 6 making a lot of efforts to make it a lot easier to read than perl 5?
Quoting Larry Wall from the Apocalypses:
- In fact, regular expression culture is a mess, and I share some of the blame for making it that way. Since my mother always told me to clean up my own messes, I suppose I'll have to do just that. [emphasis mine]
- But Perl has often been tagged as a language in which it's easy to write programs that are difficult to read, and it's no secret that regular expression syntax that has been the chief culprit. [emphasis mine]
- there's a lot of regex culture that needs breaking.
- [Read all of Apocalypse 5 to learn exactly why perl 5 sucks to read. Even the extended syntax ain't really the most readable syntax.]
- As a specific example, there are various ways things could improve if we muster the courage to break the ``weird'' relationship between @foo and $foo[].
... the botch that in Perl 5 requires us to distinguish $foo[] from $foo->[]
- I think length(@array) should be equivalent to @array.length(), so if there's a length method available, it should be called.
- Legacy Perl $pkg'var Should Die.
- odd looking constructions like: $foo->[1][2][3]
- We're definitely killing Perl 5's slice syntax
- Various special punctuation variables are gone in Perl 6
- Typeglobs are gone.
- I'd like to get rid of the gratuitously ugly \E as an end-of-scope marker.
- I've always thought qw() was kind of ugly, so I'd like to replace it with something prettier.
- Angle Brackets Should Not Be Used for File Globbing. Indeed, they won't be. In fact, angle brackets won't be used for input at all, I suspect.
- This allows us to simplify the special case in Perl 5 represented by the _ token, which was always rather difficult to explain.
- The basic underlying question is "What exactly do those curlies mean?" For Perl 5 and earlier, the answer to that question was, "Too many things". Or rather, too many things with inconsistent rules.
- curlies are so extremely overloaded in Perl 5
- The old use integer pragma was a hack.
There's more, but I got tired of skimming the Apocalypses.I agree. I was unduly influenced by Ada syntax here, and it was a mistake.
Just for a point of reference, I'm a perl programmer who doesn't fit your categories (a), (b), or (c), but still finds perl code hard to read fairly often.
With all that said, I'll close with one more quote from the Wall:
I, too, ditched Perl 5 for Ruby. I hated the OO and the way you had to expliitly make references to make lists of lists.
:-) You can learn all the interesting things about Ruby in a day, but in Perl, there's always something new to discover.
But I think I'll probably check out Perl 6 when it comes out. It looks like the OO and references'll be cleaned up, the new regex stuff looks kinda neat, and hopefully Perl and Ruby and Python will all be able to coexist peacefully when they're all ported to Parrot. Need to do some fany regexing from a Ruby program? Just write your regexing function in Perl 6 and link to it from your Ruby program!
Plus, exploring Perl is just fun
Duct tape, XML, democracy: Not doing the job? Use more.
s/can't/shouldn't/ :)
that was just for fun. (Well, actually it was also promptes by the fact that 'Apocalypses" sounds weird, and so I just grabbed another pluralization rule.)
But I didn't really know the real place to use that rule, so it was nice to have the chance to learn something. Thanks.
ps In case anyone is wondering, if you are talking about a _lot_ of Apocalypses, the correct rendering is "Apocaloodles".
Liberty uber alles.
"If I want to make a list of lists, and have value semantics, why can't I just say $a[5] = @b?"
It's called:
$a[5] = [@b];
how hard was that? Once again, it's nice to have *control* over value/reference semantics.
:Wq
Not an editor command: Wq