In den Hilfeseiten steht: "For the Lava interpreter and run time environment it would be very important to make existing class libraries of other languages accessible to Lava programs with minimum effort, since we cannot afford to develop all these libraries again from scratch in Lava. Therefore proposals on how to achieve this are highly welcome. The .NET approach of Microsoft promises to make the sharing of class libraries between languages easy; Microsoft also holds out a prospect of .NET implementations on non-Windows platforms. For Windows platforms .NET would probably provide the simplest solution. On non-Windows platforms you will presumably have to pay for the .NET software."

Möglicherweise könnte das MonoProject (OpenSource-Implementierung von SpracheCsharp und DotNet auf Linux) eine kostenfreie Lösung unter Linux ermöglichen. -- HelmutLeitner

Das wäre phantastisch (oder jetzt mit "f" statt "ph"??)! Besten Dank für den Hinweis, muss ich mir mal genauer anschauen. --kg

Frage: Wie verwandt ist das Konzept von Lava mit den Ideen, die das IntentionalProgramming-Projekt verfolgte? -- hl

Antwort: Die Vergangenheitsform "verfolgte" ist wohl nicht ganz angemessen. Nach meiner Kenntnis ist das Projekt vom langjährigen Forschungsstadium Ende 1999 oder Anfang 2001 in ein Entwicklungsstadium eingetreten und die Webseiten des Forschungsprojektes sind dementsprechend ersatzlos geschlossen worden.

