News Android: Kotlin und Swift als Java-Alternative gehandelt

[karamba]

Aber angeblich (!) soll die ratio Cycle/Watt ungeschlagen sein, daher laufen die Hintergrunddienste auf den Smartphones wohl auch meistens in C++. Mir ist jedenfalls nicht klar, warum man dann nicht den nächsten Schritt geht und C++ zum "First Class Citizen" macht. Es liegt nahe, Komplexität der Sprache hin oder her.

Es liegt eben nicht nahe. Bei App Entwicklung geht es primär um Entwicklungskosten und Funktionalität und nicht um das letzte bißchen Performance/Watt. Zudem wird Google die Laufzeitumgebung schon auf Performance/Watt optimieren. Es ergibt wenig Sinn, die Entwickler von Apps auch noch mit C++ zu (ich sage es mal) belästigen. Der Nutzen wiegt nicht den erhöhten Aufwand auf. Neue Sprachen entstehen ja nicht ohne Grund. C++ hat neben Vorteilen auch Nachteile und ist deshalb nicht der heilige Gral der Entwicklung.

 

[Grundkurs]

Es liegt eben nicht nahe. Bei App Entwicklung geht es primär um Entwicklungskosten und Funktionalität und nicht um das letzte bißchen Performance/Watt. Zudem wird Google die Laufzeitumgebung schon auf Performance/Watt optimieren. Es ergibt wenig Sinn, die Entwickler von Apps auch noch mit C++ zu (ich sage es mal) belästigen. Der Nutzen wiegt nicht den erhöhten Aufwand auf. Neue Sprachen entstehen ja nicht ohne Grund. C++ hat neben Vorteilen auch Nachteile und ist deshalb nicht der heilige Gral der Entwicklung.

ich geb dir in allem Recht was du schreibst. Maßgeblich wird die hohe Produktivität sein, die man sich unter den jeweiligen Programmiersprachen verspricht. C++ ist leider auch nicht wirklich debug-freundlich. Wenn man dann doch mal einen Crash - z.B. wegen falschem Speicherzugriff (etwa auf ein schon gelöschtes Objekt)- hat, steht man wie der Ochse vor'm Berg und darf auf Fehlersuche gehen. Kotlin (Jetbrains) und Swift (Apple) stehen unter der Federführung der jeweiligen Firmen. Wenn Google so viel Theater mit Oracle hat, wundere ich mich, warum sie ihr Heil in einer Programmiersprache wähnen, die etwa von einem direkten Konkurrenten (Apple) entwickelt wird. Da sind Reibereien vorprogrammiert, auch wenn Swift unter "Open-Source" gestellt ist. Inwieweit Apple da jetzt nachträglich die Daumenschrauben anlegen kann, entzieht sich aber meiner Kenntnis.

 

[L0g4n]

Auch die ist nicht gegeben. Dein Versuch, ausgerechnet bei älteren Versionen nach Kompatiblität zu suchen, geht übrigens in die falsche Richtung.

Ja, dann sag doch mal was gegeben ist und nicht einfach nur destruktive Statements abzugeben.

 

[Wattwanderer]

Denke die "bessere / produktivere / stabiliere / einfachere / mehr sexy" Sprachfeature ist ein netter Bonus aber spielt bei der Wahl nur eine Nebenrolle. Sonst wäre Objectiv-C längst weg vom Fenster. Wie unbeliebt sie sein muss sah man an den spontanen Jubelsturm auf der Apple Event als mit Swift ein Nachfolger angekündigt wurde. Da kaum Details bekannt war konnte man das nur als alles ist besser als Objective-C deuten.

Trotzdem ist bei Apps IOS first immer noch eher die Regel obwohl sich die Entwicklung der Marktanteile zugunsten Android deutlich abzeichnet.

Die Fakten wären, Apple hat ein Angebot unterbreitet gemeinsam bei Null anzufangen.
Android bekäme mehr und schneller hochwertige Apps weil der Portierungsaufwand sinkt. Auch würden die Geräte ohne Java und mit Swift evtl. effizienter arbeiten.

Allerdings sehe ich nicht, warum Google auf dieses Angebot eingehen sollte. Die Tendenz geht aktuell klar in Richtung Marktdominanz von Android. Da scheint es naheliegender diese Marktmacht zu nutzen als sie einfach wegzugeben.

 

[Autokiller677]

