[linux-l] Re: Programmiersprachen - Lösung in Python (kurze Version)
Peter Ross
Peter.Ross at alumni.tu-berlin.de
Mo Sep 11 10:32:53 CEST 2006
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
Mehr Informationen über die Mailingliste linux-l