Wann kommt die nächste Revolution bei den Programmiersprachen?

this->that schrieb:

Also ich könnte mir vorstellen, dass in der Zukunft das Thema Multithreading/Multicore so bedeutend wird, dass es eigene auf diese Gebiete zugeschneiderte Sprachen gibt. Hab keinen Plan wie das aussehen könnte, aber halt irgendwas, was weg geht vom sequenziellen Charakter heutiger Sprachen und hin zu einem System, dass das "parallele Denken" unterstützt.

Also so wie das oben erwähnte Erlang?

this-*gt*that

Ja, nur Mainstream-geeigneter und intuitiver.

DEvent

minhen schrieb:

Und jetzt die Gretchenfrage: wer alles hat hier schon ernsthaft mit Prolog gearbeitet?

Ich musste, weil mein Prof ein totaler Prolog-Fan ist. Aber nicht ernsthaft. Nur die normalen Aufgaben fuer Studenten. Aber ich kann mir einfach nicht vorstellen, dass man damit komlexere Anwendungen schreiben kann (ich weis, sowas soll es geben, ist mir aber raetselhaft wie).

Che Guevara schrieb:

Wann gibts das nächste mal ne große Umstellung so wie weg vom prozeduralen Programmieren hin zum OOP?

Die gibt es dann, wenn es jemand schafft, "Programmieren" und "Aufwand->Zeit->Geld sparen" noch enger miteinander zu verbinden.

IHR WERDET ES AUCH NOCH MERKEN, DASS DIE ZUKUNFT _NUR_ PYTHON GEHÖRT!
---------------------------------------------------
Wie wärs mal mit einer backward-revolution? Also back-to-the-roots *lötkolben_raushol*

nep

Ich denke auch, dass der Trend hin zu Expertensystemen, spezielle Sprachenn für die jeweilige Domänen, MDA (wobei das ja sogar meines Wissens eher wieder bissl aufm Rückgang ist), usw. geht.
Und eben das was auch schon mal gesagt wurde, nämlich hin zu viel besserem Support für nebenläufige Programmierung.
Aber als Revolution kann man das ja nicht gerade bezeichnen.

Evtl. kommt was ganz neues wenn es auch neue Computergenerationen gibt.

ChrisJ

ist die generische programmierung ( template metaprogrammierung ) eine untergruppe der objektorientierten programmierung?

Shade Of Mine

ChrisJ schrieb:

ist die generische programmierung ( template metaprogrammierung ) eine untergruppe der objektorientierten programmierung?

ne, denn man braucht kein konzept eines objektes um generisch zu programmieren. man kann aber generische programmierung und objektorientierte mischen.

rüdiger

ChrisJ schrieb:

ist die generische programmierung ( template metaprogrammierung ) eine untergruppe der objektorientierten programmierung?

Nö. Generische Programmierung ist unabhängig von OOP. Template Metaprogrammierung ist vor allem funktional (Was aber OO natürlich nicht ausschließt).

Undertaker

rüdi, du bist doch programmiersprachen-fan. kennste das: http://ccl.northwestern.edu/netlogo/
sind jedenfalls lustige beispiele dabei. die drum-machine finde ich cool.

minhen

DEvent schrieb:

minhen schrieb:

Und jetzt die Gretchenfrage: wer alles hat hier schon ernsthaft mit Prolog gearbeitet?

Ich musste, weil mein Prof ein totaler Prolog-Fan ist. Aber nicht ernsthaft. Nur die normalen Aufgaben fuer Studenten. Aber ich kann mir einfach nicht vorstellen, dass man damit komlexere Anwendungen schreiben kann (ich weis, sowas soll es geben, ist mir aber raetselhaft wie).