Wie schon erwähnt wird bei Android keine JVM verwendet. Vor 5.0 wurde die Dalvik Virtual Machine benutzt. Danach wird gar keine VM benutzt, die Programme werden zum nativen code kompiliert.
Swift und Kotlin sind beide moderne und gute Sprachen, die auch funktionale Programmierung "unterstützen". Wobei Kotlin noch den Vorteil hat, dass die ganzen Java Tools und Libraries verwendet werden können.
Und hier nochmal ein paar Benchmark für alle die glauben, dass die moderne JVM lahm ist: http://benchmarksgame.alioth.debian.org/u64q/java.html

Danke dass du alle Argumente gegen Java bestätigst. Java ist in einem einzigen Test ca. 10% schneller - braucht aber auch mal eben ca. 6 mal so viel RAM. In allen anderen Tests ist Java langsamer, teils ist C doppelt so schnell. Dazu braucht Java in allen Tests signifikant mehr RAM.

Java ist sicher schneller als ein Rechenschieber, aber wirklich an der Spitze mischen sie nicht mit.

 

[JDK]

Ich frage mich, wie viele von den "Warum nicht C++?"-Leuten hier tatsächlich ihr Geld als App-Entwickler verdienen. ^^

 

[GinoBambino]

Dann hörst du falsch, das Ding heißt mittlerweile Android Runtime. Und Just in time Kompilierung passiert zur Ausführungen und nicht einmalig zur Installation (= ahead of time Kompilierung) .

Du liest offensichtlich falsch. Ich habe nirgends geschrieben, dass Dalvik durch JIT-Kompilierung ersetzt wurde.

Ich habe nur geschrieben, dass beides konzeptuell sehr ähnlich ist. Diese Art der Kompilierung erlaubt es immer noch, Optimierungen zu machen, während bei C++ alles direkt in Maschinencode kompiliert wird. Es ist keine JIT-Kompilierung, aber auch keine native wie bei C++.

 

[G00fY]

Java ist sicher schneller als ein Rechenschieber, aber wirklich an der Spitze mischen sie nicht mit.

Sorry, aber das ist kein Thread über Grafikkarten. Hier reicht es nicht spezifische Benchmarks zum Vergleich heran zu ziehen. Die Benchmarks sagen nichts über die Geschwindigkeit von Befehlen in der alltäglichen Android Entwicklung aus. Zumal hier nun bereits mehrfach erklärt wurde, dass unter Android rechenintensive Algorithmen bereits native in C++ geschrieben werden. Das ganze ist also deutlich komplexer. Und ich denke wir haben inzwischen verstanden, dass du Android und Java lahm findest.

Letztendlich ist es wie karamba schreibt. Mit Java kommt man in der kommerziellen Softwareentwicklung schneller ans Ziel, braucht sich nicht kaum um Resource Leaks kümmern da der GC aufräumt, es gibt mächtige Libraries und dadurch, dass der Bytecode erst auf dem Endgerät in nativen Code umgewandelt wird, reicht es eine APK für verschiedene Architekturen zu erstellen. Der Compiler kann zusätzlich CPU spezifische Optimierungen durchführen.
Das Java in vielen Anforderungskriterien nicht die Speerspitze aus Sicht der Performance ist, streitet keiner ab. Mit diesem Anspruch wurde Java damals auch nicht entwickelt. Aber eine Mobile-App ist idR keine wissenschaftliche Anwendung in der massiv floating-point operations durchgeführt werden (größtenteils Grundlage der verlinkten Bechmarks).

 

[crvn075]

Java ist sicher schneller als ein Rechenschieber, aber wirklich an der Spitze mischen sie nicht mit.

Java auf der JVM ist so ziemlich das schnellste, was es an JIT- oder AOT-basierten Bytecode-Sprachen gibt und fährt um andere Technologien dieser Kategorie Kreise. Da gibt es sonst nur noch .NET im selben Feld und das wars. Wenn für dich der Performanceunterschied zu C/C++, Rust, Fortran und Co. zu groß ist, dann dürften die meisten Sprachen und deren Runtimes deiner Logik nach wohl gar nicht erst existieren. Dass ein Benchmark, der sich nur auf mathematischen Algorithmen stützt rein gar nichts mit typischen Smartphone-Apps zu tun hat sollte ohnehin klar sein.

