Die Zukunft der Entwicklung

Hallo zusammen,

wer heute das Handwerk des Programmierers erlernen will, steht vor einer teutonischen Wand von Möglichkeiten und Verfahren, viele Sprachmittel haben ihre eigenen Götzen,Gurus und Verfechter.

Eine Lösung dem gelockert gegenüber zu stehen sind die Predigten, das dass Sprachmittel ja fast keinerlei Aufmerksamkeit zukommen müsse, gehe es doch darum größere Ziele zu erreichen, egal mit welchen Mitteln.

Besonders diejenigen die nicht die Ehre hatten, die Zeiten der 70ziger und 80ziger Jahre in der Computerwelt zu erfahren ohne Internet, mit liebenswertem Briefverkehr zumeist mit der Hand erstellt, um verfahren und Möglichkeiten zu Kommunizieren, oft hatten jene ganze Wände voller Bücher um aus allen zusammen die Verfahren zu extrahieren die heute zum Einsatz kommen.

In neuster Zeit gibt es nun Hinweise auf Altersdiskriminierung, wo Softwarekerne die nicht von normalen Menschen verstanden werden können als Altmodisch oder gar unsicher betitelt werden,
so das nur noch gültige Industrie -Module als Fachfähig bezeichnet werden.

Es gibt heute weder Anwendungen noch Computerspiele die ohne eine Industriekomponente auskommt, die zumeist streng geheim und teuer bezahlt werden musste.
(Womöglich aus der Cloud geleast).

Das ist wie mit der Raumfahrt, niemand wird heutzutage mal ebbend auf dem Mond landen können
die Kernverfahren sind vollkommen verloren gegangen und müssen dann erst neu entwickelt werden.

Man sagt das Technologie später von Natur nicht mehr zu unterscheiden sei, werden wir dann vor den Computern der Zukunft dastehen wie heute vor den Zellen und Bioprozessen die wir im Ansatz nicht nachahmen können , als würden diese aus einer fernen Zukunft entstammen ?

Auch heutige Einstellungsbedingungen laufen darauf hinaus, wie gut man mit Industriekonserven umgehen kann, diese Entwickler stürzen sich lebenslang in ein Gebälk dessen Motorik unbekannt bleibt.

Wird zwar die klassische Softwareentwicklung C/C++/ASM allgemein als Stütze aller Gerüste betrachtet, wird zumeist jeder neu Einsteiger mit fertig Modulen seinen Weg finden.

Doch auch dafür benötigt man viele Jahre bis Jahrzehnte, und selbst dann ist man nicht im Stande die eigentlichen Prozesse auszulösen die zu seinen schwer erarbeiteten Ergebnissen führte.

Heute wird sogar von jungen Studierenden die althergebrachte Entwicklung komplexer Verfahren belächelt:

Altmodische Software !

Wie sieht es aus mit MFC ? Macht man sich zum Altersdösel wenn man dies als Basis verwendet,
anstatt ein Plattform cross QT zu verwenden ?

Ich denke das man diese Teile nur mit den Fingerspitzen zu tragen habe.

Was meinen andere ?

Grüße aus Berlin
Karsten

hustbaer

Also erstmal denke ich du siehst etwas zu Schwarz. Ich arbeite in einer Firma mit hunderten Entwicklern, und wir machen sehr viel C++ und haben da auch genügend gute und gleichzeitig junge Mitarbeiter (auch aber nicht nur im C++ Bereich!).

Was konkret MFC angeht: ich denke MFC ist für viele Dinge einfach zu mühsam wenn man es mit den Alternativen vergleicht. Speziell für neuentwicklung von komplexen GUIs ist MFC meiner Meinung nach keine gute Basis mehr. Wobei ich da auch Qt kritisch sehe. Ich denke man sollte sich auf jeden Fall im Bereich C#, Java oder sogar HTML5 umsehen wenn man heute ein Projekt startet wo man ne kompliziertere GUI benötigt. Das heisst ja nicht dass nicht trotzdem (u.U. grosse) Teile des Projekts in C, C++, whatever implementiert werden können. Wenn es denn Sinn macht - denn auch das wird oft nicht der Fall sein.

Meiner Erfahrung nach steht und fällt ein Projekt mit guten Entwicklern die sich gut mit "ihrer" Sprache bzw. "ihrem" Framework auskennen. (Mal abgesehen von gutem Projektmanagement/Requirements-Engineering.) Und da man normalerweise nicht auf einen Entwickler bzw. nichtmal eine kleine Gruppe von verfügbaren Entwicklern angewiesen sein möchte, sollte man sich eine Sprache und ein Framework aussuchen wo das Angebot an fähigen Entwicklern entsprechend gut ist, und das vermutlich auch in den nächsten Jahren bleiben wird. Dazu kann ich leider konkret wenig sagen. Ich würde aber vermuten dass MFC da eher am absteigenden Ast ist.

