Slashdot Mirror
Perl6 for Mortals
horos1 writes: "Hey all, I just ran across an article over at O'Reilly - Perl 6: Not Just For Damians which covers a lot of the negative commentary posted by slashdot on perl6 'featureitis'. Very interesting read, and IMO makes a hell of a lot of sense."
Reason being: written for geeks, read by geeks...
Perl6 for IMmortals. Highlander edition. I mean, I think it would take me a few hundred years to really understand Perl, which wouldn't be so bad if I was gonna live forever. :)
What, me worry?
I still don't see the "tremendous improvement" of perl 6 over perl 5 in practical use. IMHO nothing has really changed between the two versions.
__________________________________________
Take comfort in your ignorance.
Grandmaster Plague
A good article, and I hope that it accomplishes one thing: that people are willing to give Perl 6 an honest chance before burying it with arguments regarding syntaxis or "it's nothing new". I for one am anxious to see how Perl 6 will feel and how the differences will make my life easier.If it doesn't then I still got 5 waiting patiently to see me return to my senses :)
I intend to live forever, so far so good.
If you don't like a particular feature of the language don't use it. After all, the motto of perl is 'there's more than one way to do it'.
It seems to me that we should be praising the perl developers for perl6, not criticizing them. And I bet most of the moaners and whiners never wrote a line of open source code in their lives.
Surely only a fool would write an article about something they don't understand fully, and then hang it out to get shot at by the perl community?
cmclean
"Any similarity between the hooting of a million eager monkeys and Slashdot is purely coincidental." -THEFLASHMAN
Previously most Perl programs looked like the
aftermath of an explosion in a typewriter factory.
Now they'll look like someone blew it up while
the million monkies were typing on them.
Why anyone uses Perl is a mystery to me. If you
want to do scripting use shell script+awk. If you
want to write a proper app use C/C++.
The bottom line is that Perl is simply not the right tool for general programming purposes. I only use Perl as what it was originally intended to be - a "practical extraction and report generation language" that excels at scanning and computing huge amounts of text, as an integrated, improved replacement of the classical shell/sed/awk/grep etc. toolchain. Perl code can be readable and maintainable if it's written in C style and deliberately excludes the more esoteric features of the language. For anything else, and any "serious" - i.e. complex - programming, pick C/C++ or Python. It is no contradiction for me to concede this and still be a Perl afficionado.
gopher://cramer.plaintext.cc http://cramer.plaintext.cc:70
That article has been on the mainpage for several days.
I think perl as a language sucks like a vacuum cleaner.
Why? Because I've tried and tried in the past to write some small programs in perl. Each time it was a hassle to get aquinted with the stupid syntaxis. Forgot a $ sign here, did something wrong with a list there. The end result in each case was something horrible that couldn't be maintained after a few months of leaving it alone. And I don't believe it's me. People see me as a very experienced C++ developer and even give credit for the way I write perl code. But the fact remains that I can't read my own perl code after not touching it for two weeks.
I'll never, ever write perl code again. IMO for fast admin like stuff people should use {ba,k,c}sh, sed, awk and expr.
If you don't like a particular feature of the language don't use it.
Oh yeah? I don't like Perl6's object-orientedness. Could you be so kind as to tell me how can I turn that off? Yeah, I thought so.
Look, all this "change is great no matter what's changing and INTO what" is bullshit. Perl used to be a great language for admin stuff, CGI and glue code. Now can you please tell me why the fsck do I need a full-fledged object-oriented language to write scripts for cron jobs and CGI? Have *you* ever tried to write CGI in a fully object-oriented language? Why don't you go ahead and do that before you start accusing people of resistence to change?
Bah. From what I could make of Larry's "Apocalypse", perl6 is going to be the next fsckin' Java. Bloated, slow and useless.
If I am no the ONLY one not to be able to load the page, here is the google's cache of the page....
I'd never really looked into Perl before, but after reading through that document, and look at the examples, (both of perl 5 and 6) I can safely say that I will never learn it. My god, what a fucked up language. Most programming languages you can get a pretty good idea what's supposed to be going on just by looking, but with this?? Half of it looks like Asian smilies $^_+ WTF!?
It may be easy to write, but god, isn't there somthing to be said about being able to read a PL?
ReadThe ReflectionEngine, a cyberpunk style n
One of the coolest things about the Perl 6 development is that it leads to lots of improvements available right here, right now with Perl 5.
Attribute for example have been incorporated in perl 5.7.2, and a whole unch of new modules by Damian and others use them in tons of creative ways.
I am not sure this would have been done without the Perl 6 process. It forced the whole community to re-examine the language, take a step back and think of new ways to improve it. This would have been much more difficult if we had not had license to do it freely under the Perl 6 RFC process. This is the kind of things that keep a community alive and creative.
And BTW Perl 6 will still let you write quick'n dirty one-liners, and the first goal of the design of the interpretor is Speed (Larry mentionned "and it'has to be fast" about 25 times in 60 seconds in his last State of the Onion0.
Look, that's why there's rules, understand? So that you think before you break 'em. (Terry Pratchett)
Says who ? If you don't use it for "general programming purposes", you're not in much of a position to make such a judgement.
Perl code can be readable and maintainable if it's written in C style and deliberately excludes the more esoteric features of the language.
It's disingenious to call the OO support in perl a "more esoteric feature" of the language -- nearly all the modules use it. If you use the modules, you're not really using a "C-style" any more, because you're using perl OO code.
For anything else, and any "serious" - i.e. complex - programming, pick C/C++ or Python.
You're getting bogged down in false dichotomies, and arbitrary/absurd classifications. What if you want to write a shortish (~1000 lines) program that leverages an existing module , and the program isn't a drop-in shellscript replacement ? And what if there's no such module for python ?
I know I'm going to be modded to hell for this, but here goes: /. in this day and age? It wasn't that long ago that it actually was worthwhile to read people's comments here, but nowadays I mostly see my "threshold" going up, up, and not wanting to stop. I saw this article and thought "Wow! A nice, positive article about Perl 6 on my fave site /. which uses Perl", you know. And then I read all these pointless, silly and sometimes even mean comments about how baaaaaad Perl 6 is, and how everything Larry has done is wrong and screw Perl 'cause it's a sucky language, I use {Java|Python|New mega-exciting superlanguage} instead.
What's wrong with the people posting to
So do that.
Personally, I think Perl is the "Nike-language": Just Do It. When I want to code in C or C++ (I like C, I'm not too happy about C++) I always have to do all these things first. Look at man pages all the time, worry about casts and memory allocation and what not. When I do something in Perl I just do it. I find the modules, write some code, and it works.
And that's worth a lot.
:wq!
Hmm.. I hear the same fud when people talk about using Python for simple , quick and dirty scripts, etc. Just because Python gives you the ability to create classes , as well as advanced OOP features for a scripting language, doesn't mean that you have to use it at all.
I have seen and written many useful python scripts that do nothing more than impliment one function and the rest is just run out of the main.
With Perl moving (IMHO) maybe it's worth putting a few Python books aside and giving perl another look. (I haven't touched it for 2-3 years since I started doing Java programming and discovered python).
But these features are only as complicated as you force them to be.
BTW, Java can be as fast, if not faster, than perl for many many tasks. It all depends on how you write the code. Bad code can be written in any language. But frankly I wouldn't write Perl code where I would use Java, as I don't do that with Python. Like trying to use Bash scripts where perl / python would be needed.
To me, perl seems to have so many good points but at the same time seems to have a bunch of bad points.
The great thing about perl is that you can do anything in it. It also provides a good mechanism to abstract high-level concepts from the end-developer. The fact that it also provides low-level interfaces allows for one of the most flexible languages that I've ever used.
The problem with perl is that it is bloated. IMHO, a good programming language is simply, yet eligant. There should not be five ways to do something. There should also not be duplicate operators that accomplish the same purpose.
Operator overloading is one of those dangerous areas of C++ because it used improperly, it can create code that is unbelievably mantainable. Unless strict standards are followed when developing perl, perl is almost doomed to be horribly unmaintainable.
Even with all my criticisms, I would still use perl any day to lisp... It's great for little scripts. Perl6 seems to be moving in a general direction to make code even more unmaintainable.
int func(int a);
func((b += 3, b));
"as an integrated, improved replacement of the classical shell/sed/awk/grep etc. toolchain"
x t ) answers this so well:
.22
/alternate|options/ in regexes. Use gsed, awk or perl.
.45
Agreed, that's very true in some situations. I don't want to reinvent the wheel when the sed faq ( http://www.dbnet.ece.ntua.gr/~george/sed/sedfaq.t
6.5. When should I ignore sed and use Awk or Perl instead?
If you can write the same script in Awk or Perl and do it in less
time, then use Perl or Awk. There's no reason to spend an hour
writing and debugging a sed script if you can do it in Perl in 10
minutes (assuming that you know Perl already) and if the processing
time or memory use is not a factor. Don't hunt pheasants with a
if you have a shotgun at your side . . . unless you simply enjoy
the challenge!
Specifically, if you need to:
- heavily comment what your scripts do. Use GNU sed, awk, or perl.
- do case insensitive searching. Use gsed302, sedmod, awk or perl.
- count fields (words) in a line. Use awk.
- count lines in a block or objects in a file. Use awk.
- check lengths of strings or do math operations. Use awk or perl.
- handle very long lines or need very large buffers. Use gsed or perl.
- handle binary data (control characters). Use perl (binmode).
- loop through an array or list. Use awk or perl.
- test for file existence, filesize, or fileage. Use perl or shell.
- treat each paragraph as a line. Use awk.
- indicate
- use syntax like \xNN to match hex codes. Use perl.
- use (nested (regexes)) with backreferences. Use perl.
Perl lovers: I know that perl can do everything awk can do, but
please don't write me to complain. Why heft a shotgun when a
will do? As we all know, "There is more than one way to do it."
It took me ages to learn to juggle but now I can keep three things up in the air instead of two. It took me a fair ammount of time to grok Perl but now it lets me be very productive. Complicated things take time to learn, so don't write it off just because it doesn't look (or think) like C/C++/C#/Java. To the people saying "use C/C++/Java for proper apps" it's like saying "don't build your house from wood, you must use bricks".
It must be super to live in a world where you never have to maintain somebody else's code!
Take home message: language advocacy is a bad thing... but not doing it in Perl is worse ;)
I wrote it for an audience of people who already use perl, and who had read the apocalypses and exegeses describing what Larry has done so far. If I'd taken the time to explain the syntax then I'd've spent the majority of my article rehashing the references. Thank you, but no.
The particular example you cite is a currying parameter, using one introduces a currying context.
And you are so much the wiser already aren't you. But if you go and Read The Fine Apocalypse, you'll see that it's explained, with pointers to a more in depth explanation if you need it. Throwing up your hands in horror because you don't understand it and it looks weird seems a little extreme.
I ended up with this job because it is interesting and challenging. It's a fairly major application - we sell it for some pretty serious dough.
Anyhow - OO in Perl sucks. It's inelegant and not terribly efficient. End of discussion. No public, private, protected variables. Poor performance on inheritance and polymorphism. Should I go on? Sure, the modules use OO programming, but only a very simple subset of all the powerful concepts a real OO implementation will provide.
Furthermore, perl has virtually no typing. The code is rarely readable, escpecially the code written by the so-called perl gurus which use all kinds of funky constructs and features that don't translate over to another language.
The $_ variable itself is a good reason to boycott perl.
Overall, can you do stuff like "synchronized int counter" in perl? Even the threading is not production quality. (That would have made non-blocking sockets much easier)
However, perl has one gem. A true gem, that is a super-gun that will annihilate almost everything - it is the eval. Eval used correctly will save you hundreds of line of code. Used badly, it will slow your application to a crawl.
But why spend lots of hours on rarely run code, when you can use an eval and do the job in an hour?
Stop the brainwash
One of the headers detailing "bad things about Perl 6" is
:) Not as much as it used to, mind. I got around to actually looking at it rather than just being scared and it's not so half as bad as I expected.
"Perl 6 inspires fear."
And this is a change from previous versions of Perl how exactly? Perl scares me, whatever version it is
Roger
Do you have any better hostages?
Why all the griping? Am I also supposed to feel inadequate or frightened because I've not mastered Perl 5 and am now faced with Perl 6? Afraid not. I may not be a Perl wizard, but my scripts do some heavy lifting.
As a biologist turned bioinformatics programmer, I find Perl to be a fantastic tool. Bioinformatics Perl = string processing and glue. My Perl scripts move LARGE numbers of sequences in and out of Postgres DBs, feed and clean up after a variety of open source tools (written in C, python, tcl, and perl), serve up web based tools, and all within a clustered linux environment.
I openly admit to cracking the camel book and visiting cpan on a regular basis. I do this not because I'm a slave to a complex language, but because I find Perl and its associated community to be a rich source of tools. I harvest what I need to get the job done now.
First entomology, then virology, and finally bioinformatics systems. Bugs follow me wherever I go.
Yeah, well, duh...
I have worked on other's perl code and found it perfectly comprehensible. I think there is a culture amoung both the perl fans and the perl haters to claim that perl is more difficult than it really is. Once you understand references, perl is as easy as falling off a log. It really is an easy language to use.
http://www.cpan.org/src/unsupported/4.036/
Do people really say "false dichotomies" and "leverages" in real life? Or the above
post a joke by Scott Adams??
If you want to write it into a mess, you can do it. If you want to write it into something not messy, you can do it too. It's up to you. Also, you should use -w switch and use warnings.
But the fact remains that I can't read my own perl code after not touching it for two weeks.
If you don't write comments and try to be too clever for your own good, then this is what happens. I do advise you to either learn some more, or leave Perl alone.
I am personally looking forward to the creation of much smaller Parrot-based languages that truncate their syntax set and functionality to truly see how far into the realm of performance we can push VM-based languages.
Perl allows coding styles so different that two Perl programs may look as if they were written in entirely different languages. Perl6 seems to further this balkanization. This is why I consider Perl the wrong tool for large projects involving many programmers. (Imagine a Mozilla, Emacs or KDE written in Perl - shudder...)
gopher://cramer.plaintext.cc http://cramer.plaintext.cc:70
I program in perl every day too, and find that using perl's OO features is the most elegant solution to a number of problems. No problems with 'efficiency' (if by that you mean execution speed).
I agree. And the funny thing is that perl is not at all hard. When I first started serious programming I tried learning C and I dabbled in Java but I just couldn't *get* it. And then I discovered Perl and everything was right with the world.
Don't like the crazy symbols? Don't use them! Other than the $ @ % you can get by without using things like $_. And I'm sure with perl6 you won't have to use $^ if you don't want to. There's more than one way to do it. AND to one guy stated in an earlier comment that he couldn't read his own Perl after just two weeks -- don't whine comment your code.
A lot of people use and love perl, there's no reason to flame it even if you don't
The Anti-Blog
attempt to peddle a script language and sell a book. Geez, this is no better than Ruby, Rodel, Python, etc..
I admit PERL is neat, has many uses and generally belongs in every OS just like a fresh copy of GCC does.
But I don't see the merit in turning PERL into a huge fullfledged programming language. The intent of PERL was to expand upon shell scripts. I think to a large degree that has been achieved.
Personally I don't use PERL that much at all, but I can appreciate why people like it. Quick, fast, simple to write scripts for. Why add more features that will most likely not see real use.
Also what is with the "elitez PERL" programmers writting obfuscated code on purpose? To me things like what I saw in the article are not the best way of showing off the benefits of a language. Programming languages are above asm coding for the sole reason that high level abstracts like "if" and "switch" are easy to understand and use.
Instead of
if (a > b) c = d;
lets all write:
a-b>0?c=d:0;
because that's more obfuscated and "elite". In C both will compile to the same funcitonality [assuming a,b are signed] but the former is admitedly easier to read, understand and maintain.
Peace out,
Tom
Someday, I'll have a real sig.
Even if you're the only person on the project and it's private code, the 'other guy' is just you in a couple of weeks/months time. But it looks like you know this.
I'm preparing a presentation on Perl for my coworkers right now and I address this issue. It's my position that Perl's reputation for ugliness "comes mostly from fancy-pants Perl hackers showing off their obfuscation skills."
I use an actual example of code that someone used to "prove" that Perl is ugly:
Actually, that's just lousy coding. The following code, which does the same thing, is much better: In answer to the inevitable question "why is it better?", two reasons. First, it uses warnings, strictures and tainting which strongly channel the programmer towards writing robust, secure code. Second, by using well-named variables and comments, it's clear what the program does and how it does it.Perl does provide the freedom to write lousy code, perhaps even more so than other languages, and many programmers use that freedom. That's one of the side-effects of freedom: people will make choices you disagree with.
There is a movement afoot in the Perl culture to shun bad programming ... that's also how freedom works: if enough people don't like something, social pressure reduces it. For example, if the author of the exmple above were to post the code in comp.lang.perl.misc asking for help, he/she wouldn't get much help beyond "use strict and warnings" because those techniques are regarded as essential to any Perl programming and people won't help you if you don't help yourself (again, that's how freedom works).
IMHO, Perl is the language for "general programming purposes". Don't let some lousy coding throw you off on this point.
Miko O'Sullivan
Just wondering...
Programming languages are tools. Trying to nail a screw with a hammer and trying to write a CGI script in Java are two instances of the same problem (the latter generally of managerial origin, it would seem *sigh*). Right?
So. Is Perl6 the same darn fine '(formatted text -> data) && (data -> formatted text)' tool Perl5 is? If so, then it's great. Don't whine, you'll get used to the new syntax. (Note, I'm not a Perl junkie, so my appreciation of its aim as a tool may be inaccurate, I'll admit)
I'd be more concerned if the aim of the language itself shifted significantly. The mention of Python in the quote, "Yeah, and Perl 5 doesn't give us anything that a Universal Turing Machine, Intercal, or Python don't." makes me pause. Python in the same bag as Intercal. Hmm. Resentment? I hope Perl6 isn't trying to compete with Python out of resentment. That'd be stupid -- both languages rock, each in its own ecological niche (which don't seem to overlap much, BTW).
Bottom line: if Perl6 is a better (faster, more flexible, etc) tool for the same task, well, the new syntax is no big deal. However, if it starts undergoing featuritis just to compete with different tools, I'd start to worry.
Anyone care to enlighten a total Perl novice?
-- B.
This sig does in fact not have the property it claims not to have.
Using OO is not "programming in a C style". I extrapolated, perhaps incorrectly.
This is why I consider Perl the wrong tool for large projects involving many programmers.
But not all projects are "large" and involve many programmers. I agree that Perl wouldn't be the best choice for something like KDE. But for me, Perl works nicely for small programs (note emphasis: the use of the word "program" implies the task at hand can't easily be solved by shellscript or sed !) It's also handy for writing a throwaway prorotype prior to coding something in a "ral" programming language.
Are they're going to implement filehandles properly? I want to be able to do:
my $fh = open $file or die;
Because right now implementing a recursive function which opens a file is... odd... wrong... ugly:
Example snipped because of lameness filter.
(from man perlfunc, the open function)
Having to pass a string as a filehandle and manually incrementing it is just plain silly. Filehandles shouldn't be global. IMHO they just should be a reference or something similar.
Furthermore, the use of '$| = 1' to autoflush a stream is ugly. Why not 'autoflush($handle)' or something similar?
I do know about the FileHandle module. This module is proof that regular filehandles are too ugly. You shouldn't need the FileHandle module to be able to do basic filehandle stuff.
This is your sig. There are thousands more, but this one is yours.
Maybe Perl is bloated in that it's big, but what does that matter in practical terms? If performance is what you're concerned about, it's usually cheaper to throw more hardware at a problem than to throw more programmer-hours at it; I say, let programmers write in a language they can be productive in. (Obviously there are exceptions if you're building an application where performance is truly paramount, but in my experience performance is merely one consideration, along with issues like solution complexity in a given language, maintainability, portability, and so on.)
Perl definitely does give you enough rope to hang yourself with. But if you think that something like operator overloading is dangerous, then don't use it! Just because my car can go 140+ mph doesn't mean I mash the pedal to the floor every day, but it's nice to have the capability when I'm out in the middle of Montana and want to push the envelope.
In my experience, code maintainability has a lot more to do with the practices and discipline of the programmer than with the language they use. It's possible to create convoluted, hairy, unmaintainable code in any language. (I won't say the converse is true, because there is always Intercal...)
"Biped! Good cranial development. Evidently considerable human ancestry."
You can program OO using C, plenty of systems
have used it in the past.
Some of this Perl 6 stuff scares me too. Mainly because I think perl can be abused to write bad code. I am thinking stuff that is REALLY obtuse. I've seen code with $|++. Which is stupid. Because if $| == 1, then the code doesn't do anything and the inverse $|-- fails to achieve your purpose when $| == 2. STDOUT->autoflush(1) is the clear way to write it.
Just because dumb-ass "programmers" CAN write obscure code in perl, doesn't invalidate the value of Perl. Any language with expressive power is vulnerable to having "Obfusicate-X" contestants write programs in that language. A wise quote: "Fortran programmers can write Fortran in any language".
Perl 6 is looking to be the exact opposite of LISP. In my view, LISP has little or no syntax; just Lots of Incessant Silly Parenthesis. Well it looks like perl 6 is going to be nothing else but syntax.
This might be valid perl6:
I like perl by this might be to much for me.Of course the real reason I use perl is two fold; it's expressive power (unlike bondage and discipline languages) and CPAN (the killer feature).When I look at other languages like python or ruby, I look for their CPAN equivalent. Right now their is none, but maybe soon.
BTW, for the JAVA fans out there the following url is the same code as:
48 lines (took out comments and empty lines) versus 3.
BTW, This is as obfusicated as my code gets. I did it mostly for brevity.
-- I am not a fanatic, I am a true believer.
...for those of you who were confused. Thank God for AcronymFinder.com!
Have you noticed how many times the perl fans reiterate "isn't this cool, but of course you don't need to use it." "There's >1 way to do it."
Now I like functional programming as much as the next guy, but "There's >1 way to do it" is actually a symptom of the problem with perl. Yeah, I don't have to use the object-oriented triple-ended-pipe closure-thingeys so handily represented by $_?:^, but the last guy who worked on the code I'm trying to maintain now, did. So I'm stuck using (or dealing with) them whether I want to or not. When I interview a programmer I can't just ask, "Do you know Perl?". I have to probe just what subset s/he knows.
In my ideal programming language, there is exactly one program that solves each problem. That limits my search space while I'm trying to find it.
Yes, you can write OO code in C, which doesn't in anyway contradict my point.
Perl is a richer, more sophisticated language than those so-called heavyweights like C++/Java ( both of which I have used extensively. ) The 'funky' syntax, and 'strange' punctuation allow for more expressive and concise forms than in languages that force one way of saying something.
I use compound words all the time in speech, or even the occational big, or high falutin' word. Used with some judgement, using a wider vocabulary in discourse ( or in code if you are using a language that supports it ) makes you easier to understand. If someone doesn't know what you are talking about let them look it up.
(I know you didn't mean that, but the implication is funny.)
It hilites one of the truths of life. The languages you know are simple, straightforward and obvious while all those languages you don't are wildly confusing and wierd.
The cake is a pie
Not to start a flamewar on "to comment" or "not to comment" but the usage of comments in the latter example in a production environment is a little overkill.
:)
Hell I don't even do much perl work and I could tell everything except the regex without a comment, almost immediately. The regular expression probably needs a comment to say "hey here is what I'm doing since its less than obvious". When I am writing a book sure I dumb down my comment level so people can follow the example code.
When I am writing a production quality system I only comment when I do things that break accepted standard/best practice or to summarize blocks of code so that you can figure out what I am doing with comments without being innundated with an explanation of every function or feature of a language, in other words there has to be some assumed base level of knowledge.
I think there is a middle ground and it is best for the largest variety of situations. Any reasonably educated programmer worth his salt could pick up a well structured well commented program in ANY language and understand it. As soon as you know the underlying idea behind Java, or behind FORTRAN you should be able to understand the program, well placed comments enhancing this ten fold. I don't need documentation on the language in my production system
As to the fact that Perl is unreadable, that is false. The fact that Perl ALLOWS you to write obscure code, yep thats true. It is also true for any language or development tool tho.
Anyhow back to work for me.
Jeremy
that you can't institute coding standards, then yeah, stay away from perl. And from C, C++, java, lisp, etc etc etc. Unreadable code can be written in any language. But I say fix the real problem; gather your developers and put into place a set of coding standards and hold code reviews.
Perl isn't your problem, your organization is--try fixing it before you worry about features in language X.
And remember to use the language element that when done right makes any code readable: the comment.
This sig is false.
Perl6 suffers from the same problem that C++ has had over the years. In both cases, people tend to look at lots of tiny examples and come up with cool ideas to make things "nicer" for that example. The problem with this approach is that there are a very, very large number of cool ideas that make one situation or another "nicer." So lots of them get stirred into the mix. Adding two or three hundred cool new features to each version makes for a very complicated language after a few versions, especially when they interact and get used in unexpected ways. This is exactly the problem that C++ has had over the years, and the reason that other languages (Java, etc.) have gained in market share.
So, here's what will happen. Perl gurus will follow along. After all, Perl6 isn't that much more complicated that Perl5. Incrementally speaking, it's not too bad. But more and more newcomers will go with something a lot simpler: Python, Ruby, or the Next Big Thing. Why? First, if you look at Perl6 from ground zero, it is extremely daunting. The Perl6 Camel book is going to come in three volumes if it tries to maintain the same sort of coverage. Second, the design of a lot of Perl6 will be inexplicable except to people who know Perl5 and understand the history of the language. Finally, new programmers, especially good ones, want to really understand their tools from the inside out. They don't take kindly to the idea that they should learn 10% of the language, start using it, and catch up with the experts in a few years. So, over time, interest in Perl will dwindle. The old timers will retire or go into management, the newbies will be using something a lot simpler and more elegant. By the time Perl8 or Perl9 roll out, no one will care.
Perl's main problem is its reliance on "context". This is quite different from most programming languages that we use. With Perl (as it is used in the real world), this context is not always easily discernable by quick inspection. In other words, Perl's dependence upon context makes it confusing, especially so for maintenance programmers. Any Perl programmer who tells you that she has never made a "context" error is lying.
declared I was totally happy with Perl5.
Oh well... I'm just whining over the _ . thing.
"It's not stealing if you don't get caught!"
I think of it this way: If I don't know what ^=. means, I can look it up in the Camel or another corresponding dictionary. Problem solved.
If I don't know what is happening in terms of program logic, there's no dictionary that will easily, quickly explain it to me.
Perl collapses a lot of program logic into a few operators, making the language powerful for the experienced and easier to understand if people are un-lazy enough to look it up in a desk reference (sorry, Larry).
#!/usr/local/bin/perl7
# grab a line from STDIN, without the EOL
input = raw_input()
# change first letter to uppercase
input = input[0].upper() + input[1:]
# output it
print input
OR:
input = raw_input()
print input[0].upper() + input[1:]
</HUMOR>
I think most mortals will prefer Perl 7, despite its revolutionary syntatic/semantic changes
All Perl (<= 5) scripts I've seen, *including* ones for text processing, and heavy regular expression usage, were smaller to MUCH smaller as Python scripts, which were a lot more elegant and easily readable. Is there a reason to use Perl (6), other than Turing completeness that I find in Turing machines as well, over Python?
A rich vocabulary increases compactness. A richer syntax increases compactness.
While Perl offers a rich vocabulary, how is its syntax any richer, than a language that would allow representing anything Perl does, but forcing some specific readable representation?
Example: Is a language supporting: if a b;
and if b a; as two ways of saying the SAME thing, is it any richer than a language that supports if a b; alone?
The so-called richness of Perl syntax is merely duplicated syntax, increasing parsers' complexity (including the human parser), and do not compact the code.
In fact, the much stricter Python language can usually represent Perl code with fewer characters/lines, and still remain a lot more readable, etc.
This is because Python has a very rich, yet small syntax (probably richer than Perl's, as shown by the fact its more compact, usually), and a very rich vocabulary (libraries/modules/etc).
The huffman coding consideration hasn't gone away - therefore I don't see why $_ is legacy. It is an intuitive, human-centric way of recognizing focus. Which of the following is more intuitive:
- Wash, wax and vacuum each car in the lot.
- For each car CAR in the lot, wash CAR, wax CAR and vacuum CAR.
I don't see how (1) is more "cryptic" than (2). Anyone who objects to $_ ought to also object to having a current directory in his shell. If I type 'ls', isn't that cryptic? I'm not specifying which directory to ls.I find $_ clean and elegant, especially when it's used implicitly. It removes the visual noise of variable names that didn't matter anyway.
And by the same token, I am pleased with the unary '.' operator as described in the article. I really don't like typing '$self->{ whatever }'; it's more repetitive noise.
#!/usr/bin/perl -wTn
print ucfirst($_);
exit;
Perhaps someone should write a truely object oriented, cross platform, scripting language derived from some other cool languages and actually call it "The Next Big Thing". I can just see it now "The Next Big Thing for Dummies", "Learn The Next Big Thing in 24 hours". Of course it wouldn't be long before M$ released "The Next Big Thing.NET"
I think that comment in the text of the article was intended more to point out that there really isn't a whole lot to add to a language besides syntactic sugar, since perl is already Turing-complete.
I don't think the author intended for a comparison out of resentment.
You hit the nail on the head there.