[linux-l] Re: Programmiersprachen - Lösung in Python (kurze Version)

[Peter Ross]

On Mon, 11 Sep 2006, Olaf Radicke wrote:

> Am Montag, 11. September 2006 02:43 schrieb Peter Ross:
> [...]
> > Im Endeffekt nutzt eine Java-Applikation die Ressourcen des
> > Betriebssystems so nicht optimal, weil sie in einer VM ablaeuft, die vom
> > OS abstrahiert.
> >
> > Es ist eigentlich eine Art "Emulationsproblem".
> >
> > Ich weiss nicht, wie unter diesem Gesichtspunkt andere Programmiersprachen
> > abschneiden, finde aber, soetwas sollte auch bei der Wahl einer Sprache
> > fuer einen bestimmten Zweck Beachtung finden, da sie zum spaeteren
> > Zeitpunkt, wenn der Entwickler seine schoengeschriebene Anwendung eben zur
> > Anwendung kommen laesst, ploetzlich ein ernsthaftes Problem werden kann.
> 
> Java und .Net spielen beide in der selben Liga und ich werfe in diesen 
> Zusammenhang mal beide in einen Topf.
> 
> Jetzt hast du über ein Dutzend Sprachen für .Net zur Auswahl (u.a. Java). Du 
> kannst den Code in der Runtime laufen lassen, interpretieren lassen oder 
> Assemblys oder schlimmeres erstellen lassen. Es gibt unterschiedliche VM. Für 
> Java gibt es sogar eine mit harter Echtzeit. 

Schoen. Nur alle VMs, Libraries etc. haben halt ihre Bugs. Die zumindest 
fuer unsere Applikationen von Wichtigkeit sind. Die Developer sind mit 
diesen Bugs vertraut, und das Umschwenken auf eine andere 
Java-Implementierung ist nicht etwas, was man mal auf die Schnelle 
betreibt. Eine andere Hardware, ein anderes OS "mal fix" verbietet sich 
eh, bei einer Masse von 50 Servern ueberall in der Welt.

> Da sage ich: "...Jehova, Jehova!" Mir doch egal. Wenn die Puritaner noch 
> Speicherlöcher und Pufferüberläufe suchen, schreibe ich schon meine zweite 
> Applikation.

Well, angenommen Du hast Deine bei uns hier geschrieben. Dann kommt die 
Testabteilung zurueck, weil es hier und da knirscht oder schlimmstenfalls 
crasht. Und Du wirst uns nicht davon ueberzeugt bekommen, fuenf 
Java-Versionen auszuprobieren, bis eine "passt". Bei der Komplexitaet 
unserer Anwendung kannst Du auch sicher sein, dass Du mit jeder auf 
Probleme stoesst. Dann lieber "stick with the devil you know". Das 
passiert eben, wenn Anwendung auf Real World losgelassen wird.

Ich habe meine Zweifel, ob Du hier schnell mal Deine zweite App schreiben 
wuerdest;-)

Meine Kollegen, die ich fuer alles andere als inkompetent halte, haben 
auch ohne Speicherloecher und Pufferueberlaeufe genug damit zu tun, die 
Qualitaet einer rund um die Uhr von mehreren tausend usern gleichzeitig 
genutzten Anwendung zu sichern, sowie neuen Anforderungen gerecht zu 
werden. Derzeit ist eben das Speichermanaegment ein Problem, die Garbage 
Collection. koennte ich andersrum sagen: "Das kann mir mit C nicht 
passieren" ;-)

Nun halten wir dank gutem Monitoring, 24x7-Roster (inklusive dem Mobile 
auf der Bettkante des Nachts, jede dritte Woche) und Nokia Communicator 
die durchschnittliche downtime auf deutlich unter 10 Minuten pro Absturz, 
aber trotzdem sind Abstuerze zweimal die Woche nicht unbedingt der 
Reputation der Firma dienlich.

Ich bin meinen Entwicklerkollegen sehr dankbar, dass sie die Real 
World-Probleme ernstnehmen.

Gruss
Peter