Hi Hustbaer,

ja so sehe ich das auch HTML bietet eine gute Möglichkeit eine Blackbox plattformübergreifend bedienbar zu machen. Es ist jetzt schon so, das cross UI-Plattformen nur noch einen Steuercode erzeugen der dann auf ganz ähnlicher weise zur Ausführung kommt, während der Kern auf einer VM -Läuft, oder auf einen abgestellten Rechner. Das scheint mir die beste Lösung zu sein einen dezentralen Rechenkern als ggf. "Mietbarer" -Host für alle Handy's/PC's/und Mac's ansteuerbar zu halten ohne zu versuchen die Kernelfunktionen auf den lokalen Umständen ablaufen lassen zu müssen.

Sehr gut, vielleicht gibt es ja noch mehr Hinweise ?

hustbaer

Ich würde das nicht einschränken auf Systeme wo der "Kern" und die GUI getrennt sind, also auf verschiedenen Rechnern/VMs/Prozessen laufen. Man kann das auch alles in einem Prozess machen, und es macht mMn. vermutlich oft immer noch Sinn.

Wenn man mit HTML5 schön GUI machen kann, wieso dann nicht mit HTML5 schön GUI machen und das ganze über z.B. Chromium Embedded Framework mit dem "Kern" zusammenknoten? Die HTML5 GUI Coder und alles was HTML5 so an Nettigkeiten mitbringt kann man da genau so einsetzen, und die C++/C#/... Coder können genau so das Backend entwickeln. Und wenn man ein bisschen drauf achtet dass höhere Round-Trip-Zeiten nicht zu sehr schmerzen, hat man auch die Möglichkeit es irgendwann mal auseinanderzureissen.

Plattformunabhängig kann man damit auch mehr oder weniger einfach bleiben, sofern man halt überall darauf achtet dass man es sich nicht versaut. (Was normalerweise heisst: So lange man von Tag 1 an nen Build, inklusive Tests, auf zumindest einer anderen Plattform mitlaufen hat.)

hustbaer

ps: Was (für mich erschreckenderweise) auch immer beliebter wird ist gleich überhaupt alles in JavaScript zu machen, inklusive "Kern". Ausgenommen vielleicht Numbercrunching und ähnliche Sachen, was man dann in externe C DLLs auslagert. NodeJS halt. Gibt vermutlich auch dümmere Dinge die man machen kann, aber ... ich weiss nicht ... ich bin halt kein Fan davon. Hauptsächlich weil ich JavaScript abscheulich finde, aber man kann kaum leugnen dass damit viel gemacht wird, und das Zeug wohl auch irgendwie funktioniert.

@hustbaer sagte in Die Zukunft der Entwicklung:

Wenn man mit HTML5 schön GUI machen kann

Kann man nicht. Das ist alles gruselige Flickschusterei. Douglas Crockford wollte ja mit seinem Seif Projekt Qt-Gui (QML?) in den Browser bringen. Ich hab allerdings schon lange nichts mehr davon gehört. Vielleicht wartet er ja auch darauf, dass Qt per WebAssembly im Browser läuft.

@manni66 Hi Manni,

Der Grusel beginnt natürlich bei den Laufzeitaspekten so wie der Vorposter schon angedeutet hat.
Woran bisweilen noch die Spieleindustrie scheitert ist es, auf einem lokalen Rechner lediglich nur noch einen Individuellen Videostream abzubilden, der den Eingaben des Benutzers entspricht.
So das überhaupt keine UI Lokal mehr erforderlich ist. Mit Steigerung der Datenraten in den nächsten 20 Jahren könnte aber genau das zur Realität werden, vielleicht mit der Folge das es auch keine lokalen Datenspeicher mehr geben müsse, und Prozessoren lediglich nur die Bilddecodier und Ein/Ausgabe Aufgaben zu behandeln haben. Eine ganze Industrie bräche zusammen, aber das Cloud-System der Industrie verweist genau auf das Scenario. Einen interaktiven Videostream zu erfassen. Alles auf Mietbasis. Programmierer könnten auch wegen der Viren(die von der Industrie selbst verbreitet wurden) in der Zukunft verachtet werden , und dazu führen das lokale Datenspeicher wie Schusswaffen verboten werden.
Genau das kann passieren, vielleicht nicht mehr zu unseren Zeiten, aber so könnte es kommen. Wie zb der Diesel Täter heute vom Staate zur Rechenschaft gezogen wird, auch wenn die Selbstzündung des Diesel -Tröpfchens physikalisch noch nicht verstanden ist, wird zur Zeit eines der effektivsten Antriebssysteme zur Götzenfigur.

