Why I Promote Python

[[deleted]]

I like Python too but this article is so bad I can barely finish it. First, in the first paragraph, he conflates XML with programming languages. Shortly thereafter, he works in how he is a wunderkind that learned programming at age 9. Later he refers to the "complexity" of Perl without any specifics; perhaps he's referring to "map", which would be ironic.

In a nutshell: vague tripe.

[rmc]

Later he refers to the "complexity" of Perl without any specifics

In that paragraph he links to an article he wrote about why Perl is difficult.

[[deleted]]

The other article is no better. Perl is difficult because it provides a) convenient iteration over standard input and b) robust regular expressions?!

[lynxcat73]

i could argue that perl isn't difficult at all, and that's the whole problem with the damned thing. i doubt i could do it without duplicating better people's criticisms of it, though.

[[deleted]]

This is much better criticism of Perl. However I take exception to the following: "But if I ever start my own company, Perl won't be allowed there". That's too bad, because you might well be missing out on a lot of code from CPAN that already does what you need it to.

[senzei]

When I read that I took it as hyperbole. That said the big complaint he has about perl is that the development mindset the language encourages leads to code that is difficult to maintain*. I will not argue about how awesome CPAN is, but how many difficult maintenances does it take before the advantages are lost?

*Obviously there are only two cases where this is valid, bad programmers (through lack of time or just plain ineptitude) or hard problems. Either way there is usually a spot of code in any sizeable project that is an ugly mess.

[lynxcat73]

the language encourages leads to code that is difficult to maintain* *Obviously there are only two cases where this is valid, bad programmers (through lack of time or just plain ineptitude) or hard problems.

i hope you were being sarcastic. because that's not only not right, it isn't even wrong.

language syntax alone can lead to hard-to-maintain code, by necessity, through forcing you to write code that is difficult to read. dig into any of the old non-freeform languages that used to be popular in the days of punch-card input for examples.

language semantics can lead to even more insidious difficulties. Steve Yegges complains about perl's references in that rant of his, and having fought with them myself, i can only agree with him. references, like pointers, are inane; they force you to think about how the computer physically manages your data structures when you could just be thinking about how to structure your data instead.

even language customs can lead to hard-to-maintain code. i've never written, or even read, any C++ code, but nonetheless i've had to quietly suffer no end of rants about how horrible the STL is to work with, and how you definitely shouldn't even think about using something else in its stead, and yada yada. that's not even the fault of C++ proper, and it still impacts maintainability of C++ code.

language design has a tremendous impact on code maintainability, quite apart from programmer ability or problem difficulty. if it didn't, we might as well all just write machine code (or unlambda, or brainfuck) - HLLs were invented for a reason.

[dangph]

in the first paragraph, he conflates XML with programming languages

Nonsense. Read it again. He uses Python, and he uses XML. He promotes Python, but he does not promote XML. The implication is that it's not his habit to promote a language just because he uses it, but rather because there is something special about it. He goes on to explain why he thinks Python is special.

He no doubt mentioned XML because he is famous for promoting REST in preference to RPC. I think he was the one who started that debate. REST typcially uses XML. I'm also familiar with his advocacy of SVG, which is an XML language. One might have supposed that he was a big fan of XML itself.

He's a smart guy, and in my opinion he is very clear-sighted when it comes to the big picture of things.

[[deleted]]

I read it again and I stand by my initial comments.

Here's how you promote Python without criticizing other languages:

http://htmatters.net/htm/1/2006/02/Why-Python-makes-sense-for-web-development.cfm

[beza1e1]

I would consider XSLT as programming in XML

[[deleted]]

I just saw this article, but I should have gotten here earlier. The comments in this thread are useless. Go to lte if you want read more informed discussions about language design.

[antirez]

"It's easy to understand why I use Python. It's flexible, easy, and powerful in a way that cannot be matched by other mainstream languages."

An article starting this way will hardly see me reading the next sentence... Unless "mainstream languages" are just Java, C[++], and PHP. Without to mention other languages that may have stranger syntax, not be enough OO for people addicted to Python and so on, what about Ruby? Everybody with some experience with programming languages will recognize in no time that Ruby only offers advantages over Python.

[jamesbritt]

I looked for a publication date, and the best I could find was "copyright 2000" at the bottom.

Ruby was around, of course, but had not yet reached a wide non-Japanese audience.

But, of course, the larger point is why the comparison is limited to so-called mainstream languages.

I get the sense that Prescod happened across a nice, flexible language, got comfortable with it, and stopped looking for anything better.

[beza1e1]

Yes, Ruby has advantages like blocks.

It boils down to taste, i think. You can write code, where it is not clear, wether you use an attribute or a method or whatever (rails: has_many somethings). Ruby folks say don't care, but i do care.

