Perl 5.11 released(nntp.perl.org)
nntp.perl.org
Perl 5.11 released
http://www.nntp.perl.org/group/perl.perl5.porters/2009/10/msg151376.html
5 comments
What is new?
If this is an actual question (rather than snark), check out the link I gave below to the changelist: http://search.cpan.org/~jesse/perl-5.11.0/pod/perl5110delta....
Thanks. ( It was an actual question. )
Cool, and sorry then if I seemed inclined to doubt it. The troll put me on edge, but that's my bad anyhow.
I wonder if perl would be less popular if it was a better language.
Are we seriously going to have this argument? This is Hacker News, where most of us don't play the Ford/Chevy game with programming languages. Most of us have used multiple languages and know exactly when to employ the right tool for the job.
Perhaps we should have a new rule: if you haven't built a full-scale web app in a specific language, we'd prefer you not comment on it.
Perhaps we should have a new rule: if you haven't built a full-scale web app in a specific language, we'd prefer you not comment on it.
I wonder what the world would be like if people made their own choices, not influenced by what's "popular" this week.
I don't care which language is popular, I want to know what makes a language popular. I try to choose languages orthogonally to popularity.
I want to know what makes a language popular.
"Jobs."
"Jobs."
There's a chicken and egg thing here...
Such is the reality of a field where the decision-makers are not practitioners.
Then people would spend a lot more time electing better choices when they could have spent time working on solving their problem.
Prove it.
(Every week I hear about some new asynchronous web server written in Python. Do people really want to spend time working on their own problems, or do they just want to type as much code into the computer as possible?)
(Every week I hear about some new asynchronous web server written in Python. Do people really want to spend time working on their own problems, or do they just want to type as much code into the computer as possible?)
All I'm saying that evaluating every research language out there and seeing how well it suits your problem would just take too much time. Getting acquainted with a few well-known languages and a few DSLs or cult-followed languages should be sufficient.
I can't wait for 5.88.
Perl is by far the worst widely used language that I have ever seen.
Why promote it here?
It has caused enough damage, particularly in the bioinformatics community where it is required/used by people who don't know any better.
From http://www.perl.com/pub/a/2002/01/02/bioinf.html:
"But Perl programmers may be surprised to find that their handsome language has become one of the most - if not the most popular - of computer languages used in bioinformatics."
Why promote it here?
It has caused enough damage, particularly in the bioinformatics community where it is required/used by people who don't know any better.
From http://www.perl.com/pub/a/2002/01/02/bioinf.html:
"But Perl programmers may be surprised to find that their handsome language has become one of the most - if not the most popular - of computer languages used in bioinformatics."
Perl is by far the worst widely used language that I have ever seen.
I will bite.
I think this perception is prevalent because Perl was most popular before programmers knew how to program. (We still don't, but we are doing much better than we were doing 10 years ago.) Perl was especially easy to use, and attracted many non-programmers (or programmers who "didn't care"), and this left a bad taste in many people's mouths.
The thing is, everything of that era sucked. C sucks ("Segmentation fault (core dumped)"), C++ sucks (diamond inheritance, no type safety), Java sucks (no way to reuse non-trivial code), PHP sucks (no lexicals!), etc. The common thread there is that it's very easy to write bloated, unmaintainable code. Perl made that easy too.
Fast-forward 10 years, and Perl has made an attempt to solve these problems. You can still use all your old Perl code, libraries, and skills... but you can also do OO correctly, you can also test your code easily, and you can also easily share your code with the community. The good parts were kept, the ugly parts are pushed to the background, and the bad parts were replaced.
Other languages have done a bit of this too; C++ has boost and C++0x, C has the Boehem GC, eliminating many memory management problems (but it sill has no type safety), Java is being replaced with things like Scala and Clojure (which let you use old code but not suffer with the Java language's stagnation), and so on. In the end, though, I don't think any of these languages have made enough progress. (Partially because the communities are convinced that their language Is Perfection, and haven't felt any pressure to fix things. Perl is constantly derided as The Worst Language Ever, but we just can't seem to stop using it, so there is a lot of pressure to fix things. This pressure has resulted in a lot of good work on the VM, and a lot of exceptional libraries.)
So the point of my rant, I guess, is that Perl from 10 years ago is not what Perl is today. You can still use your 10-year-old skills, libraries, and applications, though... but when you want to do something new, there are tools available to help you Do It Right. More Right than, say, Java or C, anyway. (Moose is significantly more featureful than even CLOS now! Java and C++ look like a first-year CS student's first attempt at designing an object sytem. That's not the fault of Java and C++'s designers, BTW; the computer science community simply had no idea how OO worked when Java and C++ were implemented. The difference is that Java and C++ have kept their broken object systems, but Perl has replaced its.)
There are a lot of people that don't like a language (or application) for some small flaw, and feel the need to completely rewrite everything from scratch. ("I say we take off and nuke the entire site from orbit. It's the only way to be sure.")
This is very time-consuming, however, and the results tend not to be particularly compelling. The Perl community has shown that incremental improvements work a lot better than throwing everything away and starting over. We kept some historical baggage, of course, but if you are willing to ignore that, you have a language that competes with the best of them. (BTW, Perl6 is a great example of how difficult it is to design and implement a new programming language. Even with some of the smartest minds in computer science working on it constantly, it is still not complete. Programming languages are big projects; most of the new languages that we've seen crop up lately are extremely limited in scope or features, and while stable, will probably never be as popular as the "worse" langauges.)
BTW, just so it sounds like I am not fanboi-ing for Perl; Haskell is another example of successfully-applied incremental improvement. As an example, Haskell 98's type system doesn't allow overlapping instances. Instead of creating a brand new programming language to address that problem, the GHC folks just fixed GHC's type system, and allowed you to turn on the fixed version when you want it. The good stuff was kept, the bad stuff was pushed back into the realm of "historical compatibility", and the language moved forward as a result. (See section 7.6.3.3 here, if you care: http://www.haskell.org/ghc/docs/latest/html/users_guide/type... )
Anyway, it's a shame that you are letting people from 10 years ago get in the way of being a productive programmer. Throwing away an entire language and a community every time someone writes a bad script is not always the answer.
I will bite.
I think this perception is prevalent because Perl was most popular before programmers knew how to program. (We still don't, but we are doing much better than we were doing 10 years ago.) Perl was especially easy to use, and attracted many non-programmers (or programmers who "didn't care"), and this left a bad taste in many people's mouths.
The thing is, everything of that era sucked. C sucks ("Segmentation fault (core dumped)"), C++ sucks (diamond inheritance, no type safety), Java sucks (no way to reuse non-trivial code), PHP sucks (no lexicals!), etc. The common thread there is that it's very easy to write bloated, unmaintainable code. Perl made that easy too.
Fast-forward 10 years, and Perl has made an attempt to solve these problems. You can still use all your old Perl code, libraries, and skills... but you can also do OO correctly, you can also test your code easily, and you can also easily share your code with the community. The good parts were kept, the ugly parts are pushed to the background, and the bad parts were replaced.
Other languages have done a bit of this too; C++ has boost and C++0x, C has the Boehem GC, eliminating many memory management problems (but it sill has no type safety), Java is being replaced with things like Scala and Clojure (which let you use old code but not suffer with the Java language's stagnation), and so on. In the end, though, I don't think any of these languages have made enough progress. (Partially because the communities are convinced that their language Is Perfection, and haven't felt any pressure to fix things. Perl is constantly derided as The Worst Language Ever, but we just can't seem to stop using it, so there is a lot of pressure to fix things. This pressure has resulted in a lot of good work on the VM, and a lot of exceptional libraries.)
So the point of my rant, I guess, is that Perl from 10 years ago is not what Perl is today. You can still use your 10-year-old skills, libraries, and applications, though... but when you want to do something new, there are tools available to help you Do It Right. More Right than, say, Java or C, anyway. (Moose is significantly more featureful than even CLOS now! Java and C++ look like a first-year CS student's first attempt at designing an object sytem. That's not the fault of Java and C++'s designers, BTW; the computer science community simply had no idea how OO worked when Java and C++ were implemented. The difference is that Java and C++ have kept their broken object systems, but Perl has replaced its.)
There are a lot of people that don't like a language (or application) for some small flaw, and feel the need to completely rewrite everything from scratch. ("I say we take off and nuke the entire site from orbit. It's the only way to be sure.")
This is very time-consuming, however, and the results tend not to be particularly compelling. The Perl community has shown that incremental improvements work a lot better than throwing everything away and starting over. We kept some historical baggage, of course, but if you are willing to ignore that, you have a language that competes with the best of them. (BTW, Perl6 is a great example of how difficult it is to design and implement a new programming language. Even with some of the smartest minds in computer science working on it constantly, it is still not complete. Programming languages are big projects; most of the new languages that we've seen crop up lately are extremely limited in scope or features, and while stable, will probably never be as popular as the "worse" langauges.)
BTW, just so it sounds like I am not fanboi-ing for Perl; Haskell is another example of successfully-applied incremental improvement. As an example, Haskell 98's type system doesn't allow overlapping instances. Instead of creating a brand new programming language to address that problem, the GHC folks just fixed GHC's type system, and allowed you to turn on the fixed version when you want it. The good stuff was kept, the bad stuff was pushed back into the realm of "historical compatibility", and the language moved forward as a result. (See section 7.6.3.3 here, if you care: http://www.haskell.org/ghc/docs/latest/html/users_guide/type... )
Anyway, it's a shame that you are letting people from 10 years ago get in the way of being a productive programmer. Throwing away an entire language and a community every time someone writes a bad script is not always the answer.
> Why promote it here?
Why expect the world to conform to your point of view?
Your post might have been useful if you had taken the time to list concrete things about Perl that you object to. As it stands, you just whine that someone posted something you don't like. That's pretty silly.
Why expect the world to conform to your point of view?
Your post might have been useful if you had taken the time to list concrete things about Perl that you object to. As it stands, you just whine that someone posted something you don't like. That's pretty silly.
Some things are objectively bad. This is one of them. Try google to see why.
You don't really provide any proof to back up your assertions.
What makes this statement true?
> Perl is by far the worst widely used language that I have ever seen.
What makes this statement true?
> Perl is by far the worst widely used language that I have ever seen.
Try google.
Why don't you try Google and paste in the links that you like?
Your posts in this thread indicate strong feelings about Perl. If you can't describe what you feel, though, nobody will be able to agree with you; they will just slowly get the impression that Perl detractors are a bunch of wackos. I think that's the exact opposite effect that you are trying to achieve, so... think about it for a bit, and write down some reasons why Perl is bad. (Failing that, write down some reasons why you don't like Perl.)
Basically, we are trying to have an intelligent discussion about programming here, and "Try google." adds nothing to it.
Your posts in this thread indicate strong feelings about Perl. If you can't describe what you feel, though, nobody will be able to agree with you; they will just slowly get the impression that Perl detractors are a bunch of wackos. I think that's the exact opposite effect that you are trying to achieve, so... think about it for a bit, and write down some reasons why Perl is bad. (Failing that, write down some reasons why you don't like Perl.)
Basically, we are trying to have an intelligent discussion about programming here, and "Try google." adds nothing to it.
The fact that Perl is so unfashionable and yet still far more prevalent than the trendy Ruby and Python (which are also good languages - I am no partisan) should tell you that it is not a bad language. I does however enable bad programming in a way that other languages do not.
It does however enable bad programming in a way that other languages do not.
This is wrong -- read StackOverflow some time, and you will find that people write horribly, horribly bad code in Java, PHP, Python, Ruby, C#, Haskell, ... anything. Bad programmers enable bad programming. The best a language can do is to make sure that the bad code is indented consistently.
(Have you read 1984? Replacing negative words with positive words does not make the world a positive place.)
This is wrong -- read StackOverflow some time, and you will find that people write horribly, horribly bad code in Java, PHP, Python, Ruby, C#, Haskell, ... anything. Bad programmers enable bad programming. The best a language can do is to make sure that the bad code is indented consistently.
(Have you read 1984? Replacing negative words with positive words does not make the world a positive place.)
I didn't say it's not possible to write bad code in other languages. I was refering to 'there's more than one way to do it', which allows more freedom to screw up.
I think there's a reason that Perl is still the number one scripting language, and it's good to see that development on it is still progressing.
I think there's a reason that Perl is still the number one scripting language, and it's good to see that development on it is still progressing.
There is more than one way to do it in any language.
So creationism is not a bad theory because many people believe it?
No. Creationism is a bad theory because it is inherently unprovable either way, and because people have provided evidence for the alternatives.
If you want to provide evidence that 'perl is a bad language' feel free. Of course, you'll be handicapped by the fact that there is no really widely accepted definition of a good or bad language, but you should at least be able to argue it one way or the other. You just seem to continually asserting that it's bad, hoping that it'll prove your point.
If you want to provide evidence that 'perl is a bad language' feel free. Of course, you'll be handicapped by the fact that there is no really widely accepted definition of a good or bad language, but you should at least be able to argue it one way or the other. You just seem to continually asserting that it's bad, hoping that it'll prove your point.
java cobol c++ fortran basic pascal php
A poor workman blames his tools.
A poor workman blames his tools.
Not a great defense. Perl is a great language for bioinformatics, and is also a great language used the right way. It's not persuasive to assume anyone who is critical of something cannot use it. Many good workmen criticism tools only to make better tools.
Not a great defense. Perl is a great language for bioinformatics, and is also a great language used the right way. It's not persuasive to assume anyone who is critical of something cannot use it. Many good workmen criticism tools only to make better tools.
So the quality of tools is not important?
Anything that is Turing-complete will do?
Anything that is Turing-complete will do?
/me hugs amichail
http://news.ycombinator.com/item?id=786874
http://news.ycombinator.com/item?id=786874
Sure quality of tools is important. But you first need to define what it is. Are you suggesting that there is an objective definition of "quality of programming languages" applicable to everyone regardless of the context?
I appreciate what you're saying. I was a big Perl fan, working with it almost daily from 1996-2004, and I still wouldn't strongly disagree with your first sentence :)
The thing is, it's like complaining that duct tape is poorly used.. which is often true, but duct tape still rules ;-) Perl has more than its fair share of problems but it has bound a lot of the Web together over the years. (Oh, and more recently there are some really clean, well structured Perl projects out there, but.. too little too late IMHO.)
The thing is, it's like complaining that duct tape is poorly used.. which is often true, but duct tape still rules ;-) Perl has more than its fair share of problems but it has bound a lot of the Web together over the years. (Oh, and more recently there are some really clean, well structured Perl projects out there, but.. too little too late IMHO.)
too little too late
So you're saying that every time someone figures out a new way to program, they should throw away their tools and rebuild everything from scratch? No thanks.
The reason I stick with Perl is because I can use all the "bad code" that happens to work, and replace it as time permits (or as I need to maintain and extend it).
So you're saying that every time someone figures out a new way to program, they should throw away their tools and rebuild everything from scratch? No thanks.
The reason I stick with Perl is because I can use all the "bad code" that happens to work, and replace it as time permits (or as I need to maintain and extend it).
No, I couldn't say that. What I'm saying is that the focus on "good" Perl came after Perl lost some serious hearts and minds to languages like Python and Ruby.
If you want to keep using Perl and enjoy the new stuff, that's great. For those who jumped ship and got up to speed on a new platform (as I did after 8 years of Perl), I don't see much reason to come back. Even Ruby's lacklustre performance is almost on a par with Perl now - http://shootout.alioth.debian.org/u32q/benchmark.php?test=al... - and Python is developing at a great pace.
If you want to keep using Perl and enjoy the new stuff, that's great. For those who jumped ship and got up to speed on a new platform (as I did after 8 years of Perl), I don't see much reason to come back. Even Ruby's lacklustre performance is almost on a par with Perl now - http://shootout.alioth.debian.org/u32q/benchmark.php?test=al... - and Python is developing at a great pace.
I agree that there is no reason to switch between Perl/Python/Ruby. They are all the same language with slightly different punctuation.
I think Perl has better libraries, but learning those and discarding your experience with one of the other languages is probably not much of a net gain.
I think Perl has better libraries, but learning those and discarding your experience with one of the other languages is probably not much of a net gain.
Oh, please... everything has good and bad parts. Perl 5 has e.g. CPAN and Moose. Afaik, no other mainstream language can really compete there, today.
But why repeat that, since it is a standard answer in all these endless discussions?
Let me instead note one big advantage for Perl: There are much fewer embarrassing trolls doing language wars.
But why repeat that, since it is a standard answer in all these endless discussions?
Let me instead note one big advantage for Perl: There are much fewer embarrassing trolls doing language wars.
Perl does not enforce good practices, perl does not enforce nearly anything. Which means which is a good hackers tool (isn't this HN?), but probably not very suitable for your "people who don't know any better".
What language does enforce "good practices"?
(You seem to think that the programming community knows what "good practices" are. I have not seen any evidence of that.)
(You seem to think that the programming community knows what "good practices" are. I have not seen any evidence of that.)
It's a cultural thing. If you use an obscure feature of Perl (or Ruby, for that matter) to do a common task in a novel way the community will call you a "wizard", high praise. Do the same in Python and someone will patiently explain that the rest of the community has reached a consensus that this thing is done this way, for these reasons.
Most of Perl's bad reputation (e.g. that it's a "write only" language) is simply because the community around the language reinforces that style of coding.
Most of Perl's bad reputation (e.g. that it's a "write only" language) is simply because the community around the language reinforces that style of coding.
Very good point.
As of late, I think Perl has gone more in the Python direction, and Ruby has gone more in the "old Perl" direction. (It is mildly amusing to watch the Ruby community make all the mistakes that Perl made 10 years ago, especially with its advocates' constant hatred for Perl.)
As of late, I think Perl has gone more in the Python direction, and Ruby has gone more in the "old Perl" direction. (It is mildly amusing to watch the Ruby community make all the mistakes that Perl made 10 years ago, especially with its advocates' constant hatred for Perl.)
I think Perl's bad reputation comes mostly from its expressive power. People directly perceive and compare the difficulty of reading and understanding a few consecutive lines or blocks of code. Understanding 20 lines of Perl is on average more difficult than understanding 20 lines of, say, Java. The upshot is that you need much more than 20 lines of Java to implement code equivalent to those 20 lines of Perl. But this fact tends to slip your mind when you're pounding your head against the screen trying to figure out how some specific passage works.
Yes, I think so.
I recently had to explain to someone what "_" means in Perl (not to be confused with $_ or @_). It was simple for me to answer, because I had the experience. But someone seeing it for the first time wouldn't exactly be able to Google it, or look it up in a man page; who would think to look for it under "perldoc -f stat"? What's more, this particular short-cut, while useful, has a side effect: if someone maintaining the code inserts a stat on a different file in between the original stat and the "_", then the source of the "_" changes. For a single character in a script, that's a heck of a lot of barriers for a new programmer.
I recently had to explain to someone what "_" means in Perl (not to be confused with $_ or @_). It was simple for me to answer, because I had the experience. But someone seeing it for the first time wouldn't exactly be able to Google it, or look it up in a man page; who would think to look for it under "perldoc -f stat"? What's more, this particular short-cut, while useful, has a side effect: if someone maintaining the code inserts a stat on a different file in between the original stat and the "_", then the source of the "_" changes. For a single character in a script, that's a heck of a lot of barriers for a new programmer.
Perl has demonstrated itself to be an effective tool for experienced sysadmins to write single-purpose or throwaway scripts, but applications spend most of their lives in maintenance. It it always a false economy to make things difficult for maintenance programmers, even unintentionally.
Pretty much everyone I work with has been burned by being handed some legacy Perl to maintain and as a result we are very reluctant to do any new work with it. The payoff for rewriting in Python is that the technical debt incurred for using Perl in the first place is repaid.
Pretty much everyone I work with has been burned by being handed some legacy Perl to maintain and as a result we are very reluctant to do any new work with it. The payoff for rewriting in Python is that the technical debt incurred for using Perl in the first place is repaid.
I think your first paragraph contains a non sequitur. The existence of the strict and warnings pragmas, Perl::Critic, Perl::Tidy, Test::More, the size of the bundled perldoc, CPAN testers, CPANTS, et al all contribute to the maintainability of Perl 5 applications.
If you choose not to take advantage of those tools when writing a Perl 5 application, you bear the risk yourself. How does that reflect on the language or the ecosystem?
If you choose not to take advantage of those tools when writing a Perl 5 application, you bear the risk yourself. How does that reflect on the language or the ecosystem?
Not to defend this particular programming idiom, but the third result for [perl underscore] is "About Special Underscore Filehandle" http://www.perlmonks.org/index.pl?node_id=613621 so it's rather easy to Google.
I'm not sure that's true. There are plenty of languages as dense as Perl (e.g. how much you can get done with just a screenful of code) but no-one says Haskell (or even Python or Tcl) is "write only" (for example).
Some Haskell is "write only" :)
http://dev.pugscode.org/browser/src
http://dev.pugscode.org/browser/src
See also these:
http://search.cpan.org/~jesse/perl-5.11.0/pod/perl5110delta....
http://search.cpan.org/~jesse/perl-5.11.0/pod/perlop.pod#Yad...
http://www.modernperlbooks.com/mt/2009/10/why-perl-5110-matt...
http://search.cpan.org/~jesse/perl-5.11.0/pod/perl5110delta....
http://search.cpan.org/~jesse/perl-5.11.0/pod/perlop.pod#Yad...
http://www.modernperlbooks.com/mt/2009/10/why-perl-5110-matt...
Maybe these also, if so inclined:
- new perlperf man page that looks interesting: http://search.cpan.org/~jesse/perl-5.11.0/pod/perlperf.pod
- 'use 5.11.0' also implies 'use strict' now, yay: http://search.cpan.org/~jesse/perl-5.11.0/pod/perl5110delta....
- new perlperf man page that looks interesting: http://search.cpan.org/~jesse/perl-5.11.0/pod/perlperf.pod
- 'use 5.11.0' also implies 'use strict' now, yay: http://search.cpan.org/~jesse/perl-5.11.0/pod/perl5110delta....