Was kommt nach der Objektorientierung?

[Fast2]

Tut mir leid, dass das jetzt aus dem Gesprächsfluss heraussticht, aber ich dachte, ich hätte es schon gestern abgesendet, allerdings hatte ich dabei nur auf Vorschau geklickt.

Feriuko schrieb:

Die Symbolkraft endet an der Tastatur.

Solange ich da nicht die speziellen Unicodesymbole direkt und per default mit einem Tastendruck eintippen kann, werden Symbole für eine Programmiersprache keine Chance haben.

Ein kleines bisschen Hoffnung habe ich ja schon, dass sich endlich mal alternative Tastenbelegungen zumindest so weit verbreiten, dass ingendwann wenigstens mehr als 30% der Computernutzer überhaupt davon wissen, dass es die gibt …
http://neo-layout.org/

Dass es so viel mehr Symbole geben wird, glaube ich aber auch nicht, schließlich muss man die auch alle lernen, festlegen, wer welches nutzen darf, vielleicht neue schaffen, und so weiter, und so fort …
Da finde ich den bisherigen Stand schon ganz sinnvoll und auch die Konzepte, die es gibt.

Das, worauf ich ja noch warte, ist die Umstellung der Tastaturbedienung auf effizientere Varianten. Zum Beispiel sind die Tastaturform, insbesondere der Tastenversatz, und viele Bedienungsmuster noch Relikte aus der Schreibmaschinenzeit (zur Erinnerung: auch QWERTZ ).
Man könnte Tastaturen ergonomischer formen, sie besser an die Form der Hand anpassen und so nicht nur den Körper entlasten, sondern vielleicht auch schnelleres Schreiben ermöglichen.
Auch kommt mir das bisherige Programmbedienungssystem sehr suboptimal vor, Tastenkombinationen sind manchmal echt unbequem zu erreichen (besonders Emacs scheint ja dafür bekannt zu sein). Ich benutze ebenfalls bisher fast keine, sie anzuwenden war mir immer zu umständlich (und das Erlernen zugegebenermaßen wohl auch).
Die Modifikatoren könnten mehr in die Mitte der Tastatur rücken (das wurde für Neo3 auch diskutiert).
Ich wäre z.B. bereit, die Ebenen 5 und 6 aufzugeben, wenn ich auf sie dafür Tastenkombinationen legen könnte, die von Programmen auch erkannt werden und die irgendwie einheitlicher sind *.
Ich habe aber schon die ganze Zeit das Ziel im Gedächtnis, irgendwann mal zu lernen, mit einem der beiden Editoren Emacs oder Vim (oder einem Abkömmling) umgehen zu können. Falls ich die beiden gerade nicht vertausche, wird es aber wohl Vim, weil ich keine Lust habe, meine Finger zu verrenken.
Die Verteilung der Tastenkombinationen stellt mich bisher auch nicht zufrieden, ich habe mir beispielsweise g

Noch ein Einfall: Sprächen wir eine Sprache, deren Grammatik ein Rechner vollständig anwenden könnte, so könnte man auch beispielsweise nur noch Wurzeln und ggf., falls sie sich nicht ergibt, die Form eingeben und er macht den Rest. (Wobei ich nicht weiß, ob das wirklich schneller wäre, ich bin nur grad drauf gekommen, weil ich an Plansprachen gedacht hab)

*Mir ist gerade eine Idee wieder gekommen:
Eine Art Tastenkombinationsdatenbank, wo für Standardaufgaben bestimmte Tastenkombinationen gespeichert werden, die dann von Programmen direkt abgefragt werden können (und sollen). So könnte man sich beispielsweise Kopieren umlegen und müsste das dann nicht bei jedem einzelnen Programm tun.
Eigentlich alle Programme sind halt nicht auf Sonderfälle wie Neo optimiert, sondern auf QWERTZ, sodass die Bedienung manchmal – eigentlich unnötig – unbequem wird (Strg+W ist hier beispielsweise entsprechend Strg+T – da macht man die Tabs doch meistens eher mit der Maus wieder zu. Auch aufmachen liegt zwar eigentlich relativ bequem auf (entspr.) Strg+L, aber dafür muss dann entweder die linke Hand rüberspringen oder man muss beide Hände auf der Tastatur haben)
Sie würde vom BS bereitgestellt werden.