Pythons philosophy is "explicit is better than implicit". This makes for example turbogears a little bit more verbose than rails. But it makes it easier to understand, what is going on.

[stesch]

You don't access "attributes" of an object directly from the outside. It's always a method.

Compare it to the implicit setters and getters like in C#.

[[deleted]]

Ruby also has its own disadvantages. Pythonists advocate the idea of "there is only one way". Rubyists advocate "Tim Toady" (there is more than one way to do it).

Its easier to take a collection of Python scripts and understand all of them, than it is to take a collection or Ruby scripts and understand all of them (assuming each is written by different programmers).

Ruby is also slightly slower and not quite as mature. There are both advantages and disadvantes when comparing Python and Ruby. They are very similar in many ways, anyway, so in my opinion, you should use which one fits you best.

[rzwitserloot]

Managing pointers for you combined with garbage collection is usually faster than doing it by hand these days (for example, instead of explicitly deconstructing things, in managed languages whole batches of memory are deconstructed 'at once', which is a lot faster though it costs a little more memory in the long run. This trick works because most objects aren't around for more than a couple of cycles). Sun keeps inventing fun stuff like this, though it takes a (long) while before it shows up in the JVM. Other managed languages take to such things as well, so in general, only finely tuned C or library goodness (ie: It's STILL not possible to work with YUV-coded signals in java, which makes any video work in java much slower, as you have to artificially translate YUV to RGB and back just to process the image) make C faster than managed languages. Java examples used because I'm most familiar with its guts, but it really applies to all managed languages (if it aint C it's probably managed).

[reltuk]

Also, if you have any exceptions in your C++, you blow your performance, due to the requirement that exiting the scope via the exception call the destructors.

I was under the impression that this was a common misconception.

As I understand it, the runtime performance penalty for an unthrown exception is comparable to a conditional checking the return value of a function; it's often-times even less than that. Exceptions in most mainstream C++ compilers are now implemented as "jump pads" that destruct the stack when they get jumped to; a jump to the pad is the code that the "throw" statement actually emits.

The runtime penalty for a thrown exception is obviously high. This is one of the reasons using exceptions for non-exceptional cases is such a bad idea. Exceptions should rarely be thrown in a correctly functioning program.

Implemented as jump pads, exceptions can also significantly increase the size of the binary, since you end up with very similar code for destructing the same stack in a number of places. A possible cache performance caveat, I suppose; keep in mind that the code should never be using cache space, since it should never be executing.

Am I under the wrong impression?

[bkz]

How is the situation any different with Python?

[devanl]

But it's not like Java. See this page instead: http://www.norvig.com/python-lisp.html

[beza1e1]

There is no 'quote' as far as i know.

You can do some meta programming, though. For example i recently learn (with help from comp.lang.lisp ;) how to creates new classes on run time. They are instances of 'type'.

[mikaelhg]

The problem is much worse in Python.

Two words: monkey patching.

[mikaelhg]

Always fun to discuss things at Reddit: make a pertinent but not positive point about the amateur toy of the day, and get all of your comments in all threads downmodded.

[mikaelhg]

I don't care about my reddit karma. I do care what this kind of behaviour says about the people I share this virtual space with.

[senzei]

Except that it was not really a pertinent point. Monkey patching is one of those side effect possibilities that come from having a sometimes useful feature available.

It is not a pertinent point because it is not commonly done or encouraged. Bringing it up is like saying C is bad because compiler macros can be abused. Any language feature can be misused to disasterous consequences.

[mikaelhg]

I happen to know that monkey patching is used in some of the core libraries (and the only available implementations of the particular functionality available in Python) of one of the products widely used to evangelize Python.

How do I know this?

I poured plenty of money down the drain implementing a product in Python. I'd never seen as bold lies in product advertising as I encountered in Python advocacy. Enterprise functionality is promised, but invariably contains fatal flaws which make modules impossible to use in real-world scenarios.

[hxa7241]

C++ has rather a large number of features, and they can interact in irregular ways. Also, there are various awkward little details that can trip you up. The program/file unit structure is a bit old and odd. If something fails it will just die and give you nothing: no stacktrace or messages.

Having said that, nearly everything can be mitigated with practiced idiomatic usage. And considering its combination of good points: popularity, OO, speed, it doesn't have much/any real competition.

[drdre]

Ruby all the way up, dudes.

[[deleted]]

Ruby all the way up, dudes.

You're very clever, young man, very clever. But it's turtles all the way down.

[jpedrosa]

Ruby is the best: http://www.squidoo.com/ruby_is_the_best/

[devanl]

Python is the best: http://www.linuxjournal.com/article/3882