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."
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?
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.
Well. Here are some:
.NET has get, I would say that people will love this feature. Or think of having a single mod_perl-like Apache module that can efficiently run Perl, Python, Ruby, Php, without needing a separte scripting engine for each one.
* True OO. This the killer one. Everything will be an object. Core functions will return objects. And you will have a decent (and probably extraordinary) syntax for creating classes. This is something that perl5 lacked, and it was killing slowly perl.
* Unicode support. Perl didn't have Unicode support, and adding it to perl5 was making everybody crazy. Not having unicode support is something too bad to bear in the age of XML and Unicode-supporting databases.
* A GC system that sucks less.
* Real multi-thread support. Perl didn't play well with MT, even worse than python (which forces you to have a global lock for everything). Perl6, on the other hand, will have MT support build from the start, and it will be as good as it can get.
* A general clean-up of the syntax, which will surely pay off on the long-term.
* A complete change on the inners. Perl will run on top of Parrot, which is a general-purpose register-based VM for scripting languages. There is the real possibility that in the mid-term languages like python, ruby, and probably many other will target Parrot, and thus getting all the benefits (true GC, real MT, and many others) of Parrot without having to duplicate all the effort.
This will also give the ability to call Perl modules from Python or Ruby objects from any other Parrot language. Considering the good response that MS
Perl 6 is important. Please don't let the little details you may don't like make you forget about the fact, that Perl definitetly needed a rewrite, and that it can be a very good thing for the OS community as a whole, not just for Perl hackers.
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
He didn't say "turn it off", he said "don't use it". Perl is perfectly usable without creating packages.
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?
You don't. So don't use objects. I use perl as a drop-in replacement for bash script all the time, and it works just fine. I don't see how perl 6 is going to change that.
From what I could make of Larry's "Apocalypse", perl6 is going to be the next fsckin' Java. Bloated, slow and useless.
Perl has very little in common with java.
If I pull all-nighters, then my code already starts to look like the Perl 6 syntaxis some people dread :)
I intend to live forever, so far so good.
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.
Despite some rumors, Perl 6 will not force any one to use or learn OO. There will be a lot for OO users to like but, like Perl 5, OO will be entirely optional. I was involved in the very, very early days of Perl 6 (I wrote about 3 RFCs), and this has been a design guideline that nearly everyone shared. I learned OO slowly and from Perl 5 (not C++ or Java, surprisingly), and I wanted to make sure that no one was forced to use any OO at all. There should always be More Than One Way To Do It.
Perl 5's current filehandles are a little bit like objects, and Perl 6's will be a little bit more like objects. That's as object-oriented as you will ever have to get.
I write CGI programs every week using the excellent, object-oriented CGI.pm module. This module, like Perl 5 and Perl 6, gives you a choice of OO or procedural programming, and I have always used the object-oriented way. In fact, it seems much easier to me. But, I understand where you're coming from. Before I completely learned OO, I was glad to be able to take it or leave it. Now that I know it and appreciate its advantages, I'm still glad to take it or leave it. :-)
By the way, your point would be better without the four letter words. But, that's par for the course on slashdot. Sigh.
Secession is the right of all sentient beings.
I know this was stated a bit more elegantly by another responder, but I thoughtg I'd point out some personal experience.
I used to be a die-hard C-only fan. I coded everything in C. Then I had to start scanning logs for certain patterns and keeping counts. Unless you find the right libraries, this is painful to write. Then I was introduced to awk.
Wow. Awk did seem like the tool to use. It had the matching strength I needed, and that seemed good enough so I wrote around 20 little awk scripts through which I'd pipe my data to get one thing done, and then another thing done. What I found was that awk wasn't very nice when it came to repeating files, or simply storing entire files in arrays for later processing.
Then a friend showed me Perl. All those little awk scripts seemed pointless. I have made a different dichotomy in my mind: if I want to do something very numerical on a large set of numbers, I use C. If I want to do something involving lots of strings (and I don't need to manipulate on the byte level very often), I use Perl.
Now, I have had people try to introduce me to Java, and to Python, but I really cannot see how Java makes a numerical C program easier, or how it makes a stringy Perl program easier.
Just my little experience.
I demand a million helicopters and a DOLLAR!
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".
I agree with most of your response, and am happy that someone was so level-headed about it. However, I write cron jobs all the time that use LWP, which would be a major pain if it were not OO.
my $ua = new LWP::UserAgent;
$ua->timeout(10);
my $rq = new HTTP::Request('GET','http://x.y.z/');
my $rsp = $ua->request($ua);
die "$0: x.y.z is down!\n" if $rsp->is_error;
The bottom line is that TMTOWTDI.
It's a functional programming thing, named for Haskell Curry. The basic idea is that if you have a function with two arguments, f, and you call it passing in only one argument with value x, you get back another function f' such that f'(y) is equivalent to f(x,y). If you call f with a different value of x, then you get back a different f'.
This sort of thing is, if not exactly commonplace, a feature of the likes of Haskell, Lisp, Scheme, Perl 5 (if you did the hard work by hand), and various other programming languages that support closures. The perl 6 syntax is simply about making currying easier to use.
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 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.
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
Readability has nothing to do with how complex a syntax is. I'd agree if you say that Perl has one of the most complex syntaxes, but I'd disagree if you say that makes it harder to read.
To give you an example, here's a small program written in Parrot assembler, which, being an assembly language, has a very simple syntax with few operators:
set I1, 0
set I2, 20
set I3, 1
set I4, 1
REDO:eqI1, I2, DONE, NEXT
NEXT:set I5, I4
add I4, I3, I4
set I3, I5
print I3
print "\n"
inc I1
branch REDO
DONE:end
Is this program easy to read? Did you find out what it does? Probably not -- it's characters might be more readable than Perl's, but it's not really readable since you don't easly understand it's meaning.
Readability is the combination of making it easy to understand what's going on in each single instruction, and making it easy to understand the algorithm. Understanding instructions is simple in Assembler (few, simple operators), but harder in Perl (what the hell does this operator do?). Understanding the algorithm is easier in Perl and harder in Assembler.
Somewhere between Assembler and human language is your personal preference and treshold for readability. For me, Perl is still readable while Assembler is often not. For others, Perl looks like a collection of junk characters.
That's ok, just don't judge the quality of a language by how it looks to you.
(BTW, the above parrot program prints the first 20 fibonacci numbers. I found it here.)
Sig (appended to the end of comments I post, 54 chars)
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.
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.
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.
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.
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.
For raw for loops, java is currently faster than Perl5; especially with a JIT. Perl5's biggest strength is in it's complex op-codes (grep, map, reg-ex, etc). This has the effect of JIT optimizing various high-use functions, but leaves basic flow-control to the mercy of performance.
Perl6 keeps the same complex and optimized functions of perl5 (though extracting them to external libraries to make the core clean), but utilizes the optimized byte-code and jit-able features of a java VM. Thereby getting the best of both worlds. In java, a reg-ex engine is most likely written in pure java. In perlX, reg-ex is optimized-c. Since their basic flow-control is now similar they should be comparible baseline.. Thus perl6 can only be faster than java (with equivalent code maturity). There is, however one additional MAJOR difference. Non jitted java is stack based, while perl6 is register-set based (I'm currently pushing Knuth's VM-register set for highly efficient subroutine calls).
Perl6 will NOT be an OO language, dispite many beliefs to the contrary. perl5 programs should be executable AS IS, and perl6 programs will look remarkably similar to those of perl5. There will be a higher performance OO support structure in perl6 than was in perl5 (which used recursive symbolic lookups on each method invocation), but this is completely optional, just as in perl5.
By the way, preliminary benchmarks show that non-JIT compilations of perl6 are faster than both perl5 AND java. We do have a JIT, but it's too rough to trust. But for our current trite benchmark, we're 50% of the performance of even the java JIT (and we avoid the overhead of a per-execution jit-compile).
So along with other posts, I believe that every element of your complaint has now been addressed.
perl6 focuses on speed, and compatability. While trying to reconsile convolution and complexity associated with perl5. Heck we're even supposed to be fully MT capable. Thus in all respects we should be able to compete directly against java and C#(including type-safety). So what exactly is your beef again?
-Michael
-Michael
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.
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).