Hacker News Reader

Comment by shabda | Hacker News Reader

> But don't build your business around it. Python/Django and Ruby/Rails are only barely stable enough to work with.

I agree with your basic premise but,

Python and ruby both have extremely good library support. Hell, python's stated aim is batteries included. Both of them have (al least semi-)mature Jvm implementations. Django has a stated policy of not breaking backward compatibility on point releases.

I agree you need to choose stable languages to work with, but if you are selling consulting services around Java god luck competing with BigCo. If you are building your products with Struts, good luck doing xml-situps.

View on HN

If you think Python and Ruby have extremely good libraries your standards are pretty low. CPython itself is stable and well documented, but it's frequently breaking backwards compatibility across versions. My production servers can't get anything newer than Python 2.4, and the servers are barely a year old. Python 2.6 libraries almost never work in 2.4, and when I do upgrade to 2.6 I know a lot of my own code is going to break. If I used Perl instead of Python this would be no issue, because Perl _is_ stable and reliable as hell.

In two years time most libraries will move to Python 3.0, and Django is unlikely to patch security issues for Python 2.4 by then. In other words, I either have to spend a week upgrading stuff that already works, or I'll have to use insecure libraries. I don't like those options at all. How can we write solid and stable software if we don't have a stable foundation to build on?

C++ code I've written a dozen years ago still compiles and runs fine. Executables still run when double-clicked. If I scpy a Django directory to a different server I'm __surprised__ if it just works. Doesn't that say enough?

Python exists 20 years now and the spec is still not stable. Any Python library written today won't run on the computers of tomorrow. That's a pretty big price to pay for a print() function.

> If you think Python and Ruby have extremely good libraries your standards are pretty low.

.Net, JVM, Perl. Apart from these, which lanngauge has better Library than Python? Python is available on two of them. Ruby one one of them at least. (I dunno if ruby is avaialble on .Net)

> CPython itself is stable and well documented, but it's frequently breaking backwards compatibility across versions.

No. Afaik, Python has never broken backward compatibility in a majot way on point releases, and even minor details are dicussed ad infintum on the mailing list. Py3K was discussed for 8 years, before being released.

> Python 2.6 libraries almost never work in 2.4

Neither do Java's library which use generics or Autoboxing work in Java 1.4. However libaries comaptible with Java 1.4 work in 1.5(or 5.0 if you will), and so do libraries which were written for Python 2.4, do in 2.5 and 2.6. Languages can only guarantee backward compatibility. I am not sure which language you work in that guarantees forward compatibility.

> and Django is unlikely to patch security issues for Python 2.4 by then. In other words, I either have to spend a week upgrading stuff that already works

Django has a stated security policy. All security bugs must be fixed for 2 point releases prior to latest release. 0.96 got official security upgrades till recently. People have backported it to 0.95 and released.

> How can we write solid and stable software if we don't have a stable foundation to build on?

Sorry, but what you are asking here is again forward compatibilty. What will you have, Django never move to 3.0?

> Python exists 20 years now and the spec is still not stable.

Define stable. Python has 1. A reference implemntation. 2. Mutiple VM implemntations, targetting the popular ones. 3. Others, (Stackless, Pypy etc). Unless you use platform specific functions, your code will run on any of these. Fyi, the reference is, http://docs.python.org/reference/introduction.html .

Probabaly you hold a problem with this philosophy, from the reference (While I am trying to be as precise as possible, I chose to use English rather than formal specifications for everything except syntax and lexical analysis. This should make the document more understandable to the average reader, but will leave room for ambiguities.) But this is a debated, and concious decision.

Aside from those three? C and C++. Those libraries are not "batteries included", but they are plentiful and very mature. I like the "batteries included" part of Python though.

- I don't know if Python on the JVM is stable. Last time I checked Ruby on the JVM and .NET was in its infancy.

- They're not big breaks, and they are, as you say, discussed on mailing lists. The difference is that with a JAR file you can upgrade Java and you _know_ that the JAR will continue to run. With Python the only guarantee you have is that one of your libraries is going to throw an exception at some point after you upgrade. Essentially, you have to keep track of every library you use, and you have to check if it's compatible with the new point release.

- Not forward. Merely backward. Backward compatibility is offered by JAR files. You compile it, and even if the language changes the JAR will stay in place. Because the Java VM is stable you don't have to worry as much about precompiled libraries. I don't think Java is the solution to the world's problems, but at least old JAR files still run on modern JVMs (afaik). You can also design a language grammar in such a way that you leave room for future extensions. That is, to only make previously illegal statements legal. To change the semantics of legal statements (except for the rarest of corner cases) is, I think, a bad (but tempting) idea. You can have forward compatibility if you guarantee that code that uses new features won't compile or even attempt to run on an older interpreter. Essentially, if it runs it works. That is a hard guarantee, and the kind of thing you can build on.

> Define stable? That the language grammar doesn't change. Or more generally, that every version of the interpreter can flawlessly execute code written for version n - 1. Take Python: print used to be a keyword, now it becomes a function. I think it's too late for that kind of change, and it's only a minor blemish in the language anyway. You can't upgrade to Python 3 until every single library on your server has been updated. The number of man-hours this will take is staggering.