Du hast sicher nichts mit Prolog zu tun gehabt, nur weil dein Professor Prolog toll findet. Denn zumindest einmal etwas von Prolog gehört zu haben (sprich die "normalen Aufgaben") ist bei Informatik einfach üblich.
Einen angemessenen Eindruck nimmt davon aber kaum jemand mit. Auf jeden Fall kann man mit Prolog schon ganz nette Sachen machen. Ich hoffe ihr habt auch DCGs gemacht. Das sind im Grunde Abbildungen von einfachen Phrasenstrukturgrammatiken in der Linguistik und als solche sehr nützlich für Sprachverarbeitung. Aber auch ohne einer expliziten DCG-Syntax wäre Sprachverarbeitung in Prolog relativ einfach. Mit einer DCG kann man nicht nur wunderbar einen gegebenen sprachlichen Ausdruck erkennen und erzeugen lassen, sondern beides auch mit konkreten Syntax-Bäumen erledigen lassen. Und das ist dann halt schon praktisch. Man gibt eine DCG an, lässt sich einen konkreten Syntaxbaum zu einer Eingabe erzeugen, baut die Semantik auf, wertet sie aus, bekommt eine logische Formel zurück und wandelt diese rückwärts über Semantik, Syntax-Baum und DCG in natürliche Sprache um und schon hat man ein natürlichsprachiges System, das sowohl z.B. Deutsch versteht als auch in Deutsch antwortet. Sowas kann man für Sprachausschnitte in Prolog relativ einfach machen. Man hat dann ein Morphologie-Modul mit Grundformen-Lexikon und Flexionsregeln, ein Syntax-Modul (z.B. DCGs) und ein Semantik-Modul (z.B. Lambda-Kalkül und Prädikatenlogik). Gerade wenn man sich das Syntax- und das Semantik-Modul ansieht, kann man sich vorstellen, weshalb sich gerade Linguisten für Prolog begeistern.
Und sonst hat Prolog natürlich auch noch die üblichen Möglichkeiten. Zwar definiert der ISO-Standard keine Möglichkeit graphische Oberflächen in Prolog zu erstellen. Aber das ist in C++ ja nicht anders und es geht dennoch. So auch in Prolog. Hier z.B. mit XPCE:

?- new(D, dialog), send(D, append, label(text, 'Hallo Welt!')), send(D, open).

Und dann kann man Prolog natürlich noch wunderbar in anderen Sprachen, allen voran natürlich C, als "Logik-Engine" einbetten und in beide Richtungen kommunizieren. Gerade das ist für größere Anwendungen auch interessant. Also auch wenn man keinen Browser in Prolog schreiben würde, komplexe Anwendungen macht schon damit

So ähnlich wie es Prolog vorgemacht hat, stell ich mir auch die Zukunft von Erlang vor. Ein Hype, alle finden es toll und am Ende besetzt es eine Nische und die gewöhnlicheren Sprachen machen wie gewohnt das Rennen. C++09 zum Beispiel ^^

Hi,

tendenziell läuft es doch immer wieder auf ganz wenige klassische Programmiersprachen raus.
Angefangen von Fortran und Cobol, die für bestimmte Dinge heute immer noch ihre Daseinsberechtigung haben, im Großrechnerbereich sicher auch noch PL1, in Sicherheitsrelevanten Bereichen ADA und in der normalen Anwendungsentwicklung Sprachen wie C, C++, Delphi, Basic, Java, C#.
In der Vergangenheit gab es verschiedene Hypes, die aber alle als Tieger losgesprungen sind ud als Bettvorleger gelandet sind.

Ne Zeitlang war Forth mal absolut in. Ursprünglich zur Echtzeitsteuerung von Radioteleskopen entwickelt und dann als Eeierlegende Wollmilchsau für alles gepriesen ist es wieder dort gelandet, wo es herkam, nämlich in Nischenbereichen. Sicher zum großen Teil daran geschuldet, daß die umgekehrt polnische Notation und Stackverarbeitung einen ziemlichen Knoten im Kopf erfordert. auch wenn die menschliche Sprache zum Teil RPN ist
- vier und vier zusammenzählen und mit fünf malnehmen -
so ist das eigentliche Denken und Schreiben doch mehr nicht so und die Notwendigkeit einen geordneten Stack zu halten und zu wissen was wo ist vereinfacht das auch nicht.

Auch Chill war mal als der Renner gepriesen und außer in der Fernmeldetechnik wirds kaum noch verwendet.

Modula nach Pascal als das Goldene Kalp von Wirth gepriesen hat sich auch nie durchsetzen können. Hat aber bestimmte Eigenschaften doch auch an heutige Sprachen übergeben wie die Trennung in Headder und Implementation...

Zwischenzeitlich galten Transputer als Zukunft und Occam war die Sprache der Zukunft, kennt die heute noch einer???

Dann wurde Mandala als nachfolger von Prolog umschwärmt das ja noch viel näher am Menschlichen Denken ist... Ich hab mal ein Bild gesehen, das angeblich ein Mandala-Programm darstellen sollte, begrifen hab ich trotz Erklärung nichts...

Im Grunde gibt es 3 Dinge, die über den Erfolg einer Programmiersprache entscheiden:

