Was kommt nach der Objektorientierung?
-
Sone schrieb:
Man bin ich gespannt wie C++ in 40 Jahren aussieht
ich nicht, da bin ich schon so ranzig und muss hoffentlich nur noch zum spaß programmieren und dann sicher nicht in c++ :p
-
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 vermute, der Fokus wird sich mehr auf Generische Programmierung legen und es werden sich vermutlich Lösungen finden, wie man Algorithmen automatisiert auf mehrere Threads verteilt.
-
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!
-
parallel
-
DIe Zukunft ist Haskell ...
-
knivil schrieb:
DIe Zukunft ist Haskell ...
ich schreib nicht alles neu :p
-
das wort heißt nukular, n.u.k.u.l.a.r
-
knivil schrieb:
DIe Zukunft ist Haskell ...
DIe Zukunft sind Lochkarten.
-
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 vorstelltWeiß 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.
