News Android: Kotlin und Swift als Java-Alternative gehandelt

[mensch183]

Und sage ich als Informatik Student. Der größte Fehler von C++ im Design ist die abwärtskompatiblität zu ANSI C.

... die gar nicht vorhanden ist.

 

[Autokiller677]

CPython.

Ja, der Standard Python Interpreter. Und jetzt? Trotzdem ist Python damit nicht wirklich performant, z.B. bei Schleifen. Wenn kann man versuchen mit Cython oder so noch was zu reißen. Aber die Probleme mit DLL's und c_types bleiben trotzdem.

 

[L0g4n]

... die gar nicht vorhanden ist.

Klugscheißen ist natürlich immer was feines. Dann eben die Kompatiblität zu C90 bzw. zu C99. Lässt sich ja nicht so einfach sagen, da C++ nicht zum "Neusten" C kompatibel ist aber kleine Teile immer übernommen werden, jetzt glücklich ?

 

[character]

(oder C# oder was auch immer, aber halt nicht so einen unperfomanten Kram wie Java oder Python...)

C# und Java sind sich sehr ähnlich, sowohl was Funktionsweise als auch was Performance angeht. Abgesehen davon verwendet Google ja nicht mal die normale JVM für Android.

 

[TheShaft]

Apples Programmiersprache ist objektorientiert und gilt als vergleichsweise einfach. Durch die Quelloffenheit passt die Sprache zudem zu Googles Android-Konzept.

Was ist denn das für ein Argument ? Java ist objektorientiert, gilt auch als vergleichsweise einfach und ist quelloffen (nicht ohne Grund wird das an jeder Uni gelehrt).

 

[G00fY]

D.h. ein Smartphone mit (vergleichsweise) lahmen Chips und immer begrenzten Energieressourcen ist somit eigentlich das Paradebeispiel für eine C++ Anwendung (oder C# oder was auch immer, aber halt nicht so einen unperfomanten Kram wie Java oder Python...)

Sorry aber das ist unsinnig. Java grundsätzlich als "lahm" abzustempeln zeugt nicht gerade von Fachwissen. Und Android ist eher ein Paradebeispiel für Bytecode-Sprachen. Es läuft eben auf unterschiedlichen Architekturen, was einer der Gründe ist warum Android so erfolgreich ist. Aussagen wie "müsste dringend näher an die Hardware" deuten eher darauf hin, dass dir das nicht bewusst ist.
Was GinoBambino zudem meinte, werden eher Grafikberechnungen, oder komplexe Algorithmen sein. Google selbst sagt:

As a developer, you need to balance its benefits against its drawbacks. Notably, using native code on Android generally does not result in a noticable performance improvement, but it always increases your app complexity.
[...]
Typically, good use cases for the NDK are CPU-intensive applications such as game engines, signal processing, and physics simulation.

Hierfür machts Sinn auf andere Sprachen zurückzugreifen die low-level Implementierungen ermöglichen. Aber zeig mir abseits von 3D Spielen, VR Apps o.ä, mal Anwendungsfälle wo das wirklich Sinn macht?
Ich behaupte mal der Großteil der Apps auf einem Smartphone kommunizieren mit einem Webserver und visualisieren die Daten. Dafür gibts mächtige Libraries in Java (Volley, Retrofit), die ihre Arbeit sehr gut und schnell machen.

 

[Autokiller677]

Sorry aber das ist unsinnig. Java grundsätzlich als "lahm" abzustempeln zeugt nicht gerade von Fachwissen. Und Android ist eher ein Paradebeispiel für Bytecode-Sprachen. Es läuft eben auf unterschiedlichen Architekturen, was einer der Gründe ist warum Android so erfolgreich ist. Aussagen wie "müsste dringend näher an die Hardware" deuten eher darauf hin, dass dir das nicht bewusst ist.

Klar erfordert es mehr Arbeit, näher an die Hardware zu gehen. Dafür ist das Ergebnis dann besser. Java ist nicht immer und überall lahm, klar. Python oder PHP auch nicht. Trotzdem halte ich die Idee, ein halbes OS auf Java aufzubauen für bescheuert.

 

[L0g4n]

Hättest ja auch auf den zweiten Part von G00fYs Post eingehen können und nicht wieder nur den gleichen Punkt nochmal zu bringen. Diesen Aspekt vergisst du nämlich immer wieder.

 

[Limit]

Android müsste dringend näher an die Hardware, aber das ist im Grunde schon immer so. Seit Jahren zeigt Apple, dass man bei guter Optimierung mit Single und Dualcores problemlos schaffen kann, was bei lahmen Java unter Android gleich einen Quad und ein paar GB Ram braucht.

Das ist größtenteils Unsinn. Apps, die viel Leistung brauchen greifen auch unter Android schon lange auf native C/C++ Bibliotheken zurück. Außerdem solltest du beachten, dass Apples A-SoCs trotz weniger Kernen häufig die gleiche oder sogar mehr Leistung haben als die gängigen High-End SoCs, die bei Android-Geräten eingesetzt werden. Beim Speicherverbrauch haben native Apps sicherlich ein paar Vorteile, aber Googles JVM ist da mittlerweile auch nicht mehr so viel schlechter.

Aber "mal eben" stellt man ein ganzes OS halt nicht um.

Wozu das OS umstellen. Android basiert auf einem modifizierten Linux-Kernel, auf dem prinzipiell gewöhnliche Linux-Software lauffähig wäre, wenn du die entsprechende Libs aufs Smartphone kopierst und die Konfiguration anpasst.

D.h. ein Smartphone mit (vergleichsweise) lahmen Chips und immer begrenzten Energieressourcen ist somit eigentlich das Paradebeispiel für eine C++ Anwendung (oder C# oder was auch immer, aber halt nicht so einen unperfomanten Kram wie Java oder Python...)

Wären die Smartphones noch mit 16-Bit CPU mit 20Mhz und 1MB RAM unterwegs, würde ich dir da zustimmen. Bei Octacores mit 2.5GHz und 4GB RAM zieht das hingegen nicht mehr.
C# ist nicht grundlegend schneller als Java und selbst Python kann man in viele auf deutlich höhere Geschwindigkeit bringen, wenn man die Performancekritischen Funktion mit Cython optimiert oder gleich PyPy einsetzt, z.B.
IRR-Berechnung (100k Durchläufe): CPython 10s, Cython mit Annotation 2.8s, PyPy 1.2s, C++ 0.96s

C++ ist für einen ernsthaften Programmierer kein Problem. Und die ganzen Taschenlampen-, Furz- und Schrottapps - naja, auch wenn es die nicht mehr gibt wird keiner verzweifeln.
Von der Performance her würde es Android sicher gut tun.

Es geht weniger darum, ob man es mit C++ machen könnte, denn das kann man definitiv. Die Frage ist eher, ob man es will. Google hat sich damals nicht ohne Grund gegen C++ entschieden, obwohl es die offensichtlich Wahl gewesen wäre.

Trotzdem halte ich die Idee, ein halbes OS auf Java aufzubauen für bescheuert.

Das OS ist komplett in C/C++. Einzig Apps laufen in der JVM und selbst die nicht immer vollständig.

 

[karamba]

Wenn Microsoft schnell mitzieht und auch auf Swift baut dann wäre die App-Problematik relativ schnell gelöst.

Was soll da genau gelöst werden? Nur weil man dann die gleiche Sprache nutzen würde, wäre das Ökosystem und das Framework doch trotzdem völlig unterschiedlich. Am Entwicklungsaufwand würde sich dementsprechend nicht viel ändern.

Und C/C++ als Sprache? Wieso sollte man? Besonders elegant ist C Code nun nicht.

Ergänzung (9. April 2016)

Klar erfordert es mehr Arbeit, näher an die Hardware zu gehen. Dafür ist das Ergebnis dann besser. Java ist nicht immer und überall lahm, klar. Python oder PHP auch nicht. Trotzdem halte ich die Idee, ein halbes OS auf Java aufzubauen für bescheuert.

Mal ganz davon abgesehen, dass die Apps und das Framework in Java geschrieben sind und nicht das OS, was meinst du, wer bezahlt die Mehrarbeit? App Entwicklung ist bereits sehr teuer durch die verschiedenen zu bedienenden Ökosysteme. Meinst du, für ein bißchen Mehrperformance, die man dank sowieso völlig übertriebener Smartphonehardware sowieso nicht merken würde, würde jemand mehr Geld ausgeben? Vielleicht in einem Elfenbeinturm, aber nicht in der Realität.

 

[Vider]

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

 

[GinoBambino]

Nun ja, wenn man sein Leben lang nur Java genutzt hat und gewisse Konzepte und Grundlagen nicht gelernt hat, gebe ich dir recht. So jemand kommt in C++ und anderen Sprachen weit weniger zurecht. Wer jedoch Grundlagen der Programmierung gelernt hat, kommt mit jeder Sprache nach gewisser Zeit zurecht.

Die Probleme mit C++ entstehen eher, weil viele sich nicht mit gewissen Grundlagen beschäftigen, dazu eben Speicherverwaltung und den damit verbundenen Pointern. Ebenso anderen Punkten.

Das ändert aber nichts daran, dass gewisse "Komfortfunktionen" und "syntaktischer Zucker" - die man primär aus Hochsprachen kennt - durchaus auch in "tieferen" Sprachen möglich sind. Siehe D. Ich wechsel im übrigen nun zu "Interpreter-" und "Compilersprache". Interpretersprachen sind dabei Java, C# und Co, also dass was einige hier als Hochsprache bezeichnen. Compilersprachen dagegen sind C, C++ und eben das von mir erwähnte D.

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. Andersherum ist es auch nur bedingt wahr. Ein C++-Entwickler kann zwar eine funktionsfähiges Java-Programm schreiben, wird aber deshalb nicht zwangsläufig angemessenen Code schreiben.

Ich kenne nicht den aktuellen Feature-Umfang von C++. Gibt es dort auch mittlerweile Generics, Lambda Expressions, Objektinitialisierer usw?

Ich habe nicht ganz verstanden, wie du darauf kommst, C# als Interpretersprache zu bezeichnen. Nur weil es zur Laufzeit in Maschinencode kompiliert wird, ist es doch keine interpretierte Sprache.

Ergänzung (10. April 2016)

@Teralios: Stimme dir in allen Punkten zu. Aber für Leute, die kein Informatik Studium genießen durften sind Sprachen wie Java ein einfacherer Einstieg. Und du schreibst selber "weil viele sich nicht mit gewissen Grundlagen beschäftigen, dazu eben Speicherverwaltung und den damit verbundenen Pointern". Um diese Punkte zu verstehen und richtig zu machen, braucht es eben ein gutes Verständnis und man opfert viel Hirnschmalz um keine Fehler zu machen, anstatt an der eigentliche Problemlösung zu schreiben. Swift geht ja noch weiter als Java, und abstrahiert größere Teile, bzw. nähert sich Skriptsprachen. Letztendlich möchte ich mich als Entwickler einer App idR. nicht um das Speichermanagement kümmern.

(

Das ist eine legitime Ansicht. Eric Lippert hat mal in einem seiner sehr guten Blog-Artikel geschrieben, dass Speichermanagement ein "Implementation Detail" ist, für das man sich als Entwickler nicht interessieren sollte (man kann sich ja durchaus vorstellen, dass eine Software ohne das typische Stack/Heap-Memory Model arbeitet).

Dass Java langsam sei, höre ich teilweise noch von erfahrenen Entwicklern (bin in einer Firma, die ausschließlich .NET macht). Ich bin dann derjenige, der Java verteidigt. Im Gegensatz zu C++-Programmen, die im Voraus kompiliert werden, erlaubt es JIT-Kompilierung, Optimierungen zu machen. C++-Programme mögen zwar in bestimmten Szenarien schneller sein, aber für den Großteil von Geschäftsanwendungen, Apps usw. ist Java schnell genug.

Außerdem ist Leistung/Hardware billig und steigt kontinuerlich, während Personalkosten sehr teuer sind. Es ist also günstiger, eine etwas langsamere Sprache zu nehmen, die eine höhere Produktivität gegenüber einer schnelleren Sprache erlaubt. Auch das ist ein klares Argument für Java.

Ergänzung (10. April 2016)

Hört hört, hier spricht der Experte. Ich verdiene mit C# und C meine Brötchen. Wer denkt, der GC macht alles, hat einfach keine Ahnung. Insbesondere wenn man auf Performance achtet kommt man um unmanaged code nicht immer rum. Bei C++ muss man sich halt um alles selber kümmern, das hat seine Vor- und Nachteile. Übrigens finde ich Python deutlich eleganter als Java, ist aber nur meine Meinung.



CPython.

Dann würde ich gerne wissen, für welche Szenarien du unmanaged Code benutzen musst? Mir fallen keine ein, außer vielleicht für Interoperabilitätszwecke.

Und erklär mir bitte, welchen Einfluss du als C#-Programmierer auf das Speichermanagement hast. Solange man keine unmanaged Ressourcen benutzt, braucht man sich rein gar nicht um das Speichermanagement kümmern. Der Garbage Collector macht bereits einen sehr guten Job.

Was syntaktische Unterschiede angeht, magst du völlig Recht haben. Genau aus diesem Grund bevorzuge ich seit jeher die .NET-Plattform. Auch heute noch bietet C# mehr Features gegenüber Java. Aber vor allem bis vor einigen Jahren war es sehr überlegen (als Java noch keine Lambda Expressions kannte).

 

[luke8800gts]

Wie alle bin auch ich nicht der Experte, aber ich habe einige Erfahung mit c++ und Java. Beide Sprachen haben ihre spezielles Einsatzgebiet, von welchem sie auch nicht weckzudenken wärern. C++ für hardwarenahe Programmierung (ohne Pointer undenkbar), Java für Apps (da einfach produktiver, viel mehr Funktionalität). Zur Behauptung "wer c++ programmiern kann, der kann auch Java", kann ich nur Nein sagen. Um wirklich gutes Java zu schreiben, muss schon ein bisschen mehr wissen.
Einer der wichtigsten Aspekte, warum Java und nicht c++ für Apps zum Einsatz kommt, ist einfach der Security Aspekt. Bei c++ kann man gleich so richtig viel falsch machen! Man nehme mal nur die Pointer. Bei Java wird da einem viel abgenommen.

 

[GinoBambino]

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.

Ja, aber die Dalvik VM ist doch konzeptuell sehr ähnlich zu der JVM.

Ich höre das jetzt zum ersten Mal, dass die Dalvik VM ersetzt worden ist. Der Wikipedia-Eintrag widerspricht sich ein wenig mit deiner Aussage. Unter Version 5.0 werden Programme nicht nativ kompiliert (d.h. in Maschinencode übersetzt), sondern sie werden es während der Installation kompiliert. Das ist also näher verwandt zu der Just-In-Time-Kompilierung von Java als zu der Kompilation von C/C++.

 

[L0g4n]

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) .

 

[nille02]

tl;dr

Ich finde es schade das Google nicht mal ihre eigene Sprache, GoLang, etwas prominenter einbindet. Man kann noch immer nicht alle APIs, besonders FileAPIs, mit GoLang unter Android nutzen.

 

[Grundkurs]

Ich kenne nicht den aktuellen Feature-Umfang von C++. Gibt es dort auch mittlerweile Generics, Lambda Expressions, Objektinitialisierer usw?

Generics nennen sich in C++ "Templates" und die gehören zu den älteren Features der Sprache, damit meine ich seit den 80er Jahren. Falls du mit Objektinitialisierer Konstruktoren meinst, die gibt es seit es die Sprache gibt. Lambda Expressions werden seit C++11 unterstützt.
Viele reden hier über das Problem mit Speichermanagement. Die Probleme damit wurden mit Smart-Pointern zu großen Teilen gelöst, die Lebensdauer eines Objekts sollte mittlerweile kein so großes Thema mehr sein. Wenn man meint sich mit nackten Pointern in den Fuß schießen zu müssen, ist das eher das Problem des Programmierers, nicht ein Problem mit der Sprache.

C++ ist trotzdem immer noch relativ komplex, die Lernkurve höher als bei den meisten anderen Sprachen.
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.

 

[harrysun]

Swift wäre ein kluger Schritt und würde die Mobile Entwicklung um einen wesentlichen Schritt beschleunigen und damit günstiger machen.

Andere Unterstützer von Swift sind schon weiter: http://www.infoq.com/articles/Ibm-swift

 

[mensch183]

Klugscheißen ist natürlich immer was feines. Dann eben die Kompatiblität zu C90 bzw. zu C99.

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

 

[Wattwanderer]

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

Diese Liste scheint alles andere als eine Stimme FÜR Java zu sein?

Weiss nicht was die einzelnen Benchmarks testen oder was mit "gz" gemeint ist aber wenn ich den Rest hoffentlich richtig zusammenreime bedeutet es unter dem Strich:

- in Sonderfällen kann Java 10% schneller sein als C
- üblicherweise zwischen 1,5 bis 4 mal langsamer
- braucht 3 bis 40 mal mehr RAM
- braucht 1,2 bis 5 mal mehr CPU Zyklen

Ein Vorurteil entsteht ja leider nicht ohne Grund. Man stolpert über eine überraschend zäh laufende Anwendung und wundert sich, dass heutzutage immer noch Programme gibt die Probleme mit Performance haben obwohl die PCs normalerweise total überdimensioniert sind.
Irgendwann findet man heraus, dass Java beteiligt ist und denkt sich das muss wohl der Grund dafür sein.

Mir schwante, dass Java Probleme hat aber, dass sie so groß wie auf dieser Liste zu sehen ist hätte ich nie geahnt.

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.