Aber sehr oft ist der Lösungsansatz ja auch kundengetrieben
... oder vorgesetztengetrieben, hab ich da so gedacht
Wenn der Kunde eine Oracle-Datenbank hat und dort Daten durch die Gegend geschoben müssen (auch über Servergrenzen hin weg), dann mache ich dies nach Möglichkeit per
SQL-Stored-Procedure und Triggern. Dies ist an Performance nicht zu schlagen und bietet mittlerweile auch relativ viele Möglichkeiten der Codierung.
Jupp, wohl wahr. Was man in
SQL ausdrücken kann, sollte man nicht in anderen Sprachen ausdrücken. Auch schon mehrfach anders erlebt.
Aber um es zu unterstreichen (und nicht missverstanden zu werden), in einem anderen Kontext kann dann Framework A Sinn machen, weil der Aufwand sonst zu groß wird. Nur muss man es dann wirklich im Griff haben und auch trotzdem noch in der Lage zu sein, zu verstehen, was die Software wann und warum tut. Wenn man dies nicht mehr versteht, sollte man das Vorgehen überdenken, den wehe es kommt ein Fehler.
Ich denke das kann man generell so sagen, oder? Mir wird ja auch immer bange wenn Kollegen nicht wissen wie etwas hinter den Kulissen läuft, aber gleichzeitig basierend auf Annahmen (oder anders ausgedrückt: Unwissen) Entscheidungen treffen oder gutheißen. Diese Vorgehensweise gibt es natürlich in Schattierungen. Aber ein Fall wo ich das regelmäßig erlebe ist das Linken auf Linux. Da wird auf Uraltsystemen gebaut, nur weil man nicht versteht wie's funktioniert und man so ja Aufwärtskompatibilität bekommt. Daß damit auch veraltete Compiler und Bibliotheken in Stein gemeißelt werden, wird dabei gern ignoriert.
Dabei geht es ja nicht um die 40 neuen Keywörter, sondern eher um neue Konzepte wie Funktionale Programmierung.
Genau. Das meinte ich bei so Beispielen wie Lisp. Diese Konzepte aus "Fremdsprachen" sind es ja - aus meiner Sicht - die den Horizont erweitern.
Es gibt natürlich die Entwickler welche das letzte aus einer Sprache rauskitzeln müssen,
und deswegen an theoretische, performante, speicher- threading- stack- und andere Limits stossen können.
Naja, meistens habe ich es erlebt, daß basierend auf Annahmen über das Laufzeitverhalten Entscheidungen getroffen wurden wie "das implementieren wir direkt in Assembler", obwohl niemand nachgemessen hat. Und Compiler sind inzwischen extrem gut im Optimieren. Solche Anwendungsfälle gibt es und im Embedded-Bereich will man natürlich alles rauskitzeln, aber zuvor messen sollte man schon. Ansonsten optimiert man an der falschen Stelle. Daher würde ich der Behauptung, daß an einer gewissen Stelle Optimierungsbedarf besteht, immer mit Skepsis begegnen.