Eine Programmiersprache mit Fan-Potenzial?

18.02.2009

Ein Blog-Artikel von Bruce Eckel, dem Autor von Thinking in Java, hat mich auf die Programmiersprache Fan aufmerksam gemacht. Brauchen wir wirklich noch eine weitere Programmiersprache? Laut Meinung der Entwickler von Fan: ja. Aber wieso?

Der Hauptgedanke der Macher von Fan ist, eine Programmiersprache zu schaffen, die praktisch ist und eine einfache und effiziente Entwicklung ermöglicht.  Die Sprache soll die besten Eigenschaften von Java und C# in sich vereinen, und gleichzeitig ohne die Nachteile dieser beiden Sprachen auskommen. Großer Wert wird auch auf das Design der Standard-API gelegt, die im Gegensatz zu Java (großes Negativbeispiel: die Calendar-Klasse) und C# einfach, elegant und intuitiv zu verwenden sein soll.

Eine Besonderheit der Sprache ist ihre Portabilität: ihre Programme, einmal kompiliert, sollen ohne weitere Anpassung sowohl in der Java-VM als auch in der .NET-VM laufen können.

Weitere Merkmale von Fan sind:

  • Strenge Objektorientierung: Alles ist Objekt, native Datentypen wie int, float etc. gibt es nicht.
  • Generics gibt es nur für Lists, Maps und Funktionen. Dadurch sind die meisten Anwendungsfälle abgedeckt, in denen Generics gebraucht werden, ohne dass man sich jedoch gleichzeitig die Komplexität der Generics in Java einhandelt.
  • Sowohl strenge als auch dynamische Typisierung: Signaturen für Objektfelder und Methoden müssen typisiert werden, alles andere kann, muss aber nicht. Bei Methodenaufrufen hat man die Wahl, ob der Aufruf streng (Typprüfung durch den Compiler) oder dynamisch (Prüfung erst zur Laufzeit) typisiert erfolgt.
  • Übersichtliches, versionierendes Paketierungssystem: Welcher Java-Entwickler kennt nicht die „Jar- & Classpath Hell„? Besonders bei großen Projekten und/oder gleichzeitigem Einsatz von mehreren Komponenten wie Spring, Hibernate & Co. verliert man leicht den Überblick, welche Komponente von welchen Jar-Dateien in welchen Versionen abhängig ist. Bekommt man eine ClassNotFoundException, hat man keinerlei Information darüber, in welcher Jar-Datei die fehlende Klasse sich befindet. Diesen Problemen möchte Fan durch sein von Grund auf neu konzipiertes Paketierungssystem Abhilfe schaffen.
  • Closures, für Java lang ersehnt und in Version 7 erwartet, aber scheinbar nun doch nicht enthalten, machen die Verwendung der APIs schlank und elegant.
  • Keine Checked Exceptions, die den Code in der Regel nur unnötig aufblähen und den transparenten Einsatz von ORM-Mappern o.ä. erschweren.
  • Defaultwerte für Parameter
  • Variablen können den Null-Wert nur annehmen wenn explizit deklariert.
  • Implizite Getter und Setter, ohne dass diese im Code definiert werden müssen.
  • „Syntactic Sugar“ zur kurzen und prägnanten Deklaration von Listen und Maps.
  • u.v.m.

Die oben genannten Vorzüge hören sich recht vielversprechend an. Ob diese allein für einen Erfolg von Fan ausreichen, ist allerdings fraglich. Denn der Erfolg einer Sprache hängt mitunter auch davon ab, wieviele fertige Softwarekomponenten von Drittanbietern es gibt. Und für Java gibt bereits eine Menge (mittlerweile auch recht ausgereifte) Standards, Frameworks, Komponenten (wie EJB, JPA, Spring, Hibernate etc.). Man kann wohl in Fan auch Java-Bibliotheken verwenden, damit verliert man jedoch die Portabilität zu .NET. Vielleicht dann doch lieber Groovy, das die meisten der o.g. Merkmale ebenfalls besitzt?!?

Zurück zur Übersicht

2 Kommentare zu “Eine Programmiersprache mit Fan-Potenzial?

  1. Hallo Michael,

    natürlich kann man alles mit Java abbilden. Aber dass man dadurch immer lesbaren Code hat wage ich anzuzweifeln, da die Syntax von Java oft lang und umständlich ist, wie z.B.:

    List<Map<String, BigDecimal>> myList = new ArrayList<Map<String, BigDecimal>>();

    Die „Geschwätzigkeit“ von Java macht das Entwickeln damit außerdem auch nicht unbedingt effektiver (auch wenn einem heutzutage IDEs wie Eclipse viel Tipparbeit abnehmen).

    Was das Erlernen neuer Programmiersprachen angeht bin ich der Meinung, dass es niemals schadet, ab und zu über den eigenen Tellerrand hinauszuschauen und zu sehen was es sonst noch gibt. Es gibt einige Merkmale, die Java nicht hat (bleiben wir z.B. bei den Closures). Es geht nicht darum, mal schnell eine neue Sprache zu lernen, sondern darum, neue Konzepte kennen und verstehen zu lernen. Und wenn man das erreicht hat, beschränkt sich das Lernen einer neuen Sprache nur noch auf das Kennenlernen einer anderen Syntax und der Bibliotheksfunktionen dieser Sprache.

  2. Spontan fällt mir dazu auch die Programmiersprache Scale ein:
    http://www.scala-lang.org/

    Scala läuft auch vollständig in einer Java VM und sicher wie Groovy volle Interoperabilität mit Java. Scala-Quellcode lässt sich als Skript ausführen oder zu Bytecode compilieren.
    Ziel von Scala ist es, bekannte Paradigmen der Objektorientierung möglichst kompakt und elegant darzustellen. Neben „Closures“ und „Currying“ gibt es noch zahlreiche weitere Programmiermuster, die Java nicht bietet. Durch die kompakte Schreibweise mit starker Expressivität, teilweise aber ungewohnter Syntax ist Scala neben Groovy ein weiterer Stern am Himmel der JVM-Programmiersprachen.
    Dabei stellt sich natürlich die Frage: Kann ich nicht doch alles mit Java abbilden und hab dann zwar umfangreicheren, aber auch lesbareren Quellcode? Nicht jeder ist dazu geneigt mal schnell eine neue Programmiersprache zu erlernen…

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

*Pflichtfelder

*