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