Re: Man kann auch heute noch ressourcenschonend *und* portabel programmieren.

Tims Katze schrieb am 24.05.2016 13:36:

Nein, man muss es sich leisten können!

Siehe mein Punkt 2) ... War bereits in der Diskussion enthalten.

Das macht Applikationen vielleicht unnötigerweise etwas größer, aber nicht langsamer. Die Alternative wäre ja, viele Räder wieder neu zu erfinden und im Gegensatz zu vor 35 Jahren gibt es heute verdammt viele Räder.

Ressourcenschonung bezieht sich nicht allein auf CPU-Zyklen. Einer der Punkte, den andere Foristen anführten, war insbesondere auch die enorm gestiegene Programmgröße.

Weiterhin war der von Dir selbst angeführte Punkt, dass die gesteigerte Ressourcennutzung eine direkte Folge der heute geforderten Portabilität und Wartbarkeit ist. Dem ist beileibe nicht so.

Ich halte von Javascript eh nichts (und von Fefe noch weniger, da er meint, zu jedem Thema eine Meinung haben zu müssen).

Das tut nichts zur Sache, was Du von Javascript und Fefe hältst. Der Punkt war, dass Leute sich heute -- sei es aus welchen Gründen auch immer -- gerne auf eine Vielzahl von Bibliotheken stützen.

Ob das Kind dabei Javascript, Python oder C(++) heißt, ist dabei unerheblich.

Die Frage, die man sich dabei stellen sollte, ist, ob es einen wirklich -- auch langfristig -- weiterbringt, sich hier in eine Abhängigkeit zu begeben.

Wenn es sich um etwas wie z.B. die fftw handelt oder irgendwelche GUI/Widget-Geschichten ist klar, dass man das nicht nachprogrammieren will (wozu auch).

Wenn es sich jedoch um trivialere Geschichten handelt (daher das Extrembeispiel node.js, wo Leute einfache min/max-Funktionen oder rechtsbündiges Drucken einbinden), gibt es schlicht keinen Grund, sowas zu tun.

Das ist doch Käse und nährt doch nur diese "Früher waren Programmierer noch echte Kerle"-Legenden. In den 90ern mag das vielleicht so gewesen sein, dass Entwickler deutlich mehr Rechenpower als ihre Kunden hatten, aber heute ist das eher andersrum. Es fällt den Entwicklern schon auf, wenn irgendwelche Flaschenhälse auftauchen.

Ich habe nicht behauptet, dass Entwickler deutlich mehr Rechenleistung als ihre potentiellen Kunden unter den Fingern hatten.

Ich habe gesagt, dass die Einstellung, dass es sich nicht rechnet, nennenswert Zeit auf Optimierung zu verwenden, aus dieser Zeit stammt.

Eben genau das kaufmännische Prinzip, das Du eingangs in dieser Replik angeführt hast.

Nur: Diese Zeit ist eben vorbei. Heute gibt's kein "free lunch" mehr. Diese Erkenntnis muss allerdings auch (endlich wieder) im Controlling ankommen, welches letztendlich die Programmierer an der Optimierungsphase hindert (bzw. überhaupt die Zeitfenster für eine ordentliche Anwendungserstellung zu knapp fasst).

Gehirnschmalz investieren bedeutet auch: Multithreading nur dort einzusetzen, wo es auch Sinn macht. Je abhängiger diverse Threads voneinander sind, desto schwieriger wird es, Stabilität und Determinismus zu garantieren.

Richtig. Und dort, wo es nicht geht und man in der Sequentialität gefangen bleibt, muss man eben wieder -- wie früher -- überlegen, ob man den Kram nicht doch effizienter implementieren kann.

Ich habe nichts dergleichen behauptet.

Ich zitiere aus Deinem Ursprungsbeitrag:

Es ist heute weder möglich noch gewünscht, dass Applikationen die Hardware direkt ansprechen und somit "optimiert" sind. Hacks, die damals für Performance und tolle Aha-Effekte sorgten, sind heute schon aus Sicherheitsgründen nicht erlaubt.

Dass heute einige Programme behäbig wirken, hat weniger mit den Leistungen des Entwicklers zu tun, sondern häufig mit den Bibliotheken, die er nutzt und den Systemeigenschaften, mit denen er zu kämpfen hat. Portabilität, Stabilität und Wartbarkeit haben ihren Preis.

Portabilität, Stabilität und Wartbarkeit sind eben *nicht* identisch zu "ich zieh mir das aus irgendwelchen Bibliotheken" (was letztendlich nur heißt, dass Du die Wartung an andere abtrittst -- und damit ggf. diesen hinterherlaufen musst, wenn sich die API ändert).

Auch ist die Behäbigkeit der Programme mitnichten den heutigen Betriebssystemen geschuldet. Sicherlich gibt es Entwurfsfehler (wie z.B. die seinerzeit festgenagelte Audiopuffergröße bei Android, weswegen es vernünftige Audio-Apps nur für iOS gab), aber die sind in ihrer Zahl gering genug, keine Rechtfertigung für behäbiges Programmverhalten zu sein.

Sicherlich gibt es auch gewisse Änderungen am Unterbau, so dass z.B. aufgrund von Latenzen Echtzeitverhalten mit modernen Betriebssystemen i.a. nicht in der Form möglich ist wie früher, als die Anwendung direkt an den Interrupts hing.

Aber auch das hat mit Behäbigkeit oder genereller Ressourcenverschwendung nichts zu tun.