People tend to say Computers are so fast today the overhead does not really matter, and if it does for a few inner loops, no problem: our language can interface with C. But that is beside the point. The real disadvantage of these languages is not their (somewhat inferior) execution speed, but their lack of static checking. If you write bogus in a compiled language, chances are the compiler will catch it. Some stricter languages[2] will catch more kinds of bogus than more lenient ones[3], but there are surprisingly many ways to write bogus that every compiler will catch. Interpreted languages do not have a compile phase, they just throw an exception when encountering bogus at runtime. If they encounter it: There are many execution paths through a program, and some may not be followed very often, making it easy to write, install, and use completely broken software. You may say Well, write tests then, but as useful tests are, they come with large disadvantages when relied upon as the only means of detecting errors: Firstly, they have to be written. A compiler knows about the language, but the developer has to write all necessary testcases by hand. It is easy to overlook something, and it is also very easy to be lazy and write too few tests (or none at all). Secondly, executing tests takes machine time (probably more than what was saved by not compiling), and writing tests takes developer time (lots of it). Finally, the static analysis a compiler provides tends to catch different errors than tests do, so combining the two will simply catch more problems than either method on its own.

Oh, and then there is the problem of external code. Libraries, modules, whatever. APIs should not change (needlessly), but sometimes they do. With ordinary binary code, there is an established way to keep around different versions of a given library, so older programs using an older API can still function. I am not aware of a similar mechanism for Python, so getting ImportErrors from a module that installed just fine is not that unusual. In fact, implementing such a method for an interpreted language would be somewhat more involved than for a compiled one: When a programmer links to a shared library, the linker will take that to mean the latest installed version of that library. The version number is then encoded into the application binary, so the correct library will be used whenever the application is started. However, the very nature of an interpreted language means that the program is not touched by anyone but the developer. So if the developer does not demand a particular version, nothing else does, either. Seriously: use a tool that fits the job rather than clutching a hammer and trying to see nails everywhere.

1. like Python
2. like Ada
3. like C

In the past few months, I have spent an hour or two almost every week to find the leak. Today, I have met with success:

In the normal fast-forward case the behavior remains unchanged. However, now local modifications and commits will be erased, and upstream rewrites are handled smoothly.  This ensures that the upstream
branch is tested as expected.

Argh! What bally idea is that? I would like to decide for myself what I want to test, thank you very much. If I really want to test Upstream, I will create a branch for that purpose. It is not up to some piece of software to decide in my place, and then remove my code from the repository!

If the computer eventually says no, that is not due to a tingling in the back. Rather, the certificate is rejected because one of the tests has failed; and a this place in the program, it is exactly known which test failed, so why not tell the user? Otherwise, the problem is pretty hard to fix, so most people probably just click ignore. In that case, I can just as well do away with support for certificates: they only work when the user understands what is going on and heeds error messages.

Nur: es klappte nicht. Egal, wie ich an der Konfiguration gedreht habe, das System hat immer alle reingelassen. Nach der Mittagspause bin ich dann über diesen Satz in der Dokumentation von rlogin gestolpert:

The login process is an instance of the login(1) program, invoked with the -f option if authentication has succeeded.  If automatic authentication fails, the user is prompted to log in as if on a standard terminal line.

Im Klartext: zuerst werden die ausgefuchstesten Bedingungen überprüft; wenn die sagen: komm rein, dann bist du drin. Wenn die aber sagen: du nicht, dann darfst du dein Paßwort eingeben und bis trotzdem drin. Na toll.

Wer denkt sich denn soetwas aus?

Hallo? In welchem Jahrhundert leben wir? OK, zu Zeiten von System 7 war das normal, aber ich dachte, diese Zeiten seien vorbei. Was soll ich denn ohne iTunes machen? Unglaublich.

