heise Developer hat keine Ahnung!



  • Soweit ich weiß verfasst Heise Developer die Artikel bewusst so, dass viele Trolle anschlagen. 😋



  • naja ich hatte jetzt nicht den eindruck, dass man mit dem artikel bewusst etwas falsches mitteilen wollte. immerhin war man bei oracle so schlau dafür zu sorgen, dass man als informatiker bei mir an der fh als erstes klickibunti mit java lernt, sodass mir das mit der beliebtheit nicht falsch vorkommt, und das gerede über die angebliche flexibilität ist ja auch nichts neues.

    jedenfalls bin ich der meinung, dass eine angenommene prozessorleistung von 1W für die virtuelle maschine gegenüber hocheffezientem c-code bei 1 mrd geräten ungefähr 1GW ausmacht und das ist imho ein überflüssiges atomkraftwerk oder meinetwegen auch ein überflüssiger offshore-windpark.

    ps: für mich ist common lisp die sprache des jahres 2016, aber die wird da gar nicht erwähnt. 🙄



  • HansKlaus schrieb:

    ...immerhin war man bei oracle so schlau dafür zu sorgen, dass man als informatiker bei mir an der fh als erstes klickibunti mit java lernt,...

    Die Sprachauswahl im Studium wird in der Regel nicht durch den Hersteller vorgegeben. Bei einigen Unis ist sie sogar Dozentenabhängig, die Vorgabe ist dort nicht die Sprache sondern ein thematischer Schwerpunkt (z.B. Prozedurale Programmierung, Objektorientierte Programmierung, Skriptprogrammierung...). Die Sprachauswahl fällt in dem Fall unter "Freiheit in Forschung und Lehre".

    Und als der Java-Hype begann hatten viele Studiengänge noch kein Java angeboten.

    HansKlaus schrieb:

    ...jedenfalls bin ich der meinung, dass eine angenommene prozessorleistung von 1W für die virtuelle maschine gegenüber hocheffezientem c-code bei 1 mrd geräten ungefähr 1GW ausmacht und das ist imho ein überflüssiges atomkraftwerk oder meinetwegen auch ein überflüssiger offshore-windpark.

    Das mag ja alles stimmen, nur wählt man die Sprache in der Regel nicht nach Energieeffizienz, sondern nach anderen Kritierien wie der Zielplattform, der Entwicklungszeit bezogen auf ein Projekt, den verfügbaren Programmierern...



  • asc schrieb:

    Die Sprachauswahl im Studium wird in der Regel nicht durch den Hersteller vorgegeben. Bei einigen Unis ist sie sogar Dozentenabhängig, die Vorgabe ist dort nicht die Sprache sondern ein thematischer Schwerpunkt (z.B. Prozedurale Programmierung, Objektorientierte Programmierung, Skriptprogrammierung...). Die Sprachauswahl fällt in dem Fall unter "Freiheit in Forschung und Lehre".

    also bei uns fällt sie glaub ich eher unter "die zukünftigen arbeitgeber = geldgeber wollen das so". das ist aber auch "nur" eine fachhochschule.

    Und als der Java-Hype begann hatten viele Studiengänge noch kein Java angeboten.

    naja man muss ja auch erstmal "hypen". ich will ja auch gar nicht abstreiten, dass das programmieren einfach wird, wenn nicht mehr zwischen objekt->funktion() und objekt.funktion() unterschieden werden muss, oder man nicht für jedes popelige gerät einen extra compiler programmieren muss, aber...

    Das mag ja alles stimmen, nur wählt man die Sprache in der Regel nicht nach Energieeffizienz, sondern nach anderen Kritierien wie der Zielplattform, der Entwicklungszeit bezogen auf ein Projekt, den verfügbaren Programmierern...

    ...genau das geht mir eigentlich ziemlich auf den sack!


  • Mod

    Ich weiß noch in etwa, wie es losging. Java war Hoffnung. An den Unis gab es bald mehr oder weniger aber in der Summe doch viel/umfangreiches Einführungsmaterial von bekannten "Quellen".

    Man muss folgende Entwicklung vor Augen haben: WWW, Html, Linux, Telefone, Prozessoren und Server - und auch Emulatoren und Haushaltsgeräte.

    (man könnte noch fragen, was kann oder was ist an Java besser als Basic?)
    (bei Basic war die Emu-Szene noch nicht so groß? , kein Internet? keine Handys?)

    Der entscheidende Punkt war dann, bzw. ist irgendwie: Viel Liebe.

    Insofern passt ja der Spruch "beliebteste" Programmiersprache.
    Und insofern passt es dazu, dass die "Begründungen"..etwas daneben. 😉



  • HansKlaus schrieb:

    asc schrieb:

    Die Sprachauswahl im Studium wird in der Regel nicht durch den Hersteller vorgegeben...

    also bei uns fällt sie glaub ich eher unter "die zukünftigen arbeitgeber = geldgeber wollen das so". das ist aber auch "nur" eine fachhochschule.

    Was ist daran so verkehrt wenn mehrere Sprachen möglich sind und eine davon potentiellen Arbeitgebern zusagt? Java ist nicht per se schlecht, undabhängig was hier einige im Thread sagen, hat eine sehr breite Unterstützung (Tools, Bibliotheken, sogar darauf angepasste Prozessoren...) kann für nahezu alles genutzt werden und hat in den letzten Jahren durchaus an Performance zugelegt (und zwar jenseits von der Prozessorentwicklung).

    Nein, die Sprache ist nicht das Optimum für alles, aber eben nicht schlecht weil manche sie nicht mögen (ich ziehe im direkten Vergleich vieler ähnlicher Anforderungen C# vor, würde mich Java aber auch nicht verweigern). Ich glaube auch nicht das die Energiemehrkosten noch immer so viel ausmachen da Java, soviel ich weiß, inzwischen auch auf einen JIT setzt - sprich der Code wird beim ersten Aufruf compiliert und jeder weitere Aufruf nutzt das Compilat. Dadurch kann Javacode sogar in der Theorie (ob es in der Praxis abseits weniger Einsatzfälle relevant ist steht auf einen anderen Blatt) bei einem langen Lauf schneller sein als eine C-Programm, die nicht für einen spezifischen Prozessor übersetzt wird (da es auf genau die Zielplattform hin optimiert werden kann).

    Und nochmals: Nein, ich bin kein Java-Fan. Aber es gibt nicht DIE Sprache, DIE Anforderung. Und Java hat zumindest einen Vorteil: Es ist sehr portabel (auch wenn hier einige etwas anderes sagen kenne ich Java-Entwickler die damit noch nie ein Problem hatten - liegt vielleicht auch an den verwendeten Bibliotheken oder Befehlen) und kann viele Bereiche abgecken wenn RAM und absolute Performance nicht das Hauptargument sind.



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


  • Mod

    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.


  • Mod

    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.




Anmelden zum Antworten