Weekly Edition
Return to the Development page
| |||||||||||||
|
| |||||||||||||
On the future of Perl 5
Here's an interesting
discussion from the "Journal of Ovid" on the usePerl site on the
(apparently) declining popularity of the Perl language. "When 5.12
hits we have a chance of winning programmers back, but the language has so
much baggage -- both technical and social -- that I don't think it will win
anyone back. We're losing because we didn't need marketing when we were the
duct tape of the internet and now we sneer at it. We're losing because we
rested on our laurels and scoffed at the up-and-comers. We're losing
because older programmers ignored the concerns of the younger
programmers. We're losing for the same reason that there are still people
who object to images on Web pages, much less Flash and Javascript."
(Log in to post comments)
On the future of Perl 5 Posted Dec 3, 2008 15:23 UTC (Wed) by clugstj (subscriber, #4020) [Link]
Every time I am forced to look at a perl script, I have to re-learn the meaning of the annoying variable name prefixes that indicate the type. This (mis)feature is enough for me to avoid the language like the plague.
On the future of Perl 5 Posted Dec 3, 2008 15:39 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246) [Link] I guess it came somewhat naturally to me, having programmed in Microsoft BASIC for all those years. That said, having $A refer to one thing, @A refer to another, and $A[0] refer to the latter, not the former (as opposed to, say, @A[0]) took a little getting used to. I'm personally wondering when Perl 6 is getting here. I personally put off learning Perl 5 in greater depth for awhile when I heard that Perl 6 was Coming Real Soon and was going to have Radical Changes. That was almost a decade ago. Maybe that had something to do with Perl's declining popularity?
On the future of Perl 5 Posted Dec 3, 2008 15:40 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246) [Link]
Personally, I personally feel I was personally redundant in that last paragraph. I personally apologize. Personally.
On the future of Perl 5 Posted Dec 3, 2008 16:01 UTC (Wed) by stijn (subscriber, #570) [Link]
Same here, I got used to the sigils pretty easily, back in 1994. Complaining about them is pretty similar to complaining about Python's use of indentation
for block structure. I find the latter pretty annoying, but at the same time it is just something to get used to and get over. Perl is not as idiosyncratic as sometimes made out to be.
About perl 6, I've found the apocalypses pretty depressing reading. There is heaps of syntax, and it seems that syntax of tokens/operators is overloaded to the fullest extent possible, depending on the types of the surrounding expressions. It looks too baroque for my taste. At the same time I'd like to salute Larry Wall for perl, I think he and co-authors created a great language and a good community. In bioinformatics perl is certainly still alive and kicking. Apparently the perl 5 internals have become hard to hack. Perhaps it needs a drastic solution (reimplementation that does not promise backwards compatibility) different from perl 6.
On the future of Perl 5 Posted Dec 3, 2008 17:11 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246) [Link]
As I recall, weren't they going to provide a Perl 5 reimplementation in Perl 6 to bridge old scripts forward? Of course, Perl 6 looks to be the ultimate case of Kitchen Sink Syndrome.
On the future of Perl 5 Posted Dec 3, 2008 17:48 UTC (Wed) by jordip (guest, #47356) [Link]
A friend of mine just entered in a bioinformatics lab and they ask her to learn Perl. I just took my first look to the language trying to help her and for simple data managing scripts it is quite neat.
I wondered why they make the students learn perl instead of other languages. It looks like there are a big library of scripts with all sorts of utilities noone want to rewrite .... Maybe I am wrong...
Biopython Posted Dec 3, 2008 19:56 UTC (Wed) by southey (subscriber, #9466) [Link]
No need to say any more than biopython http://biopython.org for bioinformatics.
On the future of Perl 5 Posted Dec 3, 2008 15:51 UTC (Wed) by kragil (guest, #34373) [Link]
Perl5 is a hideous write once language. Ruby and Python are just better in so many ways.
IMHO all distros should stop shipping it in their default installs (I know it is still used in a lot of places .. but eventually you have to get rid of cruft.)
On the future of Perl 5 Posted Dec 3, 2008 16:16 UTC (Wed) by orev (subscriber, #50902) [Link]
No, bad Perl programmers write hideous write-once programs in it. That's a byproduct of how flexible Perl is. But you could say the same thing about C, C++, Java, etc... Anyone can write a program that is hard to maintain in any language.
A huge majority of "programs" on most Linux distros are actually scripts, and Perl scripts at that. Removing it would take a herculean effort.
On the future of Perl 5 Posted Dec 3, 2008 19:10 UTC (Wed) by sbergman27 (guest, #10767) [Link]
I just spot checked a Fedora 8 box, and in /usr/bin and /usr/sbin, there are 2706 executables. 580 of those are scripts. 142 are perl scripts. So it's really more along the lines of about 5% of "programs" being perl scripts, and less than 25% of scripts being perl scripts. Also, I would imagine that the perl scripts would mostly fall under the category of command line utilities as opposed to full-blown programs, and would thus be easier to port to, say, Python.
What in the world made you think that 'A huge majority of "programs" on most Linux distros are actually scripts, and Perl scripts at that', BTW?
On the future of Perl 5 Posted Dec 4, 2008 0:05 UTC (Thu) by njs (guest, #40338) [Link]
> Anyone can write a program that is hard to maintain in any language.
I used to be a huge perl fan and made exactly this argument all the time. Then I noticed that, while it's true that one *can* write beautiful code in any language, if you look at the code that people actually *do* write, the actual average readability varies a huge amount between languages (and this is just as true for expert code as for quick-hack beginner code).
Arguments from absolutes, can vs. can't, are philosophically comforting; but in practice percentages matter at a lot.
On the future of Perl 5 Posted Dec 4, 2008 20:22 UTC (Thu) by elanthis (guest, #6227) [Link]
Unless you fail to understand what the percentages mean. :) Reminds me of how people keep claiming that PC games are dying because the percentage of PC sales vs console sales keeps shrinking, despite the fact that PC games are making more money year after year... statistics are useless if you don't analyze them intelligently.
The amount of bad code a language is going to have can be highly dependent on the language's popularity with novice and hobbyist programmers. Take JavaScript, for example. Almost every last single bit of JavaScript I've seen in real projects has been absolutely atrocious. Most of it actually breaks the rules that JavaScript implies, and ends up resulting in bugs that are not the language's fault.
It's a symptom of the fact that there are millions of people writing JavaScript code that have not a single ounce of real computer science software engineering education.
The same tends to be true for Perl in terms of UNIX/Linux scripting. It's the language-of-choice for users in that environment who need to hack together some quick something-er-other, so you get a lot of unskilled folks putting together crappy code because they don't know any better.
The worst thing that you could say about Perl is that its syntax makes it possible for unskilled programmers to write very ugly code, while other languages make it difficult for unskilled programmers to do anything without first learning a bunch of concepts and uncompromising syntax rules. Python, touted as an oh-so easy language, requires a user to learn more; you must understand OOP, scoping, function calls, variables, etc. to get anything done. In Perl, you can get an amazing amount done without understanding much at all.
On the future of Perl 5 Posted Dec 4, 2008 20:51 UTC (Thu) by njs (guest, #40338) [Link]
Well, yes, perl attracts beginner programmers. (Let's put aside for the moment whether python, originally designed as a first language for newbies, does the same.) But that's not what I'm talking about, which is why *I already said* that IME, expert code is also uglier on average in perl than, say, python.
My claim is simply this: in perl the path of least resistance is ugly code. That doesn't contradict your point: if your strength of will never falters then you can resist this and indeed, produce uniformly beautiful code - we agree. But, contrary to geek standard philosophy, real humans are not perfect rational agents. I have my moments of weakness. I suspect you do too. Can you really say you never succumb to temptation against your better judgement? Humans are messy critters, and ignoring that feels good but it doesn't actually help; we do better to admit it, study it, and design our systems to support our strengths while de-emphasizing our weaknesses.
On the future of Perl 5 Posted Dec 6, 2008 16:46 UTC (Sat) by sbergman27 (guest, #10767) [Link]
"""
python, originally designed as a first language for newbies, """
To my knowledge Python was designed as a successor to ABC, and with practical goals in mind. Although it is often recommended as a first language, I do not believe that it was originally designed as one.
On the future of Perl 5 Posted Dec 7, 2008 0:27 UTC (Sun) by njs (guest, #40338) [Link]
Right, I was thinking of the "Computer programming for Everybody" computer literacy initiative that got Python DARPA funding in early years; it looks like the history is more complicated than I implied, though.
On the future of Perl 5 Posted Dec 5, 2008 0:47 UTC (Fri) by johnkarp (guest, #39285) [Link]
Personally, I found it much easier to learn Python than Perl. I learned largely by reading existing programs. The bizarre use of punctuation, umpteen ways to write a conditional statement, and shuffling with 'shift' and '$_' are all somewhat offputting. In contrast, python reads like psuedocode in an algorithms textbook.
(I do end up using perl more than python at the moment, though I'd use ruby if that were supported where I worked.)
On the future of Perl 5 Posted Dec 3, 2008 17:04 UTC (Wed) by niner (subscriber, #26151) [Link]
Sorry, but Python is _not_ in any regard more readable than Perl.
The programmer was to lazy to invent a new method name? Ah so he just named it __call__ and made the object callable. Stupid crap like that can make code a horror to read. On the other hand I've read beautiful Perl code that was just like a book and instantly comprehensible.
The language has nothing to do with maintainability of code. One can abuse any
And yes, I _hate_ it that Python makes me write 15 lines of code, just because it doesn't
Or how do you want to execute code today? Would you use the builtin function eval,
Better stop here...
On the future of Perl 5 Posted Dec 3, 2008 18:52 UTC (Wed) by jbh (subscriber, #494) [Link]
What is list interpolation (or what do you mean by it)? I did try a web search, but didn't get any wiser.
On the future of Perl 5 Posted Dec 3, 2008 19:06 UTC (Wed) by niner (subscriber, #26151) [Link]
Another name for it is list flattening.
You have:
For example in:
In Perl, you would just do:
The workaround in Python is to create a temporary variable holding that array and
On the future of Perl 5 Posted Dec 3, 2008 19:34 UTC (Wed) by jbh (subscriber, #494) [Link]
Right, I recognized it under the second name.
-- quote:
You could use list concatenation (+) to do something like
"foo %s bar %s, %s, %s, %s, %s" % tuple([foo, bar] + map(lambda x: baz(x), [1, 2, 3, 4]))
... which is slightly uglified by the "%" operator not accepting a list (hence the "tuple" call). But yeah, it would be handy to be able to use the argument list syntax in other places.
Still, 15 lines? :-)
On the future of Perl 5 Posted Dec 3, 2008 19:39 UTC (Wed) by sbergman27 (guest, #10767) [Link]
Explicit is better than implicit.
It's a seven or eight line function to generically flatten any list to arbitrary depth. Hardly "much code". Save it in my_utilies.py, and import and use it anywhere, while avoiding "magic", and thereby *helping* readability. It's all that love of magic that gets Perl programmers, and the unfortunate maintainers who follow after them, into trouble in the first place.
On the future of Perl 5 Posted Dec 3, 2008 20:10 UTC (Wed) by niner (subscriber, #26151) [Link]
"Explicit" as in implicit type conversion? Just right now got bitten by that:
0: looks like a zero, tastes like a zero, but somewhere along the line got converted to a string and therefore it's suddenly True, not False.
Another very nice argument: "Perl looks confusing to outsiders coming from other
Whoops! What happened here? "++i" is obviously legal Python code with just one
On the future of Perl 5 Posted Dec 3, 2008 20:52 UTC (Wed) by sbergman27 (guest, #10767) [Link]
"""
"Explicit" as in implicit type conversion? Just right now got bitten by that: 0: looks like a zero, tastes like a zero, but somewhere along the line got converted to a string and therefore it's suddenly True, not False. """
Please be more specific. Where are you saying that Python does implicit type conversion? Python types dynamically, but strongly. Sure you're not thinking of Javascript, where "2" + 2 = "22"?
On the future of Perl 5 Posted Dec 3, 2008 21:36 UTC (Wed) by sbergman27 (guest, #10767) [Link]
Oh, forgot to mention that "+" is, of course, the unary plus operator:
---
> -x
> ++x
> --x
> +++x
> ---x
How would you handle that differently, keeping in mind that not stepping on Perl's rather bizarre syntax is not top priority?
And just to make a point:
---
In perl that would have silently become a numeric 0. Oops.
On the future of Perl 5 Posted Dec 3, 2008 21:44 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
++ can be a different operation than +
just like many languages use * for multiplication and ** for exponents
many languages also support the concept of i++ and ++i as a command to add 1 to i. in python it's valid syntax, but produced unexpected (to many programmers) results.
On the future of Perl 5 Posted Dec 3, 2008 22:05 UTC (Wed) by sbergman27 (guest, #10767) [Link]
Of course. I doubt there is a language that does not have a pothole or two to fall into for programmers coming from other languages. Niner's "++i" selection was a bit cherry-picked in my opinion. I wonder how Perl's "potholes per mile" figure compares to Python's? I've programmed in both, neither having been my first language, and I have a strong opinion on that matter.
On the future of Perl 5 Posted Dec 3, 2008 22:41 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
in my experiance with perl, if you try a construct from just about any language it will probably work, if it doesn't it will give you a syntax error (whitespace being significant is an exception)
this is both a blessing and a curse.
it's great for writing programs (especially when they really are one use), but it means that if you are looking at programs that other people wrote and have not done any thinking about code style you can run into constructs from many different languages.
On the future of Perl 5 Posted Dec 7, 2008 2:05 UTC (Sun) by madscientist (subscriber, #16861) [Link]
> And just to make a point:
> > --- >> x = "0" >> y = -x > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > TypeError: bad operand type for unary -: 'str' > --- > > In perl that would have silently become a numeric 0. Oops.
I don't get the point you're trying to make. When or why would Perls' behavior be an "oops"? Or put another way, what problem would this cause in the code?
On the future of Perl 5 Posted Dec 4, 2008 14:30 UTC (Thu) by pboddie (subscriber, #50784) [Link] "Explicit" as in implicit type conversion? There are hardly any implicit conversions in Python, and certainly none between strings and numbers. Just right now got bitten by that: My guess is that you used "print" or "str" to see the value, when you should have looked at the representation using "repr". Just evaluating the thing which provided the value in the interpreter would give you the representation. Whoops! What happened here? "++i" is obviously legal Python code with just one unexpected effect: nothing. It just does nothing. Endless loop, here we come. "++" is you using the unary plus operator twice, not some operator that isn't in the language: obvious if you've read even a small amount of the documentation. There are a few things about Python which could be better, even in Python 3.0, but I don't think the improvements need to come from the language in this particular instance.
On the future of Perl 5 Posted Dec 3, 2008 20:11 UTC (Wed) by rfunk (subscriber, #4054) [Link]
One person's magic is another person's useful syntax.
On the future of Perl 5 Posted Dec 3, 2008 20:09 UTC (Wed) by rfunk (subscriber, #4054) [Link]
Thank you. I get tired of people claiming that Python is so amazingly
easy to read. __Magic__ __underscore__ __symbols__ and hyper-verbosity don't translate to easy reading.
On the future of Perl 5 Posted Dec 4, 2008 2:04 UTC (Thu) by dw (subscriber, #12017) [Link]
In any sane code base, these method names will only appear in very specific places as part of tightly defined and documented classes, and would include a docstring. In my 8 years of Python, I have used __call__ exactly once, to try and emulate C# delegates, which turned out to be too insane to use in the end anyway.
Please ignore all the new-fangled "Pythonic" (GRRRRRR!) ORMs, template systems, and what have you that wonderfully misrepresent what makes Python nice in the first place (I'm talking about you here, Django).
I'm closely aligned to njs's way of thinking (see comment above). And if you think Python is verbose, you've either never read a line of C++ in your life, or you're reading really bad Python! With a good understanding of the core language (easily accomplished), it's actually pretty hard to write ugly code (__call__ and such) without trying.
It's worth remembering that the alternative to these ugly method names is special syntax, or friendlier method names that the average programmer is likely to overwrite by accident. That's why they are delineated with such brutishness.
Personally, if I was reading a piece of C++ that had "operator()" every 5 lines, I'd reserve my judgement on the language until I found some less crackpiped code.
...and that's about as coherent a comment as I can come up with having been awake 36 hours. :) 'night!
On the future of Perl 5 Posted Dec 4, 2008 9:35 UTC (Thu) by niner (subscriber, #26151) [Link]
> In any sane code base, [...]
> Please ignore all the new-fangled "Pythonic" (GRRRRRR!) ORMs, template systems, and what have you that wonderfully misrepresent what makes Python nice in the first place (I'm talking about you here, Django). > With a good understanding of the core language (easily accomplished), it's actually pretty hard to write ugly code (__call__ and such) without trying.
Thats _exactly_ _my_ point!
When you listen to American TV, you'd think that the English language is a horrible
On the future of Perl 5 Posted Dec 4, 2008 10:38 UTC (Thu) by sbergman27 (guest, #10767) [Link]
"""
A good programmer will write good, readable and maintainable code in just about any language. And on the same account, any language can be abused to write horrible monsters. """
And what you keep leaving out is that average programmers, the common case, will likely write the kind of code that the language encourages them write. All your hand-waving about how its possible to write good, readable structured code in TRS-80 BASIC (which is true) is only trying to distract from the reality that a quirky language that prides itself on its TMTOWTDI anarchy will likely reap (has demonstrably already reaped, actually) what it sews when average programmers get hold of it. And when they leave the project, their replacements, good, bad, or average, have to deal with the mess. That makes languages which encourage writing
BTW, I think a couple of us here are still waiting to see the evidence to support your claim that Python's PostgreSQL modules use popen() on psql.
On the future of Perl 5 Posted Dec 4, 2008 11:38 UTC (Thu) by niner (subscriber, #26151) [Link]
Sorry, but I just can't find a difference between average Python code and average Perl
code. Both are nicely indented, averagely structured and so so readable. I can only speak from my own experience which is a couple of 100,000 lines of code in each language. And this experience says: Python aims at forcing people to write readable code, but it fails. It certainly does not do worse than other languages, but it also doesn't do better. And yes, there is often more than one way to do anything in Python.
Now internals, that's someting different. As the current maintainer of Perl's Inline::Python
A funny thing tough: while in Perl you have to explicitly sv2mortal an object when
On that PostgreSQL thing: you must be confusing me with someone else. I've certainly
On the future of Perl 5 Posted Dec 4, 2008 14:35 UTC (Thu) by rfunk (subscriber, #4054) [Link]
Well, there are other common magic __underscore__ symbols in Python
besides __call__; __init__ is probably the most common one. (Though I haven't done much with Python in a while.)
Python is certainly much less verbose than C++, but C++ is a lower-level
On the future of Perl 5 Posted Dec 5, 2008 2:55 UTC (Fri) by sbergman27 (guest, #10767) [Link]
"""
And yes, I _hate_ it that Python makes me write 15 lines of code, just because it doesn't have list interpolation. Oh but yes it does, but only for function arguments. Talk about consistency. """
Apparently, someone agrees with you. I was just reading over the "What's New in Python 3.0?" document. And that inconsistency has been resolved. :-)
On the future of Perl 5 Posted Dec 7, 2008 18:40 UTC (Sun) by oak (guest, #2786) [Link]
> And yes, I _hate_ it that Python makes me write 15 lines of code, just
because it doesn't have list interpolation.
In my (very limited) comparative experience, yes, you spend more writing
Last experience I had with Perl was that Perl script took 15 min to write
(After that I avoided Perl like plague and Python improved a lot since
On the future of Perl 5 Posted Dec 7, 2008 0:06 UTC (Sun) by rwmj (subscriber, #5474) [Link] Perl5 is a hideous write once language Sorry, but you are talking utter nonsense. I have worked in a commercial Perl environment with 10 people contributing to a large Perl codebase (>250,000 LOC) and there was no problem understanding other people's code. There are many reasons not to like Perl, but your unfamiliarity with reading Perl is not one of them. Rich.
On the future of Perl 5 Posted Dec 7, 2008 0:16 UTC (Sun) by nix (subscriber, #2304) [Link]
By that argument, C is a horrible write-once language: I've seen appalling
unreadable spaghetti filled with longjmps and free casting between pointers and integers before (and had to maintain it, generally by rewrite).
What I think can be fairly said is that Perl, when exposed to programmers
On the future of Perl 5 Posted Dec 7, 2008 19:45 UTC (Sun) by chromatic (guest, #26207) [Link] Perl, when exposed to programmers who read absolutely minimal docs and mostly work by cargo-culting, is particularly amenable to having those programmers turn out unreadable crap. That's certainly true. Yet it's also true that a lot of that unreadable, unmaintainable code gets stuff done. The barrier to entry is exceedingly low, while the barrier to maintainable code is about as high as for any language.
On the future of Perl 5 Posted Dec 3, 2008 19:19 UTC (Wed) by jengelh (subscriber, #33263) [Link] Variable prefixes are actually simple ($ one, @ many). What is much more mind-boggling with Perl5 are all the puncutation variables: You mention variable prefixes, right, probably referring to PHP which uses $ everywhere. Well, you can also use $ everywhere in Perl, just make a ref/pointer instead of an array: @foo = (1..9); $foo = [1..9]; Oh yeah that leads to another thing. The choice of ( [ { } ] ) for list, arrayref and hashref. I really prefer PHP here which instead uses a function-style prefix, In fact, C showed oodles of years ago that no variable prefixes are needed at all. Coincidentally, having to predeclare all variables used makes for a better typo-resistant program. Yes, Perl has
On the future of Perl 5 Posted Dec 3, 2008 20:05 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246) [Link] In fact, C showed oodles of years ago that no variable prefixes are needed at allThat whippersnapper? What about COBOL? Algol? FORTRAN?
On the future of Perl 5 Posted Dec 4, 2008 0:16 UTC (Thu) by salimma (subscriber, #34460) [Link]
Don't forget Lisp.
On the future of Perl 5 Posted Dec 4, 2008 0:27 UTC (Thu) by jzbiciak (✭ supporter ✭, #5246) [Link]
Can you believe that all of those are 50 years old, except for COBOL, which gets that distinction next year?
On the future of Perl 5 Posted Dec 3, 2008 20:16 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
only a handlful of the puctuation variables are commonly used, so it's not like you need to memorize all of them.
On the future of Perl 5 Posted Dec 3, 2008 22:25 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link] And you can use English; if you would rather use $INPUT_RECORD_SEPARATOR rather than $/ (or if you get $/ confused with $\).
On the future of Perl 5 Posted Dec 3, 2008 22:35 UTC (Wed) by jengelh (subscriber, #33263) [Link]
INPUT_RECORD_SEPARATOR, wait, they should have called that use Cobol;
What is to replace Perl then? Posted Dec 3, 2008 15:51 UTC (Wed) by rvfh (subscriber, #31018) [Link]
If Perl is on the decline, which language is replacing it? I thought Python was ubiquitous, but I have the feeling that Ruby is growing faster now...
For example, most tools on desktops seem to be Python-based, but are new tools being developed in Ruby, or even Javascript? Or something else?
What is to replace Perl then? Posted Dec 3, 2008 16:33 UTC (Wed) by drag (subscriber, #31333) [Link]
personally I wouldn't mind Python. But it doesn't fundamentally matter that much.
All languages are ugly, cludgy, and stupid. Except for those elegant little research languages that are fundamentally worthless for the tasks that most people need to do.
The advantage main advantage of python, it seems to me, is that it's module library. You can now pretty much do anything you want in python...
Web server? Sure
There are modules for everything and anything you'd care to want and the Python 3000 effort is based in reality and is working on maturing the language. The whole 'kitchen sink and batteries included' is the main advantage of it as I see it.
What is to replace Perl then? Posted Dec 3, 2008 21:59 UTC (Wed) by jwb (guest, #15467) [Link]
You can do anything you want in python, except the incredibly simple things like parsing URLs. And the last time I tried to use the python postgresql interface, it was popen()ing psql behind the scenes. I would say that python's standard library has about 50% of the coverage of CPAN and roughly 10% of the maturity. If you want to get something done you can get it done quickly and easily in perl. If you want to gaze at the beauty of your code, python is a far better choice.
What is to replace Perl then? Posted Dec 3, 2008 23:00 UTC (Wed) by sbergman27 (guest, #10767) [Link]
"""
You can do anything you want in python, except the incredibly simple things like parsing URLs. """
Ummm... import urlparse and/or urllib? Which have been in the standard library for, oh... years and years? Unless you think those should be builtins?
"""
Please show me where this was ever true, if it was ever true, and when. IIRC, historically, there have been pgSQL, psycopg, and psycopg2 modules. Giving you the benefit of the doubt for the time being, *maybe* one of the early ones did that sometime back in the 90s or something. I've certainly never heard of it.
But based upon the level of disinformation I see in your post, it just looks to me like a Perl programmer feeling threatened.
What is to replace Perl then? Posted Dec 4, 2008 11:42 UTC (Thu) by niner (subscriber, #26151) [Link]
> Ummm... import urlparse and/or urllib?
> there have been pgSQL, psycopg, and psycopg2 modules
And they say that Perl is bad for there being more than one way to do something.
What is to replace Perl then? Posted Dec 4, 2008 17:58 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
to be fair there are sometimes alternate database packages for perl, the DBI/DBM arrangement works well for many things, but it's a 'least common denominator' type of interface.
for postgres there is the Pg.pm module as well as the DBI interface.
What is to replace Perl then? Posted Dec 4, 2008 23:07 UTC (Thu) by niner (subscriber, #26151) [Link]
Fair? The last version of Pg.pm is from April 2000, 8 1/2 years ago.
Honestly, who would be tempted by this ancient module?
What is to replace Perl then? Posted Dec 3, 2008 23:06 UTC (Wed) by drag (subscriber, #31333) [Link]
You could be right. I don't know about the relative maturity of either language's libraries of modules.
For parsing urls though it's simple. From within ipython shell:
In [1]: from urlparse import urlparse
In [2]: url = urlparse('http://lwn.net/Articles/309375/')
In [3]: print url.hostname
In [4]: print url.path
If specified in the string it'll do port, username, and passwords and whatnot.
What is to replace Perl then? Posted Dec 3, 2008 23:38 UTC (Wed) by jwb (guest, #15467) [Link] That wasn't exactly what I was referring to:Python 2.5.2 (r252:60911, Oct 5 2008, 19:24:49)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from urllib2 import urlopen
>>> urlopen('http://user:password@google.com/')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python2.5/urllib2.py", line 124, in urlopen
return _opener.open(url, data)
File "/usr/lib/python2.5/urllib2.py", line 381, in open
response = self._open(req, data)
File "/usr/lib/python2.5/urllib2.py", line 399, in _open
'_open', req)
File "/usr/lib/python2.5/urllib2.py", line 360, in _call_chain
result = func(*args)
File "/usr/lib/python2.5/urllib2.py", line 1107, in http_open
return self.do_open(httplib.HTTPConnection, req)
File "/usr/lib/python2.5/urllib2.py", line 1064, in do_open
h = http_class(host) # will parse host:port
File "/usr/lib/python2.5/httplib.py", line 639, in __init__
self._set_hostport(host, port)
File "/usr/lib/python2.5/httplib.py", line 651, in _set_hostport
raise InvalidURL("nonnumeric port: '%s'" % host[i+1:])
httplib.InvalidURL: nonnumeric port: 'password@google.com'
urllib2 can't understand a URL when the authority contains a colon. The fact that there exists, quite separately, urlparse module actually reinforces my point. The tuple returned by urlparse is completely useless anywhere else in the standard library. urlopen won't accept it. urlopen takes either a string or an instance of urllib2.Request object.
In Perl the situation is quite satisfactory. The URI module exists and works, and work harmoniously with HTTP::Message and its descendants, which in turn work harmoniously with LWP and WWW::Mechanize and so forth. Considering python's age and the fact that it has developed coincidentally with the web, you would think that python's web support would be quite mature by now, but it isn't. python's support for basic web operations in quite bad.
What is to replace Perl then? Posted Dec 4, 2008 0:15 UTC (Thu) by sbergman27 (guest, #10767) [Link]
"""
That wasn't exactly what I was referring to """
You mean when you said: "You can do anything you want in python, except the incredibly simple things like parsing URLs."? Yeah, I can see where you might really have meant you have a trivial quibble with the syntax.
Python URL parsing 101, in case anyone is interested:
---
> o = urlparse('http://user:password@google.com:8080/')
> o.netloc
> o.path
> o.username
> o.password
> o.hostname
> o.port
What is to replace Perl then? Posted Dec 4, 2008 0:17 UTC (Thu) by jwb (guest, #15467) [Link]
That's great, now what are you going to do with that tuple? You can't feed it to urllib2. urllib2 wants the URL as a string, but it can't parse all the ones that urlparse can parse. See the problem?
What is to replace Perl then? Posted Dec 4, 2008 2:40 UTC (Thu) by drag (subscriber, #31333) [Link]
Ya. I would consider that a bug.
What is to replace Perl then? Posted Dec 4, 2008 3:42 UTC (Thu) by sbergman27 (guest, #10767) [Link]
If so, it doesn't seem to be one that many Python users care about. I spend a lot of time in Python web development communities (Django, TurboGears) and its not something I hear complaints about.
urllib does support this directly:
---
There have, however, been a couple of request nibbles on the issue tracker over the last 4 years or so to add the functionality to urllib2 as well, and no actual opposition to it. Interestingly, there was activity today from a dev saying he was implementing it, noting that it would be trivial to do.
Personally, I think its probably a good idea, but since its just a few lines to handle this case, it doesn't really bother me.
Like I said, this seems something of a cherry-picked example to "prove" that Python's url handling is "not mature". I'm sure that Python and Ruby folks could pick more than a few cherries regarding Perl's problems if they wanted to.
What is to replace Perl then? Posted Dec 4, 2008 1:49 UTC (Thu) by jamesh (subscriber, #1159) [Link]
It probably isn't very helpful to you, but the RFC for HTTP URLs doesn't actually allow for putting passwords in the URL.
The urllib2 module can perform authentication though, as described in http://docs.python.org/library/urllib2.html#examples
What is to replace Perl then? Posted Dec 4, 2008 2:27 UTC (Thu) by jwb (guest, #15467) [Link]
That is interesting, I hadn't noticed before that HTTP RFC specifies 'host' instead of 'authority', but you're right it's of little use because the problem is that such URLs are found in the wild and when you're building a crawler you pretty much have to handle them.
What is to replace Perl then? Posted Dec 4, 2008 1:43 UTC (Thu) by jamesh (subscriber, #1159) [Link]
Having contributed to the more popular PostgreSQL database adapters for Python (psycopg and psycopg2), I can't say I ever ran into a case where it was spawning psql as a subprocess to perform queries.
Do you remember what module you were using?
What is to replace Perl then? Posted Dec 3, 2008 17:08 UTC (Wed) by tjc (guest, #137) [Link]
> I thought Python was ubiquitous, but I have the feeling that Ruby is growing faster now...
My perception is that Ruby is stalled, while Python continues to grow, largely due to Google's App Engine. That said, I'm not a huge Python fan, although I don't hate it either.
What is to replace Perl then? Posted Dec 3, 2008 19:45 UTC (Wed) by sbergman27 (guest, #10767) [Link]
Fedora 8 has about a hundred (and increasing) Python scripts in /usr/bin and /usr/sbin, and exactly zero ruby scripts. For all practical purposes, Ruby can be defined as "the scripting language that the Rails framework uses".
What is to replace Perl then? Posted Dec 3, 2008 20:08 UTC (Wed) by muwlgr (guest, #35359) [Link]
In FreeBSD I remember 'portupgrade' tool is written in Ruby.
What is to replace Perl then? Posted Dec 3, 2008 20:07 UTC (Wed) by rfunk (subscriber, #4054) [Link]
Ruby and Python are the most obvious successors to Perl -- Python because
it's mature and popular, and Ruby because it's heavily inspired by Perl (though most of the uglier Perlishness is deprecated). Personally I think a Perl programmer looking for a new language would be more comfortable with Ruby than with Python.
On the future of Perl 5 Posted Dec 3, 2008 16:00 UTC (Wed) by dreadnought (subscriber, #27222) [Link]
In addition to being a really hard to read language for newly initiated I think its user base which was a fusion of C/sed/awk and shell is slowly being lost and consequently so is its beauty. I used to work with it a lot but have not bothered to look at Perl6 and for the most part have abandoned Perl 5 in favor of Groovy. Kind of funny that its taken 7 or 8 years for the Java folks to come around to doing what others have been for a while. In addition I guess there is ruby which most of my Perl compatriots have moved to and frankly, for Perl, I don't think there is a way to turn that bus around.
On the future of Perl 5 Posted Dec 3, 2008 16:01 UTC (Wed) by dskoll (subscriber, #1630) [Link] We use Perl extensively. It is possible to write large, robust programs in Perl. That said, Perl has a number of problems:
Sadly, I don't see improvements coming. We'll continue to use Perl because we like it and we don't really care what the herd is doing. But it will become harder and harder to find good Perl programmers.
On the future of Perl 5 Posted Dec 3, 2008 16:54 UTC (Wed) by nix (subscriber, #2304) [Link]
If you want a *nice* embedding interface, look at Lua's virtual stack machine. Now that's neat.
On the future of Perl 5 Posted Dec 5, 2008 20:44 UTC (Fri) by topher (guest, #2223) [Link] That said, Perl has a number of problems: There are many different OO frameworks. If you want to use CPAN modules, you might end up with three different and incompatible OO frameworks in your dependency list, leading to extreme bloat. Have you looked at Moose? It is rapidly becoming the defacto OO framework, and I expect nearly all new Perl code utilizing OO will likely make use of it. Some very cool stuff there for the OO fans. Perl 6 frankly scares me. It seems to me more like a research project conducted by crazy students on drugs than a serious infrastructure development project. I'm going to guess you haven't looked into it recently? I ask because I felt the same way as you until a few weeks ago. I was talking Perl with a former coworker who'd been playing with Perl6 and the Parrot implementation-in-progress Rakudo, and he informed me that things were rather different than I thought. I took a little time to investigate Parrot, Rakudo, and the Perl 6 specification, and I was very surprised with it's progress. It's not yet at the point where I would write production code based on it, but I plan to start playing with it a little bit. If I were starting a large, long term project, I might give it some serious thought. The innards of Perl 5 are ugly and mysterious. Its interface for embedding in C is nightmarish compared to (say) Tcl. Absolutely no argument there. If you're looking for an embedded language, I think Lua's almost impossible to beat, though. Sadly, I don't see improvements coming. We'll continue to use Perl because we like it and we don't really care what the herd is doing. But it will become harder and harder to find good Perl programmers. I think you are absolutely correct that Perl has some problems, but I disagree with the lack of improvements and dismal future outlook. I'm actually more optimistic about Perl and it's future now than I was a year ago. I think most of the problems are being addressed, and addressed well.
On the future of Perl 5 Posted Dec 3, 2008 16:21 UTC (Wed) by orev (subscriber, #50902) [Link]
Perl is not on the decline. In fact, it has reached the point of ubiquity and is thus becoming invisible. Perl is on every Linux system, and a large number of tools are written in it. It's been around for a long time, so it's not as exciting as all the newcomers, but that's because it's well-understood and stable. The newcomers are exciting because they have not reached the same level of maturity.
Perl is akin to a mainframe... people think it is a dinosaur, but in reality it is the workhorse that is so stable that you don't need to mess with it anymore and can just focus on the actual work that needs to get done, and it gets done reliably. I don't expect you whippersnappers to understand that, but once you've been in IT for 10 years or more, and with the right attitude, you eventually will.
On the future of Perl 5 Posted Dec 3, 2008 17:41 UTC (Wed) by jordip (guest, #47356) [Link]
In my system (Ubuntu 8.10 desktop with some random development packages):
locate *.pl | wc -l
locate *.py | wc -l
locate *.rb | wc -l
On the future of Perl 5 Posted Dec 3, 2008 17:47 UTC (Wed) by tzafrir (subscriber, #11501) [Link]
python modules are .py . Perl modules are .pm and not .pl .
Here:
$ locate *.pl | wc
$ locate *.pm | wc
$ locate *.py | wc
$ locate *.rb | wc
(From my Debian Lenny system with a similar role)
On the future of Perl 5 Posted Dec 3, 2008 18:18 UTC (Wed) by drag (subscriber, #31333) [Link]
This is a fairly fresh Fc10 install.
locate *.pl |wc
locate *.pm |wc
locate *.py |wc
locate *.rb |wc
On the future of Perl 5 Posted Dec 3, 2008 18:30 UTC (Wed) by kragil (guest, #34373) [Link]
The amount of perl scripts in modern distros is declining. I think Red Hat and Canonical with their strong Python focus will be the first companies to phase out Perl in their base distros ( might take a few more years, but reimplementing/developing new in Python is the sane choice. Porting to Perl6 isn't IMHO ).
On the future of Perl 5 Posted Dec 4, 2008 8:55 UTC (Thu) by job (subscriber, #670) [Link]
I don't think the number of files with a particular extension is the question.
A better metric may be:
(Repeat through $PATH.) At least on Ubuntu Intrepid this shows them on roughly equal footing.
On the future of Perl 5 Posted Dec 4, 2008 15:19 UTC (Thu) by hummassa (subscriber, #307) [Link] Solving the dispute with a little Perl script :-)
#!/usr/bin/perl
use strict;
my %languages;
for( grep !m{^/home}, split /:/, $ENV{PATH} ) {
for( <$_/*> ) {
$_ = do { <F> if open F, '<', $_ };
next unless /^#!/;
$languages{$1}++ if /\b(perl|php|python|ruby)\d*\b/
}
}
printf "%-20.20s %6d\n", $_, $languages{$_} for sort keys %languages
__END__
Output (on my Kubuntu 8.04):
perl 891
php 2
python 242
ruby 40
On the future of Perl 5 Posted Dec 5, 2008 21:59 UTC (Fri) by cdmiller (subscriber, #2813) [Link]
I'm still waiting for the "equivalent" Python script to appear :)
On the future of Perl 5 Posted Dec 6, 2008 5:47 UTC (Sat) by dmag (subscriber, #17775) [Link] Oh, please, let's not have a language flame war on LWN.Besides, Ruby is much better :)
#!/usr/bin/ruby
is_home = lambda {|path| path =~ /^\/home/ }
languages = Hash.new(0) # Default value is zero
ENV['PATH'].split(/:/).reject(&is_home).each do |one_path|
Dir[one_path + "/*"].each do |binfile|
File.open(binfile,"r") do |data|
first_line = data.gets
languages[$1] += 1 if first_line =~ /\b(perl|php|python|ruby)\d*\b/
end rescue puts "#{binfile} unhappy"
end
end
languages.each_pair do |language, count|
puts "%-20.20s %6d" % [language, count]
end
__END__
Output from Slackware 12.0 (with lots of rubygems installed):
php 1
python 62
ruby 79
perl 203
For comparison: (sh|bash|tcsh|csh|ash|ksh|zsh|fish)
sh 488
bash 22
ksh 1
csh 1
Of course, we're not really measuring anything useful here. For example, git used to install tons of commands in /usr/bin. This could tilt the scales (if it were written in one language).
Seriously, I doubt that Ruby (or even Python) will unseat Perl from it's sysadmin tool niche, which is what we seem to be measuring here. Since every distro has bash and perl, that's what people tend to use. On the other hand, I think Ruby (and perhaps Python) has already unseated Perl from web scripting, where the client doesn't care what language the server is written in.
On locate Posted Dec 3, 2008 20:01 UTC (Wed) by rfunk (subscriber, #4054) [Link]
The locate command isn't a good way to measure how much of any given
language there is on your system, since file extensions don't need to be used. That is, not all Perl scripts end in .pl (or .pm), not all Python scripts end in .py (or .pyc), and not all Ruby scripts end in .rb. On top of that, the files most likely to end in those extensions are support files, inflating the numbers.
On the future of Perl 5 Posted Dec 7, 2008 18:22 UTC (Sun) by oak (guest, #2786) [Link]
Lintian warns if script has extension, so it's unlikely any of the
Perl/Python/Ruby/... scripts in Debian or derived distros have extensions. Only things like Python modules (under lib/) have extensions, not the scripts themselves.
On the future of Perl 5 Posted Dec 3, 2008 19:19 UTC (Wed) by smoogen (subscriber, #97) [Link]
Well as a fellow old fart.. I can say that the mainframes are going away as fast as people hit retirement age. Its as if the mainframe is the gated retirement community. There aren't a lot of them and they are expensive when they go down so only the experienced people are allowed on them.. and the new people play with this Linux stuff... and all the paycheck software that was on the mainframe is moved over to the Linux systems for what 1 month of support from IBM etc cost.
The same is the way for any language.. yes it is ubiquitous and will be around for a long time, but eventually it becomes a Fortran or Cobol. The community is a small set of people who used it in its heyday and a smaller crowd of people who are "accepted" into the Secret Brotherhood. And eventually the decline becomes terminal where only people in a certain set ever really know the language anymore.
One could say this is natural course of events for computer languages.. they are born, grow, become mainstream, retire, and then spend their final years sitting on their front porch yelling at the kids to get off their lawn. Some sadly spend their last years in a nursing home with tubes stuck up every orifice because the kids are living off their pension checks.
On the future of Perl 5 Posted Dec 3, 2008 20:21 UTC (Wed) by muwlgr (guest, #35359) [Link]
Interesting is that Unix shell and its variations seems not going into decline. Unlike some JCL/DCL etc. Very few people try to replace /bin/sh with something else. Even csh/tcsh were not so successful. bash/ksh/zsh are extensions, they still have common subset standardized by POSIX (may be that's the catch?).
On the future of Perl 5 Posted Dec 4, 2008 11:58 UTC (Thu) by jonth (subscriber, #4008) [Link]
Not true: On Debian Etch:
$ ls -l /bin/sh
On Ubuntu Hardy:
$ ls -l /bin/sh
(They replaced bash with dash for speed reasons, IIRC)
On the future of Perl 5 Posted Dec 4, 2008 14:30 UTC (Thu) by muwlgr (guest, #35359) [Link]
Yes but these shells still implement /bin/sh functionality as set in POSIX.
On the future of Perl 5 Posted Dec 3, 2008 19:57 UTC (Wed) by sbergman27 (guest, #10767) [Link]
"""
Perl is not on the decline. In fact, it has reached the point of ubiquity and is thus becoming invisible. """
The percentage of scripts in /usr/bin and /usr/sbin which are perl scripts on a Fedora Core 1 server I manage is about 35%. Checking a similar installation of F8, it's less than 25%. This certainly does not support that assertion... except for maybe the "becoming invisible" part. ;-)
On the future of Perl 5 Posted Dec 4, 2008 15:03 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]
Atleast for the Fedora Live CD, there has some people looking to see, if we can drop the perl dependency since it occupies considerable amount of space which could be used for more useful purposes. So you are right but it probably will take more time for that to happen.
On the future of Perl 5 Posted Dec 7, 2008 18:19 UTC (Sun) by oak (guest, #2786) [Link]
> there has some people looking to see, if we can drop the perl dependency
since it occupies considerable amount of space which could be used for more useful purposes
At least in Debian, the "perl-base" package (which is an essential, Perl's
On the future of Perl 5 Posted Dec 11, 2008 19:51 UTC (Thu) by biged (subscriber, #50106) [Link]
> Perl is on every Linux system
Not the OLPC, I think:
On the future of Perl 5 Posted Dec 3, 2008 22:47 UTC (Wed) by davidw (subscriber, #947) [Link]
He's basing his arguments on TIOBE though. It's impossible to get good numbers, but I'd like to think my approach with LangPop.com is at least a little bit better. I mean... Logo and Delphi?!
On the future of Perl 5 Posted Dec 3, 2008 23:22 UTC (Wed) by chromatic (guest, #26207) [Link]
Delphi is in the top 10 because of the programming language Oxygene (formerly Chrome), a port of Delphi to .Net. Around the time Google released a web browser, searches for "Chrome programming" increased dramatically.
I leave the relevance of TIOBE's other statistics as an exercise for the reader.
|
|
||||||||||||