Mechanics

@hustbaer sagte in Die Zukunft der Entwicklung:

Wenn man mit HTML5 schön GUI machen kann, wieso dann nicht mit HTML5 schön GUI machen und das ganze über z.B. Chromium Embedded Framework mit dem "Kern" zusammenknoten?

Haben wir vor mindestens 10 Jahren schon so gemacht. Die meiste GUI ist bei uns zwar Qt (also, in den Desktopvariante, mittlerweile haben wir natürlich alle möglichen Mobile- und Webfrontends), aber es gab durchaus einige Teile (vor allem die customisierbaren), die in einem eingebauten Browser liefen, und mit einem internen Webserver und/oder registrierten JavaScript Funktionen mit der Software geredet haben.

Gruselig ist GUI-Entwicklung immer. Oft kommt man mit Qt schnell ans Ziel. Ab und zu ist es aber ziemliches Gefriemel, bis man irgendwelche Nebensächlichkeiten so hinbekommen hat, wie man das wollte. Und vieles an unserer GUI ist sowieso ziemlich komplex, aber das ist einfach so und da ist Qt dann ausnahmsweise nicht dran schuld. Die komplexeren Sachen kann man auch ganz schlecht in HTML machen. Entweder müsste man dafür ziemlich viele Daten laden und der Server müsste sie irgendwie verwalten/cachen/nachladen. Oder man würde sie bei jedem Zugriff nachladen. Beides langsam und schlecht. Und man bräuchte für vieles viele Roundtrips. Da ist die saubere Trennung zwischen Darstellung und Kern dann nachhaltig.

HTML Entwicklung ist bestimmt auch gruselig, aber das interessiert mich nicht. Hab kaum mal jemals was mit HTML gemacht. Dafür gibts viele billige HTML Bastler wie Sand am Meer, die können das "einfach" machen und die erfahrenen C++ Programmierer müssen sich nicht mit GUI rumschlagen.

hustbaer

@Mechanics Klar gibt es viele Dinge bei denen man mit ner HTML GUI nicht glücklich werden wird. CAD oder so... uiuiui.

Aber bei GUIs die "nur" in dem Sinn komplex sind dass es hunderte Fenster/Masken/Abläufe gibt, ist HTML vermutlich oft OK. Ganz speziell wenn man dabei "TeX-artig" arbeiten möchte. Also ... wenns nicht wichtig ist dass jede Form 1:1 auf den Pixel so aussieht wie der Designerfritze sich das vorgestellt hat, dafür aber wichtig ist dass man ohne gross am Design schrauben zu müssen viele Form raushauen kann die dann automatisch alle zum Design der Anwendung passen und halbwegs brauchbar aussehen.

Und man bekommt eine Menge "gratis", wie schön pixelweise scrollbare Views. Wenn ich mir angucke wie viel Aufwand es z.T. in "klassischen" GUI Toolkits ist eine flüssig pixelweise scrollbare virtuelle ListView zu bekommen...

Dass es Dinge gibt die bei HTML GUIs nerven und z.T. fürchterlich nerven ist auch klar. Speziell wenn man zu viel CSS-KoolAid gesoffen hat und meint wirklich überall und immer auf Tables verzichten zu müssen.

Mechanics

@hustbaer sagte in Die Zukunft der Entwicklung:

Aber bei GUIs die "nur" in dem Sinn komplex sind dass es hunderte Fenster/Masken/Abläufe gibt

Nee, das meinte ich nicht mit "komplex". Komplex tatsächlich in dem Sinne, dass sie "komplex" sind. Also z.B. eben gut bedienbare List/Tree/Table Views mit sehr vielen Elementen. Die sehr dynamisch sind und aus vielen Quellen bei Bedarf nachgeladen werden und zur Laufzeit dazukommen oder durch Benutzerinteraktionen geändert werden. Und bei denen, bei denen der Benutzer was umstellen kann, ist es keine Logik die man in JavaScript implementieren würde/könnte, sondern basiert auf sehr viel C++ Code. Müsste man auf dem Server also so ein "Ding" mit Millionen Einträgen verwalten, weil ein Benutzer das kurz aufgemacht hat, und dann die Änderungen zum Browser synchronisieren. Nicht lustig, können wir auch nicht ^^ Ist aber eben auch in Qt sehr kompliziert, aber das ist eben der Client, und das sind die Daten, mit denen er arbeitet, die hat er halt direkt zur Verfügung.
Oder irgendwelche 3D Sachen, die man sich unterschiedlich anschauen und irgendwelche Auswirkungen von irgendwas visualisieren lassen kann. Da gehts auch nicht um das WebGL, um irgendwelche 3D Modelle darzustellen, sondern darum, woher diese Modelle kommen und wie sie berechnet werden und dass der Server sie dann auch komplett im Speicher halten oder jedes mal neue berechnen müsste.