1. Sie entspricht in ihrem Aufbau und ihren Denkgewohnheiten menschlichen Denkgewohnheiten
2. Sie ist nützlich, d.h. sie löst eine große Menge Aufgaben mit möglichste geringem Aufwand
3. Es gibt gute Programmierumgebungen.

Wenn es dann noch einen großen Pool an schon vorhandenem gibt, auf dem aufgebaut wird, dann ist der Erfolg schon fast vorbereitet.

Unter den Rennern gibt es da zwei Typen. Die einen sind Sprachen, die auf ein bestimmtes Ziel hin entwickelt wurden. Fortran für numerische Berechnungen, Cobol für Massendatenverarbeitung, Pascal für die Ausbildung um Studenten zu disziplinieren, Basic um selbst unausgelasteten Hausfrauen das Schreiben einfacher Programme zu ermöglichen und ADA um Programme mit höchsten Sicherheitsanforderungen erstellen zu können.

der andere Typ sind C und C++, bei denen Programmierer eine Aufgabe zu bewältigen hatten und sich dafür ihre eigene Sprache auf den Leib geschneidert haben. Und gerade das ist der große Vorteil dieser Sprachen gewesen. Diese Sprachen ticken so, wie auch Programmierer ticken. Zumindest trifft das fast uneingeschränkt auf C und die Anfänge von C++ zu. In letzter zeit ist C++ da noch gewaltig erweitert worden um Dinge, die nicht ganz so intuitiv zu handhaben sind, wie z.B. Generisches Programmieren (ich meine jetzt das direkte Programmieren, nicht die Anwendung von Templates). Aber insgesamt stricken sich da immer noch Top-Programmierer ein Hilfsmittel für ihre tägliche Arbeit.
Von daher erwarte cih eigentlich eher, daß C++ um weitere jeweils gebrauchte Erweiterungen bereichert wird. Bestes Beispiel ist da Delphi, das war ja ursprünglich das Wirthsche Disziplinierungspascal, und im laufe der Zeit wurden immer mehr Elemente aus C undC++ reingenommen einfach weils die Programmierer wollten und brauchten, so daß es fast schon sowas wie C++ mit Pascalsyntax ist.

Was die Grundstile betrifft, so kann man das eigentlich doch ein wenig vom menschen und der Sprache ableiten.
prozedurale Programmierung: einfache Verben und Angabe womit... Etwas Waschen, etwas kämmen...
OOp: reflexive Verben, Sich waschen, sich kämmen...
logische Programmierung: es müste, es sollte...

oder noch ein Beispiel aus dem täglichen Leben:
Kleine Kinder - prozedural - die Mutter muß alle waschen, das Ergebnis ist klar definiert das was die Mutter macht...
Große Kinder - objektorientiert - wasch DICH. Das Ergebnis ist das was die Mutter den Kndern beigebracht hat.
Ehemann - logische Programmierung - Tatbnestand: Mann müffelt, Programmieranweisung: Du könntest auch ein wenig besser riechen - Ausführung ungewiß, Zigarre anzünden, Haarwasser oder Eau de toilette benutzen, im Idealfall frische Socken und Duschen, im schlechtesten Fall Toll wie herb ich heute wieder nach Mann rieche.

Das Problem ist bei dingen wie logischer Programmierung, daß dann die Rechner auch ein wenig auf unser "Verarbeitungsniveau" kommen müsten. Wemm ich nur die Wunscheigenschaften meines Ergebnisses nennen will, der muß wissen wovon ich rede und wie ich dahin komme (Beispiel Ehemann).
Außerdem bereitet gerade das Abstrahieren des Ergebnisses den meisten recht große Schwierigkeiten. Uns als Menschen liegt es eigentlich mehr, uns jeweils anhand des bereits vorhandenen Schritt für Schritt weiterzuhangeln, egal ob auf Papier oder am Bildschirm.

Gruß Mümmel das Mümmel.

Jedenfalls ist die Objektorientierung keinesfalls das vollkommene Paradigma, und wird vielleicht irgendwann abgelöst werden.

