Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
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)
A huge majority of "programs" on most Linux distros are actually scripts, and Perl scripts at that. Removing it would take a herculean effort.
Posted Dec 3, 2008 19:10 UTC (Wed) by sbergman27 (guest, #10767)
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?
Posted Dec 4, 2008 0:05 UTC (Thu) by njs (guest, #40338)
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.
Posted Dec 4, 2008 20:22 UTC (Thu) by elanthis (guest, #6227)
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.
Posted Dec 4, 2008 20:51 UTC (Thu) by njs (guest, #40338)
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.
Posted Dec 6, 2008 16:46 UTC (Sat) by sbergman27 (guest, #10767)
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.
Posted Dec 7, 2008 0:27 UTC (Sun) by njs (guest, #40338)
Posted Dec 5, 2008 0:47 UTC (Fri) by johnkarp (subscriber, #39285)
(I do end up using perl more than python at the moment, though I'd use ruby if that were supported where I worked.)
Posted Dec 3, 2008 17:04 UTC (Wed) by niner (subscriber, #26151)
The language has nothing to do with maintainability of code. One can abuse any
language and write clear and readable code in any language (concept or "fun" languages
like Brainfuck excepted of course).
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
Or how do you want to execute code today? Would you use the builtin function eval,
which can do only a single statement and return it's value. Or would you use the keyword
exec, which takes a block of code, but cannot return anything? What if you need the
return value of the block? Easy: indent the whole block, put a function header before it,
exec it and then call and delete the temporary function. +1 for maintainability
Better stop here...
Posted Dec 3, 2008 18:52 UTC (Wed) by jbh (subscriber, #494)
Posted Dec 3, 2008 19:06 UTC (Wed) by niner (subscriber, #26151)
[1, 2, [3, 4]]
[1, 2, 3, 4]
For example in:
"foo %s bar %s, %s, %s, %s, %s" % (foo, bar, map(lambda x: baz(x), [1, 2, 3, 4]))
which does not work that way, because what one gets is a tuple containing three values,
the last one being a list.
In Perl, you would just do:
($foo, $bar, map baz($_), 1, 2, 3, 4)
would create: ($foo, $bar, baz(1), baz(2), baz(3), baz(4))
If you want to preserve this array inside a list, you have to create an array reference:
($foo, $bar, [ map baz(x), 1, 2, 3, 4 ])
would crate: ($foo, $bar, [baz(1), baz(2), baz(3), baz(4)])
The workaround in Python is to create a temporary variable holding that array and
manipulating that. Much code which doesn't help readability at all.
Posted Dec 3, 2008 19:34 UTC (Wed) by jbh (subscriber, #494)
"foo %s bar %s, %s, %s, %s, %s" % (foo, bar, map(lambda x: baz(x), [1, 2, 3, 4]))
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? :-)
Posted Dec 3, 2008 19:39 UTC (Wed) by sbergman27 (guest, #10767)
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.
Posted Dec 3, 2008 20:10 UTC (Wed) by niner (subscriber, #26151)
Another very nice argument: "Perl looks confusing to outsiders coming from other
languages". Confusing like:
>>> i = 0
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.
Posted Dec 3, 2008 20:52 UTC (Wed) by sbergman27 (guest, #10767)
Posted Dec 3, 2008 21:36 UTC (Wed) by sbergman27 (guest, #10767)
> x = 3
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:
> 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.
Posted Dec 3, 2008 21:44 UTC (Wed) by dlang (✭ supporter ✭, #313)
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.
Posted Dec 3, 2008 22:05 UTC (Wed) by sbergman27 (guest, #10767)
Posted Dec 3, 2008 22:41 UTC (Wed) by dlang (✭ supporter ✭, #313)
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.
Posted Dec 7, 2008 2:05 UTC (Sun) by madscientist (subscriber, #16861)
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?
Posted Dec 4, 2008 14:30 UTC (Thu) by pboddie (subscriber, #50784)
"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:
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.
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.
Posted Dec 3, 2008 20:11 UTC (Wed) by rfunk (subscriber, #4054)
Posted Dec 3, 2008 20:09 UTC (Wed) by rfunk (subscriber, #4054)
Posted Dec 4, 2008 2:04 UTC (Thu) by dw (subscriber, #12017)
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!
Posted Dec 4, 2008 9:35 UTC (Thu) by niner (subscriber, #26151)
Thats _exactly_ _my_ point!
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. Because it's not the language, but the one who uses it who decides.
I'm so sick of this "Perl code is unreadable by definition while Python code is always
pure joy to read" crap.
When you listen to American TV, you'd think that the English language is a horrible
monster but actually, there's even very nice poetry in it. It's all about use and abuse.
Posted Dec 4, 2008 10:38 UTC (Thu) by sbergman27 (guest, #10767)
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
unmaintainable code a hazard to all programmers: good, bad, and average.
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.
Posted Dec 4, 2008 11:38 UTC (Thu) by niner (subscriber, #26151)
Now internals, that's someting different. As the current maintainer of Perl's Inline::Python
module which is embedding a Python interpreter, I can say that I like Python's internals.
They really are more readable than Perl's though it still takes some source code reading
to fully understand them. The docs just aren't enough.
A funny thing tough: while in Perl you have to explicitly sv2mortal an object when
returning it from a C-function to Perl space, to get the reference count lowered after the
next Perl statement (which could be an assignment), Python implicitly gives this
responsibility to the stack, which is very confusing for the beginner for sure.
On that PostgreSQL thing: you must be confusing me with someone else. I've certainly
never written about anything concerning PostgreSQL and Python. I've not even used this
Posted Dec 4, 2008 14:35 UTC (Thu) by rfunk (subscriber, #4054)
Python is certainly much less verbose than C++, but C++ is a lower-level
language. It's more appropriate to compare Python to Perl (the original
topic here) and Ruby than to C++.
Posted Dec 5, 2008 2:55 UTC (Fri) by sbergman27 (guest, #10767)
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. :-)
Posted Dec 7, 2008 18:40 UTC (Sun) by oak (subscriber, #2786)
In my (very limited) comparative experience, yes, you spend more writing
code in Python, at least if you need to do text parsing, but you get that
time back many times over when you need to debug & maintain your scripts.
Last experience I had with Perl was that Perl script took 15 min to write
and half an hour to debug, but still didn't work (due to some mysterious
side-effects). Writing the same straight forward text handling script in
Python took 20 min to write and 5 min to debug. All errors in Python code
were obvious to fix.
(After that I avoided Perl like plague and Python improved a lot since
Posted Dec 7, 2008 0:06 UTC (Sun) by rwmj (subscriber, #5474)
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.
Posted Dec 7, 2008 0:16 UTC (Sun) by nix (subscriber, #2304)
What I think can be fairly said is that 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. (I very much wish that such programmers didn't exist: however, in my
entire working life I have worked with perhaps two people who did *not*
fall into that classification. So they are regrettably common.)
Posted Dec 7, 2008 19:45 UTC (Sun) by chromatic (guest, #26207)
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds