Was kommt nach der Objektorientierung?
-
die zukunft kennt keine menschen, traurig aber wahr
-
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
Weiß doch hier keiner. Hier kommen nur ein paar alte Konzepte wie funktionale Programmierung oder Haskell, die uns jetzt schon seit es Jederman-Multicore-CPUs gibt als die Zukunft versprochen werden, aber Jahre später sind sie immer noch nicht die Zukunft. Vielleicht wird noch die Sprachprogrammierung, wie aus Enterprise, aufgezählt.
Wenn hier einer eine wirklich gute Idee hätte, wird er sie doch nicht hier verraten.
-
Ich denke, ein großes Problem bei der Softwareentwicklung ist es, komplexen Code handhaben zu können. Die OOP ist dieses Problem angegangen, indem sie Funktionalitäten und Daten sinnvoll zusammengefasst hat. Ich denke, in diese Richtung werden wir noch ein bisschen Entwickkung sehen. Vielleicht nicht so sehr in den Sprachen selbst, als vielmehr in den Standardbibliotheken. Möglicherweise wird es bessere Unterstützung für Patterns geben und vielleicht werden dafür auch ein paar Sprachmittel entstehen.
Auf der anderen Seite kommen Herausforderungen durch die Veränderungen der Hardware. Wir sehen in den letzten Jahren, dass mehr und mehr Rechenkerne in die Prozessoren einziehen. Zudem werden jetzt auch noch Grafikkerne in die CPU integriert. Man hat in Zukunft also eine sehr parallele und heterogene Hardware. In erster Linie wird das eine Herausforderung für die Compiler sein, aber ich denke, dass eine gute Ausnutzung dieser Hardware vor allem dann zu erreichen ist, wenn in die Sprachen auch ein paar Sprachmittel einfließen, die es dem Programmierer ermöglichen, bestimmte Eigenschaften seines Codes explizit zu machen. Zum Beispiel die Parallelisierbarkeit.
Was funktionale Programmierung angeht, bin ich skeptisch. Es ist ja nicht so, dass Haskell oder eine andere funktionale Sprache in den letzten Jahren einen riesigen Boom jenseits der Hobbyprogrammierer-Szene hatte. Ich habe zumindest nichts in der Art mitgekriegt. Es ist eine absolute Ausnahmen, wenn irgendwo mal Haskellprogrammierer gesucht werden.
Aber wie gesagt: Ich denke, die größten Veränderungen wird es bei den Standardbibliotheken geben.
-
ehrlich schrieb:
Weiß doch hier keiner. Hier kommen nur ein paar alte Konzepte wie funktionale Programmierung oder Haskell, die uns jetzt schon seit es Jederman-Multicore-CPUs gibt als die Zukunft versprochen werden, aber Jahre später sind sie immer noch nicht die Zukunft.
Weil wir auch erst am Anfang der Entwicklung sind, die für funktionale Sprachen als Vorteilhaft angenommen wird. In einem bekannten Artikel von Herb Sutter (http://herbsutter.com/welcome-to-the-jungle/ ) wird genau dargelegt, welche Entwicklung in naher und mittelfristiger Zukunft zu erwarten sind. Gregor hat sie bereits angesprochen: heterogene multi-core cpus mit einer großen Zahl von Kernen, sowie Cloud-Computing. Erste Ansätze dieser Entwicklung finden sich bereits in MapReduce-Datenbanken, die auf einem funktionalen Konzept basieren.
Ich würde nicht so weit gehen zu sagen, dass rein funktionale Sprachen wie Haskell den Siegeszug antreten. Dafür ist es zu früh. Ich würde aber darauf wetten, dass wir mittelfristig in allen größeren Programmiersprachen das Hinzufügen oder die Emulation von funktionalen Konzepten sehen werden.
-
knivil schrieb:
DIe Zukunft ist Haskell ...
... und Haskell wird immer die Zukunft sein ...
-
ehrlich schrieb:
Wenn hier einer eine wirklich gute Idee hätte, wird er sie doch nicht hier verraten.
Mit dem Thema beschäftige ich mich jetzt seit über 10 Jahren. Ich entwickle eine Programmiersprache, in der ich Ideen ausprobiere, teilweise halte oder auch wieder verwerfe. Eine der Ideen, habe ich vor 5 oder 6 Jahren hier in einer Rohfassung im Forum diskutiert mit dem Ergebnis, dass mir von allen Seiten erklärt wurde, das diese Idee ziemlich dämlich ist.
Dieses Jahr habe ich mich an die Implementation eben dieser Idee gesetzt. Sollte ich die Sprache dann irgendwann mal geschliffen habe, so dass ich nicht nur im kleinsten Kreise zeige, bin ich sehr auf die Reaktionen gespannt, ob die Idee nun dämlich oder sinnvoll ist. Bisher bin ich sehr optimistisch. Im kleinen Kreis fiel auch schon das Wort "genial".
Schlussendlich ist was ich mache allerdings weniger "genial", als nur eine Reaktion auf (mir) bekannte Probleme oder Reaktionen aus besagtem kleinen Kreis. Es ist eine Weiterentwicklung, kein Neubeginn, wie alles, was ich für meine Sprache entwickle. Ich stehe in C++ vor einem Problem, es nervt, ich formuliere einen Code, der das Problem löst und überlege, wie man ein solches Konstrukt in (m)einer Sprache beschreiben würde.
Genauso wie OOP eigentlich kein neues Paradigma darstellt, sondern nur eine sinnvolle, standardisierte Lösung auf ein Standard-Problem; OOP ist ein in Programmiersprachen eingearbeitetes Design-Pattern. Klassen und OOP in C++ als Spracherweiterung zu C, eben "C with Classes", wie es Stroustrup nannte.
Für diese Aussage habe ich hier auch schon gut einstecken dürfen, denn das ist fast schon eine religiöse Frage in der Informatik. Im Informatik-Duden lässt sich jedenfalls meine Aussage belegen, wie auch widerlegen, was dem Duden eine gewisse Bibelqualität verleiht.
Die ganze Diskussion, ob funktional oder imperativ, reduziert sich auf wenige gemeinsame Grundlagen, bei denen man schlussendlich feststellen muss, dass die einen Sprachen einfach sich einfach mehr um die einen Standardprobleme kümmern und die anderen mehr um die anderen Standardprobleme. Wer in einer solchen Problem recht behält ist derjenige, der glaubt, dass seine Standardprobleme für den Rest der Welt auch gelten.
Daraus lässt sich schließen, dass wir in Zukunft eher weiterhin über Standardprobleme streiten werden. Eher als über Sprachen oder Ideen, wie man diese Probleme so abstrahieren kann, dass sich mehrere Probleme mit einer zu als Sprachfeature zu implementierenden Lösung erschlagen lassen. Dieser Streit wird sich argumentativ vorrangig mit existierenden Features ausgefochten, denn Ideen wären ja schon längst Realität, wenn sie sinnvoll wären - sonst hätte das ja schon längst einer gemacht.
Im IRC erklärte man mir mal, dass was ich tue nicht machbar ist. Dass etwas bereits umgesetzt ist und existiert, ist dabei jedoch kein Argument.Und ob es überhaupt Lösungen gibt, muss man dann ausprobieren. Vieles wurde nämlich noch nicht gemacht. Den Aufwand machen sich aber nur wenige, während ein Reply zu einem Posting vergleichsweise schnell geschrieben ist.
In Hinblick auf die Historie gehe ich also von Weiterentwicklung aus: zum einen der Entwickler, die sich mehr mit generischer Programmierung auseinandersetzen werden, genauso wie in den 80er Klassen überflüssiger Humbug waren und heute State-of-the-Art sind, so wird sich generisches Programmieren ausbreiten. Und es zeichnet sich ab, dass Multithreading zu einem Standard-Problem wird, für das Lösungen gefunden werden müssen. Daher meine vorherige Antwort.
Die Details, die im kleinen Kreis bei mir oder den Entwicklern der anderen Sprachen entstehen, würden niemals als Paradigmenwechsel bezeichnet werden, ergo wird auch nie in einem solchen Forum ein Paradigmenwechsel im Voraus diskutiert werden.Am Ende lösen wir nämlich nur Probleme mit Hilfe von Computerprogrammen unabhängig von religiösen Überzeugungen. Mehr Sprach-Paradigmas haben wir eigentlich nicht, was sich sehr schön daran zeigt, dass C++ eine "Multi-Paradigma-Sprache" sein soll.
-
Immer diese Metadiskussionen. So nach: "Ich habe ein Problem" (ja welches?) "dann loese ich das irgendwie" (??) "genial" (??). Ausser du selbst Weiss keener worum es geht. Dann folgt allgemeines Blabla ... Kenn ich schon, war ich schon, hab ich schon.
Wenn hier einer eine wirklich gute Idee hätte, wird er sie doch nicht hier verraten.
Ach und wer wuerde diese geniale Idee auch als solche erkennen?
-
knivil schrieb:
Wenn hier einer eine wirklich gute Idee hätte, wird er sie doch nicht hier verraten.
Ach und wer wuerde diese geniale Idee auch als solche erkennen?
ich hab einen riesen rüssel, der riecht _fast_ alles, sogar über die grenzen sozialer kreise hinweg
-
knivil schrieb:
Immer diese Metadiskussionen. So nach: "Ich habe ein Problem" (ja welches?) "dann loese ich das irgendwie" (??) "genial" (??). Ausser du selbst Weiss keener worum es geht. Dann folgt allgemeines Blabla ... Kenn ich schon, war ich schon, hab ich schon.
Hehehe, das sind immer "Meta-Diskussionen", denn in dem Moment, wo sie konkret würden, kommt sofort jemand an mit "Das kann man doch auch so und so lösen." und das braucht man nicht.
Oder in den Worten eines mir bekannten Informatikers: "Man kann doch alles schon mit den vorhandenen Programmiersprachen beschreiben, wozu braucht man das dann?"
knivil schrieb:
Wenn hier einer eine wirklich gute Idee hätte, wird er sie doch nicht hier verraten.
Ach und wer wuerde diese geniale Idee auch als solche erkennen?
Aus genau diesem Grund finden diese Diskussionen nicht in öffentlichen Foren statt.
Sobald etwas öffentlich wird, wird nicht gefragt, wofür man es brauchen kann sondern nur, weshalb man es überhaupt nicht braucht.
Genauso wie Klassen in den 80ern nur Boiler-Plate waren.Die öffentliche Diskussion ist m.E. Zeitverschwendung.
-
"Man kann doch alles schon mit den vorhandenen Programmiersprachen beschreiben, wozu braucht man das dann?"
Das frage ich mich auch staendig, Lisp war doch schon perfekt.
-
Xin schrieb:
Hehehe, das sind immer "Meta-Diskussionen", denn in dem Moment, wo sie konkret würden, kommt sofort jemand an mit "Das kann man doch auch so und so lösen." und das braucht man nicht.
Das ist aber ein wichtiger Punkt. Ich sag jetzt nichts gegen deine Idee (kenn sie ja nicht), und generell nichts gegen neue Ideen, hab auch schon einiges ausprobiert. Aber es ist schon echt schwer, sich in der Praxis tatsächlich durchzusetzen, wenn die Vorteile nicht sehr deutlich sind. Es ist ein immer ein gewisser Aufwand, sich eine neue Programmiersprache anzutun, vor allem mit den neuen Standardbibliotheken, 3rd party Bibliotheken usw. D interessiert mich z.B. gar nicht, auch wenn es einige Vorteile gegenüber C++ haben mag. Aber Scala hab ich mir gern angeschaut und setz das auch ab und zu in Java Projekten ein, weil das eine coolere Sprache als Java ist und man die Sprachen gut kombinieren kann.
-
Xin schrieb:
Hehehe, das sind immer "Meta-Diskussionen", denn in dem Moment, wo sie konkret würden, kommt sofort jemand an mit "Das kann man doch auch so und so lösen." und das braucht man nicht.
Doch, das braucht man! Man braucht Kritiker, weil man selbst keine allumfassende Sicht auf alles hat. Deshalb ist es eigentlich immer gut, auch auf andere Sichtweisen aufmerksam gemacht zu werden. Was man dann daraus macht, ist eine ganz andere Sache. Sachliche Kritiken sind etwas gutes. Man muss eben nur die entsprechende Kritikfähigkeit haben.
-
Was kommt nach der Objektorientierung?
eine Bildsprache oder ein Formalismus ähnlich APL wäre denkbar, wenn ich weit in die Zukunft blicke.
denn irgendwann werden Operatoren wie map-reduce, filter, lambda etc so selbstverständlich sein wie heute + und -, und dann braucht man für solche Operatoren ein Symbol. Zukünftige Progsprachen sind ja nicht mehr an ascii gebunden, warum also nicht eine Vielfalt neuer Symbole nutzen, um Schlüsselwörter durch kurze prägnante Formelsprache zu ersetzen - Symbolisierung ist ein Trend, der in der Mathematik seit Jahrhunderten anhält.
-
kellerkindanwärter schrieb:
threads/paralell und die ganzen anderen buzzwords, was wollt ihr damit eig? ist doch alles alt und langweilig
ich gebe mal ein bsp. mein aktueller webserver unterstützt nur einen thread. der geplante server hat aber 4 kerne, also werde ich einen haproxy laufen lassen und das programm 3x starten. und bei mehr kernen eben öfter. muss ich deswegen was an meinem style ändern - ich denke nicht!
jo top.
du hast nur leider nicht verstanden worum es geht.
-
Gibt nach AOP, ist halt oft für mehr high-level als C++ und co. Aber da gehen halt die Abstraktionsebenen weiter.
OOP hat imo den großen Vorteil, dass man es sich gut bildlich vorstellen kann. Für die Frage, ob es auf der Gerade "prozedurale Programmierung -> OOP" einen Nachfolger geben kann, müsste man sich imo fragen, ob man noch anders strukturiert denken kann. Ich tu das nicht. So was wie assoziative Programmierung oder idea-based-programming könnte man sich vorstellen, aber das ist halt wieder mehr high-level.
Also es könnte irgendwelche Automatisierungen oder höheren Abstraktionsebenen geben, das könnte sein. Aber die klassischen Sprachen braucht man auch immer noch und da wüsste ich nicht, wie sich viel tun soll.
Portabler wird's evtl. noch, gerade wegen Smartphones und so. Und dann wird alles evtl. noch stärker eventbased, kann auch sein. Was weiß ich...
-
hustbaer schrieb:
kellerkindanwärter schrieb:
threads/paralell und die ganzen anderen buzzwords, was wollt ihr damit eig? ist doch alles alt und langweilig
ich gebe mal ein bsp. mein aktueller webserver unterstützt nur einen thread. der geplante server hat aber 4 kerne, also werde ich einen haproxy laufen lassen und das programm 3x starten. und bei mehr kernen eben öfter. muss ich deswegen was an meinem style ändern - ich denke nicht!
jo top.
du hast nur leider nicht verstanden worum es geht.dann klär mich doch mal auf
-
Dinge zu "paralellisieren" indem man einfach ein Programm 4x oder 16x rausstartet ist trivial. Interessant wird es wenn du Fälle hast wo das so einfach nicht möglich ist.
-
Ich denke, man sollte sich nicht fragen, was nach OOP kommt, sondern erstmal bestehende Programmiersprachen fixen.
-
Kellerautomat schrieb:
Ich denke, man sollte sich nicht fragen, was nach OOP kommt, sondern erstmal bestehende Programm
iersprachenfixen.
-
Mechanics schrieb:
Xin schrieb:
Hehehe, das sind immer "Meta-Diskussionen", denn in dem Moment, wo sie konkret würden, kommt sofort jemand an mit "Das kann man doch auch so und so lösen." und das braucht man nicht.
Das ist aber ein wichtiger Punkt. Ich sag jetzt nichts gegen deine Idee (kenn sie ja nicht), und generell nichts gegen neue Ideen... Aber es ist schon echt schwer, sich in der Praxis tatsächlich durchzusetzen, wenn die Vorteile nicht sehr deutlich sind.
Bis hierhin sind schon zwei Denkfehler... oder sagen wir Denkhindernisse drin, die nicht progressiv an die Sache herangehen.
Erstens: Wer verlangt, dass es sich durchsetzt?
Zweitens: Wieso müssen die Vorteile jedermann deutlich sein?Ein Experiment muss erstmal gemacht werden, dafür reicht es, wenn sich Dinge wenigstens in die richtige Richtung bewegen. Bevor das Experiment allerdings nicht zeigt, dass es umständlich oder unnütz ist, muss man es allerdings ausprobieren, wenn man sich unsicher ist.
Das mache ich in der Regel, in der ich Probleme mit einem Konstrukt löse und mir überlege, ob mir das gefällt.Auch müssen die Vorteile nicht sofort für jedermann deutlich sein. Da wären wir nochmal bei den Klassen - das war früher auch nur überflüssig und der Zweck dahinter nicht jedermann ersichtlich. Ich habe ein Konstrukt entworfen, dass durch klassenbasiertes Programmieren quasi überflüssig ist - und dann habe ich probehalber die Enigma-Verschlüsslung implementiert und festgestellt, dass es für diesen Algorithmus wie gemacht ist - es war aber nicht dafür gemacht. Es war nur ein Konstrukt, was sich auf mehr als das von mir ursprünglich angedachte Szenario anwenden ließ. Es besteht also der Verdacht, dass es nützlicher sein könnte, als ich ursprünglich gedacht habe.
Mechanics schrieb:
Es ist ein immer ein gewisser Aufwand, sich eine neue Programmiersprache anzutun, vor allem mit den neuen Standardbibliotheken, 3rd party Bibliotheken usw. D interessiert mich z.B. gar nicht, auch wenn es einige Vorteile gegenüber C++ haben mag. Aber Scala hab ich mir gern angeschaut und setz das auch ab und zu in Java Projekten ein, weil das eine coolere Sprache als Java ist und man die Sprachen gut kombinieren kann.
Das ist sicherlich ein Punkt. Ich spekuliere allerdings nicht direkt auf die große Masse - im Gegenteil, solange ich an der Sprache feile, habe ich inzwischen lieber ein kleines konzentriertes Publikum, dass ...
Gregor schrieb:
Xin schrieb:
Hehehe, das sind immer "Meta-Diskussionen", denn in dem Moment, wo sie konkret würden, kommt sofort jemand an mit "Das kann man doch auch so und so lösen." und das braucht man nicht.
Doch, das braucht man! Man braucht Kritiker, weil man selbst keine allumfassende Sicht auf alles hat.
...sehr kritisch an die Sache rangeht und Fragen stellt. Dabei ist der Hintergedanke aber da, dass ich mir wohl etwas sinnvolles dabei gedacht habe. In den öffentlichen Foren erhielt ich zumindest bisher vorrangig Antworten. Die Antworten sind eigentlich recht einfach: "Braucht man nicht", "kann man anders machen", "setzt sich eh nicht durch".
PS: Zu dem Text den Du von mir zitiert hast (und das braucht man nicht), da habe ich die Anführungszeichen vergessen, daher war er missverständlich: << und "das braucht man nicht". >>
Leute, die kritisieren, brauche ich in jedem Fall. Aber eben konstruktiv kritisieren.</ps>Antworten sind so langweilig, wenn man stattdessen Fragen haben kann.
Antworten bekam ich meistens von Informatikern. Menschen aus anderen Fachbereichen, werden sehr kreativ, weil sie sich an die üblichen Grenzen der Programmiersprachen gar nicht herankommen oder diese einfach nicht als Gegeben akzeptieren. Da kommt dann eher die Frage "Warum kann ich etwas nicht machen?" und dann ich als Informatiker das oftmals gar nicht begründen, warum man etwas nicht machen kann. Ich kann mir aber ein Konzept ausdenken, wie man es umsetzen könnte.Gregor schrieb:
Sachliche Kritiken sind etwas gutes. Man muss eben nur die entsprechende Kritikfähigkeit haben.
Genau, deswegen liefere ich Futter auch nur noch an einen kleinen Kreis von Entwicklern und/oder Informatikern, bei dem ich von sachlichen Kritiken ausgehe. Die meisten Entwickler haben nämlich schon alle Antworten, die sie für ihren Alltag brauchen.
buchstaben schrieb:
Was kommt nach der Objektorientierung?
eine Bildsprache ...wäre denkbar, ... Symbolisierung ist ein Trend, der in der Mathematik seit Jahrhunderten anhält.
Gibt es schon, ist aber eher unpraktisch, um Algorithmen zu beschrieben.
Hier sehe ich überhaupt keine Zukunft drin, weder in UML noch in Labview. Wissen tue ich es natürlich auch nicht, aber wenn wir wetten sollen, wette ich darauf, dass bei den professionellen Programmierern Texteditor und Konsole auch in 50 Jahren noch erhalten sind.
Auf die Tastatur wette ich nicht, aber auch hier gehe ich davon aus, dass der Entwickler Laptops besitzt und keine Tabletts.
