Ausgangspunkte für eine ideale Sprache kann sein:

• Weiterentwicklung der "bisher besten" Sprache (C++, C#)
• Die Menge aller Features der bekannten Programmiersprachen (Idee einer optimalen Mischung)
• Ein neuer paradigmatischer Ansatz der "was ist programmieren" neu definiert (SpracheLava)
• Mathematische Vorstellungen von konstruktiver Vollständigkeit oder Perfektheit (SpracheLisp)
• ...

• Fähigkeit universell für alle Problemstellungen geeignet zu sein. Aber stimmt das wirklich im Detail?
• Großprojekttauglichkeit ja/nein
• GUI-Tauglichkeit ja/nein
• Datenbank-Unterstützung ja/nein
• Stringverarbeitungsstärken ja/mäßig
• Mathematik-Tauglichkeit ja/nein
• Console-Tool-Tauglichkeit ja/nein
• Spiele-Tauglichkeit ja/nein
• Multimedia-Tauglichkeit ja/nein
• Embedded-Programmierung ja/nein
• Eignung für die Lehre ja/nein
• Maximale Performance (sobald entsprechend optimierte bzw. optimierende Compiler vorhanden sind)
• Leichte Erlernbarkeit
• z. B. durch vertraute Syntax (C-Sprachfamilie mit C, C++, Perl, Java, C#, D, ...)
• durch Konsistenz und Orthogonalität
• Verfügbarkeit auf den gängigen Betriebssystem
• MS Windows-Variante
• Linux / Unix
• Mac / Apple
• ...

• Speichermanagement:
• explizit (z. B. malloc + free)
• automatisch (z. B. GarbageCollection)
• Typisierung (Typkontrolle):
• statisch (durch den Compiler zur CompileTime?) (z. B. C)
• dynamisch (durch das Laufzeitsystem zur RunTime?) (z. B. Perl, Smalltalk)
• Exekutierbare Form:
• "Native Executable" (statisch oder dynamisch gelinkt)
• Runtime-Environment (meist umfangreich)
• Native Code Interface zur Verwendung vorhandener Libraries (z. B. in C)
• Interface durch entsprechende Deklarationen
• Interface durch Zwischencode (z. B. Java JNI, C# automatisch erzeugter Zwischencode)
• ...

• Sprachform (jede Sprache kann in jeder Form implementiert werden)
• Compiler
• p-Code-Compiler
• Interpreter
• goto ja/nein (jede Sprache kann/könnte goto implementieren, es könnte auch eine "Management"-Entscheidung sein es durch eine projektspezifische Konfigurationsentscheidung zuzulassen oder zu verbieten)
• ...

• Menge der primitiven Datentypen
• Menge höherwertiger Datentypen (Grundumfang ohne Libraries)
• dynamische Arrays (z. B. Perl, VB, D, ...)
• Hash-Tabellen (z. B. Perl, D)
• Baumartige Listen (z. B. Lisp)
• Menge höherwertiger primitiver Funktionen (Grundumfang ohne Libraries)
• RegEx (z. B. Perl, ...)
• Vektor- bzw. Matrixsyntax
• Reflection (z. B. Java, C#, ...)
• Multitasking
• Closures = Codeblöcke als Parameter (z. B. Smalltalk, Ruby, D, ...)
• Exceptions
• Ausstattung mit Libraries und Möglichkeiten bereits vorhandene Libraries aus anderen Programmiersprachen zu verwenden
• Ausstattung mit Objektorientierung
• Vererbung, Kapselung, Polymorphie, Delegation
• Ausstattung mit Entwicklungumgebung
• keine (Commandline-Compiler, make, Standard-Tools)
• eigene Entwickungsumgebung
• Projekt-Build
• Debugging, Profiling, Inspection...
• Visueller GUI-Designer
• Visueller DB-Designer (z. B. ACCESS)
• Visueller Code-Designer (z. B. SpracheLava)
• Ausstattung mit Großprojekt-Features
• TestFramework
• DesignByContract
• ...
• ...

Diskussion

Über die generelle Einsetzbarkeit einer Sprache

Das ist ein gefährliches Terrain. Schauen wir uns mal SpracheCpp an, die als universale Sprache konzipiert wurde:

• Komplexe Stringoperationen: Dank std::string einfacher als unter SpracheCee, erreicht jedoch nie die "Eleganz" von SprachePerl.
• Numerische Berechnungen: Möglich, erreicht aber nicht die "Eleganz" von SpracheFortrans "A = B + C" Vektorrechnung.
• Graphische Interfaces: Braucht externe Tools um managebar zu bleiben (auch ein Bibliotheksproblem). VisualBasics ist - wohl auch wegen der Beschränkungen der Sprache - wesentlich besser in den GUI-Builder integriert.

Ich habe mal versucht, deinen Kommentar oben einzuarbeiten. -- hl

Gefällt mir

Mir gefällt der Begriff der lockeren Typisierung nicht. SpracheSmalltalk hat zwar "nur" dynamische Typprüfung, die ist aber mitnichten locker. Typfehler werden in Smalltalk beim ersten Aufruf einer unbekannten Methode erkannt und resultieren in einer Exception. Der Programmierer hat zwar den Freiraum, auch auf solche Fehler mit Exception-Handling zu reagieren und das kann dank Metaprogrammierung auch ziemlich heftige Formen annehmen, er macht dies dann aber unter bewusster Inkaufnahme möglicher Fehler.

Man könnte dagegen eine in C++ ohne weiteres mögliche Fehlinterpretation von Speicherbereichen als Typfehler werten. Da das vom C++ Laufzeitsystem nicht sicher erkannt wird, kann ich mich nicht dazu durchringen, hier von einer strengen Typprüfung zu sprechen ;-)

Ich denke, die Attribute statisch vs. dynamisch treffen es besser.

SaschaDördelmann

"Typfehler" werden in Smalltalk _nicht_ erkannt (und resultieren somit natürlich auch nicht in einer Exception). Wie Sascha richtig schreibt, wird ein Aufruf einer unbekannten Methode erkannt und resultiert in einer Exception (die ja auch dementsprechend heißt: MessageNotUnderstood). Ruft man eine Methode auf, die bekannt ist (und das kann wg. eines Programmierfehlers auch "typfalsch" geschehen), gibt es dazu logischerweise keine Exception. -/- In C++ ist (wenn der Compiler nicht kaputt ist) eine Fehlinterpretation von Speicherbereichen _nicht_ möglich, jedenfalls nicht - wie Sascha schreibt - "ohne weiteres". Sondern nur, wenn der Programmierer den Freiraum, zu "casten", anwendet (was ziemlich heftige Formen annehmen kann), er macht dies dann aber unter bewusster Inkaufnahme möglicher Fehler. ;-) -- VolkerGlave

Was ein Typ ist, kann mitunter schwer definiert werden. Was ist z. B. ein Typ in SpracheRuby, wo ich sogar die Schnittstelle von Instanzen verändern kann? Bei dynamischer Polymorphie wird der Typ eines Objekts ausschließlich über seine Schnittstelle und nicht durch seinen Platz in einer Klassenhierarchie bestimmt. Die statische Variante eines solchen Typbegriffs implementieren in C++ die Templates. Will man in Smalltalk explizit Typen definieren, kann man das über Spracherweiterungen wie Interfaces tun, was aber nach meiner Erfahrung eher unüblich ist.

Zu C++: Ich meinte eigentlich nicht die Casts sondern etwas viel profaneres. Was ist ein Speicherzugriffsfehler anderes als eine Fehlinterpretation des Speichers? Wenn ich mit einem Iterator oder Zeiger über das Ende meiner Collection laufe, zeigt dieser auf Speicherbereiche, die allenfalls zufällig Dinge enthalten, die noch irgendetwas mit dem Typ meines Zeigers zu tun haben. Wenn ich ein Objekt aus dem Speicher lösche, aber noch anderweitig darauf verweise, dann lügt der Verweis bzgl. dessen, was an dieser Stelle vorzufinden ist. Mir ist klar, dass diese Auffassung gewöhnungsbedürftig ist, daher auch der ;-) -- Sascha

Wo du recht hast, hast du recht. -- Volker

Ich glaub auch, du (Sascha) hast recht und hab das oben entsprechend geändert. -- HelmutLeitner

Den Punkt mit den Scheinalternativen finde ich essentiell. Gängige Smalltalk-Implementationen unterscheiden sich von Ruby u. a. durch den imagebasierten Ansatz: Das gesamte Objektgeflecht samt Prozessen und deren Status ist speicherbar. Das führt zu einer völlig neuen Entwicklungskultur ist aber eigentlich keine Eigenschaft der Sprache.

Bei der Konzeption einer Programmiersprache müsste man sich im Grunde also ständig fragen: Was baue ich in die Kernsprache hinein, was überlasse ich Bibliotheks- und Tool-Entwicklern. Ein Beispiel: In Eiffel oder D gehören Kontrakte zu den in die Sprache integrierten Features. Kann man Kontrakte auf die Sprache aufsetzen, ohne sie in die Sprache einzubauen? Muss man dann Einschränkungen in Kauf nehmen? Ist der Einbau in die Sprache hinreichend, oder wird es irgendwann zusätzliche Türmchen an meinem Sprachgebilde geben? Lassen sich Erweiterungen schwer oder leicht realisieren? Lässt sich das Feature ausstellen? Ein weiteres Beispiel: Ich habe einen Bytecodeinterpreter für meine Sprache. Ein anderer Anbieter hat eine VM mit JIT-Compiler und dort wird der gleiche Code 10 x schneller ausgeführt. Hat nichts mit der Sprache zu tun, beeinflusst aber maßgeblich deren Außenwirkung. Weiter: Ist die Anzahl der primitiven Methoden meiner VM eine Spracheigenschaft oder einfach nur eine Designentscheidung des Anbieters?

Mein persönlicher Eindruck ist, dass Sprachdiskussionen sich häufiger an "kulturellen" Unterschieden entzünden als an dem, was man als Kern der jeweiligen Sprachen bezeichnen könnte. Wenn dem aber so ist, dann sollte die Macht der Scheinalternativen nicht unterbewertet werden. Das was ich an Sprache XY toll finde, könnte man theoretisch ja auch in Sprache Z haben, hat man aber typischerweise nicht.

Meine ideale Spache wäre so einfach wie LISP, so schnell wie C, so typsicher wie D, so pragmatisch wie Ruby, so funktional wie Haskell, so sauber wie Eiffel und sie hätte einen Smalltalk-Debugger und jeder Browser, jeder Webserver, jedes Case-Werkzeug hätte ein Plugin dafür und natürlich würden alle Betriebssysteme eine superschnelle VM für meine Sprache und einen ENVY-Server für's Konfigurationsmanagement enthalten. ;-)

--- SaschaDördelmann

Moin Benjamin. Meinst Du vielleicht soetwas wie eine Sprache, die in einem Wiki zum Einsatz kommt und so den Funktionsumfang desselben erweitert bzw. neue Applikationen damit ermöglicht? FlexWiki? ( http://www.flexwiki.com ) und IxWiki? (eigentlich XWiki, aber damit's CamelCase wird; http://www.xwiki.org ; Mischung aus Groovy und Velocity) bieten soetwas. -- bs

Hallo Bernd. Nein, ich meine eigentlich zwei Dinge auf einmal:

1. Ein Wiki-System, dass alle Aufgaben eines CVS übernimmt und so im Prinzip Mitentwicklung von jedem Browser ermöglicht
2. Eine Programmiersprache, die in diesem System von allen gemeinsam erst entwickelt wird im Stil von Lisp, wo Programmieren teilweise praktisch das Bauen/Erweitern eines Compilers ist. Die Sprachlogik könnte auch aus S-Expressions bestehen, zusätzlich sollten aber alle Aufsätze/Toolkits fast beliebig eigene Syntax drübersetzen können - auch wenn ich nicht weiß wie man mögliche Konflikte da vernünftig bereinigen kann.

Die ideale Sprache wird es schon deswegen nicht geben, weil Sprachen viel zu sehr nach dem Geschmack beurteilt werden. (Das ist nicht nur bei Programmiersprachen so.) Da gibt es so einige Ziele, bei denen viele Programmierer sofort zustimmen, dies aber auch schnell wieder vergessen, wenn es an die konkrete Umsetzung geht. Solche Ziele sind in der Regel: kompakter Sprachumfang, konsistente Syntax, damit einhergehend leichte Erlernbarkeit, Sicherheit, Flexibilität. In der Praxis wird aber der Einfachheit halber meistens irgendeine Sprache hergenommen, alles geändert, was dem Sprachschöpfer nicht passt und alles andere ungeprüft übernommen. (Welcher Durchschnittsprogrammierer kennt sich schon mit Fallstricken der Arithmetik oder der Zeitrechnung aus.) Oder aber es wird aus mehreren Sprachen zusammengeworfen, was dem Sprachentwickler gerade gefällt. Statt einer logischen Syntax wird es dann wieder nur C-Syntax die noch mit allerhand Schnickschnack beladen wird, statt einer konsistenten Standardbibliothek werden Funktionen der C-stdlib übernommen, statt Einfachheit wird nach dem Motto "viel macht viel" erweitert ohne Maß, und leichte Erlernbarkeit wird auf leichte Erlernbarkeit für C-Programmierer reduziert. So lange Sprachentwickler nicht ihre Eitelkeiten überwinden und ihrer Gewohnheit eine höhere Bedeutung beimessen als der Verfolgung der angestrebten Ziele, wird es so viele ideale Sprachen geben wie Entwickler. -- HenningThielemann