heise Developer hat keine Ahnung!
-
ps: für mich ist common lisp die sprache des jahres 2016, aber die wird da gar nicht erwähnt
Ich bin Opfer einer schlechten Klasse von Lisp Interpretern.
Nachteile des Interpreters:
- keine vollständige Doku
- bei undokumentierten Objektreferenzen muss man den Typ raten
- fehleranfällige Konstrukte (if ohne progn)
- Präfix Notation ist gewöhnungsbedürftig
- Der einzigste Interpreterfehler ist Error Around Expression. Stelle unbekannt. Ohne Git wäre ich aufgeschmissen.
- Keine gute IDE ala Visual Studio bekannt
- Funktionen zur Auflistung aller Befehle sind ein Witz angesuchts fehlender Doku
- Unterstützung zur Einbindung einer Lisp Datei in einer anderen fehlt
- Unterstützung der Definition von abstrakten Datentypen fehlt
...Für mich war das eine Katastrophe.
-
Der Vergleich hinkt einfach. Die JVM bzw. Der Bytecode hat z.B. Reflektion, Managed References, GC usw. Diese Features kann aber jeder Programmierer nutzen, wenn er es braucht. Alles was der Release-Build eines C++ Programms nicht hat, und man vielleicht nachprogrammieren muss. Man kann sagen, das die JVM im Prinzip immer mit Debug Informationen läuft. Und dafür ist die Performance am Ende doch erstaunlich gut.
Wer den Energiebedarf anmeckert, sollte aber vielleicht beim Web anfangen zu protestieren, da aufgrund der JavaScript VMs die auf Milliarden Web-Clients laufen, noch ineffizienter sind als die JVM. Komisch das Java immer den Kopf hinhalten muss, wo doch heute praktisch alles auf VMs hinausläuft.
-
das kenner-der-"was auch immer" seit Jahren gerne mal kontroverse Themen gepaart mit einer oder mehreren provokativen Behauptung hier einstreuen , sich entspannt zurücklegen und das folgende Schauspiel begutachten, ist 2017 wirklich nichts mehr neues.
ansonsten, ich bin doch erstaunt wie positiv Java bewertet wird, es dürfte sich da um Leute handeln welche ganz sicher nicht mehrere Jahre im Java Umfeld gearbeitet haben, allein das header und DRI Argument zu verwenden zeigt das praktische und realitätsbezogene Java Erfahrungen fehlen dürften. Einfach mal ein IIrgendwas, ISonstigens, INochwas und IUpsDaWarJaNochWas in 120 Klassen nach implementieren und dann noch mal über header und DRI sprechen:-)
Es hat schon seine Gründe warum in so manchen neuem Projekt auf Sprachen gesetzt wird die zwar auf der JVM aufsetzten, existierende Java Frameworks und Code verwenden können, aber nicht mehr Java heißen.
Das heise keine Ahnung hat kann ich jedoch bestätigen, spätestens seit 2013 sollte jedem klar sein das wenn schon eine Sprache verwendet werden soll die auf einer VM läuft, Erlang/OTP die erste, und logische Wahl sein muss!
Und damit ich nicht nur Behauptungen aufstelle, hier meine Begründung und der Beweis (
)
https://www.youtube.com/watch?v=rRbY3TMUcgQ(Anmerkung, und dieses Intro so richtig zu verstehen empfiehlt es sich Teil eins zu vor gesehen zu haben)
-
kurze_frage schrieb:
ansonsten, ich bin doch erstaunt wie positiv Java bewertet wird, es dürfte sich da um Leute handeln welche ganz sicher nicht mehrere Jahre im Java Umfeld gearbeitet haben, allein das header und DRI Argument zu verwenden zeigt das praktische und realitätsbezogene Java Erfahrungen fehlen dürften. Einfach mal ein IIrgendwas, ISonstigens, INochwas und IUpsDaWarJaNochWas in 120 Klassen nach implementieren und dann noch mal über header und DRI sprechen:-)
Wie witzig ist das? Du behauptest nen professionalen Java Entwickler, dass dieser Entwickler realitätsbezogene Java Erfahrungen fehlen dürften!
Lehn dich mal nicht soweit aus dem Fenster.Zum dem Kritik versteh ich auch nicht, ich finde das Interface-Pflicht auch wesentlich angenehmer, als die Trennung Header und Source. Bei Design kann man darauf achten, dass die Klassen sinnvoll sind. Bei C++ kannst du nix gegen die Trennung machen außer auf eine andere Programmiersprache zu wechseln.
-
kurze_frage schrieb:
...ich bin doch erstaunt wie positiv Java bewertet wird, es dürfte sich da um Leute handeln welche ganz sicher nicht mehrere Jahre im Java Umfeld gearbeitet haben...
Ich selbst mag kein Java-Entwickler (bis auf mehrere relativ kurze Ausflüge) sein, kenne aber viele langjährige Java-Entwickler die von der Sprache überzeugt sind (jedenfalls weit mehr als solche, die sie hassen).
kurze_frage schrieb:
...DRI Argument... Einfach mal ein IIrgendwas, ISonstigens, INochwas und IUpsDaWarJaNochWas in 120 Klassen nach implementieren und dann noch mal über header und DRI sprechen:-)
Meinst du DRY (Don't repeat yourself)? Ansonsten: was heißt DRI? Und wenn du DRY meinst, solltest du reine Interfaces nicht mit Implementierungen verwechseln - Ein Interface selbst ist kein Verstoß gegen DRY.
kurze_frage schrieb:
spätestens seit 2013 sollte jedem klar sein das wenn schon eine Sprache verwendet werden soll die auf einer VM läuft, Erlang/OTP die erste, und logische Wahl sein muss!
Nimm es mir nicht übel: Aber jeder, der meint das seine Meinung die einzig wahre ist, kann man nicht ernst nehmen. Es gibt für nahezu jede Sprache und jedes Framework gute Gründe, abhängig vom Kontext.
-
Die Interface in Java sind ein Design-Element. Muss man nicht einsetzen, wenn man nicht mag. Die Headers von C/C++ sind dagegen ein rein technischer Grund aus längst vergangenen Zeiten, um die kein aktueller C++-Programmierer drum herum kommt. Der Vergleich hinkt also total und man könnte natürlich ohne Headers trotzdem weiter C++ programmieren, ohne auf sein C++-Sprachfeatures zu verzichten (wenn es endlich mal in der C++ Spezifikation angegangen würde).
-
Artchi schrieb:
Wer den Energiebedarf anmeckert, sollte aber vielleicht beim Web anfangen zu protestieren, da aufgrund der JavaScript VMs die auf Milliarden Web-Clients laufen, noch ineffizienter sind als die JVM. Komisch das Java immer den Kopf hinhalten muss, wo doch heute praktisch alles auf VMs hinausläuft.
Gut dass du JavaScript ansprichst. Auf dem Heise-Bild kann man sehen was gerade im Gange ist.
Performance? Kommt drauf an. Z.B. spielt sich Diablo2 online praktisch genauso gut wie offline (bis auf ein paar kleinere Probleme. Eines wurde sogar neulich noch gepatcht).
Man kann sich darüber wundern, dass man immer noch weitgehend kostenfrei und teilweise sogar werbefrei (den Punkt muss man aber auch relativieren (Werbebots als Spiel-/Cheathilfe (Baalruns, Enchants(Verzauberhilfen)))) Diablo2 Online spielen kann.
Die Technik hinter Diablo2 z.T. (also) Opensouce so auch hier Gemeinschaft und Geld.-> https://www.heise.de/tp/features/Teuflisches-Vergnuegen-3447532.html
(noch eine Heise Seite)- Java, Java Script??
ganz gute vergleichende Übersichtseite: http://www.infoworld.com/article/2883328/java/java-vs-nodejs-an-epic-battle-for-developer-mindshare.html
-
Naja, Diablo 2 aus Pentium 90 MHz Zeiten (oder auch mehr Mhz). Natürlich läuft das auch als JS-Implementierung auf einem aktuellen PC flott. Wird es auch mit Java/JVM, oder nicht?
Oder würde Diablo 2 in JS auch auf einem P90 spielbar laufen? Ernste Frage, da ich es nicht ausprobieren kann.
Also, warum soll die JVM schuld sein zusätzliche Atomkraftwerke zu fordern, während es JS angeblich nicht soll?
Oder kann JS mit nativen C++ mithalten? Das ist ja gerade die Diskussion, das angeblich Java so unbrauchbar sein soll, und wahrscheinlich noch für die Erderwärmung oder Fukushima verantwortlich ist (würden ja manche am liebsten so auslegen).Mich wundert die Diskussion nur, weil bis auf wenige Komponenten heute, alles in Bytecode auf einer VM läuft. Sei es JavaScript/EcmaScript, Java, C#, PHP, Lua usw. Nur wusste ich nicht, das die alle so schnell laufen wie natives C++ und nur Java langsamer ist.
Ich wette, das 90% der Consumer-Anwendungen (vorranging das interaktive Web, Smartphone-Apps und Game-Scripts) auf Bytecode laufen. Und komisch das immer mehr dieser VMs weiter optimiert werden können? Das können sie nur, weil sie noch weit weg vom nativen Code sind.
-
Artchi schrieb:
Naja, Diablo 2 aus Pentium 90 MHz Zeiten (oder auch mehr Mhz). Natürlich läuft das auch als JS-Implementierung auf einem aktuellen PC flott. Wird es auch mit Java/JVM, oder nicht?
Oder würde Diablo 2 in JS auch auf einem P90 spielbar laufen? Ernste Frage, da ich es nicht ausprobieren kann.
Diablo2 nutzt eine Javascriptengine zur Spielsteuerung (Figursteuerung, Items usw.), die Js-Engine selbst ist in C++.
Hier auf dieser Internetseite ist eine Javascriptversion von Diablo: http://mitallast.github.io/diablo-js/
Was ich meinte, ist, dass Diablo2 trotz der eingebauten Scriptengine und der Internetverbindung performant läuft, flexibel konfigurierbar ist usw. und das Javascript hier eine (über viele Jahre) sehr gute Figur macht.
Das Wort "ineffizent" passt hier einfach nicht.
-
Und? Das gleiche ist auch mit Java möglich in mind. gleicher Performance. Was ist somit an der JVM ineffizienter?
Das ist doch gerade das absurde an der Kritik die man an der JVM führt: sie kann mind. das gleiche wie die anderen Bytecode-VMs leisten, aber es wird immer auf sie drauf gekloppt, während die anderen gefeiert werden...
-
Artchi schrieb:
Und? Das gleiche ist auch mit Java möglich in mind. gleicher Performance. Was ist somit an der JVM ineffizienter?
Das ist doch gerade das absurde an der Kritik die man an der JVM führt: sie kann mind. das gleiche wie die anderen Bytecode-VMs leisten, aber es wird immer auf sie drauf gekloppt, während die anderen gefeiert werden...Lies mal JEP 295 http://openjdk.java.net/jeps/295 die Motivation, wenn das wirklich so stimmt, ist das ineffzient. Btw ich hab nix vom AOT Compiler gewusst, bist du es sagstes xD
-
ich bin doch erstaunt wie hier gleich Leute auf meine 'kenner-der-"was auch immer"' Imitation anspringen, die similies im Post wurden wohl geflissentlich übersehen, ... nur um los prügeln zu können? Naja, ...
kein Wunder das es Leute gibt die das kenner-der-"was auch immer" schon fast professionell betreiben und sich amüsiert mit Pocorn in der Hand zurück lehnen wenn hier auf kleinst Provokationen schon so die Post abgeht.
PS: und erlang the movie teil 2 ist großartig und erzählt die Wahrheit
-
Also ich klopp nur auf Java drauf, weil ich die Sprache übelst finde, nicht auf der JVM. Und ich bekrittle das Fehlen des einen Features was sie halt nicht kann, nämlich Value Types. Und dann natürlich "echte" Generics und dichte Arrays aus diesen Value Types dazu - wobei man das vermutlich sogar "as if" über den JITer lösen könnte, wenn man die Value Types einfach über Immutable Types umsetzt.
-
http://www.ffconsultancy.com/languages/ray_tracer/comparison.html
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/haskell-beats-C.pdf
https://justindomke.wordpress.com/2009/02/23/the-stalin-compiler/
Okeh das war alles :3