Aber ansonsten klar, für einfachere Sachen sind HTML Guis bei uns auch auf dem Vormarsch.

*john 0

@kahnsoft sagte in Die Zukunft der Entwicklung:

Heute wird sogar von jungen Studierenden die althergebrachte Entwicklung komplexer Verfahren belächelt:

Altmodische Software !

Das Problem mit den ganzen neuen Softwarelösungen ist, dass sie vor allem eines sind – neu. In diesem FAZ-Artikel geht es ja explizit um Software aus der Naturwissenschaft. Ich kenne selbst Programmcode (aktueller Code!) aus der Physik, der noch in Fortran66 geschrieben ist. Wichtig ist in erster Linie, dass der Programmcode korrekte Ergebnisse liefert. Dann kommt der Punkt er soll möglichst schnell laufen. Klassischer Fortran77 Code nutzt deshalb in der Physik die Libraries BLAS, LAPACK, ODEPACK, o.ä. Insbesondere die BLAS und LAPACK gibt es von den Systemherstellern als hochoptimierte Versionen (MKL, SSP, …), so dass man ohne großem Aufwand sehr schnelle Programme erstellen kann. Die überwiegende Anzahl an Fachliteratur für Naturwissenschaftler nutzt noch Fortran77 als Programmiersprache, oder setzt auf moderne Modesprachen die dann ganz andere Probleme haben.

Wenn man wegen der sehr hohen Leistungsanforderungen auch auf einem HPC-Cluster rechnen muss, dann gibt es in diesem Bereich seit vielen Jahren etablierte Methoden die Software zu parallelisieren. Dazu wird dann fast ausnahmslos OpenMP und MPI eingesetzt. Diese beiden Techniken sind nur für C, C++ und Fortran vorhanden und getestet. Dazu gibt es spezielle kommerzielle Cluster-Debugger, die mit diesen drei Sprachen und diesen Techniken besten zurecht kommen.

Moderne HPC-Programmierung besteht in erster Linie aus Cache-Miss-Vermeidung. Sprich man muss immer und zu jeder Zeit wissen, wo welche Daten liegen und die Schleifen darauf optimieren. Macht man das nicht, lässt man sehr viel Rechenzeit ungenutzt verstreichen. Da mittlerweile SIMD-Einheiten und NUMA-Systeme alltäglich sind, muss man auch aus den Programmiersprachen heraus dies steuern können. Nur all die tollen neuen Programmiersprachen, nehmen darauf keinerlei Rücksicht.

Egal ob man neue Sprachen wie Rust oder die Neuerungen von C++ betrachtet. Überall wird so entwickelt, dass überhaupt keine Rücksicht auf die real vorhandene Hardware genommen wird. Die neuen Threads in C++ finden Softwarentwickler wahnsinnig toll. Aber sie sind zu 100% inkompatibel mit den von OpenMP bekannten Threads. Jetzt darf man sich auf dem System mit dem Systemthreads (bei HPC meistens pthreads), OpenMP Threads und den neuen C++ Threads herumschlagen.

Was dieser „tolle“ Artikel leider vollständig verschweigt ist das wissenschaftliche Problem der Programmseite. Wenn man Standardsoftware verwendet, dann kann man damit auch nur Standardprobleme lösen. Das mag bei etlichen Bereichen der Wissenschaft ganz ok sein, aber wenn man daran forscht wie man neue Methoden entwickeln kann, nützt das einem diese Standardsoftware rein gar nichts. Das ist nämlich das Problem mit standardisierter Software.

Was die Qualität von wissenschaftlicher Software betrifft. Man muss i.d.R. ohnehin sich exzessiv mit der wissenschaftlichen Fragestellung auseinandersetzen, um diesen Programmcode verstehen zu können. Müssen die Programme dann softwaretechnisch auf dem höchsten Niveau sein? Wenn die Programme schnell auf einem Cluster laufen, und die korrekte Forschungsergebnisse liefern, dann tun sie das wofür sie geschaffen wurden. Ich sehe beim Programmcode eher weniger das Verständnisproblem als bei der wissenschaftlichen Seite.