C++ wird auf Smartphones nie ein First Class Citizen werden. Das Argument "Hardwarenähe" ist hier genauso ein Kontra- wie ein Pro-Argument. Apple konnte diesen Schritt mit Objective-C damals natürlich ohne Risiko gehen, denn das ist einfach, wenn man im wesentlichen nur eine Hardwareplattform anbietet, die hin- und wieder mal aktualisiert wird (und davon abgesehen ist an Objective-C auch nur der C-Teil schnell, aber das ist eine andere Geschichte).

 

[Wattwanderer]

C++ wird auf Smartphones nie ein First Class Citizen werden. Das Argument "Hardwarenähe" ist hier genauso ein Kontra- wie ein Pro-Argument.

Waren die kaum konkurrenzfähigen Atom SOCs wert, ARM dermaßen auszubremsen? Über die vielen Jahre?

Bei Samsung sieht man ja, dass die aktuellen Geräte am thermischen Limit angelangt sind. Ein genervter Nutzer hat deswegen sogar eine aktive Kühlung an sein Gear VR angeflanscht damit sein Handy unter Last nicht mehr throttelt.

Apple hat die letzten Reserven noch nicht angeknabbert.

 

[KlaasKersting]

Bisher hat es durch die riesigen Fortschritte der ARM-SoCs ausgereicht, simple Apps mit Leistung zu erschlagen.
Nutz mal ein älteres Smartphone oder schwächeres Neugerät, du fragst dich an manchen Stellen ernsthaft, wie einfachste Programme so hängen können - das taten sie mit der selben Hardware vor einigen Jahren noch nicht und da kamen keine hungrigeren Funktionen hinzu.

Es wurde schlechte Optimierung mit Leistung kaschiert, das wird aber nicht ewig so weitergehen und dann wird man sich darüber Gedanken machen müssen, wie man mit dem TDP-Budget eines Smartphones und stagnierender Leistung softwareseitig möglichst viel rausholen kann.

 

[Autokiller677]

Nutz mal ein älteres Smartphone oder schwächeres Neugerät, du fragst dich an manchen Stellen ernsthaft, wie einfachste Programme so hängen können - das taten sie mit der selben Hardware vor einigen Jahren noch nicht und da kamen keine hungrigeren Funktionen hinzu.

Ich hatte auf meinem alten Android (1Ghz SC, 512MB RAM)eine Taschenlampen App, die über eine halbe Minute zum Starten brauchte. Die Programmierung dahinter muss so grottig gewesen sein, dass es kaum vorzustellen ist. Messenger, Browser, Spotifiy, alles war flotter.

 

[Magellan]

Wird in jedem Fall eine interessante Entscheidung und würde den "Sieger" auf einen Schlag enorm pushen.
Allein dass Google Kotlin in Betracht zieht ist ja bereits eine Adelung...

 

[0xffffffff]

Abseits vom Geschwindigkeitsunterschieden, mehr CPU Zyklen lassen sich wohl direkt in mehr Stromverbrauch übersetzen. Auch der riesige RAM Bedarf. Da kann man Google zu ihrer Optimierungsleistung nur gratulieren, dass die High End Android Flagschiffe nur mit 4GB RAM auskommen obwohl Apple für dieselbe Leistung schon 2GB RAM braucht. Ebenso, dass der Akku nur etwa 30% größer sein muss.

Apple kann hier einen kleineren Akku fahren, da die ganze Smartphone-Serie noch nicht auf diesen 4k Display Blödsinn aufgesprungen ist. Nach wie vor ist sind das Display und das Funkmodul die hauptsächlichen Stromfresser.

Dalvik hat schon seinen kompilierten Code gecached und seit Android 5 werden die Anwendungen bei Installation Ahead-of-Time für die jeweilige Plattform kompiliert. Ich denke Du unterschätzt JIT bzw. überschätzt den Overhead. Klar, es gibt ihn, aber die Optimierungsmöglichkeiten zur Laufzeit sind meist denen, die zur Kompilierzeit durchgeführt werden überlegen, sodass es am Ende auf das Gleiche hinausläuft.

Wenn dich das interessiert, schau mal ins Wiki von LuaJIT, da ist manches gut beschrieben und interessant zu lesen: http://wiki.luajit.org/Home

 

[Wattwanderer]

Dalvik hat schon seinen kompilierten Code gecached und seit Android 5 werden die Anwendungen bei Installation Ahead-of-Time für die jeweilige Plattform kompiliert. Ich denke Du unterschätzt JIT bzw. überschätzt den Overhead. Klar, es gibt ihn, aber die Optimierungsmöglichkeiten zur Laufzeit sind meist denen, die zur Kompilierzeit durchgeführt werden überlegen, sodass es am Ende auf das Gleiche hinausläuft.

