Wird es eine funktionale Sprache geben, die für die Java-Community das tut, was F# für die .NET-Community tut?
Welche funktionalen Programmiersprachen sind für die JVM verfügbar bzw. in Entwicklung?
Scala wäre die Sprache.
Obwohl es nicht strikt funktional ist (es ist eine Mischung aus funktional und objektorientiert) und es ist nicht strikt für Java (es gibt eine .NET-Version von Scala ), das wäre das nächstliegende Analogon zu F# in der JVM.
Das erste, was mir in den Sinn kam, war Scala aber wirklich Ocaml-Java kommt näher, da F# eine Variante von Ocaml ist. Siehe dieser Beitrag, der Ocaml-Java mit Scala vergleicht :
OCaml-Programmierer sind in der Regel mehr als 10-mal so produktiv wie Java- oder C++-Programmierer. Programmierer bei einer Vielzahl von praktischen Aufgaben. Obwohl es auf einer OOP-Plattform basiert, ist F# weit davon entfernt, die produktivitätssteigernden Vorteile von OCaml (und der gesamten ML-Familie). Im Gegensatz dazu kann Scala viele der Vorteile nicht, einschließlich einiger wirklich grundlegender Vorteile, und, Folglich ist das Schreiben von korrektem Code in Scala viel schwieriger als in jeder echten ML.
Darüber hinaus ist die ML-Sprachfamilie darauf ausgelegt, kurz und bündig zu sein, aber Scala ist unnötig langatmig für alles ab "Hello world!" aufwärts. Die ML-Familie Sprachen bieten umfangreiche Typinferenz (OCaml mehr als die meisten), aber Scala hat im Vergleich dazu nur eine rudimentäre Inferenz. OCaml hat ein ungewöhnlich ausdrucksstarkes Typsystem, aber Scala fügt der OOP wenig hinzu, was von praktischer Bedeutung ist.
Es gibt zwar kein Argument, dass ML/OCaml viel prägnanter und funktionaler ist als Scala, aber es ist schwer, alle Behauptungen in dem (etwas veralteten) Forumsbeitrag zu unterstützen. Ich stimme allerdings zu, dass Scala nicht zu der Analogie passt. F# ist im Grunde OCaml für die CLR.
@Daniel: Da muss ich voll und ganz zustimmen. Es gibt ein paar Szenarien, in denen F#/OCaml diesen Vorteil bieten, aber für die meisten alltäglichen Programmierungen (d.h. das Brot und Butter der meisten Leute) ist dieser Anspruch einfach unrealistisch.
Der Autor des verlinkten Beitrags (Jon Harrop) trollt häufig das Usenet und andere Foren, um Beratungsaufträge zu erhalten. Nehmen Sie seine Ratschläge mit Vorsicht auf - er versucht, Ihnen etwas zu verkaufen.
Vielleicht Clojure . Es ist nicht statisch typisiert, aber es legt mehr Wert auf Unveränderlichkeit und Gleichzeitigkeit als F#. Wie F# (und im Gegensatz zu Common Lisp) ist sie jedoch als primär funktionale Sprache gedacht, die gut darin ist, OO-Bibliotheken von der zugrunde liegenden Plattform zu nutzen.
+1, weil es richtig ist, und es bringt dich auf 10, was Jop sein Populisten-Abzeichen gibt
Das gilt auch für mich. Ach, wenn ich doch nur ein Meer von Parens sehen könnte und das ständige mentale Parsing von unten nach oben, das man wegen der unaufhörlichen Präfix-Notation machen muss... Ich würde Lisp benutzen. Ich glaube, ich bin der einzige Mensch, der ML-Sprachen für syntaktisch schön hält.
Im Moment würde ich Scala sagen. Aber für die Zukunft würde ich einen Blick auf Fortress werfen. Die erste Implementierung der Spezifikation wurde am 1. April 2008 veröffentlicht. Und nein, das ist kein Scherz. Die wichtigsten Merkmale sind:
Mehr Informationen auf der Projekt Festung Gemeinschaftswebsite und die Wikipedia Festungsseite .
@RoelSpilker: Ich war's nicht. Ich war auf der Website und konnte die Spezifikation nicht herunterladen. Als Fortran-Abkömmling scheint sie nicht als funktionale Sprache zu gelten? Liege ich da falsch?
Obwohl sie auf den ersten Blick nur wie eine neue Version von Fortran aussieht, ist sie auch von Scala und Haskell beeinflusst. Und so wie die Sprache konzipiert ist, unterstützt sie sowohl Objekte als auch Traits. Siehe auch die FAQ: research.sun.com/projects/plrg/faq/index.html#five
@RoelSpiker: +1 ... Hört sich gut an, aber ich frage mich, wie die allgemeine Dynamik dahinter aussieht. Ihre "Roadmap" führt derzeit nirgendwo hin :s
Wohl kaum, denn der JVM fehlen Tail Calls, die aber erforderlich sind, um fast allen funktionalen Code in Bezug auf den Stackverbrauch robust zu machen.
Am nächsten kommen funktionale Sprachimplementierungen auf der JVM den folgenden Clojure , Scala und die OCaml-Java Projekt. Obwohl es Umgehungsmöglichkeiten für das Fehlen von Schwanzaufrufen gibt (z. B. Trampolining), tut dies keine dieser Sprachimplementierungen, weil die Umgehungsmöglichkeiten noch ernstere Probleme mit sich bringen, z. B. Leistungseinbußen und eine vollständige Verschleierung der Fehlersuche.
Sun spricht schon seit Jahren von Tail Calls und hat in jüngster Zeit angedeutet, dass sie diese in Kürze einführen wollen. Sobald dies geschehen ist, werden wir sicher eine größere Sprachenvielfalt auf der JVM sehen und vor allem einige funktionale Sprachimplementierungen in Produktionsqualität. Bis dahin betrachte ich alle diese Sprachen als Spielzeug.
Zum Wohl, Jon Harrop.
Wieder einmal erzählt uns John Harrop Märchen darüber, wie "Schwanzrufe sind erforderlich " (Hervorhebung von mir) für funktionalen Code. Wer immer das liest - es ist einfach nicht wahr. Zugegeben, die Unterstützung von Schwanzaufrufen ist eine nette Sache - genau wie eine FPU eine nette Sache ist, aber nicht erforderlich um Gleitkommaberechnungen durchzuführen.
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
