Perl6 for Mortals 224
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."
Where is... (Score:4, Funny)
Re:Where is... (Score:2)
Call me crazy, but I prefer Python syntax and Python semantics, and getting rid of all the damn syntax noise
A good article (Score:2)
Re:A good article (Score:2)
But more power to 'em. I just hope it's not some respectability thing thats drivin' this.
Re:A good article (Score:3, Funny)
Perl 6 is the way forward. (Score:5, Insightful)
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.
Re:Perl 6 is the way forward. (Score:2, Flamebait)
Why is it that people dislike change (read: progress) so much ? Its not like anyone ever said 'perl is perfect - leave it just the way it is'. So why all the sad faces when Larry tries to improve on what is already a great language ?
Because the people who like progress are already programming with better languages than Perl; the Perl users are the old guard (or the initiates).
Re:Perl 6 is the way forward. (Score:2, Insightful)
Re:Perl 6 is the way forward - Fat Chance (Score:2, Insightful)
It must be super to live in a world where you never have to maintain somebody else's code!
Re:Perl 6 is the way forward. (Score:3, Interesting)
Why is it that people who want to change things inevitably choose the label 'progressive'?
Perl isn't perfect, nor ever was. But that doesn't mean that any change is a good change. Not to say those developing Perl have made mistakes before... I'm not that bold... but let's just say that indirect object syntax was a rather dubious feature.
If you don't like a particular feature of the language don't use it.
Some of the changes you can indeed ignore... and most Perl people are pretty tolerant both features they don't use and ambiguity in their conceptual model of the language. You don't have to fully understand Perl to use it effectively... which is good, because very few people understand it fully.
Some of the changes you can ignore at the cost of some effort. The dot-operator nonsense falls into this category. Yes, they're fixing something that ain't broken, and trying to appeal to the sensibilities of people from other languages at the expense of veteran Perl hackers. But Conway has a good point. In Perl 6, you can redefine operators. This means you can have your -> and . operators back to 'normal' without much effort.
Of course, if you thought tie() made things hard to read, this and the Unicode support could wind up producing not only different dialects, but different languages. But that's another story.
After all, the motto of perl is 'there's more than one way to do it'
That motto should properly end, '...except when there isn't.' Perl presently has reliable destructors, but circular references are the responsibility of the programmer, and may produce a memory leak if you're not careful. Soon (if all goes well), circular references will be garbage collected, but we'll lose reliable destructors. Either way, not everyone was going to be happy.
Pardon me for cutting this short, but I have to get back to work. Suffice it to say, there are good reasons to be excited, but many of people's concerns are legitimate too. There is both opportunity and danger in change.
And I bet most of the moaners and whiners never wrote a line of open source code in their lives
Would their arguments be less valid if they hadn't? Would they be more valid if they had? This is argument ad hominem, and makes no interesting point.
Re:Is it really. (Score:4, Insightful)
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.
Re:Is it really. (Score:4, Interesting)
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.
Re:Is it really. - FUD (Score:4, Interesting)
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.
Re:Is it really. (Score:3, Insightful)
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.
You can still use perl5 or perl4 (Score:2, Insightful)
http://www.cpan.org/src/unsupported/4.036/ [cpan.org]
Re:Is it really. (Score:2)
There are going to be perl scripts written in perl6, object oriented style. If it catches on, there will be many many scripts written, including ones inside your company or group of friends. So at that point you can decide whether you can find the motivation to learn OO and Perl6. Either way, somebody will take the baton and run with it....
Like it or not, there is a great chance that Perl6 will catch on, because it has lots of support and probably a few book contracts! From what I understand, perl 6 is going to run perl 5 code....so if you don't mind being deprecated....
deprecated: marked for future replacement, not upgradable/supported, unwilling to move along with progress.
I can certainly understand how most computer ppl begin to have a limit for wanting to learn new stuff, but its all part of the job, like it or leave it....sux, don't it?
Re:Is it really. (Score:2)
Re:Is it really. (Score:3, Informative)
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
Messing things up or using Perl for what it fits (Score:3, Troll)
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.
Re:Messing things up or using Perl for what it fit (Score:5, Insightful)
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 program perl every day (Score:2, Troll)
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?
Re:I program perl every day (Score:2)
The semantics of that block of code are obscured by the loop semantics. By replacing it with a single hyper operator, the semantics are much clearer, I think.
This same thing can be applied to Perl's weak-typing. When we convert back and forth from the types, the semantics are now less clear. Dropping the types allows for the code to be much more readable and understandable since there is less crap that must be filtered out.
Re:I program perl every day (Score:2)
OO in Perl was a bolt-on, so it's not surprising that many of the features you claim it lacks were later bolted on. "use fields", for example allows you to have private member variables (just prefix the variable with an underscore). Likewise there are ways to produce private functions: declare an anonymous sub with my; it's even faster than OO.
Polymorphism in Perl5 is O(n) with respect to the inheritance tree depth, so it has the potential of being slow, agreed. None the less, I've never found OO-constructs to be the bottle-neck. (Ever use Devel::DProf?)
Once again, the bolting on approach.
my FooObj $obj = new FooObj...;
When used with the "use fields" and "use base" directives is fully type-case. In fact, I find myself using this for non-oo methods to enforce type-casing on hashtables (such as from database requests which would otherwise have NO type-casting in ANY language). It is the idea that you can use your knowledge of how the device works to minimize programming time (Such as w/ database queries), that perl's power shines.
Yes, it makes for more cryptic code on occasion. But that's just part of the learning curve. Did you ever get confused by:
struct my_struct_t (*my_func_ptr[20])(struct my_arg1_t arg1, int arg2);
When you work out the context it makes sence. The complexity is just a by-product of the adopted parsing conventions. Java tried to alleviate much of these syntactic line-noise, but it had the benifit of hind-sight. Java already has this garbage "bolted on" in subsequent versions:
BaseObj obj = new BaseObj() {
public run() {
};
Now C# has the advantage of hind-sight. But guess what, the next great feature will make even C# look occasionally awkward in version 3.0. That's what's great about evolution - you have all these wierd things like an appendix lingering around, and get to fuddle over what their original uses were.
In any case, one of perl's design goals has always been (and continues to be in perl6) huffman encoding of the syntax. Meaning easy things shouldn't require a whole hell of a lot of typing.. Java NEVER valued that. You can't just type a one line program. Even a simple (and VERY common) for loop requires:
Enumeration list = obj.createEnum();
try {
while ( list.hasMoreElements() ) {
MyFooType obj = (MyFooType)list.nextElement();
}
} catch ( InvalidIteratorException e ) {
But here's the catch... If you don't like the obscurity of say:
for my $idx ( 1
Then you can write:
for ( my $idx = 1; $idx The $_ variable itself is a good reason to boycott perl.
Granted, this was another legacy feature, but is still around because of the huffman encoding. If you're creating a new app and don't like cryptic stuff.. Or better yet, if you're a department and want to make it easy for new developers to join, then you simply utilize "use English" and viola, you have
"$ARG". No fuss, no fetter. (Though this doesn't work well in MT environments as I've found). But if you're not squeamish, then you can go the opposite route.. $_ was designed as the "default", and thus can be excluded in most uses. Thus
#!/usr/bin/perl
use IO::File;
$fh = new IO::File $ARGV[0];
while( $ARG = $fh->getline() ) {
$ARG =~ s/x/y/g;
print $ARGV;
}
can be replaced by:
#!/usr/bin/perl
use IO::File;
$fh = new IO::File $ARGV[0];
while( $_ = $fh->getline() ) {
s/x/y/g; # default $_
print;
}
can be replaced by:
while() { s/x/y/g; print; }
can be replaced by:
%> perl -n -e 's/x/y/g; print;'
can be replaced by:
%> perl -p -e 'tr/x/y/'
can be replaced by:
%> perl -p -e 'y/x/y/'
If you find yourself typing the first entry thousands of times for simple shell-scripts, you too would understand the power of the last statement. Once you've used the last statement enough times to memorize it, it's very hard NOT to use these features in your larger programs. Therein lies the problem. Most developers don't "use English" because they don't have to. Much like most java developers don't use javadoc comments (even though it's trivial to do so). Programmers are inherently lazy.. And that's a good thing (tm).
Not sure what you mean by sync int counter. In the highly volitile MT library you can just lock any variable to synchronize it.. That's the equivalent of:
synchronized (foo) {
in java. So no loss there. Additionally if you want non-blocking sockets in java, forget it.. It's not even an option. In perl, on the other hand, you have the full use of the non-portable ioctl and fcntl. What's more, you have "unix-select". Which is an awsome power to behold within servers.
A java-threaded instant messenger (via IBM benchmarks) crawled to a halt after some number of users had connected. The extra memory requirements for each thread were insane for such a simple task as IO multiplexing. select-based servers, on the other hand only have the overhead of one additional file handle. Granted threading approaches are insanely easy to understand and maintain, but they're not benifitial to performance (since the unix-select model could simply have multiple workers bidding for the same collection of file-handles). In perl, you have the choice to do either. In java, you don't.
More generally, this is a feature of any late-bound application. Ironically even Visual Basic (and hense most ASP) is early-bound. Python, Ruby, Lisp, and many others fall into this category. There are many unfortunate consequences of this design scheme, however. Most notably much compile-time-checking and provability of code. Further most concepts of object-oriented optimizations go out the window. Even perl6 which will be compiled will still be late-bound (It's just too useful).
I like $_ (Score:2)
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:
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.
Re:Messing things up or using Perl for what it fit (Score:2)
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...)
Re:Messing things up or using Perl for what it fit (Score:2)
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.
Re:Messing things up or using Perl for what it fit (Score:2, Informative)
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."
Re:Messing things up or using Perl for what it fit (Score:4, Insightful)
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 [google.com] 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.
Perl 7 (Score:2)
#!/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
How about: (Score:2)
print ucfirst($_);
exit;
Perl sucks (Score:2, Troll)
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.
Re:Perl sucks (Score:2)
So, what you're saying is, that you couldn't write a script without learning the language, and thus you don't like it?
Well, so what? I don't like C. So I don't write C. Big deal. I don't go on about the way I think managed code (decent garbage collection for example) is nice, and that C forces you to cover your own memory space, and if I make a tiny mistake it'll leak and eventually slow/crash my machine.. instead I use something I do like.
I know this is
Re:Perl sucks (Score:2)
I personally think Perl is a dead end, but if it weren't criticism could have helped it.
Re:Perl sucks (Score:2)
Then you're no doubt familiar with the concept of a language that lets you shoot yourself in the foot (-; I'm sorry that Perl didn't work for you. But a lot of other people find that it works very nicely. The syntax is quite ugly, but it's not a show-stopping misfeature. Those familiar with the syntax can read it without that much difficulty. I use C++ and often come back to perl after a long break and don't have much trouble picking it up again.
IMO for fast admin like stuff people should use {ba,k,c}sh, sed, awk and expr.
These languages aren't substantially nicer. Try doing anything nontrivial in any of them (except perhaps awk) and you'll have a truly hideous beast on your hands.
Re:Perl sucks (Score:2)
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.
Let me preface my response with this: Since I started programming I've learned/used Applesoft BASIC, 6502 Assembly, Pascal, QuickBASIC, x86 assembly, C++, Java, and Perl. Never once was a language intuitively easy enough for me to jump write in a code without learning the language first. However, out of all of them Perl was the easiest to learn and put into real use.
Really, your post and most similar posts seem to read like "I don't know how to use it so it sucks."
That's kind of ridiculous. Not long after I learned Perl I got interested in learning Python. I guess in a way I expected that I'd pick it up quickly and it would be banging out code in a day or two. This wasn't the case. I gave up on it (at least for the time being) because I didn't want to spend the time to learn it. However, I at least learned enough about it to be impressed with it and put it on my list of languages that I'd like to learn at some point.
I find Perl much easier to use than C++, but just because you know C++ doesn't mean you'll automatically be able to program in Perl without learning it.
As far as posts about the ugliness of _some_ people's Perl code, I think there is a reasonable explanation for this. Perl is easy enough to use that people are able to write code in the language before they've really come to understand the pitfalls involved with writing unclear code.
Also, addressing comments about being able to accomplish different things in more than one way: Yes, it's true that this can lead to harder to read code. This also makes it easier to write _clearer_ code if used properly.
Well-written Perl code is extremely easy to read. There may be a lot of ugly Perl code out there, but it doesn't mean that clear, well-written Perl scripts are impossible.
Re:Perl sucks (Score:2)
That's extremely weird, as Python can be picked up in about 2 hours, by complete programming newbies, who know no language (unless you consider Visual Basic a language).
I found the Python tutorial to be quite awful at teaching Python, and maybe, when I have some time on my hands, I'll write a better one.
In any case, knowing quite a bit about Perl, and quite a lot about Python, its learning experience, and how it compares to other languages, I must recommend Python and recommend against any important usage of Perl.
Sure, if you somehow find it easy to use (all people I know, and myself can't even imagine how this is possible), use it for some simple text parsing scripts. But if you want anything you want to ever read again, use Python.
Re:Perl sucks (Score:2)
However, I've tried the *sh languages, and I have to recommend Python. Its not like Perl.
Its very very elegant, and I can almost guarantee you, that you will love it, at least if you try to be openminded about syntatic indentation, which is something everyone grows to love over time
Re:Perl sucks (Score:2)
- Python's syntax is very small and elegant, and almost never gets in the way.
- LISP has virtually 0 syntax, and there's really almost nothing to learn in that aspect.
As for 'nothing can touch Perl', I've yet to see a single Perl script that is not better done with Python.
Re:Perl sucks (Score:2, Informative)
I find languages like C++ and Java to be less "personalized" and therefore easier to maintain.
BTW, I find VB...um...frustrating. It's amazing how much you miss things like inheritence and polymorphism ;^)
Re:Perl sucks (Score:2)
What about polymorphism? Building the type into every usage of an object is a polymorphism killer, disallowing OO-style. Thus Perl, with its TIMTOUWTDI motto, still cannot really use true OO style.
Besides, its basically agreed upon, that Hungarian notation is evil and unreadable (NounThe AdjectiveHungarian NounSentence NounExample), which is exactly what $ and _ are.
More than one way? Yes, Python is the other way
Perl 6 for Perl 5-ers (Score:5, Informative)
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 [cpan.org] for example have been incorporated in perl 5.7.2, and a whole unch of new modules [cpan.org] 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 Onion [perl.com]0.
What's wrong with you people? (Score:5, Insightful)
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.
Re:What's wrong with you people? (MOD PARENT UP) (Score:5, Insightful)
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
Re:What's wrong with you people? (Score:2)
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.
What makes my threshhold go up is people who think that there are only three or four languages in the world. Perl is more productive than C or Java. Wow! And my Camry has better pickup than dump truck.
Is Perl more productive than Python? Lisp? Ruby? SmallTalk? Maybe it is. Maybe it isn't. Those languages at least a better point of comparison.
It's a big world out there! C, Perl and Java are not your only choices.
Re:What's wrong with you people? (Score:2)
Companies invest lots of time and effort in an environment; they don't just hop from one language to another as the fads change.
Thats why a lot of people still care about Perl, because they like it, and have invested a lot of time and code in it.
Why change all that and move to Python/Ruby/Lisp/etc...?
Re:What's wrong with you people? (Score:2)
That was not the issue. I can't get things done fast in Python, Scheme or Java either, but I do get things done fast in Perl. Just Do It.
Re:What's wrong with you people? (Score:2)
Pros and Cons of Perl (Score:2, Interesting)
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.
Re:Pros and Cons of Perl (Score:2, Interesting)
Of course, many of these tools will allow criminal bastards who shouldn't be allowed anywhere near a production codebase to perpetrate monstrosities. But they can do that already in any language they choose to pollute. And Larry has been making noises about allowing folks to write their own versions of things like strict, which, when taken hand in hand with the more accessible parser should mean that sites that want to can enforce their own rules for coding.
If you want to be good, Perl 6 is going to let you be better.
I disagree profoundly (Score:2)
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...)
Perl is like Juggling (Score:5, Insightful)
Re:Perl is like Juggling (Score:2)
Oh, and it took me about 40 minutes to learn to juggle.
Re:Perl is like Juggling (Score:2)
C++ (Score:2)
(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.
Fear Not: Pick and Choose (Score:5, Insightful)
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.
Useless quote of the day (Score:3, Funny)
Yeah, well, duh...
Hammers, nails, etc (Score:4, Insightful)
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?
Re:Hammers, nails, etc (Score:3, Insightful)
I don't think the author intended for a comparison out of resentment.
As for featuritis, what's wrong with looking at other languages, seeing what they did right (and wrong), and then learning from it? It's how the body of knowledge grows. Perl borrows bits from other places and perl-ifies it. Then at some point in the future, other languages borrow from what perl did, and improve upon it. The result is a cycle of improvement and innovation.
I love programming in Perl for many reasons; one of which is the lingustic aspects Larry designed into the language. If more features are added to make my use of perl more efficient, I'm all for it!
Re:Hammers, nails, etc (Score:2)
Turing-completeness has NOTHING to do with the issue at hand, of creating a language serving ease of development, eliminating error-proneness to shorten the development cycle, etc.
Almost all languages out there are Turing complete. The most obvious example is a Turing Machine.
To say "Perl5 didn't give us anything that Turing Machines didn't" is basically saying Perl's features do not exceed a Turing Machine's in terms of getting things done.
Re:Hammers, nails, etc (Score:2)
Of course the Turing-complete argument is FUD. However, if you read the article, you see that it was used in a sarcastic sort of tone.
I think the author was trying to say that new features will give new ways of doing things, not necessarily new things to do. That's a subtle distinction, but it is one worth making for many of the people that tend to complain about "mere syntactic sugar."
That's what the author, and many other people working on many other languages, are trying to say. OF COURSE the language can theoretically do anything; itis Turing-complete afterall. How effective it is at expressing a given operation in a reasonable amount of time is another matter. That is what Perl's syntax (especially the new additions in Perl 6), and that is what I think the author was trying to say.
Filehandles (Score:4, Insightful)
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.
Re:Filehandles (Score:4, Interesting)
open my $fh, $file or die;
will give you a nice shiny, lexically scoped filehandle.
And yeah, $| = 1 is a historical PITA. It's going away in Perl 6 though. Hurrah!
Re:Filehandles (Score:2, Interesting)
That works well with Perl 5.6...
'$| = 1' to autoflush a stream is ugly
Then use the full variable name? $| is in fact a shortcut for $OUTPUT_AUTOFLUSH (just make sure you Use English;)
I really don't see what you are complaining about, all you want to do is there, right here right now.
Re:Filehandles (Score:2)
On the autoflush: it's ugly to do:
select HANDLE
$| = 1;
I want to be able to do
autoflush HANDLE;
Re:Filehandles (Score:2)
Well, I think you'll be dissapointed then. I don't think file-IO is going to be part of the core. Meaning I think you might have to include at least one module to get any IO to work.
Given that, FileHandle is outdated. Use
my $fh = new IO::File "...", ".."
Even if you hate OO, its the most feature complete of the file-types.. Not to mention it's the only one that evolves with file-enhancements.
TypeGlobs are going away I think, so *FH won't be applicable anymore (though perl5 compatabilty mode will deal with it properly). Likewise with the global symbols which aren't thread-safe I don't think.
-Michael
Comment from a real PERL programmer (Score:3, Insightful)
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 [sun.com]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.
Re:Comment from a real PERL programmer (Score:3, Funny)
$/ = undef; $wc{$_}++ for split(/\W+/,); print($_, " = ", $wc{$_}) for sort keys %wc;
and got rid of 45 lines of java code.
AWW, MAN! How am I supposed to make any MONEY with perl if I get paid by the number of LINES OF CODE I write???? I have a LOC quota, you know.
(Just kidding)
--jeff
Re:Comment from a real PERL programmer (Score:2)
All of which are conveniently unquantifiable. The code snippet provided is quite readable to and maintainable by Perl programmers. (By the way,
Perl is a higher level language than Java, just as Java is a higher level language than assembler. If you think there's something inherently good (or readable or robust) about using a lower level language (which means more explicit actions, more steps chosen from a smaller vocabulary) why not go all the way and use assembler?
perl motto summararizes its fatal weakness (Score:4, Insightful)
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.
Re:perl motto summararizes its fatal weakness (Score:2)
If the programmer didn't correctly document his algorithms, it is unreasonable for you to decipher them.
This is a problem shared by all languages; without proper documentation, a piece of software is much more difficult to figure out.
Re:perl motto summararizes its fatal weakness (Score:2)
There's hardly any Perl code readable without commentary.
There's hardly any Python code unreadable without commentary.
Python code can usually be shorter than any Perl equivalent.
If you investigate the consequences of these sentences, you can produce the facts:
Perl is inefficient at representing code as a language (Getting the thing done)
Perl is ineffective at having working code convey the code's concepts to the next human reader (Getting the thing across to the next programmer)
This makes Python more efficient for thedevelopment process, and more effective for maintainability.
The fact Python is more easily learnt by newbies, and has strong typing and other more powerful semantics, is an added bonus.
Okay, I'll bite. If your organization is so weak (Score:3, Insightful)
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.
Re:perl motto summararizes its fatal weakness (Score:3, Insightful)
This already exists.. It's called CPAN.
In open-source (as with almost all perl), or when the 3'rd party was via another developer within the company, you at least have the option to trace through the code. Now most developers have to make some assumptions. These assumptions SHOULD be documented somewhere, but even when they are, the location of that documentation isn't always known. Perl again comes to the rescue with pod-documentation (similar to javadoc inlined documentation). You can put the description right next to the relavent regions, and at least in the relevant files. But, as we all know, developers are lazy and thus the added work of thourough documentation (in both java and perl) is lacking.
Now if you're proficient with the perl-code basics, then you have all the tools that you need to trace through a perl-module (or executable). Perl is highly context-sensative (name-spaces can be dynamically changed), arguably you have your work cut out for you (when it happens that sufficient documentation on such subtlties were not noted). The same can be said about java and package-spaces. There are tricks and tweaks a developer can do to perform efficient "magic" which is incomprehensible to an outsider (at least at first glance).
But to alleviate your problems, we have the debugger, which allows not only real-time inspection of the context, but thanks to the magic of late-binding, you can modify the context on the fly (importing new symbols, redefining old ones, etc, adding ad-hoc test routines). Java / C can't do this.
So yes, it is "harder" to debug / update someone else's code when they programmed above your level of proficiency. But if they were indeed more sophisticated developers they'd document their "magic". And if you weren't proficient enough to at least utilize the analitical tools at your disposal, then what are you doing modifying someone else's code?
-Michael
A rich vocabulary and sophisticated syntax is good (Score:2, Insightful)
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.
Re:A rich vocabulary and sophisticated syntax is g (Score:3, Insightful)
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).
Perl going the way of C++ (Score:3, Interesting)
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.
The Next Big Thing (Score:2)
Re:Perl going the way of C++ (Score:2)
If you look at the current state of the language, I see few features you could remove without compromising its fundamental goals of being C-compatible and object-oriented. References and operator overloading are the only ones that come to mind.
IMHO, Java is simpler than C++ only because of all the C baggage that was removed. Its removal of const and multiple inheritance did not make the language simpler, only more foolproof (multiple inheritance does have a frustrating tendency to unexpectedly blow up in your face, but it's no more difficult to understand than interfaces). And nobody who has ever used templates argues that C++ would be better without them (mmm, templates). I think it's really the legacy baggage of C++, and the need to have "two languages in one" that made it such a mess.
Anyway, complexity is certainly a major problem for C++, as its target audience is large team projects. But as for Perl, I think extra features don't harm its niche of small to medium-sized projects where maintainance isn't a major issue. And unlike other languages, it doesn't need to be mastered completely to be made effective use of, since there is more than one way to do it.
I learned enough Perl to write useful scripts in a weekend. Its huge number of features actually made things easier, because I was able to easily apply my knowledge of C and awk (which didn't help me at all when I learned Lisp, for example). I don't see Perl's death on the horizon (C++ isn't becoming unpopular anytime soon, either).
Perl 6's usefulness (Score:2)
Re:I still don't see... (Score:5, Insightful)
* 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.
Re:I still don't see... (Score:2)
Re:I still don't see... (Score:2)
Re:I still don't see... (Score:2)
Yup, and nope. We're new, but we have the benifit of hind-sight. Since we're open source, we can build upon any existing implementation of open-source jits/VMs. So lifetime is a red-hering.
We currently have a preliminary jit-compiler. Works pretty fast too. Currently it's 50% as fast as java's jit for a simplistic synthetic benchmark (considering the core isn't anywhere near finished). In theory parrot's jit can be faster than java's since we're using a register set instead of a stack-machine. Additionally, excluding java's grahpics library, perl has a larger collection of core c-routines for it's op-codes(Basically everything perl5 had). I'm curious to see if we can ultimately match java jit-speed; since we've already matched java VM-speeds. We also have a wider collection of fundamental types than java. Since strings in java are mostly handled by the String class. Then there's of course our ever-powerful scalar type with many useful low-level routines. In general, object orientation is at a higher level in parrot than within the java-VM.
-Michael
Re:I still don't see... (Score:2)
Re:I still don't see... (Score:2, Insightful)
I'm a long-time user of perl - one of those who defected to Python, in my case, mostly because Perl 5 OO really doesn't go the full hog - it still clings to Perl-4 type syntax - and your're left with what looks like, and feels like, a kludge:-( Going to Python seems a better use of my resources than re-learning perl, if I'm to learn another language.
What is it with Parrot? Why can't we stick to the JVM? There's already an experimental perl project for this (lingo?) and there's Jython - python for Java. I'd don't see the need for Parrot. Why re-invent the wheel?
Sure, the JVM might not be as ethically pure as Parrot but I'd want to bury the hatchet with Sun (or do a clean-room implementation of a JVM, just as MS are doing) if I wanted to beat
Re:I still don't see... (Score:2, Informative)
>about Python but now rather than tomorrow
Well, that's not true. The MT support in Python is rather limited, and python's Garbage Collector is like perl5's one.
On the other hand, I am was not comparing perl to python, but perl5 to perl6. So yes, many of this thing were in python or ruby. This means to me that perl was lagging behind in some areas, and so it did need this rewrite.
I like python. I like perl too. And i will like perl6 more than perl5.
>What is it with Parrot? Why can't we stick
>to the JVM?
Oh, Parrot and JVM are rather different. Stack-based vs Register-based. Designed for static languages vs designed for Scripting languages. They are totally different in the inners, and parrot is (will be) much more suited to scripting languages.
There will be probably a JVM port of Perl though. And there is people developing tools for translating Java bytecode to Parrot bytecode and the reverse.
Re:I still don't see... (Score:2)
But when you balance the two factors:
(1) Perl 6 is most certainly an incremental improvement over Perl 5, not something completely new.
(2) Completely rewriting a huge and previously stable language.
Then it doesn't make sense. That a complete rewrite is somehow better is a standard myth among inexperienced programmers.
Re:I still don't see... (Score:2)
But most importantly, the system is being built heirarchicly, like an OS. Each layer builds apon it's foundation layers. Thus the "robustness" should not be a problem. The main problems are going to be dealing with particulars of the syntax implementations (since they're non-trivial languages).
As for Perl5 reuse. It's strange but very little has been reused. Suggestions to do so are quickly quelched. Perl5 was non-thread-safe, non signal-safe, non-extensible. Thus the new core's paradigm (which includes layers) doesn't fit much of the old core routine. I believe one of the old code were the scalars, which are now 100% different. The monolithic functions of old are now tiny optimized multi-indirected functions. One thing that I think "might" survive is complete rewrite is the reg-ex engine, and other such monolith single-purpose devices. But that's too far in advance.
-Michael
Parrot will be pivotal in years to come (Score:3, Insightful)
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.
Re:I still don't see... (Score:2)
You miss the point. Perl6's syntactic redesign is mostly sugar. Likewise Ruby was mostly a syntactic redesign of perl5. Thus Ruby is not (nor will it be anytime soon) what perl6 attempts to accomplish.
You can think of perl as the x86. It's an aging legacy product that just never seems to die.. More-over, it's ever gaining market share (well, don't know about today with the recession and the migration to ASP). Why? because it did what was needed for a very wide audience. More-over this wide audience (coupled with open-source) afforded the sharing of code (mostly through modules) which avoided the constant reinventing of the wheel.
Sure there are viable alternatives to x86 (alpha, IA64, x86-64, etc), but they involve re-inventing at least part of the wheel, and many don't have the time. Someday python will have at least as much of a code base as perl5, but until it dwarfs perl5, it's not an "obvious choice". Ruby is just too new to really be compared on this level. What's more, so long as the inside is a black-box, who cares how it works; so long as it gets the job done in a cost effective manner (meaning either performance and or available code to reuse).
But this is exactly what parrot gives you. The ability (in theory at least) to use all of ruby, python, perl5, perl6, java, etc. Unlike JVM, which is early bound and thus can't "fully" utilize perl5 and friends, parrot should be able to run both java and perl5. In theory, the open-source platform could handly any language (albeit with missing optimizations here and there). So unless Ruby runs faster than parrot, there is nothing that it's black-box has over perl6 (and likewise the x86).
-Michael
Re:I still don't see... (Score:2)
Unfortunately you seem to want to have your cake and eat it too (don't you hate that phrase?). You praise perl for rapid design, and how features were added without compromising existing paradigms, then criticize the concept of TMTOWTDI. One of Larry's chief design goals has always been intuitive programming.. If you think something should work one way, then darn it, it should work that way. The problem is that Larry has to violate all sorts of consistencies:
if ( $x ) { doSomething() }
---
doSomething() if $x;
@file_list = ;
---
open FH,
@contents = ;
print MyObject @arguments;
---
print FH @arguments;
---
MyObject->print( @arguments );
---
$obj->print( @arguments );
And so on.
Granted, some syntaxes are only "intuitive" because that's how it use to work in perl4, so we'd expect something similar (albeit magic) in perl5 in another context. But that's the price you pay for having a history.
As with the switch statement, I never understood why Larry didn't include one. Even bash has:
case $x in
*.txt) # do stuff
*.pl|*.pm) # do stuff
*) # do stuff for default
esac
which was incredibly useful. My take is that Larry has finally found the huffman coding he's doing to the language compatible with this approach.
Remember, perl shares more with (k|ba)sh than c. (Need you look any further than the variable names?) So having nameing convenions different than "switch(x) case nine:.. break" is no straw off the camel's back *cough*.
As for streamlining the syntax-base. This could only hurt perl, since it would cripple the utility that we attribute to it. Larry is (hopefully) being very careful with what gets cut (such as formats which serve a highly specialized role or "?reg-ex?"). But notice even the teneray operator didn't stay alive. Larry determined that the ":" symbol was waaay too useful to waste on "var = cond ? true : false". So he mutated it to a parser friendly "con ?? true
Lastly, as for "everything is an object". This is purely from a parsing stand-point. In Ruby, you could theoretically do "1.print;" which would instantiate a new object. From the VM's point of view, a 1 is even more fundamental of a data-type than in perl5 since there was no concept of an integer, just a scalar. So unless you go around actually saying "1.method_name()", then you're not going to have any OO overhead.
As for OO being more cumbersome, I'd beg to differ. How about file-stat. Currently you use:
($dev,$ino,$mode,$nlink,$uid,$gid,$rdev,$size,
$atime,$mtime,$ctime,$blksize,$blocks)
= stat($filename);
Or:
$uid = (stat($filename))[4];
Which is very cumbersome. Now how about:
$stat = stat $filename; (notice the lack of OO syntax thus far)
$uid = $stat.uid;
notice the perl6 syntax which avoids the "->". If you wanted compaction, then you wouldn't be able to avoid OO as follows:
$uid = stat($file_name).uid;
or
$uid = $file_name.stat().uid;
or just
$uid = $file_name.stat.uid;
But notice how OO producing LESS syntax instead of more. And that's the whole point.. If a technology / paradigm makes things more efficient, then why reject it.
-Michael
Re:Just what Perl needs - more syntax (Score:2, Insightful)
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.
Re:Just what Perl needs - more syntax (Score:4, Insightful)
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.
Re:Just what Perl needs - more syntax (Score:2)
For weaker similar code (that doesn't actually test for the character types being letters only, and does not convert age to integer).
firstname, lastname, age = s.split(' ')
For a real equivalent:
firstname, lastname, age = re.match(r"([A-Za-z]+) ([A-Za-z]+) (\d+)").groups()
And if you wish, add:
age = int(age) afterwards.
If you ask me, it beats the Perl code, because re.match... is probably more readable, and the lack of syntax noise ($'s) helps too.
I'd love a Regular expression class suite, replacing the annoying unreadable regexp syntax, and that's possible in Python, and would make this look like:
firstname, lastname, age = (re.Word() + re.Word() + re.Number()).match(s)
Certainly more readable, and you can easily extend the regexp classes to include your own specific behaviours.
Re:Just what Perl needs - more syntax (Score:2)
Re:Maybe, possibly.. (Score:2, Informative)
Larry hasn't finished yet. There's another 30 Apocalypses due. So that means some things are conditional, and I've got to guess which way Larry is going to jump. So I do. And if I'm wrong, so what, it's still fun trying to read the tea leaves.
Re:dear GOD (Score:2)
You know, I had the same exact feeling the first time I opened my spanish book in high school!
So let me pass along some helpful advice.
First you learn the language, THEN you can read it. When you start learning any language, you don't learn all the nuances that make that language cool. You learn the simple stuff. You write the simple stuff. Then you pick up more advanced tricks along the way.
It's the same for any language.
Re:dear GOD (Score:3, Insightful)
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 [perl.com].)
Re:dear GOD (Score:2)
Think of readability as how easy it is to tell what the goal of a piece of code is. The assembly code makes it very easy to tell what each individual step does, but as a whole, it takes a lot of work. The semantics of the code block are obscured.
Perl6 adds so much to Perl5, specifically, a lot of things to unobscure the semantics of code blocks.
I'm really excited about Perl6, becuase I will be able to condense some of my complicated many-line idioms into much shorter 2-3 line segments with clearer semantics.
Re:Seems like the article wasn't for you (Score:3, Informative)
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.