Ein deutscher Kollege, Lutz Roeder (s. http://www.aisto.com/roeder/active/), der im Mai 2001 als Mitarbeiter oder Gastforscher zu dem IP-Projekt gestoßen ist, hat mir seinerzeit geschrieben, das Lava-Konzept klinge wie von IP abgeschrieben. Das sehe ich jedoch nicht so. Bei IP liegt die Betonung auf der sehr ambitionierten Idee, alle möglichen Programmiersprachen quasi in IP rekonstruieren und mit anpassbaren Struktureditoren unterstützen zu können. Existierende Software in allen möglichen Sprachen soll durch diese Rekonstruktion in IP kombinierbar gemacht werden. Domain-spezifische Ausdrucksmittel sollen mit IP leicht ad hoc konstruierbar sein und durch fortschrittliche, anpassbare Werkzeuge (Struktureditoren) unterstützt werden.

Lava ist da viel bescheidener. Es macht keinerlei Versuch, andere Sprachen "aufzusaugen", sondern ist eine einzelne, konkrete Sprache mit Lava-spezifischen, nicht anpassbaren Struktureditoren. Lava ist vielmehr geprägt durch die Idee,

• von der "Spaghetti-Programmierung" (wild verschlungener Kontrollfluss) der ersten höheren Programmiersprachen,
• über die "Tortellini-Programmierung" (viele kleine Methoden-Bröckchen, mangelnde Struktur "im Großen") der objekt-orientierten Sprachen zu einer Art
• "fraktalen Programmstruktur" überzuleiten.

Die Bausteine, Zweige und Detaillierungs-Ebenen dieser fraktalen Struktur sollen dabei jeweils so weit wie möglich für sich verstehbar und überhaupt so einfach und überschaubar wie möglich sein. Wichtige weitere Maßnahmen um dies zu erreichen:

• Auftrennung von Klassen in "Interface" und "Implementation",
• Modularisierung großer Klassen durch Mehrfachvererbung,
• Verzicht auf globale Variablen,
• ausschließlich expliziter Datenfluss durch Methoden-Parameter,
• Verzicht auf geschachtelte Schleifen zugunsten rekursiver Funktionen,
• dadurch viele kleine statt monolithischer großer Funktionen,
• Single-Assignment,
• dadurch, in Verbindung mit dem Schleifenverzicht: überschaubarer Datenfluss "von oben nach unten",
• lückenlose Variablen-Initialisierungs-Checks,
• strenge Objekt-Initialisierungs-Disziplin,
• Unterscheidung veränderlicher Zustands-Objekte (Bankkonto) und nach Fertigstellung eingefrorener Werte-Objekte (Überweisungsauftrag),
• dadurch wiederum weitergehende Prüfungsmöglichkeiten zur Programmierzeit,
• ...

IP war von Anfang an mit einem Höchstmaß an Geheimniskrämerei verbunden, und man hat nur sehr abstrakte philosophische Papiere zu fassen bekommen, die es einem sehr schwer machen, die Realisierungschancen der IP-Ideen zu beurteilen. Ich kann mir z.B. schwer vorstellen, dass man unsere Lava-Konzepte in IP rekonstruieren kann, und zwar mit einem Aufwand, der nicht einer totalen Neu-Implementation "from the scratch" gleichkommt.

Klaus, du wirfst da für mich eine Menge Fragen auf, die aber nur zum Teil auf diese Seite passen. Auch wenn Lava und IP eigenständige Konzepte sind, so weisen sie doch in die gleiche Richtung, nämlich Software noch stärker über eine IDE geführt zu produzieren (entschuldige, dass ich das auf eine so banale Ebene bringe). Für dich ist es ein Forschungsprogramm. Für MicroSoft und CharlesSimonyi sicherlich ein Programm gesteigerte Produktivität an die eigenen proprietären Produkte zu binden. Für mich hat das durchaus problematische Aspekte, weil dadurch der Aufwand zur Entwicklung kompetitiver Sprachen bzw. Entwicklungssysteme in der Zukunft enorm ansteigen würde (womöglich könnten sich das in Zukunft nur mehr wenige Großfirmen leisten).

In Bezug auf Lava verstehe ich deine Argumente für eine Integration, gleichzeitig widerspricht diese Integration meinem Empfinden. Wäre z. B. die Lava-IDE durch eine AST-Konfigurationssprache für andere Sprachen konfigurierbar, dann könnte der einzelne Programmierer wesentlich leichter Kontakt zum AST-Konzept finden, weil er sehen könnte, wie sich seine Programme in diesem Umfeld anfühlen. Ihr hättet dann auch nicht sofort das Problem, dass Lava (das Konzept) sofort auch an den - derzeit noch begrenzten - Fähigkeiten von Lava (als Sprache incl. Bibliotheken) gemessen wird. Ihr könntet auch sofort das "experimentell" streichen. Für mich ist das ein Fall von DivideEtImpera. Aber ich bin sicher, dass ihr schwerwiegende Gründe für diese Integration habt. Aber welche? -- hl

Helmut, du hättest Recht, wenn das mit der "AST-Konfigurationssprache" so einfach wäre, aber dahinter steckt, ist mehr oder weniger das volle Programm des IP-Projektes. Und das hat seit 1989, also über 12 Jahre, mit -zig Leuten daran gearbeitet, ohne für die Allgemeinheit sichtbares konkretes Ergebnis. Zu zweit müssen wir da entschieden bescheidener sein, und wir waren nach meinem Empfinden trotzdem schon ganz schön mutig, als wir eine neue oo Sprache mit vielen außergewöhnlichen Features und eine ebenso außergewöhnliche Entwicklungsumgebung für diese Sprache in Angriff genommen haben.

An die allgemeine "AST-Konfigurationssprache" mit IP-ähnlichem Anspruch glaube ich also derzeit nicht. Allenfalls kann man über Struktureditor-Generatoren, wie den "Synthesizer Generator" von GrammaTech?, siehe http://www.grammatech.com/products/sg/overview.html, sprechen, der aber nicht diesen universellen Sprach-Assimilierbarkeits-Anspruch nach Borg-Manier erhebt.

Ich glaube nicht, dass Struktureditoren für andere, verbreitete Sprachen, die nur als Texterstellungs-Hilfen benutzbar sind, den Durchbruch bringen würden. Unser Augenmerk liegt auch gar nicht so einseitig auf der Struktureditor-Technik, sondern uns sind die Lava-Sprachkonzepte mindestens genau so wichtig, und es kommt, so glaube ich, darauf an, beides auf sorgfältig abgestimmte Weise zum Tragen zu bringen (was mit generischen Tools schwer erreichbar wäre).

Ich glaube auch nicht, dass IDEs auf Struktureditor- und AST-Basis aufwendiger zu entwickeln sind. Da werden sich so wie im Compilerbau bewährte Techniken, Datenstrukturen und Tools etablieren. Lexikalische und Syntaxanalyse falle ja sogar weg, und die AST-Basierung ermöglicht erweiterbare/anpassbare IDEs durch Plug-ins, die auf dem AST arbeiten.

Im Übrigen sollte man "AST" nicht als Zauberwort ansehen. Auch die gegenwärtige XML-Schwärmerei, so als ob die bloße Existenz eines Daten-Darstellungs- und -Kodierungs-Standards schon alle Probleme lösen würde, kann ich nicht nachvollziehen. Was man jetzt mit XML als Datenaustausch-Format macht (also von der Webseiten-Formatierung abgesehen), hat man schon vor 25 Jahren mit ASN.1 und ODA/ODIF vergeblich versucht. Es scheiterte einfach am mangelnden Willen und Markt-Druck zur Standardisierung konkreter Anwendungs-Datenstrukturen, obwohl mit ASN.1 etc. die nötigen Ausdrucksmittel vorhanden waren.

Ähnlich fehlt es heute an dem nötigen Willen und Markt-Druck, aber auch an dem nötigen Verständnis der Grundlagen, auf der IDE-Ebene und der Ebene der "sichtbaren" Programmiersprachen-Struktur auf Basis generischer AST-Techniken zu einer Vereinheitlichung zu kommen.

Aussichtsreich, hoch interessant und spannend finde ich dagegen den Microsoft-Vorstoß, mit der .NET-IL und -CLR auf der Ebene der Compiler-Zwischensprachen und Laufzeitumgebungen zu einer Vereinheitlichung zu kommen. Dort wollen wir auch mit der Lava-Entwicklung einhaken, um das Problem der fehlenden Lava-Libraries zu lösen (ohne dass wir jedoch die Hoffnung haben, die Lava-Semantik auf IL/CLR in aller Allgemeinheit abbilden zu können). --kg

Ich kann alle deine Argumente nachvollziehen und glaube auch nicht, dass das Scheitern von CS an dem Projekt (wenn ich mir herausnehme, das so flappsig zu formulieren) viel bedeutet. Gerade der Mangel an Resourcen (keine -zig Leute) führt nach meinen Erfahrungen oft zu kreativeren und besseren Lösungen. -- hl

Frage: Angesichts des großen Interesses für OpenSource-Projekte: Wie könnte eine gemeinsames SourceCode-Repository bei Verwendung der SpracheLava organisiert werden? Da der SpracheLava doch eine TextuelleRepresentation? fehlt, cvs also nicht gut einsetzbar ist? Oder anders gefragt, wie soll die Verwaltung von Revisionen in einem Lava-Projekt erfolgen?

Wenn man da auf eigene Lösungen verzichten, sondern auf bewährte textbasierte Systeme, wie CVS, zurückgreifen will, liegt es natürlich sehr nahe, eine Transformation Lava <==> XML zu entwickeln. Dies wäre auch kein großes Problem: Wir haben ja jetzt schon eine Transformation Lava ==> HTML, das ist kein großer Unterschied.

Derzeit hat das nur noch so keine hohe Priorität für uns. Wir wollen erst noch ein paar Sachen machen, die uns konzeptionell wichtiger sind. Z.B. eine nicht-generative, vielmehr auf modifizierter Vererbung basierende Unterstützung für aspekt-orientierte Programmierung durch Übertragung und Erweiterung des "inner"-Konstruktes von BETA auf Lava. --kg