When you're actively developing in a language, these changes are only a minor nuisance, and upgrades come with a bunch of goodies. 10 years down the road you just want things to run, and with Python the only way to guarantee that is by deleting aptitude.

As was said before you are arguing for forward compatibility as backwards compatibility between point releases is guaranteed.

If you have code that works fine in Python 2.4 upgrading to 2.5, 2.6, 2.7 etc won't break your program. If you write you program in Python 2.6 you have to take special care if you want it to run in 2.4. Until Django decides to bump up the minimum version required, which I believe is at 2.3 now, you have nothing to worry about.

Since Python 3.x is not a point release, compatibility is not guaranteed anymore between 2.x. The 2to3 tool will take care of all the easier but time consuming tasks. Why waste the man hours converting 'print x' to 'print(x)' and 'xrange' to 'range' if there is a free tool to do it for you?

Really you are making a mountain out of a mole-hill. If you are not updating your software/site anymore with new features let it be. Python interpreters can run side by side.

I may be making a mountain out of a mole-hill, but I think these little things do matter. Python 2.6 introduced the "with" keyword, as you probably know. That's a breaking change, because it alters the language grammar and changes the meaning of previously legitimate programs. And it's a point release. This changes the "it won't break your program" statement to "this will probably not break your program".

When I see a statement that "backwards compatibility is guaranteed", I generally take that literally. And it's really a binary thing. Either it's guaranteed, or it isn't. And with Python it most definitely isn't.

We clearly look at this from a different perspective. I think it's a big deal, and you don't.

Ruby on the JVM is production ready. Apparently Thoughtworks generally deploy on it. I've got it in production too - there's a few very very minor issues, but basically rock solid.

http://martinfowler.com/articles/rubyAtThoughtWorks.html

> Take Python: print used to be a keyword, now it becomes a function. I think it's too late for that kind of change, and it's only a minor blemish in the language anyway. You can't upgrade to Python 3 until every single library on your server has been updated.

Stop using Python 3 as an example of "python instability" damn it, it's a change known to be incompatible, it's been in preparation for 5 years, it's not an evolution one's supposed to take lightly and it does not mean the end of the 2.x branch for at least a pair of years.

Before that, here's the track record of Python backwards compatibility: you can run Python 1.6 (2000-09-05) code on Python 2.6. In fact that's exactly what ElementTree does.

You cannot run all legit Python 1.6 code on Python 2.6 (except perhaps with special flags).

If Python 2.6 would flawlessly execute all Python 1.6 code I would have no complaint.

"I am not sure which language you work in that guarantees forward compatibility."

Lisp? :-)

Trying to avoid sounding like a fan-boy but your python bashing goes a bit far, imho.

CPython itself is stable and well documented, but it's frequently breaking backwards compatibility across versions.

I think you are over-dramatizing this. The big transition to Python 3.0 is still ahead of us. I'm using python since 2.3 and the path to 2.6 has been much less troublesome here than CPAN or the jar interdependency hell have ever been.

I especially find your claim that Perl is "stable and reliable as hell" amusing. CPAN has always been hit & miss for me and I've seen much greater variance in the quality of 3rd party perl modules than in python land.

If I scpy a Django directory to a different server I'm __surprised__ if it just works. Doesn't that say enough?

I think that says more about your deployment methods than about python or django.

Any Python library written today won't run on the computers of tomorrow. That's a pretty big price to pay for a print() function.

That's simply not true. Nobody stops you from running python 2.4 or older on computers of tomorrow. Just like you don't upgrade JVM versions willy-nilly in production.

Python has it's quirks and problems like any other platform. But the particular issue you're going at here (backwards compatibility) is really far from our biggest concern.

Actually, I like Python. I think it has a lot going for it and I use it on a daily basis.

You say that you shouldn't upgrade Python or the JVM willy-nilly. I say: why not? Why do you find it acceptable that languages break existing functionality?

It's not actually about breaking functionality. Both java and python go through a long deprecation period before removing language features. Most Python 2.4 code will run on 2.6 just fine, a few warnings nonwithstanding. Just like most Jdk1.3 code will run on 1.6, again with a bunch of deprecation warnings.

The bigger problem with willy-nilly upgrades is that the new version is not the version you tested on. It might introduce new bugs, unwillingly. I have seen many more subtile problems with minor version jdk updates (e.g. changes in GC behaviour or outright segfaults) than with any python upgrade so far.

The gist is that when you upgrade your environment then you'll just naturally also update the codebase to match it anyways. Or do you upgrade your jdk1.3 project to jdk1.6 and then just ignore the 20 screens of warnings scrolling down on each build?

You don't. You either just stick with what works (for finished projects) or port it forward (for ongoing projects).

The Python community, being relatively small, seems to dig this aggressive way of making changes to libraries and the interpreter itself. It has many advantages and speaking of disdvantages, most of the ones you specify are really non-issues.

I mean, you're not forced to use the newest version of the interpreter. You're not forced to use the newest version of any library. Moreover, you're not forced to use a single specific version of the interpreter on a machine. And with the use of virtualenv or buildout, you won't complain that your application used to work, and it doesn't, because the environment evolved.

And if you're "scpying directories" between servers, relying on whatever version of the interpreter you find, you're doing it wrong.

Reply on news.ycombinator.com