Oh je...

Noch ein Punkt den ich vergessen wollte.

Die Installation bzw. Aktualisierung von Apps ist eine relativ unerfreuliche Angelegenheit geworden weil sie nun deutlich länger dauert. Die Motivation verstehe ich sehr wohl, warum nicht so viele Schritte wie möglich vorwegenehmen statt sie immer zu wiederholen. Würde mich darüber weniger aufregen wären da nicht die Google Zwangsapps die sich im Gegensatz zu denen vom Hersteller nicht deaktivieren lassen. Gefühlt mindestens eine handvoll Google App Aktualisierungen jede Woche die ich nie nutze aber dennoch durch die Optimierung laufen.

Noch schlimmer bei Android Updates. Der Balken mit "Optimierung der Apps 1 von 350...". Und nein, selbst installiert habe ich vielleicht 20 Apps.

 

[G00fY]

Noch schlimmer bei Android Updates. Der Balken mit "Optimierung der Apps 1 von 350...". Und nein, selbst installiert habe ich vielleicht 20 Apps.

So häufig formatiert man die Cache Partition aber nicht. Und so häufig erhält man (leider) auch keine OS-Updates. Zumal sich andere grundsätzlich über Updates freuen würden. Man muss das ja nicht durchführen wenn man sein Gerät gerade braucht. Und man muss dem Compiler nicht beim Arbeiten zugucken.

Zudem hat Google dase in Android N bereits geändert.

With Android N, Google is changing things up again. To cut on the long time required to compile apps when the system is updated (depending on the system, this may take 20 minutes or more), Android N now switches back to Just-in-Time compilation, but only the first times an app is launched. After that, Android N proceeds to compile apps Ahead-of-Time, presumably during idle times.

Also bald wieder ein Kritik Punkte weniger.

Edit:

Bei Samsung sieht man ja, dass die aktuellen Geräte am thermischen Limit angelangt sind. Ein genervter Nutzer hat deswegen sogar eine aktive Kühlung an sein Gear VR angeflanscht damit sein Handy unter Last nicht mehr throttelt.
Apple hat die letzten Reserven noch nicht angeknabbert.

Solche VR Anwendungen werden mit Sicherheit nicht in Java geschrieben. Was hat jetzt das Thema der Diskussion, die Wahl der Programmiersprache, mit dem Power Design der SoCs zu tun? Zumal die Galaxy Flagschiffe seit je her eine deutlich höhere Auflösungen haben als die iPhones. Klar kommt die Hardware da schneller ans Limit.

Nutz mal ein älteres Smartphone oder schwächeres Neugerät, du fragst dich an manchen Stellen ernsthaft, wie einfachste Programme so hängen können - das taten sie mit der selben Hardware vor einigen Jahren noch nicht und da kamen keine hungrigeren Funktionen hinzu.

Vor einigen Jahre wurde aber auch schon Java eingesetzt. Wie sonst, außer durch immer mehr Gimmicks, Funktionen, Extras, Animationen, Grafiken etc. innerhalb der Apps soll sich die Performance verschlechtert haben? Inzwischen haben viele Android Apps zudem mehrere Hintergrunddienste zum Synchronisieren, Senden von Metadaten usw. Die Entwickler nehmen hier einfach immer weniger Rücksicht. Man könnte fast meinen die werden von den Geräteherstellern mitfinanziert. Denn effizienter ginge das Ganze mit Sicherheit.
Will gar nicht wissen was die "Riesen" wie Facebook etc. inzwischen für Spagetti Code zusammengeschustert haben. Die Vergangenheit hat gezeigt, dass die nicht mal vor Hacks am OS zurückschrecken.

Öffne mal eine moderne Website mit einem alten Rechner. Da kannst du genauso sagen, früher konnte ich mit dem System flüssiger surfen.

 

[noxon]

Ja, ich gebe dir Recht. Solange man Programmieren als ein Paradigma gelernt hat, sollte es weitestgehend egal sein, welche Sprache man benutzt. Teilweise haben Sprachen aber auch individuelle Eigenschaften, weshalb man nicht einfach sagen kann, dass ein Java-Entwickler automatisch C++ kann.

Na dann empfehle ich mal das Buch Seven Languages in Seven Weeks - A Pragmatic Guide to Learning Programming Languages zu lesen. Heut zu Tage denkt jeder immer nur an OOP Sprachen, wenn's um Programmierung geht, dabei ist das nur ein kleiner Bereich dessen, was es dort draußen gibt.