Nachtrag 1:

buchstaben schrieb:

auf einem touch-Display kann man unbegrenzt viele Symbole verwenden, man braucht dazu nicht mehr als eine icon-Leiste. Zukunftsfähig.

Jo, ein Dadsch-Bildschirm (wie er in Franken genannt wird) ist genau das, was ich fürs Programmieren benutzen möchte

Ansonsten möchte ich Mechanics zustimmen, Sprechen is doch viel zu anstrengend (und natürlich auch unschön, wenn man in irgendeiner Firma sitzt oder es in der Umgebung laut ist; das hatten wir ja beim Thema Sprachsteuerung schonmal)
Gestensteuerung und Hologramme halte ich ebenfalls für ungeeignet, aber grad bei der Arbeit mit DNS könnte ich sie mir Vorstellen, weil man damit doch ziemlich gut im Modell navigieren könnte, sich Ausschnitte anschauen, usw. (macht also quasi das Debuggen einfacher).

[pyhax]

Fast2 schrieb:

*Mir ist gerade eine Idee wieder gekommen:
Eine Art Tastenkombinationsdatenbank, wo für Standardaufgaben bestimmte Tastenkombinationen gespeichert werden, die dann von Programmen direkt abgefragt werden können (und sollen). So könnte man sich beispielsweise Kopieren umlegen und müsste das dann nicht bei jedem einzelnen Programm tun.
Eigentlich alle Programme sind halt nicht auf Sonderfälle wie Neo optimiert, sondern auf QWERTZ, sodass die Bedienung manchmal – eigentlich unnötig – unbequem wird (Strg+W ist hier beispielsweise entsprechend Strg+T – da macht man die Tabs doch meistens eher mit der Maus wieder zu. Auch aufmachen liegt zwar eigentlich relativ bequem auf (entspr.) Strg+L, aber dafür muss dann entweder die linke Hand rüberspringen oder man muss beide Hände auf der Tastatur haben)
Sie würde vom BS bereitgestellt werden.

