| |||||||||||||
On the future of Perl 5On the future of Perl 5Posted Dec 3, 2008 15:51 UTC (Wed) by kragil (subscriber, #34373)In reply to: On the future of Perl 5 by clugstj Parent article: On the future of Perl 5
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.)
(Log in to post comments)
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 (subscriber, #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 (subscriber, #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.
|
|||||||||||||