Funktionssprachen, die mit der Dalvik VM von Android kompatibel sind? [geschlossen]


16

Ich habe ein Softwareproblem, das zum funktionalen Ansatz der Programmierung passt, aber der Zielmarkt wird das Android-Betriebssystem sein. Ich frage, weil es funktionale Sprachen gibt, die zu Javas VM kompilieren, aber Dalvik-Bytecode! = Java-Bytecode.

Oder wissen Sie, ob das dxDienstprogramm .classdie aus Funktionssprachen wie Scala generierten Dateien intelligent konvertieren kann ?

Bearbeiten : Kann ich die Frage ein wenig verfeinern, um der Community ein bisschen mehr Hilfe zukommen zu lassen und um mir bei der Auswahl zu helfen?

  • Haben Sie andere Sprachen mit Dalvik verwendet? Welche?
  • Was sind einige "Fallstricke" (Probleme), auf die ich stoßen könnte?
  • Ist die Leistung akzeptabel? Damit meine ich, dass die Anwendung immer noch auf den Benutzer reagiert.

Ich habe noch nie Mobiltelefone entwickelt, bin aber mit eingeschränkten Geräten aufgewachsen und habe keine Illusion, dass die Verwendung von Nicht-Standardsprachen mit der Plattform Kosten verursacht. Ich muss nur wissen, ob die Kosten so hoch sind, dass ich meinen Ansatz in die Standardsprache umwandeln sollte (dh Funktionsprinzipien in der OOP-Sprache anwenden).


Ich habe die Frage aktualisiert. Vielen Dank an @geekosaur für Ihre erste Antwort. Das waren die Anfangsinformationen, nach denen ich gesucht habe.
Berin Loritsch

Ich habe im Haskell-Café ein Flüstern von Leuten gehört, die dies mit FFI + Haskell + Courage taten. Ich glaube, es gibt eine Bibliothek auf Github / Hackage dafür
Daniel Gratzer

Antworten:


7

Es gibt einen Blog-Beitrag von Christian Neukirchen mit dem Titel Programming for Android with Scala , in dem gezeigt wird, wie man Scala-Programme für Android erstellt. Wie es aussieht, dexkann Scala damit umgehen, aber Sie müssen ein Tool wie ProGuard verwenden, um die Scala-Klassenbibliothek auf die richtige Größe zu bringen, da dexandernfalls die gesamte Scala-Laufzeit importiert wird.

An der Android-Programmierung mit Erjang und Clojure wird derzeit gearbeitet .


1
Es sieht so aus, als ob fast alle Optionen, die Sie angeboten haben, schwerwiegende Leistungseinbußen nach sich ziehen. Das zeigt mir, dass die Optionen für die Hauptsendezeit noch nicht ausgereift genug sind. Vielleicht in einem anderen Jahr?
Berin Loritsch

Solange Sie keine großen Teile der Klassenbibliothek von Scala verwenden, sollte es keine nennenswerten Leistungseinbußen geben. Außerdem können Sie den gesamten Prozess mit maven automatisieren.
Kim

@Berin: Ich denke, die Zukunft verwendet keine JVM-Targeting-Sprachen - dexist immerhin optimiert, um nicht nur Java-Bytecode, sondern auch Javas Bytecode- Konventionen zu behandeln (Sie werden dies in den zuvor bereitgestellten Links erörtern) - sondern Targeting die Dalvik VM direkt. Möglicherweise ist das schneller als die Java- dexRoute.
Geekosaurier

1
Und für diejenigen, die sich fragen: Der Dalvik VM-Bytecode ist dokumentiert: Opcodes , Befehlsformate . Ich sehe einige Möglichkeiten für Gucklochoptimierungen, die nicht möglich sind, wenn Sie sofort auf die JVM abzielen, geschweige denn intelligentere Optimierungen unter direkter Verwendung der Dalvik-Architektur.
Geekosaurier

@ Kim, der Artikel, den ich gefunden habe, sagte, das Leistungsproblem liege in den Unterschieden zwischen den Klassenladealgorithmen für Java und Dalvik. Wenn ich mich von den dynamischen Sprachfunktionen von Scala fern halte, sollte es mir möglich sein, Probleme beim Laden von Klassen zu vermeiden. Dasselbe Problem quälte die anderen Optionen. Im Moment ist alles noch ziemlich neu. Möglicherweise probiere ich es trotzdem bei diesem Projekt aus - es ist auf jeden Fall ein Proof of Concept.
Berin Loritsch

7

Kawa ist eine schöne, aber wenig bekannte Variante des Programms, die seit vielen Jahren leise existiert und sowohl auf der JVM als auch auf Dalvik ausgeführt wird . Daher enthält die Ausgabe ähnlich wie bei Mirah keine zusätzliche VM und nur explizit importierte Bibliotheken. Kawa verfügt über viele Standardmakros (einschließlich einiger für Android-APIs spezifischer Makros), die für eine schöne, saubere Syntax sorgen (vorausgesetzt, man ist nicht abgeneigt von Klammern) und zusätzlich zu Scheme einige leckere Extras wie "Versprechen" (Lazy Eval und Futures) hinzufügen in Eins). Die Sprache ist ziemlich robust und gut dokumentiert und wurde seit den Anfängen von Java aktiv gepflegt und weiterentwickelt.

Der Java-Adventskalender fasst Kawas Verdienste mit einigen informativen Beispielen und Links zusammen.


Wow, danke, dass du mich in Richtung Kawa gelenkt hast! Ich wollte unbedingt eine Nicht-Java-Android-Entwicklung durchführen, und das sieht wirklich vielversprechend aus.
Evicatos

1

Neben Scala kann ich Ihnen vorschlagen, sich Mirah auf Android anzuschauen. Hier einige Details: http://threebrothers.org/brendan/blog/strange-loop-2011-mirah-for-android-development/

Was macht diesen Ansatz "besser" als die anderen Sprachen? Mirah ist eine statische typisierte Sprache mit Ähnlichkeit zu Rubin. Das erlaubt einen funktionalen Stil, der vermutlich besser ist als Java. Normalerweise ist das 'Portieren' einer Sprache auf Android problematisch, da Sie auch die Standardbibliothek portieren müssen. Mirah vermeidet dies, indem es vermeidet, eine Standardbibliothek zu haben. In dem referenzierten Material gibt es eine schöne Übersicht von REAL WORLD Erfahrung mit mirah auf Android und wie es sich herausstellte. (versuche 2)


1
Bitte veröffentlichen Sie nicht dieselbe Antwort erneut. Sie mussten nur darum bitten, dass Ihre Antwort nach der Bearbeitung wiederhergestellt wird, um sie für die Aufmerksamkeit der Moderation zu markieren.
Yannis


Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.