Ein Problem das ich bei der OOP sehe, ist die Schaffung der Abhängigkeiten eines Objektes von anderen Objekten. Das ist zwar im Prinzip ein edler Gedanke, dass zwei in sich vollständige Objekte, von denen jedes eine Aufgabe verwaltet, miteinander gezielt kommunizieren, aber wenn man sich eine große Reallife-OOP Anwendung ansieht, sieht es dann doch nicht mehr so schön aus.
Ich habe in einer neuen Firma angefangen, und das dortige Projekt hat einen Quellcode von >300 Megabyte und mehrere tausend Klassen. Hier kam es, wie bei OOP üblich, sehr schnell zu Spaghettiprogrammierung. Hunderte von Klassen, welche teilweise von drei "Generationen" erben, teilweise nur um sich zwei Eigenschaften und ein 4-Zeilen-Methödchen in den Unterklassen zu sparen. Eine Unmenge von Schnittstellen.
Das Verstehen eines großen OOP Projektes ist entspricht der Entwirrung eines riesigen Kabelsalates.

Ich weiß, man kann auch übersichtlich darin programmieren, in dem man gezielt Schichten auslagert etc., aber die OOP verleitet doch sehr zu den obengenannten Problemen.

Wobei sich hier die Frage stellt ob das Projekt unter identischen Bedingungen aber mit einem anderen Paradigma (bzw. einer Mischung mehrerer) übersichtlicher wäre. Aber die werden wir wohl laum beantworten können...

Klar, da hast du natürlich recht. Vermutlich wäre das Projekt prozedural auch nicht übersichtlicher. Ich wollte damit nur sagen, dass die OOP vllt nicht der Weisheit letzter Schuss ist, und eventuell doch in absehbarer Zeit ein besseres Paradigma geben wird. Vielleicht aber auch nicht.

meinungg schrieb:

Hier kam es, wie bei OOP üblich, sehr schnell zu Spaghettiprogrammierung. Hunderte von Klassen, welche teilweise von drei "Generationen" erben, teilweise nur um sich zwei Eigenschaften und ein 4-Zeilen-Methödchen in den Unterklassen zu sparen. Eine Unmenge von Schnittstellen.

OOP ist nicht OOP nur weil man Klassen benutzt. Wie sich in anderne Diskussionen mehrfach gezeigt hat gibt es sehr unterschiedliche Meinungen darübe wann etwas OOP ist. Bei dieser Beschreibung würde ich fast vermuten, daß hier OOP sehr falsch angewendet wurde...

Die Behauptung, das OOP üblicherweise zu Spaghettiprogrammierung führt kann ich einfach nicht nachvollziehen (und ich habe auch schon an Großprojekten mitgearbeitet). Nach meiner Erfahrung ist es eher umgekehrt, eben das richtig angewandte OOP eine bessere Ordnung und Übersicht im Projekt erzeugt...

mathik

meinungg schrieb:

Hunderte von Klassen, welche teilweise von drei "Generationen" erben, teilweise nur um sich zwei Eigenschaften und ein 4-Zeilen-Methödchen in den Unterklassen zu sparen.

Typisches Problem. Viele Entwickler haben keine Ahnung von OO und "mißbrauchen" Vererbung. Dadurch entsteht Spaghetticode...
Ich behaupte, dass Vererbung eine der Methoden ist, die in der Softwareentwicklung am häufigsten fehlinterpretiert wird.

Gruß
mathik

Shade Of Mine

mathik schrieb:

Ich behaupte, dass Vererbung eine der Methoden ist, die in der Softwareentwicklung am häufigsten fehlinterpretiert wird.

Dem kann ich nur zustimmen.

Shade Of Mine schrieb:

mathik schrieb:

Ich behaupte, dass Vererbung eine der Methoden ist, die in der Softwareentwicklung am häufigsten fehlinterpretiert wird.

Dem kann ich nur zustimmen.

Du beziehst dich doch nicht auf irgendwelche Flag klassen, oder?
(ist aber nicht böse gemeint)

Shade Of Mine

Eine Frage schrieb:

Du beziehst dich doch nicht auf irgendwelche Flag klassen, oder?
(ist aber nicht böse gemeint)

Allgemein. Die Flagklasse ist ein aktuelles Beispiel (aber es ist kein Massenphänem) - das wirkliche Problem ist zB in Java sehr groß.

Wenn wir uns dort mal normale Swing-Fenster-Klassen ansehen, dann haben wir dort der bequemlichkeit halber gerne mal 520.000 Interfaces implementiert um für alle Steuerelemente auf die Ereignisse reagieren zu können. Anstatt das schön sauber zu trennen wie es Java einem ja ermöglicht.

Oft verwenden die Leute Vererbung weil es "praktisch" ist. Man siehe sich zB Stack aus Java an. Viele Leute definieren OOP sogar über Vererbung.

Vererbung wird oft überhaupt nicht oder falsch eingesetzt. Ist traurig, ist aber leider Fakt