Filipe Brandenburger wrote: > At the risk of adding more wood to this fire... > > On Mon, Jun 15, 2009 at 11:04, Les Mikesell<lesmikesell at gmail.com> wrote: >> Yes but it has been obvious for a long time that python does not >> consider backwards compatibility to be important. > > Not true. There is a 2to3 program bundled with Python 3 that will take > care of most issues in the migration of Python 2 to Python 3. It's > true that some changes will affect scripts in a way that 2to3 can't > help, but those are mainly issues with the introduction of the > distinctions of "bytes" and "characters" in Python 3, which IMO are a > much needed feature. So there are parts that will change in mysterious ways that not even a pre-planned translator can fix predictably... And you'd like me to let something like that have administrative control of my machines? No, thanks. > Python 1 to 2 also introduced many changes, but AFAIR there were only > new (more OO-like) ways to do things, the old ones (not so OO) became > "deprecated" but scripts continued to work. But this was ages ago and > I don't think it's that relevant to this discussion... The scripts did not continue to work. I remember updating a Red Hat machine probably in the 6.x era and having mailman just stop working because of a gratuitous syntax change. >> By comparison, perl has been around longer and >> through more changes and yet about the only thing you might have to >> check on a program written for perl 1.x to run under 5.x would be >> whether you have @ in double-quoted strings that you wanted to remain >> literal. > > Excuse me? Have you heard about Perl 6? It's a complete rewrite of the > grammar of the language. They even want to change "." as the > concatenation operator. If not by the fact that they started working > on it about 7 or 8 years ago and it is complete vaporware, it would be > have been a *major* compatibility breaking change. Yes, I know about perl 6 and the fact that the developers have been responsible enough not to release it in a form that will break perl <6 programs. And I expect it to stay that way. Plus, perl has always been designed to support multiple concurrent installations although RPM packaging doesn't deal with it well. > Now, talking about Java, that's a nightmare... I, as a sysadmin, have > to maintain three or four JVM versions around in my machines, because > each developer needs a different one of them. Blame Red Hat for most of that. If they had shipped a working version or worked together with Sun to provide an easy third party RPM install that landed in the expected place, nobody would have used anything else. > Some say their code must > run in 1.5 and is not compatible with 1.6, 1.6 has some bugs, depending on the version. > some use GWT and need a > 32-bit JVM, That's a quirk of their hosted mode for debugging and should eventually have a workaround. I don't think it matters where the production runtime runs - I'm fairly sure OpenNMS uses gwt and I have both 32 and 64 bit JVMs running it unchanged. They package all the compiled java as noarch rpms. > I also need another 32-bit 1.6 JRE for Firefox which is > more stable, now there is OpenJDK (which does not have browser > plug-in) to complete the mess. Again, blame Red Hat packaging. > One of the developers said he needed > jdk_1.5.0_06 and he would not use jdk_1.5.0_15jpp because he was not > sure that the results would be the same. Too lazy to try and see? That seems very unlikely to break. > Not to mention that they have > very specific constraints on the versions of Tomcat and all the other > components... And while it is possible (though I doubt it) that a Java > program written in JDK 1.0.2 would still run in OpenJDK 1.6, the > language is completely changed, most methods were deprecated, there > are new ways to do *everything* from strings to basic I/O > (Input/Output Streams -> Readers/Writers) to Class Templates (whatever > they call them) to Graphic UI (AWT -> Swing -> whatever they're using > today) to Databases and threading/networking. I learned Java 10 years > ago and did not keep up... my knowledge of it is worth almost zero > today. Agreed on that point, but the changes are big improvements and I think you are judging the language comparing a decade old version to next year's python which seems a bit unfair. And as you obviously know, it it fairly self-contained and easy to run multiple versions concurrently although again, rpm packaging and the alternatives system don't really understand this concept very well. > I won't say one is better than the other. Each one has its advantages > and its own problems. You should choose one based on your personal > choice, and learn how to switch to another one for a specific project > if it seems it could be the right tool for the job. The unfortunate thing is that as projects evolve, you end up finding parts of what you want in one language and other parts in different ones so you can't easily combine them. For example, I'd love to be able to integrate the data from OpenNMS (snmp, network monitoring in java with a postgresql backend database and jrobin time-series data), Ocsinventory-ng (C++, and perl agents, php/perl servers with a mysql database) and racktables (php/mysql). Each does something the others miss, but each has its own copy of the relevant data. -- Les Mikesell lesmikesell at gmail.com