rg88 schrieb:
Zeigt, dass du ziemlich wenig Ahnung bei sehr viel Meinung hast.
Diese "Schrott-Software" ist teilweise einfach der Backbone Systemen die seit Jahrzehnten eine hervorragende Arbeit machen. Vielen davon im Finanzsektor btw. Wenn man da mal einen Bug findet 25 Jahre später, weil einfach zum Beispiel größere Summen transferiert werden, als ursprünglich jemals geplant wurden, dann muss da eben jemand ran und das fixen.
Ja und jetzt? Dann hat man eben vor 60 Jahren SCHROTT-Software geschrieben. Warum muss sie erst jetzt jemand fixen? Warum gab es in den letzten 60 Jahren keinen Audit? Warum wurden die Probleme nicht erkannt? Warum gab es keine Unit-Tests?
Und überhaupt, "größere Summen"... was für eine Überraschung... warum hat man das nicht als Anforderung spezifiziert und keine Tests dafür geschrieben?
rg88 schrieb:
Ansonsten sind diese Codes so gut und ausgereift, dass man das nicht einfach mal so neuschreibt in einer modernen, objektorientieren Sprache. Vorallem, wenn diese hochkomplexen Systeme noch genau das machen, was sie sollen.
"ausgereift"... sorry, nein, auf schlechten Annahmen aufbauend hingerotzte Software ist nicht "ausgereift". Spätestens seit dem Y2K-Debakel sollte man gelernt haben, dass "ein paar Jahrzehnte ausreifen" als Qualitätsmerkmal nicht taugt.
Und wo habe ich geschrieben, dass objektorientierte Sprachen der heilige Gral seien? Projiziert da jemand seine eigenen speziellen Vorstellungen?
rg88 schrieb:
WorstCase musst eben einen Entwickler aus der Rente holen.
Ist halt so. MIt "Altmist" hat das überhaupt nichts zu tun. So eine stabile und
Wenn du schon OOP (scheinbar) verachtest: Nein, es muss nicht unbedingt nach der Machart von C++ oder Java oder .NET designt werden. Ganz im Gegenteil, der Java-Style der Architektur, der seit 20-25 Jahren gern gepredigt wird, halte ich nicht unbedingt für "das Beste". Man kann auch andere Patterns verwenden, die Fokus auf Komposition statt Vererbung legen.
rg88 schrieb:
zuverlässige und vorallem schnelle Software schreibe heute mal mit modernen Sprachen.
Ach so? Zuverlässig und schneller? Okay, Stichwort Zuverlässigkeit: dann sollten wir endlich, verdammt noch mal, RUST pushen. Das ist zuverlässig (schon AUS PRINZIP, jedenfalls sofern man keine Logik-Fehler einbaut, aber das in der Praxis nun mal viel seltener als blöde Programmierfehler). Und IMHO auch schneller, weil der Compiler an vielen Stellen optimieren kann, wo es eben den Kontext analysieren kann und auf den sicheren Regeln aufbauen kann, und damit eben schnelleren Code erstellen kann, und vor allem MULTITHREADED läuft (was aktuellen CPUs zugute kommt, also was so seit ca. 20 Jahren gewünscht ist, und eben nicht das Cobol-Gefrickel aus den 1960ern).
Sorry, aber du hast sowas von überhaupt keine Ahnung von Softwareentwicklung, das ist direkt putzig