Gibt es schon bei KDE 4 ( http://www.kde.org ) Ich habe aber noch nicht ausprobiert, in wie weit sich die Programme daran halten.

[redrew99]

Mechanics schrieb:

Wohl kaum. Ich glaube nicht, dass eine effizientere Eingabemöglichkeit geben wird, als eine stinknormale Tastatur, findets euch damit ab. Beim Programmieren muss man einfach viele Informationen eingeben und das wird auch so bleiben. Es wird nicht reichen, zwei Gesten im Raum zu machen (außerdem finde ich sowas sehr anstrengend). Und selbst Sprachsteuerung ist für soetwas nicht optimal. Sprechen ist (zumindest für mich, ich denke für viele andere auch) anstrengender, als tippen, und programmieren ist grundsätzlich zum Sprechen wenig geeignet und wird es wohl auch noch eine Weile bleiben.

Schwer zu sagen. Vielleicht braucht man dafür eine neue Programmiersprache.

Aber selbst bei C++ müßte es möglich sein,den Großteil der Sprache in dreidimensionale, veränderbare Symbole umzuwandeln.

Zusätzlich könnte man bestimmte Mechanismen der Sprache dreidimensional umsetzen.

Ganz ohne Tastatur wird es natürlich vermutlich nicht gehen.

[Xin]

redrew99 schrieb:

Aber selbst bei C++ müßte es möglich sein,den Großteil der Sprache in dreidimensionale, veränderbare Symbole umwandeln.

Zusätzlich könnte man bestimmte Mechanismen der Sprache dreidimensional umsetzen.

Ich stelle die Frage absolut wertfrei: Warum sollte man das tun?
Welchen Vorteil versprichst Du Dir davon, Quelltexte in 3D zu beschreiben? Und was soll die dritte Dimension abbilden?

[redrew99]

Xin schrieb:

Ich stelle die Frage absolut wertfrei: Warum sollte man das tun?
Welchen Vorteil versprichst Du Dir davon, Quelltexte in 3D zu beschreiben?

Ich könnte mir vorstellen, daß durch eine zusätzliche Dimension komplexere Programme möglich sind.

Evtl. sollte auch schnelleres Programmieren möglich sein.

So könnte z.B. ein Vektor mit einem bestimmten Gebilde dargestellt werden, wo man den Datentyp durch Veränderung der Farbe bestimmt. Der "Vektor" könnte darüberhinaus Buttons haben oder andere Eigenschaften(evtl. Displays?), um weitere Verändungen vornehmen zu können. Auch mit Tönen könnte man arbeiten.

Xin schrieb:

Und was soll die dritte Dimension abbilden?

Die dritte Dimension könnte die "Grammatik" der Sprache abbilden.
Womöglich könnte man z.B. einen Zeiger als einen echten Zeiger darstellen.

Natürlich könnte auch die jeweilige Anordung der Gebilde im Raum eine bestimmte Funktion haben.

[hustbaer]

@redrew99
Ich hoffe du meinst das nicht ernst.

Ich kann es auf jeden Fall nicht ernst nehmen. Alles was du schreibst führt bloss dazu dass man noch weniger Chancen hat ein Programm zu verstehen, und dass man vermutlich auch länger braucht um es einzugeben/bearbeiten.

Je genauer ich darüber nachdenke, desto eher kommt ich zu dem Schluss dass es eigentlich nur Getrolle sein kann.

[likeiceinthesun]

hustbaer schrieb:

Je genauer ich darüber nachdenke, desto eher kommt ich zu dem Schluss dass es eigentlich nur Getrolle sein kann.

Oft ist das leider nicht so.

[redrew99]

hustbaer schrieb:

@redrew99
Ich hoffe du meinst das nicht ernst.

Ich kann es auf jeden Fall nicht ernst nehmen. Alles was du schreibst führt bloss dazu dass man noch weniger Chancen hat ein Programm zu verstehen, und dass man vermutlich auch länger braucht um es einzugeben/bearbeiten.

Je genauer ich darüber nachdenke, desto eher kommt ich zu dem Schluss dass es eigentlich nur Getrolle sein kann.

Vielleicht hast Du Recht. Allerdings - gab es auch mal Zeiten, wo man sich nicht vorstellen konnte, daß Hochsprachen wie C++ ein derart hohes Leistungsniveau erreichen können.

Was wurden die Leute niedergemacht, ein Mehr an Abstraktion führe zwangsläufig
zu Geschwindigkeitseinbußen, etc.,etc.

[Eisflamme]

Also das ganze Dargestelle als Vektor usw. ist doch eigentlich nur eine andere Darstellungsform des Codes, oder? Dann hat das mit Kompilier/Ausführungszeit nichts zu tun. Trotzdem will ich lieber alles im Code eingeben als mich dann je nach Ausprägungsform der Struktur (Matrix, Vektor usw.) auch noch mit dem UI rumplagen zu müssen.

[Xin]

redrew99 schrieb:

Xin schrieb:

Ich stelle die Frage absolut wertfrei: Warum sollte man das tun?
Welchen Vorteil versprichst Du Dir davon, Quelltexte in 3D zu beschreiben?

Ich könnte mir vorstellen, daß durch eine zusätzliche Dimension komplexere Programme möglich sind.

Evtl. sollte auch schnelleres Programmieren möglich sein.

Ich tue mich sehr schwer damit, Ideen als Unfug abzutun, wenn ich sie nicht verstehe. Diese Idee verstehe ich nicht, habe aber den Verdacht, dass Du derzeit auch kein Konzept hast. Jedenfalls lassen "könnte mir vorstellen" und "eventuell möglich" darauf schließen.

Könntest Du ein konkretes Beispiel, einen konkreten Anwendungsfall beschreiben - unter Berücksichtigung, das der Mensch nur in der Lage ist, 2D Informationen mit einer ungefähren Entfernung wahrzunehmen, aber nicht 3D-Informationen. Um den Unterschied zu verdeutlichen: Du siehst den Monitor, Du siehst, dass er etwa 60cm vor Dir steht, aber Du siehst nicht, was hinter dem Monitor ist. Der Mensch sieht immer einen kleinen Ausschnitt der ihm zugewandten Ebene. Das Hauptsinnesorgan des Menschens ist das Gedächtnis, nicht das Auge. Entsprechend wird jede Kommunikationsform scheitern, die den Menschen überfordert.

Das höchste der Gefühle sind Ebenenwechsel, gewissermaßen kontextabhängige, also integere Schritte durch eine 3. Dimension, die jedoch mehr als Filter, denn als Sprachdimension funktioniert. Und das wiederum gibt es bereits in einfacher Form, auch wenn ich auf den derzeit populären Systemen keine brauchbare Umsetzung kenne.

redrew99 schrieb:

So könnte z.B. ein Vektor mit einem bestimmten Gebilde dargestellt werden, wo man den Datentyp durch Veränderung der Farbe bestimmt. Der "Vektor" könnte darüberhinaus Buttons haben oder andere Eigenschaften(evtl. Displays?), um weitere Verändungen vornehmen zu können. Auch mit Tönen könnte man arbeiten.

Bis auf die Töne verstehe ich nur Bahnhof und da pfeift bei mir der Zug.
Man könnte mit Tönen arbeiten, das kann ich mir mal vorstellen... damit hätten wir eine zusätzliche Dimension. Aber was sollte man dadurch zusätzlich ausdrücken? Und überflieg mal einen Buch und ein Tonband. Das Tonband geht Dir sehr schnell auf den Keks.

redrew99 schrieb:

Xin schrieb:

Und was soll die dritte Dimension abbilden?

Die dritte Dimension könnte die "Grammatik" der Sprache abbilden.

Definiere Grammatik.

Die Grammatik einer Sprache lässt sich in C, wie auch in Deutsch, wunderbar in einer einzigen Dimension (eine Zeile bestehend aus Buchstaben/Wörtern) abbilden. Die zweite Dimension (Zeilen) benötigen wir nur, damit wir nicht endlos nach links und rechts scrollen müssen, wie z.B. die Turing-Maschine.

redrew99 schrieb:

Womöglich könnte man z.B. einen Zeiger als einen echten Zeiger darstellen.

Ein Zeiger ist ein Integerwert. Das ist nicht sonderlich intuitiv, aber Zeiger konkret abzubilden würde einem Spaghetti-Teller entsprechen. Ebenfalls nicht meine erste Assoziation mit "intuitiv".

redrew99 schrieb:

Natürlich könnte auch die jeweilige Anordung der Gebilde im Raum eine bestimmte Funktion haben.

Neben dem Darstellungsproblem, wie auch Problem der menschlichen Unfähigkeit 3D-Informationen wahrnehmen zu können, erscheint mir das ganze... weit hergeholt.

Solltest Du Bezug nehmen auf Hollywoodfilme, wird Dir sicher aufgefallen sein, dass alle Geheimagenten grundsätzlich futuristische Betriebsysteme verwenden, die supertoll sind, aber niemals Windows und in jedem Film läuft ein Super-Nerd rum, der nie mehr als 3 Minuten benötigt, um sich in die geheimsten Anlagen reinzuhacken. Außerdem können sie aus vier Pixeln ein Bild rechnen, in dem man in der Spiegelung der Sonnenbrille noch genug Qualität hat, um ein Fahndungsfoto zu generieren.
Science Fiction beschreibt eine mögliche Zukunft. Aber die Wahrscheinlichkeit, dass wir irgendwann durch einen Spalt in den Erdkern fallen und dann mittig in der Luft schweben, wird auch in Zukunft mehr Fiktion als Science sein.

Hier geht's um komplexe Aufgaben, nicht nur darum mit einer Handbewegung ein Foto rotieren zu lassen: Hier ist die Technik soweit, aber man scheitert daran, sinnvolle Aufgaben für die Technik zu finden - die Beschreibung hat Hollywood nämlich nicht mitgeliefert.

[_matze]

Programmieren in einer stylischen 3D-Umgebung, wie du sie dir vorstellst, wird es sicher nicht geben, höchstens mal als Spaßprojekt von ein paar Studenten oder so. Ich könnte mir nichts unpraktischeres vorstellen. Du guckst zu viele Hacker-Filme.

Selbst bei grafischer Programmierung wie beispielsweise per LabView kann ich mir nur schwer vorstellen, welche Verbesserung eine dritte Dimension bringen soll. Höchstens könnte man mehrere Vi's in einem Control darstellen. Wird ein Sub-Vi aufgerufen, könnte es hinter dem aktuellen vi angezeigt werden o.ä. Aber das wäre absolut keine Weiterentwicklung des Programmierens an sich, sondern nur ein modisches Grafik-Gimmick ohne echten Mehrwert.

[*rant*]

Eigentlich gab es in den letzten 50 Jahren nur 2 "Trends", die sich halten konnten: Strukturierte Programmierung und (viel später) Objektorientierung. Ich denke, dass die Objektorientierung erhalten bleiben wird, sich aber weiterentwickeln muss. Die Grundidee ist sehr gut und unterstützt das Prinzip der Low Representational Gap. Man orierntiert sich an Konzepten, die es in der Realität offensichtlich gibt und abstrahiert dann.

Funktionale Programmiersprachen haben einen schweren Stand, weil das Paradigma so völlig quer steht zu praktisch allem, was etabliert ist. Klar, spezialisierte Anwendungen gibt es immer, aber verbreitet sind diese Sprachen nicht.

Die grossen objektorientierten Sprachen (ich denke da an .NET-Sprachen, C++ und Java etc.) werden in Zukunft noch mehr Rosinenpickerei betreiben und sich die besten Elemente der funktionalen Sprachen (und andere Konzepte) stehlen.

[Xin]

/rant/ schrieb:

Die grossen objektorientierten Sprachen (ich denke da an .NET-Sprachen, C++ und Java etc.) werden in Zukunft noch mehr Rosinenpickerei betreiben und sich die besten Elemente der funktionalen Sprachen (und andere Konzepte) stehlen.

Das Wort stehlen passt nicht.

Funktionale Programmierung ist - wie auch OOP - auch in C möglich und(!) wird auch betrieben. Es ist beides etwas unhandlicher als bei Sprachen, die OOP bzw. FP besser unterstützen.

Deswegen sehe ich hier auch keine Paradigmen, sondern Problemlösungen: Entwurfsmuster.
Die funktionale Programmierung ist allerdings ein etwas umständlicheres Konzept, was dank Multi-Threading derzeit Aufwind erhält.

Schlussendlich sind funktional ausgelegte Sprachen lediglich Sprachen, die diese Problemlösung syntaktisch hervorheben, bzw. bevorzugen, während imperative Sprachen mehr der Idee eines Kochrezeptes folgen, wo man auch mal was in eine Schüssel geben darf und das dann später weiter verwendet. Gerade dieses "Vorkochen" von Ergebnissen war früher deutlich wichtiger. Ein Programm reagierte nur durchgehend flüssig, wenn bei komplexen Berechnungen zuvor schon einiges vorbereitet war. Das passt aber nicht so gut in die Idee der FP.

Funktionale Design-Patterns wurden in der Vergangenheit also seltener benötigt. Sprachen wandeln sich entsprechend der Anforderungen. So vereinfacht sich die C++-Syntax nun zur funktionalen Programmierung hin, wie sie sich ursprünglich aufbauend von C zu OOP gewandt hat und anschließend zur generischen Programmierung gewandelt hat.

Das ist Evolution, eine Anpassung an die Wünsche und Bedürfnisse der Benutzer. Nicht stehlen.

Wer Programmieren als "Kampf der Paradigmen" hochstilisiert, hat offenbar nichts besseres zu tun.

[loks]

redrew99 schrieb:

Ich könnte mir vorstellen, daß durch eine zusätzliche Dimension komplexere Programme möglich sind.

Darin scheint mir den Denkfehler zu liegen das eine komplexere Abbildung der Sprache komplexere Programme ermöglich.

Genau das Gegenteil ist der Fall. Komplexere Probleme können heute nur dadurch bewältigt werden, weil die Darstellung vereinfacht wurde.

redrew99 schrieb:

Evtl. sollte auch schnelleres Programmieren möglich sein.

Komplexität => mehr Denkarbeit => mehr Chancen auf Fehler ==> langsameres Programmieren.

redrew99 schrieb:

So könnte z.B. ein Vektor mit einem bestimmten Gebilde dargestellt werden, wo man den Datentyp durch Veränderung der Farbe bestimmt.

Farben sind abhängig vom Monitor und der Sehfähigkeit des Benutzers (-> rot/Grün Schwäche, Farbenblindheit etc). Allein das ist erzeugt ein Problem. Ausserdem erzeugst Du nur eine Abstraktionseben. Anstatt den Datentyp direkt zu shene (long) musst Du lernen das Rot = long ist, Grün = int usw. Die Darstellung eigener Datentypen wird dann schon eine Herausforderung. UNd so viele unterscheidbare Farben gibt es gar nicht.

redrew99 schrieb:

Auch mit Tönen könnte man arbeiten.

Ok, alle die Hand heben die eindeutig den Ton C erkennen wenn er gespielt wird. Dafür braucht man ein absolutes Gehör und das ist sehr selten.

redrew99 schrieb:

Natürlich könnte auch die jeweilige Anordung der Gebilde im Raum eine bestimmte Funktion haben.

Eines der wichtigsten Kriterien für eine Sprache ist, das man sich auch mit anderen Menschen darüber unterhalten kann. So, jetzt beschreib mal die Anordnung der Konstelllation Kassiopeia eindeutig nur durch Worte so das jemand anders begreift, das Du Kassiopeia meinst.

[Mechanics]

redrew99 schrieb:

Vielleicht hast Du Recht. Allerdings - gab es auch mal Zeiten, wo man sich nicht vorstellen konnte, daß Hochsprachen wie C++ ein derart hohes Leistungsniveau erreichen können.

Was wurden die Leute niedergemacht, ein Mehr an Abstraktion führe zwangsläufig
zu Geschwindigkeitseinbußen, etc.,etc.

Da gibts aber einen ganz wichtige Unterschied. C++ und Objektorientierung sind Sachen, die grundsätzlich nützlich und einleuchtend sind. Dass man sich früher nicht vorstellen konnte, dass man sie ohne gravierende Nachteile in der Praxis einsetzen können wird, ist eine andere Sache, das waren technische Probleme, die gelöst wurden. Wenn du von "3D Programmierung" reden, ist es etwas, wo sich niemand (außer Hollywood) vorstellen kann, wie das gehen soll und was es für einen Sinn haben sollte, außer dass es stört und ablenkt.
Man kann C++ sicher nicht in die dritte Dimension erweitern. Du bringst Daten und Darstellung durcheinander. Die Darstellung hat nichts mit der Sprache zu tun. Du könntest also (rein hypothetisch) statt vector<int> irgendwie vector und in der Z-Ebene int schreiben. Das wäre eine andere Darstellung. Irgendwie. Kannst aber nicht in die Sprache einbringen, nicht richtig beschreiben, speichern, nichts. Stört nur. Und natürlich kann ich viel schneller vector<int> eintippen, als irgendwie in die dritte Dimension zu wechseln, int einzugeben, und dann zurückzuwechseln. Das macht von vorne bis hinten überhaupt keinen Sinn.
Selbst so grafische "Programmiersysteme" wie Workflows, die z.B. Geschäftsprozesse beschreiben kann ich mir nicht dreidimensional vorstellen. Ich kann jetzt überhaupt keinen Vorteil darin erkennen, aber zusätzliche Komplexität.
Töne macht genauso überhaupt keinen Sinn. Versuch bloß nicht, irgendwelche Zusätzlichen Dimensionen reinzubringen, KISS. Geschriebenen Code kann man sehr schnell überfliegen und versteht oft gleich, was es macht. Etwas, was da aus der Reihe tanzt, eine zusätzliche Dimension von Tönen z.B. macht es schon sehr viel schwieriger. Das muss man im Hirn synchronisieren. Und dann hat man sich verhört und denkt sich, hä, nochmal... Weil mans eben nicht sehen kann
Ansonsten: YMMD

[Allesquatsch]

Marty Mc Fly schrieb:

Wildes Spekulieren über Softwareentwicklung in 10, 30 oder 50 Jahren.
Würde mich interessieren wie ihr euch die Zukunft der Programmierung vorstellt

Ich denke, dass schon die Fragestellung veraltet ist. In den Achtzigern und Neunzigern wurde die Programmierung als die Schlüsselstelle angesehen, die die Effektität des Einsatzes von IT maßgeblich beeinflusst.
Tatsächlich aber hat sich an den in der Softwarekrise benannten Problemen in den letzten vierzig Jahren eigentlich nichts verändern.

Ich halte deshalb die Fragestellung schon für das Problem selbst: Die Vorstellung, dass die Lösung von üblichen Problemen der Softwareentwicklung in der Findung eines technischer Mittels (Hardwarearchitekturen, Programmiersprache, Entwurfsmuster, Softwareentwicklungsprozess, Modellierungswerkzeug) läge.

Ciao, Allesquatsch

[hustbaer]

Allesquatsch schrieb:

Ich halte deshalb die Fragestellung schon für das Problem selbst: Die Vorstellung, dass die Lösung von üblichen Problemen der Softwareentwicklung in der Findung eines technischer Mittels (Hardwarearchitekturen, Programmiersprache, Entwurfsmuster, Softwareentwicklungsprozess, Modellierungswerkzeug) läge.

Also Hardwarearchitekturen, Programmiersprachen, Entwurfsmuster, Softwareentwicklungsprozesse, Modellierungswerkzeuge - das sind mMn. alles Dinge die in der Vergangenheit massiv viel gebracht haben. OK, über Modellierungswerkzeuge kann man vielleicht streiten, aber der Rest...?!?

Einige davon sind vermutlich noch nicht ausgereizt, andere (was die Lösung von "üblichen Problemen der Softwareentwicklung" angeht) vermutlich schon. Nur ... wenn es in der Vergangenheit solche "technischen Mittel" gab, die viel gebracht haben, wieso sollte es dann in Zukunft nicht wieder so sein?

[Nexus]

Im Bezug auf Visualisierung könnte sich aber schon noch was tun. Das müssen ja nicht gleich Hologramme und Steuerung à la Minority Report sein.

Automatisch generierte Klassendiagramme sind schon ein Anfang. Der nächste Schritt wäre, solche Darstellungen auch während der Laufzeit anzupassen. Für Debugging könnte man Datenstrukturen grafisch darstellen und Beziehungen untereinander sichtbar machen. Beispielsweise Zeiger als Pfeile oder Veränderungen von Werten durch Animationen (und evtl. Soundeffekten). Um den Spaghettiteller zu vermeiden, bildet man eben nicht den ganzen Adressraum, sondern nur relevante Teile ab. Interessant sind vielleicht auch Grafiken, welche den zeitlichen Verlauf miteinbeziehen.

Fürs Schreiben des Codes sehe ich diesbezüglich aber eher weniger Potential. Wizards können zwar einzelne Boilerplate-Aufgaben übernehmen, aber der Grossteil des Codes wird wohl weiterhin von Hand (u.U. mit Unterstützung von Vervollständigungstools) geschrieben.

[Mechanics]

Nexus schrieb:

Beispielsweise Zeiger als Pfeile oder Veränderungen von Werten durch Animationen (und evtl. Soundeffekten).

Sicher könnte man was verbessern, evtl. sogar viel. Weiß nur noch nicht wie. Aber was du vorschlägst schaut für mich schon wieder nach Spielereien aus. Visual Studio Debugger markierte Werte, die sich geändert haben rot. Damit komme ich durchaus zurecht. Ich will da keine Animation und bloß keine Soundeffekte. Würde nur ablenken und stören.
Und ein Pfeil für Zeiger? Auf was soll er zeigen und wie soll das ausschauen? Wenn der Debugger den Zeigertyp kennt (und das tut er, wenn man nicht grad void* verwendet), dann zeigt er den Wert an, den kann man aufklappen usw... Find ich schon durchaus brauchbar gelöst.
Was mich beim Visual Studio C++ Debugger stört ist die autoexp.dat. Ich finde sie nicht intuitiv genug um damit viel anfangen zu können. Viel zu kryptisch, ich muss mich jedesmal reindenken und rumprobieren (und dabei Visual Studio neustarten). Der C# Debugger ist da z.B. wesentlich besser, allein schon weil es eine ToString Methode gibt, die man überschreiben kann und die in 98% der Fälle beim Debuggen enorm weiterhilft, und weil man eigene Visualizer programmiern kann, was man aber selten braucht.

[Allesquatsch]

hustbaer schrieb:

Also Hardwarearchitekturen, Programmiersprachen, Entwurfsmuster, Softwareentwicklungsprozesse, Modellierungswerkzeuge - das sind mMn. alles Dinge die in der Vergangenheit massiv viel gebracht haben. OK, über Modellierungswerkzeuge kann man vielleicht streiten, aber der Rest...?!?

Da stimme ich Dir auch zu und ich selbst finde diese Ansätze auch wunderbar. Aber es gab immer eine große Diskrepanz zwischen den Erwartungen und dem, was nachher wirklich passiert ist. (Und es waren nicht nur die Marketing-Jungs, die diese Erwartungen hatten. Noch heute begegnen mir genügend Techniker, die daran glauben, dass die konsequente Anwendung der Innovation XY in x Jahren die üblichen Probleme beseitigen würde.)

Natürlich ist die technische Infrastruktur, Standard- und Individualsoftware immer mächtiger geworden, aber bei den klassischen Kriterien der Softwarequalität hat es nicht den erwarteten Sprung gegeben: Korrektheit, Zuverlässigkeit, Robustheit, Effizienz, Benutzerfreundlichkeit, Wartbarkeit, Wiederverwendbarkeit, Portabilität.

Zumindest habe ich nicht den Eindruck, dass sich die Quote der erfolgreichen, in Time&Budget gebliebenen Softwareprojekte nicht verändert hat, dass Programme nicht fehlerfreier oder korrekter geworden sind.

Natürlich sind die Entwicklungen positiv und konsequent: Von strukturierter Programmierung zur Objektorientung zur Serviceorientierung.
Aber die Kluft zwischen dem fachlichen Bedarf und den produzierten Lösungen ist geblieben.

Ciao, Allesquatsch