What is the programming model? Is it object-oriented (OO), functional, procedural, or some type of hybrid? This book has languages spanning four different programming models and, sometimes, combinations of more than one. You will find a logic-based programming language (Prolog), two languages with full support for object-oriented concepts (Ruby, Scala), four languages that are functional in nature (Scala, Erlang, Clojure, Haskell), and one prototype language (Io). Several of the languages are multiparadigm languages, like Scala. Clojure’s multimethods will even let you implement your own paradigm. Learning new programming paradigms is one of the most important concepts in this book.

Ist wirklich sehr empfehlenswert und sollte man sich definitiv mal durchlesen auch wenn man die Sprachen nicht wirklich erlernen will. Zumindest ist es interessant sich die unterschiedlichen Konzepte mal zu betrachten.

 

[Wattwanderer]

IMHO wird der Aufwand beim Lernen einer Computersprache hier überschätzt.

Im wesentlich gibt es einen Pool von bekannten Techniken die jeweils anders abgemischt werden und als neue Sprache die Welt erblicken. Es dürfte für einen erfahrenen Programmierer lediglich auf ein Wochenende Syntaxstudium hinauslaufen, wie schon viele male vorher mit anderen Sprachen.

Das heisst natürlich nicht, dass er dann die Sprache virtuos beherrscht aber genug, um Resultate zu liefern. Mit der Zeit wird er immer besser oder auch nicht.

 

[GTR]

Ich würde nie freiwillig C++ einsetzen wenn es Alternativen auf dem Gebiet gibt. Es gibt aber Situationen wo es zwingend notwendig ist.

Den Code von den Spezialisten die meinen sie könnten programmieren sehe ich jeden Tag.
Die wenigsten haben was von TDD, BDD, SOLID Prinzip etc gehört. Programmierung ist in erster Linie nicht die Sprache sondern die Architektur.
Irgendein Pflichtenheft kann jeder Praktikant runter schreiben wenn nur das Ziel die Lösung ist.

Warum gibt es so viele Buffer Overflows und memory leaks in C++? Weil es möglich ist ganz einfach. Auch erfahrenen Programmierern von Microsoft passiert das.
Virtuellen Destruktor vergessen und dadurch ein Memory Leak bekommen (happy debugging)? Hab ich schon bei Senior Entwicklern gesehen.
Bei sprintf gepennt und die buffer size nicht beachtet? Gerade bei denen die meinen "man sollte C dort benutzen wo es möglich ist weil performanter" gibt es die besten Überraschungen.

C++ ist meiner Meinung nach eine veraltete Sprache und fehleranfälliger als andere Sprachen.
Allerdings muss man sagen das Sprachen wie Java schnell dazu führen das man sich überschätzt was zu grauenhaften Ergebnissen führt (Spaghetti-architektur ist da noch harmlos). Sie nimmt einen viel Denken ab und damit verführt sie schnell zu der Annahme man könnte programmieren obwohl man weit davon entfernt ist. Das ist in etwa so als würde man jeden Tag mit dem Autopilot fahren. Irgendwann kann man selber kaum noch das Steuer übernehmen.

Wenn man erfahren ist und sauber und strukturiert arbeitet kann man mit C++ gut klar kommen. In den falschen Händen ist es aber eine sehr gefährliche Sprache die man eben nicht mal eben so lernen kann.

 

[GinoBambino]

Na dann empfehle ich mal das Buch Seven Languages in Seven Weeks - A Pragmatic Guide to Learning Programming Languages zu lesen. Heut zu Tage denkt jeder immer nur an OOP Sprachen, wenn's um Programmierung geht, dabei ist das nur ein kleiner Bereich dessen, was es dort draußen gibt.



Ist wirklich sehr empfehlenswert und sollte man sich definitiv mal durchlesen auch wenn man die Sprachen nicht wirklich erlernen will. Zumindest ist es interessant sich die unterschiedlichen Konzepte mal zu betrachten.

Danke für die Empfehlung. Dieses Buch kenne ich noch nicht. Aber auch aus anderen Büchern (zum Beispiel The Pragmatic Programmer - From Journeyman to Master) weiß ich, dass Programmieren aus unterschiedlichsten Konzepten und Modellen besteht.

Das ist wirklich hochinteressant, wie es das eigene Denken beeinflusst und in neue Richtungen lenkt