Wann kommt die nächste Revolution bei den Programmiersprachen?

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

mathik

Shade Of Mine schrieb:

Eine Frage schrieb:

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

Man siehe sich zB Stack aus Java an.

Lol! Ich wußte garnicht, dass Stack von Vector ableitet !!!

Ich musste die Erfahrung schon öfter machen, dass es jede Menge OO-Software gibt, die durch Vererbung sowas von vermurkst ist , dass da keiner mehr durchsteigt und dann deshalb behaupten, dass OO doch was ganz schlimmes ist.
Nicht Vererbung oder Wiederverwendung ist das große Geheimnis an OO, sondern Polymorphie.

Gruß
mathik