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?
A good article, and I hope that it accomplishes one thing: that people are willing to give Perl 6 an honest chance before burying it with arguments regarding syntaxis or "it's nothing new". I for one am anxious to see how Perl 6 will feel and how the differences will make my life easier.If it doesn't then I still got 5 waiting patiently to see me return to my senses :)
I intend to live forever, so far so good.
If you don't like a particular feature of the language don't use it. After all, the motto of perl is 'there's more than one way to do it'.
It seems to me that we should be praising the perl developers for perl6, not criticizing them. And I bet most of the moaners and whiners never wrote a line of open source code in their lives.
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
I think perl as a language sucks like a vacuum cleaner.
Why? Because I've tried and tried in the past to write some small programs in perl. Each time it was a hassle to get aquinted with the stupid syntaxis. Forgot a $ sign here, did something wrong with a list there. The end result in each case was something horrible that couldn't be maintained after a few months of leaving it alone. And I don't believe it's me. People see me as a very experienced C++ developer and even give credit for the way I write perl code. But the fact remains that I can't read my own perl code after not touching it for two weeks.
I'll never, ever write perl code again. IMO for fast admin like stuff people should use {ba,k,c}sh, sed, awk and expr.
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.
Out of interest, could Perl's internals be replaced by a JVM, instead of Parrot? Then you'd benefit from the large amount of tweaking and tuning that has gone into todays JVM's. Would this speed up Perl at all? Just an idea...
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)
I see the need for a re-write but, from what I've read, this isn't the re-write it needed. Perl 6 doesn't give me any more clarity over Python than perl 5. All the things you say about Perl 6 I can say about Python but now rather than tomorrow - and Python still has far less syntactic sugar than perl 6. I'd say, on the evidence I've seen so far, that Perl 6 -still- doesn't hack it.
.NET. I figure inventing YAVM isn't the way to go. Go with what's already successful rather than pouring effort into something new, untested, untried, with yet another round of bugs and promotional effort all round. Reinforce the positive rather than reinvent the wheel, IMO.
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
Patriotism is a virtue of the vicious
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!
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.
Does Parrot have JIT compilation? Does it have 4+ years of optimisation? The JVM's have a come a long way in the last few years. I'd be suprised if Parrot could match it for a long while.
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!
Well, as I wrote the article and I'm reasonably confident I'm not a fool, I guess I'd better respond.
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.
To me, perl seems to have so many good points but at the same time seems to have a bunch of bad points.
The great thing about perl is that you can do anything in it. It also provides a good mechanism to abstract high-level concepts from the end-developer. The fact that it also provides low-level interfaces allows for one of the most flexible languages that I've ever used.
The problem with perl is that it is bloated. IMHO, a good programming language is simply, yet eligant. There should not be five ways to do something. There should also not be duplicate operators that accomplish the same purpose.
Operator overloading is one of those dangerous areas of C++ because it used improperly, it can create code that is unbelievably mantainable. Unless strict standards are followed when developing perl, perl is almost doomed to be horribly unmaintainable.
Even with all my criticisms, I would still use perl any day to lisp... It's great for little scripts. Perl6 seems to be moving in a general direction to make code even more unmaintainable.
int func(int a);
func((b += 3, b));
"as an integrated, improved replacement of the classical shell/sed/awk/grep etc. toolchain"
x t ) answers this so well:
.22
/alternate|options/ in regexes. Use gsed, awk or perl.
.45
Agreed, that's very true in some situations. I don't want to reinvent the wheel when the sed faq ( http://www.dbnet.ece.ntua.gr/~george/sed/sedfaq.t
6.5. When should I ignore sed and use Awk or Perl instead?
If you can write the same script in Awk or Perl and do it in less
time, then use Perl or Awk. There's no reason to spend an hour
writing and debugging a sed script if you can do it in Perl in 10
minutes (assuming that you know Perl already) and if the processing
time or memory use is not a factor. Don't hunt pheasants with a
if you have a shotgun at your side . . . unless you simply enjoy
the challenge!
Specifically, if you need to:
- heavily comment what your scripts do. Use GNU sed, awk, or perl.
- do case insensitive searching. Use gsed302, sedmod, awk or perl.
- count fields (words) in a line. Use awk.
- count lines in a block or objects in a file. Use awk.
- check lengths of strings or do math operations. Use awk or perl.
- handle very long lines or need very large buffers. Use gsed or perl.
- handle binary data (control characters). Use perl (binmode).
- loop through an array or list. Use awk or perl.
- test for file existence, filesize, or fileage. Use perl or shell.
- treat each paragraph as a line. Use awk.
- indicate
- use syntax like \xNN to match hex codes. Use perl.
- use (nested (regexes)) with backreferences. Use perl.
Perl lovers: I know that perl can do everything awk can do, but
please don't write me to complain. Why heft a shotgun when a
will do? As we all know, "There is more than one way to do it."
It took me ages to learn to juggle but now I can keep three things up in the air instead of two. It took me a fair ammount of time to grok Perl but now it lets me be very productive. Complicated things take time to learn, so don't write it off just because it doesn't look (or think) like C/C++/C#/Java. To the people saying "use C/C++/Java for proper apps" it's like saying "don't build your house from wood, you must use bricks".
>All the things you say about Perl 6 I can say
>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.
It must be super to live in a world where you never have to maintain somebody else's code!
I ended up with this job because it is interesting and challenging. It's a fairly major application - we sell it for some pretty serious dough.
Anyhow - OO in Perl sucks. It's inelegant and not terribly efficient. End of discussion. No public, private, protected variables. Poor performance on inheritance and polymorphism. Should I go on? Sure, the modules use OO programming, but only a very simple subset of all the powerful concepts a real OO implementation will provide.
Furthermore, perl has virtually no typing. The code is rarely readable, escpecially the code written by the so-called perl gurus which use all kinds of funky constructs and features that don't translate over to another language.
The $_ variable itself is a good reason to boycott perl.
Overall, can you do stuff like "synchronized int counter" in perl? Even the threading is not production quality. (That would have made non-blocking sockets much easier)
However, perl has one gem. A true gem, that is a super-gun that will annihilate almost everything - it is the eval. Eval used correctly will save you hundreds of line of code. Used badly, it will slow your application to a crawl.
But why spend lots of hours on rarely run code, when you can use an eval and do the job in an hour?
Stop the brainwash
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.
I'd never really looked into Perl before, but after reading through that document, and look at the examples, (both of perl 5 and 6) I can safely say that I will never learn it.
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.
"And like that
Yeah, well, duh...
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
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.
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 think it comes down to this...
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?
I need a TiVo for my car. Pause live traffic now.
Perl allows coding styles so different that two Perl programs may look as if they were written in entirely different languages. Perl6 seems to further this balkanization. This is why I consider Perl the wrong tool for large projects involving many programmers. (Imagine a Mozilla, Emacs or KDE written in Perl - shudder...)
gopher://cramer.plaintext.cc http://cramer.plaintext.cc:70
I 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)
Yup, and it's not too bad compared to the JVMs I've used. mod_perl is the fastest complex web programming environment I've used, and it's memory requirements are comparable to a servlet engine. Too bad that you can trash the server with it, and that object-oriented programming in current perl is ugly shit. I'm actually excited about trying out Apache 2 with mod_perl6. It might just be enough to make me forget about using anything else.
Expanding a vast wasteland since 1996.
My beef is not with OO programming. I would use nothing but OOP when I write an application server in Java, or a KDE app in C++. OOP has its place, and it's a very good solution for a lot of problems. However, there ARE places where OOP is totally inappropriate. Like CGI/mod_perl, or admin-related scripts. Perl was a perfect fit for this kind of things, because it was fast and powerful. Now when all the Perl internals are going to be rewritten to fit the OO paradigm in Perl6, not only will this impose a performance overhead (the interpreter WILL be slower, unless the dev team has out-of-this-world coding skills), but it will also force YOU to think in OO terms, even when all you want is to solve simple problems that would be better off dealt with in the old procedural way. But hey, that's just my opinion. Fortunately, there will be a Perl5 compatibility mode in Perl6, so I don't really have many reasons to bitch. :)
I'm preparing a presentation on Perl for my coworkers right now and I address this issue. It's my position that Perl's reputation for ugliness "comes mostly from fancy-pants Perl hackers showing off their obfuscation skills."
I use an actual example of code that someone used to "prove" that Perl is ugly:
Actually, that's just lousy coding. The following code, which does the same thing, is much better: In answer to the inevitable question "why is it better?", two reasons. First, it uses warnings, strictures and tainting which strongly channel the programmer towards writing robust, secure code. Second, by using well-named variables and comments, it's clear what the program does and how it does it.Perl does provide the freedom to write lousy code, perhaps even more so than other languages, and many programmers use that freedom. That's one of the side-effects of freedom: people will make choices you disagree with.
There is a movement afoot in the Perl culture to shun bad programming ... that's also how freedom works: if enough people don't like something, social pressure reduces it. For example, if the author of the exmple above were to post the code in comp.lang.perl.misc asking for help, he/she wouldn't get much help beyond "use strict and warnings" because those techniques are regarded as essential to any Perl programming and people won't help you if you don't help yourself (again, that's how freedom works).
IMHO, Perl is the language for "general programming purposes". Don't let some lousy coding throw you off on this point.
Miko O'Sullivan
Just wondering...
Programming languages are tools. Trying to nail a screw with a hammer and trying to write a CGI script in Java are two instances of the same problem (the latter generally of managerial origin, it would seem *sigh*). Right?
So. Is Perl6 the same darn fine '(formatted text -> data) && (data -> formatted text)' tool Perl5 is? If so, then it's great. Don't whine, you'll get used to the new syntax. (Note, I'm not a Perl junkie, so my appreciation of its aim as a tool may be inaccurate, I'll admit)
I'd be more concerned if the aim of the language itself shifted significantly. The mention of Python in the quote, "Yeah, and Perl 5 doesn't give us anything that a Universal Turing Machine, Intercal, or Python don't." makes me pause. Python in the same bag as Intercal. Hmm. Resentment? I hope Perl6 isn't trying to compete with Python out of resentment. That'd be stupid -- both languages rock, each in its own ecological niche (which don't seem to overlap much, BTW).
Bottom line: if Perl6 is a better (faster, more flexible, etc) tool for the same task, well, the new syntax is no big deal. However, if it starts undergoing featuritis just to compete with different tools, I'd start to worry.
Anyone care to enlighten a total Perl novice?
-- B.
This sig does in fact not have the property it claims not to have.
Using OO is not "programming in a C style". I extrapolated, perhaps incorrectly.
This is why I consider Perl the wrong tool for large projects involving many programmers.
But not all projects are "large" and involve many programmers. I agree that Perl wouldn't be the best choice for something like KDE. But for me, Perl works nicely for small programs (note emphasis: the use of the word "program" implies the task at hand can't easily be solved by shellscript or sed !) It's also handy for writing a throwaway prorotype prior to coding something in a "ral" programming language.
Are they're going to implement filehandles properly? I want to be able to do:
my $fh = open $file or die;
Because right now implementing a recursive function which opens a file is... odd... wrong... ugly:
Example snipped because of lameness filter.
(from man perlfunc, the open function)
Having to pass a string as a filehandle and manually incrementing it is just plain silly. Filehandles shouldn't be global. IMHO they just should be a reference or something similar.
Furthermore, the use of '$| = 1' to autoflush a stream is ugly. Why not 'autoflush($handle)' or something similar?
I do know about the FileHandle module. This module is proof that regular filehandles are too ugly. You shouldn't need the FileHandle module to be able to do basic filehandle stuff.
This is your sig. There are thousands more, but this one is yours.
Maybe Perl is bloated in that it's big, but what does that matter in practical terms? If performance is what you're concerned about, it's usually cheaper to throw more hardware at a problem than to throw more programmer-hours at it; I say, let programmers write in a language they can be productive in. (Obviously there are exceptions if you're building an application where performance is truly paramount, but in my experience performance is merely one consideration, along with issues like solution complexity in a given language, maintainability, portability, and so on.)
Perl definitely does give you enough rope to hang yourself with. But if you think that something like operator overloading is dangerous, then don't use it! Just because my car can go 140+ mph doesn't mean I mash the pedal to the floor every day, but it's nice to have the capability when I'm out in the middle of Montana and want to push the envelope.
In my experience, code maintainability has a lot more to do with the practices and discipline of the programmer than with the language they use. It's possible to create convoluted, hairy, unmaintainable code in any language. (I won't say the converse is true, because there is always Intercal...)
"Biped! Good cranial development. Evidently considerable human ancestry."
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.
(I know you didn't mean that, but the implication is funny.)
It hilites one of the truths of life. The languages you know are simple, straightforward and obvious while all those languages you don't are wildly confusing and wierd.
The cake is a pie
Thank you! Your comment gives a good example of what I have been trying to tell people about why Perl6 is a very good thing.
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.
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.
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
-Michael
I already use Perl 6. It's called RUBY.
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
-Michael
In the perl6-internals mailing list, you hear a lot of discussion about theoretical white-papers. Many developers perform complete implementations of these white-papers and are submitted as patches to the source tree.. From this, we can balance a multitude of variations on a theme, and pick the one we like best.
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
-Michael
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
-Michael
#!/usr/local/bin/perl7
# grab a line from STDIN, without the EOL
input = raw_input()
# change first letter to uppercase
input = input[0].upper() + input[1:]
# output it
print input
OR:
input = raw_input()
print input[0].upper() + input[1:]
</HUMOR>
I think most mortals will prefer Perl 7, despite its revolutionary syntatic/semantic changes
All Perl (<= 5) scripts I've seen, *including* ones for text processing, and heavy regular expression usage, were smaller to MUCH smaller as Python scripts, which were a lot more elegant and easily readable. Is there a reason to use Perl (6), other than Turing completeness that I find in Turing machines as well, over Python?
A rich vocabulary increases compactness. A richer syntax increases compactness.
While Perl offers a rich vocabulary, how is its syntax any richer, than a language that would allow representing anything Perl does, but forcing some specific readable representation?
Example: Is a language supporting: if a b;
and if b a; as two ways of saying the SAME thing, is it any richer than a language that supports if a b; alone?
The so-called richness of Perl syntax is merely duplicated syntax, increasing parsers' complexity (including the human parser), and do not compact the code.
In fact, the much stricter Python language can usually represent Perl code with fewer characters/lines, and still remain a lot more readable, etc.
This is because Python has a very rich, yet small syntax (probably richer than Perl's, as shown by the fact its more compact, usually), and a very rich vocabulary (libraries/modules/etc).
I use 's' instead of $_
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.
The huffman coding consideration hasn't gone away - therefore I don't see why $_ is legacy. It is an intuitive, human-centric way of recognizing focus. Which of the following is more intuitive:
- Wash, wax and vacuum each car in the lot.
- For each car CAR in the lot, wash CAR, wax CAR and vacuum CAR.
I don't see how (1) is more "cryptic" than (2). Anyone who objects to $_ ought to also object to having a current directory in his shell. If I type 'ls', isn't that cryptic? I'm not specifying which directory to ls.I find $_ clean and elegant, especially when it's used implicitly. It removes the visual noise of variable names that didn't matter anyway.
And by the same token, I am pleased with the unary '.' operator as described in the article. I really don't like typing '$self->{ whatever }'; it's more repetitive noise.
#!/usr/bin/perl -wTn
print ucfirst($_);
exit;
Perhaps someone should write a truely object oriented, cross platform, scripting language derived from some other cool languages and actually call it "The Next Big Thing". I can just see it now "The Next Big Thing for Dummies", "Learn The Next Big Thing in 24 hours". Of course it wouldn't be long before M$ released "The Next Big Thing.NET"
Yep. This changes in Perl6, though. In Perl 6, this is a complete class definition:
my $.x; # Instance variable
our $.y; # "Static" instance vairable ala C++
method bar ($param1, $param2) {
return $.x+$.y*$param2;
}