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."
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
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.
Sincerely, Mike Bouma
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.
Because it's useful.
If you
want to do scripting use shell script+awk. If you
want to write a proper app use C/C++.
This is a false dichotomy. Not everything is neatly classifiable as "scripting" or a "proper app". As for using shell script, it doesn't work very well when you need to use pointers (and awk, iirc), which rules it out for most nontrivial tasks. Also, neither shellscript or awk have the same available libraries as perl.
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!
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".
It must be super to live in a world where you never have to maintain somebody else's code!
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.
http://www.cpan.org/src/unsupported/4.036/
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.
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.
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.
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).