Bei uns ging jedenfalls erstmal das Kopfschütteln los: Wollen die eigentlich kein Geld verdienen? Immerhin haben wir locker einen dreistelligen Betrag dagelassen, und das war sicher nicht der letzte Sonntag, den wir gemeinsam frühstücken — allerdings der letzte in diesem Café. Andernorts ist man sicher flexibler.

Eine kurze Google-Recherche führte zu dem Ergebnis, daß das bei diesem Gerät schonmal vorkommt. Vielleicht auch nur, wenn das WLAN eingeschaltet ist — wobei dann wiederum egal ist, ob man es auch benutzt. Abhilfe gibt es leider keine — vielleicht hilft es, WLAN auszuschalten, aber dann habe ich ein Kabel quer im Zimmer.

Ich bin begeistert. Offenbar gibt es also nicht nur Bananensoftware, sondern auch Bananenhardware. Vielleicht hilft es ja, ein paar Äpfel danebenzulegen.

Als ich am nächsten Tag Kollegen davon erzählt habe, sagten die mit größter Selbstverständlichkeit, daß spontane Reboots bei allen Herstellern zum Programm gehören.

Ich verbringe meine Zeit derweil mit Kopfschütteln — es kann doch nicht sein, daß es Standard ist, Produkte mit dermaßen dicken Fehlern auf den Markt zu bringen. Gibt’s denn niemanden mehr, der Wert darauf legt, gute Arbeit abzuliefern?

Das ist doch echt nicht wahr.

An einer Stelle mußte ich aber doch kräftig den Kopf schütteln:
Ihre privaten Schulden sind inzwischen doppelt so hoch wie das – schon kräftig gestiegene – verfügbare Einkommen.
Hallo? Schonmal was davon gehört, daß man Größen verschiedener Dimension nicht vergleichen kann? Offensichtlich nicht. Liebe Herren Reis und Nikolov: Schulden haben gemeinhin die Dimension Geld, Einkommen hingegen Geld pro Zeit. Die Aussage, das eine sei größer als das andere, ist ungefähr so sinnvoll, wie der bekannte Spruch Nachts ist es kälter als draußen; um den Vergleich ziehen zu können, muß man das Einkommen schon auf einen Zeitraum beziehen. Gut, das werden die beiden wohl gemacht haben, aber warum sagen sie uns dann nicht, ob sie Wochenlohn, Monats- oder Jahreseinkommen gemeint haben?

Ein Stückchen tiefer tun sie es dann schon wieder:
Für Stirnrunzeln sorgen vor allem Islands Auslandsschulden: Sie liegen mehr als vier Mal höher als die laufenden Einnahmen aus Exporten, die traditionell vor allem Fisch und Aluminium umfassen
Für Stirnrunzeln sorgt hier vor allem die Dimensionsanalyse, die wiederum feststellt: Schulden sind Geld, laufende Einnahmen aber Geld/Zeit, erstere können also gar nicht vier Mal höher als letztere sein.
Im übrigen beschleicht mich hier der üble Verdacht, daß selbst unter Berücksichtigung des korrekten Zeitraums (ich vermute mal: ein Jahr) immer noch eine falsche Aussage dasteht, weil die Auslandsschulden gar nicht viermal höher als die jährlichen Exporte, sondern nur viermal so hoch wie diese sind.
Aber da kann ich mich natürlich auch irren.

Manche Leute haben offenbar eine solch panische Angst vor dem Alter, daß sie auf gar keinen Fall 18 oder 34 oder sonstwieviele Jahre alt sein wollen — also sind sie 18 Jahre jung. An der Stelle bekomme ich dann regelmäßig einen Krampf in der Semantikeinheit meines Hirns. Wenn 25 mehr ist als 18, dann ist jemand, der 25 Jahre jung ist, wohl auch jünger als mit 18? Mit 36 wäre man dann gar doppelt so jung wie zur Volljährigkeit.

Wer unbedingt einen Jugendkult betreiben möchte, soll das gerne tun, aber nach Möglichkeit ohne Vergewaltigung der Sprache.

Reicht mir mal einer die Salzstreuerin?