1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Ehemalige Sun-Projekte: Open…
  6. Th…

Anmerkung zu Java

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


  1. Re: Anmerkung zu Java

    Autor: zilti 03.01.17 - 00:56

    pythoneer schrieb:
    --------------------------------------------------------------------------------
    > "Use of the Commercial Features for any commercial or production
    > purpose requires a separate license from Oracle."

    Nochmal...

    > "Use of the Commercial Features"

    Das normale Oracle JDK und auch das normale Oracle JRE (ohne Zusatzbezeichnung) enthält keine "Commercial Features".

  2. Re: Anmerkung zu Java

    Autor: Hello_World 03.01.17 - 01:07

    zilti schrieb:
    --------------------------------------------------------------------------------
    > Ich habe auch eine Weile mit Scala gearbeitet, mein Fazit ist aber:
    > gottseidank nicht mehr! Scala ist ein Durcheinander.
    Sehe ich nicht so.

    > Ein
    > Turingvollständiges Typsystem,
    Ist das Java-Typsystem auch:
    https://arxiv.org/abs/1605.05274
    Erklärst Du jetzt noch, warum das ein Problem ist? Ich sehe jedenfalls, dass das Scala-Typsystem Sachen ermöglicht, von denen Java nur träumen kann. Eine Bibliothek wie z. B. shapeless ist in java schlichtweg nicht möglich.

    > x Arten die Syntax zu schreiben,
    Ist ein Witz, oder? Nur mal ein paar Fragen zur Java-Syntax:
    - warum braucht man ?: *und* if/else? Dass die Unterscheidung von Statements und Expressions Blödsinn ist, ist seit Anno '58 (Lisp) bekannt.
    - und wenn man sich schon darauf einlässt, wieso gibt es kein Expression-Äquivalent für das switch-Statement?
    - wozu zum Geier braucht man Operatoren wie ++ und --?
    - Warum bedeutet == mal Referenzgleichheit und mal Wertgleichheit (bei primitiven Typen)?
    - Warum kann man ein Array als int foo[] oder int[] foo deklarieren?
    - Warum gibt es überhaupt spezielle Syntax für Arrays?
    - Warum gibt es spezielle Syntax für die sog. primitiven Typen?

    Und jetzt kommst Du und regst dich auf, dass bei x.foo({a => b}) ein Klammerpaar weglassen kann.

    Ganz ehrlich: wenn Du Ahnung von Scala hättest, würdest Du Dich nicht über solche albernen Oberflächlichkeiten aufregen. Es gibt nämlich auch bei Scala genug zu meckern. Hier meckert jemand, der Ahnung hat:
    https://www.youtube.com/watch?v=hzf3hTUKk8U
    Nur: dieses Gemecker ist quasi wie das Gemecker, dass das Auto immer noch nicht fliegt, während die Java-Welt Tretroller fährt.

    > und jede
    > Furz-Library bringt irgend eine vermurkste DSL mit.
    Also wenn Leute schlechte Bibliotheken schreiben, ist die Sprache daran Schuld?

  3. Re: Anmerkung zu Java

    Autor: Hello_World 03.01.17 - 01:15

    Trockenobst schrieb:
    --------------------------------------------------------------------------------
    > Nicht wirklich, wenn man die Software gut aufteilt. Da gibt es sich nichts
    > zu C# oder C++. Man muss da natürlich einen Plan haben.
    Go würde ich mit der Kneifzange nicht anfassen. Generics wurden mit ML Anno
    '73 eingeführt, und Go verweigert sich bis heute. Wie kann man damit freiweillig
    arbeiten?

    > Java 9 wird ja gerade diskutiert, während in meinen Großprojekten in zwei
    > Konzernen Tools aktiv sind, die alle Java 8 Neuerungen abgefangen werden.
    > Man soll also Java 7 für mindestens noch 2-3 Jahre fahren. Java ist hier
    > das neue Cobol und so wird es auch behandelt, mit Nachdruck.
    WTF, im Ernst?! Java 7 ist seit mehr als anderthalb Jahren EOL. Das sagt ja
    einiges aus über die Java-Community…

  4. Re: Anmerkung zu Java

    Autor: Trockenobst 03.01.17 - 03:03

    Hello_World schrieb:
    --------------------------------------------------------------------------------
    > Go würde ich mit der Kneifzange nicht anfassen. Generics wurden mit ML
    > Anno '73 eingeführt, und Go verweigert sich bis heute. Wie kann man damit
    > freiweillig arbeiten?

    https://appliedgo.net/generics/

    Da ist eigentlich alles gesagt. Bei komischen Java-Generics Wahnsinn wie:
    List<Dictionary<string<IEnumerable<HttpRequest>>>>

    Ist schon irgendwas in der API falsch designt - oder die Sprache erzwingt sowas.
    Mit map und list vermisse ich eigentlich gar nichts "Generic" in Go, aber vielleicht sind meine Projekte nicht groß genug.

    Go macht Dinge anders, und "ideomatic Go" ist eben genauso anders wie Scala nicht Java ist und man sich auf die Denkweise einlassen muss damit die Sprache wirklich ihre Wirkung entfaltet.

    > WTF, im Ernst?! Java 7 ist seit mehr als anderthalb Jahren EOL. Das sagt ja
    > einiges aus über die Java-Community…

    Java ist schon länger am verwesen. Die Hälfte der Klassen von apache.org die wir nutzen sind praktisch Feature-Complete seit ca. 4-8(!) Jahren. Die fasst niemand mehr an und passt sie an die neue JVM 8,9 Welt an, da werden nur noch Bugs gefixt.

    Genau aus dem Grund lieber Scala und Go.

  5. Re: Anmerkung zu Java

    Autor: Das Osterschnabeltier 03.01.17 - 03:59

    Trockenobst schrieb:
    --------------------------------------------------------------------------------
    > Hello_World schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Go würde ich mit der Kneifzange nicht anfassen. Generics wurden mit ML
    > > Anno '73 eingeführt, und Go verweigert sich bis heute. Wie kann man
    > damit
    > > freiweillig arbeiten?
    >
    > appliedgo.net
    >
    > Da ist eigentlich alles gesagt. Bei komischen Java-Generics Wahnsinn wie:
    > List<Dictionary<string<IEnumerable<HttpRequest>>>>

    YMMD.
    Dir ist schon klar, dass "Java Generics" eigentlich aus C# sind? xD

    Btw. du kannst auch einfach Raw Types verwenden, wenn dir das so lieb ist. Wer braucht schon Statische Überprüfung. Dynamische Programmiersprachen sind die Zukunft!

  6. Re: Anmerkung zu Java

    Autor: amie 03.01.17 - 08:02

    100%ACK

  7. Re: Anmerkung zu Java

    Autor: tha_specializt 03.01.17 - 11:16

    ... du hast nicht ernsthaft gedacht dass Millionen von Entwicklern, die die JDK für die Erstellung kommerzieller Software nutzen Lizenzen auf alltäglicher Basis verletzen, oder?

    Lol ... Wer denken kann is klar im Vorteil aber bei "Pythoneern" muss man das glaube ich nicht so wirklich erwarten ;)



    1 mal bearbeitet, zuletzt am 03.01.17 11:16 durch tha_specializt.

  8. Re: Anmerkung zu Java

    Autor: Anonymer Nutzer 03.01.17 - 11:22

    > Wenn man keine Argumente hat, wirft man mit Wörtern wie [...] Scheiß-Sprache,
    > Scheiß-Typsystem, Scheiß-Tools, Scheiß-Kultur [...] um sich.

    So viel dazu.

  9. Re: Anmerkung zu Java

    Autor: derats 03.01.17 - 20:58

    Wer empfiehlt hier eigentlich immer JavaFX, das Zeug ist purer Krebs. Dann doch lieber irgendeine JS-Mumpitz-Lösung ala Electron oder CEF mit einem Java-Service im Hintergrund, wenn letzterer denn wirklich unbedingt sein muss.

  10. Re: Anmerkung zu Java

    Autor: flAming_Ace 03.01.17 - 21:17

    Java wurde bei heise zur Sprache des Jahres gewählt:

    http://m.heise.de/developer/meldung/Programmiersprache-des-Jahres-ist-Java-3583597.html

    Von verwesen kann keine Rede sein, da gerade mit Java 8 funktionale Elemente hinzukamen..

  11. Re: Anmerkung zu Java

    Autor: Hello_World 03.01.17 - 22:26

    Trockenobst schrieb:
    --------------------------------------------------------------------------------
    > https://appliedgo.net/generics/
    Mir sind die Pseudoargumente der Go-Fanboys durchaus bekannt. Nur leider sind sie ausnahmslos Unfug.
    Punkt 1, Performance:
    Russ Cox' Analyse ist für die gängigen Sprachimplementierungen zunächst einmal korrekt: Man boxed (z. B. Java) das führt zu Laufzeitoverhead, oder man spezialisiert (z. B. C++), das macht den Compiler langsamer. Nur leider verschwindet die Notwendigkeit für generischen Code nicht einfach so, nur weil man eine Sprache ohne Unterstützung dafür einsetzt. Das führt dann zu Code, der mit einem Top-Typ arbeitet (z. B. Object in Java 1.4, interface{} in Go) und damit exakt den gleichen Laufzeit-Overhead aufweist wie Generics mit Boxing, nur dass er darüber hinaus auch nicht typsicher ist. Oder zu manueller Codevervielfältigung, die den Compiler genauso ausbremst wie die Template-Instanziierung in C++ und darüber hinaus absolut unwartbar ist.
    Generics wegzulassen löst also kein einziges Problem, schafft aber die oben genannten.

    Punkt 2, Komplexität:
    List<Dictionary<string<IEnumerable<HttpRequest>>>>
    Offensichtlich ein Fantasiekonstrukt, schließlich ist string kein generischer Typ. Aber selbst wenn's kein an den Haaren herbeigezogener Strohmann wäre: solche Typen sind kein Problem, sondern das Symptom eines Problems. In einer Sprache ohne Generics, beispielsweise Java 1.4, wäre das eben einfach ein Objekt vom Typ List. Ändert sich dadurch irgendwas an den Inhalten der Liste? Nein, natürlich nicht, die Komplexität ist nach wie vor da, der Unterschied ist lediglich, dass Compiler, IDE einem nicht mehr helfen können, aus so etwas noch klug zu werden. Also genau das gleich wie oben, Generics wegzulassen löst keine Probleme, sondern kehrt sie unter den Teppich.

    > Ist schon irgendwas in der API falsch designt - oder die Sprache erzwingt
    > sowas.
    Tut sie nicht, was sollen solche albernen Behauptungen?

    > Mit map und list vermisse ich eigentlich gar nichts "Generic" in Go, aber
    > vielleicht sind meine Projekte nicht groß genug.
    Es geht nicht nur um generische Typen, sondern um generische Algorithmen. Eine Sprache, in der man grundlegende Operationen wie map, filter, fold etc. nicht typsicher implementieren kann, ist IMO schlicht unbrauchbar.

    > Go macht Dinge anders, und "ideomatic Go" ist eben genauso anders wie Scala
    > nicht Java ist und man sich auf die Denkweise einlassen muss damit die
    > Sprache wirklich ihre Wirkung entfaltet.
    Jaja. Der von Dir verlinkte Artikel sagt eigentlich schon alles, das ist praktisch eine Anleitung, wie man beschissenen Code schreibt:
    2. „Consider copy & paste“
    Ich glaube, das meint der tatsächlich Ernst…
    3. „3. Use interfaces“
    Erklärt am Beispiel von sort.Interface. Ach, und wenn ich den gleichen Container mit unterschiedlichen Vergleichsfunktionen sortieren will? Dann darf ich wahrscheinlich den Container wrappen und damit natürlich auch vollkommen unbeteiligte Methoden wie Len und Swap implementieren, obwohl die mit sortieren mal so gar nichts zu tun haben...
    6. Use a code generator
    Das ist nur ein armseliger Workaround für fehlende Sprachfeatures.

    Es folgt eine vollständige Liste der Vorteile, die Go aus dem Verzicht auf Generics zieht:

  12. Re: Anmerkung zu Java

    Autor: tha_specializt 04.01.17 - 10:50

    wie man sieht hast du nicht die geringste Ahnung über JavaFX. In dem Fall bietet es sich an, einfach die Klappe zu halten - der "Mumpitz" ist eines der fortschrittlichsten UI frameworks dieser Tage ... bestimmt gibt es noch Besseres aber es definitiv gut.

  13. Re: Anmerkung zu Java

    Autor: Trockenobst 04.01.17 - 15:15

    Hello_World schrieb:
    --------------------------------------------------------------------------------
    > Es folgt eine vollständige Liste der Vorteile, die Go aus dem Verzicht auf
    > Generics zieht:

    Genauso die selben Vorteile, die die Leute in den Sprachen nutzen, die ihre "Generics" einfach nicht benutzen, wenn es außerhalb der typischen Listen, Maps und sonstiges stattfindet. Also im eigenen Code, in der eigenen Infrastruktur.

    Wie alt ist nun Java 7? Da müsste doch die halbe Apache.org OpenSource Welt nun voller toller generifizierter Modelle und Klassen sein (und mit Java 8 auch noch alles super auf die Stream()/Closure() Mechanik umgeschrieben sein)

    Nichts davon ist in der Masse passiert. D.h. die sog. Vorteile existieren nur auf dem Papier und nur dann wenn man bereit ist diese zu nutzen. Die Masse sieht den Vorteil also nicht, sonst wäre es längst passiert.

    In C++ muss man sehr fortgeschrittener Entwickler sein, um Templates wirklich zu nutzen. Deswegen verlassen sich die Leute darauf das "andere" dieses Feature beherrschen, um dann fertige Systeme wie STL oder Boost zu nutzen. Wenn nur wenige Profis ein Feature wirklich nutzen können, ist es unkoscher das auf die "Positiv" Liste zu setzen.

    Generics sind schwierig für das gesamte Ecosystem in GO. Bisher hat es keinen guten Umsetzungsvorschlag gegeben, der alle Nachteile von Java-Generics (Runtime Hit), C++ Generics (Compiletime hit) auflöst.

    Wer unbedingt Generics nach C++ Vorlage braucht, kann einen Precompiler nutzen:
    http://alikewise.com/gen/

    Es gibt große Projekte in GO die auch ohne Generics ausgekommen sind:
    https://news.ycombinator.com/item?id=11494181

    Am Ende kommt es zu "Geschmacksrichtung" und wie man seinen Code strukturieren möchte. Wenn Go irgendwann ein offizielles Templatting nach C++ bekommt bin ich nicht dagegen. Ich muss es, wie viele andere dann eben nicht nutzen und habe keinen Runtime Penality.

  14. Re: Anmerkung zu Java

    Autor: Hello_World 04.01.17 - 21:39

    Trockenobst schrieb:
    --------------------------------------------------------------------------------
    > Genauso die selben Vorteile, die die Leute in den Sprachen nutzen, die ihre
    > "Generics" einfach nicht benutzen, wenn es außerhalb der typischen Listen,
    > Maps und sonstiges stattfindet. Also im eigenen Code, in der eigenen
    > Infrastruktur.
    Und was wären das für tolle Vorteile? Du hast immer noch keinen einzigen genannt.

    > Wie alt ist nun Java 7? Da müsste doch die halbe Apache.org OpenSource Welt
    > nun voller toller generifizierter Modelle und Klassen sein (und mit Java 8
    > auch noch alles super auf die Stream()/Closure() Mechanik umgeschrieben
    > sein)
    >
    > Nichts davon ist in der Masse passiert. D.h. die sog. Vorteile existieren
    > nur auf dem Papier und nur dann wenn man bereit ist diese zu nutzen. Die
    > Masse sieht den Vorteil also nicht, sonst wäre es längst passiert.
    Existierender, funktionierender Code wird nicht mal eben neu- oder umgeschrieben, nur weil es ein neues Sprachfeature gibt. Und wie sieht's mit neuem Code aus?
    Schauen wir mal wahllos in ein paar Bibliotheken rein.
    Guice:
    https://github.com/google/guice/blob/master/core/src/com/google/inject/AbstractModule.java
    Huch, alles voll mit Generics.
    Kafka-Client:
    https://github.com/apache/kafka/blob/trunk/clients/src/main/java/org/apache/kafka/clients/consumer/ConsumerRecord.java
    Na so was, schon wieder Generics.
    Guava:
    https://github.com/google/guava/blob/master/guava/src/com/google/common/hash/BloomFilter.java
    Wer hätt's gedacht, schon wieder Generics.
    RxJava:
    https://github.com/ReactiveX/RxJava/blob/1.x/src/main/java/rx/Subscriber.java
    Schau an, Generics.
    JavaFX:
    https://docs.oracle.com/javase/8/javafx/api/javafx/beans/binding/package-summary.html
    Generics…

    Tatsache ist also: Generics kommen an allen Ecken und Enden zum Einsatz. Dass sie in erster Linie für Listen und Maps taugen, ist dutzendfach widerlegter Mythos der Go-Fanboys.

    > In C++ muss man sehr fortgeschrittener Entwickler sein, um Templates
    > wirklich zu nutzen. Deswegen verlassen sich die Leute darauf das "andere"
    > dieses Feature beherrschen, um dann fertige Systeme wie STL oder Boost zu
    > nutzen. Wenn nur wenige Profis ein Feature wirklich nutzen können, ist es
    > unkoscher das auf die "Positiv" Liste zu setzen.
    Sehe ich nicht so, einfache Templates sind nicht schwer zu schreiben und niemand zwingt einen dazu, komplexe Sachen zu machen, wenn man das nicht beherrscht. Aber unabhängig davon sind Templates auch für Entwickler, die gar keine eigenen Templates schreiben, ein enormer Vorteil, einfach weil sie eben Bibliotheken wie STL und Boost ermöglichen. Ganz zu schweigen von Sachen wie Eigen3. Es hat schon Gründe, wieso C++ de-facto-Standard für numerische Mathematik ist, und Templates sind ein ganz wesentlicher Grund.

    > Generics sind schwierig für das gesamte Ecosystem in GO. Bisher hat es
    > keinen guten Umsetzungsvorschlag gegeben, der alle Nachteile von
    > Java-Generics (Runtime Hit), C++ Generics (Compiletime hit) auflöst.
    Nochmal: keine Generics zu haben führt *exakt* zu den gleichen Problemen. Entweder, man boxed nach interface{} (Boxing-Overhead zur Laufzeit), oder man dupliziert den Code (manuell oder mit irgendwelchen Tools), was die Compile-Zeit verlängert. Und natürlich handelt man sich zusätzliche Probleme ein: mangelnde Typsicherheit, katastrophale Wartbarkeit (bei manueller Codeduplikation), oder man muss sich mit Dreck wie "go gen" herumschlagen.

    > Wer unbedingt Generics nach C++ Vorlage braucht, kann einen Precompiler
    > nutzen:
    > alikewise.com
    Mit anderen Worten: weil offensichtlich doch Bedarf besteht, hat man es irgendwie drangefrickelt. Und man hat sich irgendeine selbstgefrickelte Syntax ausgedacht mit {{}} für Typparameter und irgendetwas hässlichem für Typconstraints. Und das hier ist ja wohl ein schlechter Witz:
    „It’s a local dev tool[...]. Run it locally, test it, and commit the generated code to the repo.“
    Go ist offenbar eine Brutstätte für worst practices.
    Hast Du dir go gen eigentlich mal angeschaut? Code in Stringliteralen, ernsthaft? Damit fliegt natürlich jede Toolunterstützung aus dem Fenster, angefangen beim Syntaxhighlighting.

    > Es gibt große Projekte in GO die auch ohne Generics ausgekommen sind:
    > news.ycombinator.com
    Klar lässt sich so etwas umsetzen, wenn man nur bereit ist, genug Zeit, Geld und Entwicklerressourcen zu investieren, und was glaubst Du, damit bewiesen zu haben? Wir wissen schlichtweg nicht, wie das Projekt mit einer Go-Version mit Generics gelaufen wäre, es sagt also exakt gar nichts darüber aus, ob das ein Vorteil gewesen wäre. Es ist übrigens IMO ziemlich aussichtslos, den Wert des Features allein mit empirischen Mitteln bewerten zu wollen, dafür sind unterschiedliche Projekte schlicht zu unterschiedlich.

    Aber ein paar schöne Zitate gibt's in dem Thread, zum Beispiel:
    One of the best things about Go is it seems to be a strong signaler of the type of engineering team I avoided.
    Aber klar, natürlich haben alle die Sprachforscher, die sich 40 jahre lang mit modernen Typsystemen beschäftigt haben keine Ahnung… Die echten Profis sind natürlich die, die uns C mit seinen Buffer Overflows und Formatstring-Schwachstellen beschert haben
    </ironie>

    > Am Ende kommt es zu "Geschmacksrichtung" und wie man seinen Code
    > strukturieren möchte.
    Nö. Noch ein schöner Post in dem von Dir verlinkten Thread:
    https://news.ycombinator.com/item?id=11494181#11504878
    30 Zeilen Boilerplate für Funktionalität, die man mit Generics in 3 Zeilen abhaken kann. Niemand macht mir weis, dass das nicht die Produktivität beeinträchtigt.

    > Wenn Go irgendwann ein offizielles Templatting nach
    > C++ bekommt bin ich nicht dagegen. Ich muss es, wie viele andere dann eben
    > nicht nutzen und habe keinen Runtime Penality.
    Die haben C++-Templates auch so nicht. Bitte, informier dich doch wenigstens, bevor Du Dich auf eine Diskussion einlässt…

  15. Re: Anmerkung zu Java

    Autor: bofhl 05.01.17 - 09:26

    tha_specializt schrieb:
    --------------------------------------------------------------------------------
    > du demonstrierst geradezu herrlich eine ausgeprägte Unwissenheit in Bezug
    > auf Java.

    Inwieweit? Das eigentlich außer JEE (und Android, aber da gibt es inzwischen auch andere Ansätze...) kaum mehr ein Anwendungsgebiet existiert, das breit damit "bespielt" wird ist ja inzwischen bekannt (Oracle vielleicht nicht)! Und selbst bei JEE da gibt es einige, die eigentlich nur mehr die VM nutzen und mit anderen Entwicklungssprachen die Programme erstellen.

  16. Re: Anmerkung zu Java

    Autor: mxrd 05.01.17 - 09:30

    bofhl schrieb:
    --------------------------------------------------------------------------------
    > tha_specializt schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > du demonstrierst geradezu herrlich eine ausgeprägte Unwissenheit in
    > Bezug
    > > auf Java.
    >
    > Inwieweit? Das eigentlich außer JEE (und Android, aber da gibt es
    > inzwischen auch andere Ansätze...) kaum mehr ein Anwendungsgebiet
    > existiert, das breit damit "bespielt" wird ist ja inzwischen bekannt
    > (Oracle vielleicht nicht)! Und selbst bei JEE da gibt es einige, die
    > eigentlich nur mehr die VM nutzen und mit anderen Entwicklungssprachen die
    > Programme erstellen.

    Hast du in deiner Glaskugel gesehen bzw. in der Fußgängerzone deiner Stadt eine representative Stichprobe/Umfrage gemacht, mit der sich das ohne weiteres auf den gesamten Globus bezieht.

    Oder doch nur auf Deutschland?
    Oder doch nur auf deine Stadt?
    Nur deine Fußgängerzone?
    Oder doch nur auf dich und deine direkt Umgebung?

    Deine Unwissenheit solltest du nicht noch mehr zu Tage tragen.

  17. Re: Anmerkung zu Java

    Autor: jungundsorglos 10.01.17 - 21:49

    > Wir sind in 2017 - es gibt nur mobile, Web, IoT und Cloud.
    Auch 2017 heißt es immernoch: "Wir sind im Jahr 2017", oder "Es ist 2017".
    "In <Jahreszahl>" ist falsch und hört sich ungebildet an, auch wenn es häufig zu lesen ist.

  18. Re: Anmerkung zu Java

    Autor: jungundsorglos 10.01.17 - 22:03

    > Java ist eine eierlegende Wollmilchsau.
    Nicht wirklich. GUI-Entwicklung war schon immer ein Krampf, und vieles andere sehr umständlich.

    > Braucht man das in allen Projekten?
    > Oder ist man nicht besser bedient, die beste Programmiersprache für ein
    > konkretes Projekt auszuwählen?
    Gut designte (und unterstützte) Bibliotheken sind meistens wichtiger.

    >mobile
    Ersetzt keine Desktopanwendungen, wird es auch nie. Andere Zielgruppe und anderer Anwendungszweck.

    > (Client-Server, Desktop) ist legacy
    Cloud ist Client-Server, so wie die meisten Web-Anwendungen...

    > oder Nische (embedded)
    Embedded und IoT sind praktisch das Gleiche. Mit Industrie 4.0 kann man kaum von einer Nische sprechen...

    >Davon kann ein Java-Programmierer zwar noch viele Jahre
    > überwintern, spannend geht aber anders. Ich würde allenfalls für mobile
    > (Android) Java wählen. Aber für den Rest?
    Nur die Sprache/Framework wechseln man es nicht spannender. Alter Wein in neuen Schläuchen.

    >Die kannst du in Java
    > entwickeln, aber um Gotten Willen warum? JEE spielt in der Cloud jedenfalls
    > keine Rolle. Das ist klassische Client-Server-Programmierung.
    > Cloud: micro services sind der Stand der Technik.
    Den ganzen Bullshitbingo aus der Java-Welt hast du aber gut übernommen. Die Unterschiede sind doch marginal. Micro(Services) und Client-Server ist im Prinzip das Gleiche.

    >Kein Mensch mit
    > Verstand würde daraus einen Cloud-Service entwickeln. Man muss auch noch
    > nicht einmal C# bemühen (meine Meinung zu C# ist nur unwesentlich anders -
    > besseres Sprachdesign als Java, aber immer noch zu viele Kompromisse). Mit
    > Python, Go, Ruby, Javascript, den ganzen funktionalen Sprachen kommt man
    > meiner Erfahrung nach in der Cloud deutlich schneller zu Ergebnissen.
    JavaScript ist wirklich eine tolle Sprache...
    Python zum debuggen völlig ungeeignet, für Prototyping ok. Go? Dann schon eher Rust.

  19. Re: Anmerkung zu Java

    Autor: derats 10.01.17 - 22:19

    jungundsorglos schrieb:
    --------------------------------------------------------------------------------
    > >Kein Mensch mit
    > > Verstand würde daraus einen Cloud-Service entwickeln. Man muss auch noch
    > > nicht einmal C# bemühen (meine Meinung zu C# ist nur unwesentlich anders
    > -
    > > besseres Sprachdesign als Java, aber immer noch zu viele Kompromisse).
    > Mit
    > > Python, Go, Ruby, Javascript, den ganzen funktionalen Sprachen kommt man
    > > meiner Erfahrung nach in der Cloud deutlich schneller zu Ergebnissen.
    > JavaScript ist wirklich eine tolle Sprache...
    > Python zum debuggen völlig ungeeignet, für Prototyping ok. Go? Dann schon
    > eher Rust.

    Python ist schwer zu debuggen?

  20. Re: Anmerkung zu Java

    Autor: flAming_Ace 10.01.17 - 23:13

    HerrLich schrieb:
    --------------------------------------------------------------------------------
    > Java ist eine eierlegende Wollmilchsau. Braucht man das in allen Projekten?
    > Oder ist man nicht besser bedient, die beste Programmiersprache für ein
    > konkretes Projekt auszuwählen?
    ...


    Für jedes Projekt die Sprache neu auszuwählen, erhöht die Komplexität im Unternehmen extrem! Das ist grob fahrlässig..
    Bei der Masse von Sprachen und Frameworks kann man dann den Rest seines Lebens mit Einarbeitung verbringen.. Um mal ein paar Sprachen zu nennen: Java, C, C++, C#, Objective C, Python, Ruby, Rust, Go, Scala, Javascript, Dart, PHP, Visual Basic, Swift, Objectiv-C, Groovy, Xtend, Hack, Julia, Haskell, Clojure und und und... Multipliziere das mit den Frameworks, die IDEs und den Build-Systemen der jeweiligen Sprachen.. Viel Spaß!
    In einem Unternehmen sollte es eine entsprechende IT-Strategie geben. Diese sollte natürlich regelmäßig reflektiert werden.. Schon mal was von einer Lernkurve gehört??

  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. AKKA Deutschland GmbH, München
  2. ADLON Intelligent Solutions GmbH, Ulm, Ravensburg
  3. Landeshauptstadt Stuttgart, Stuttgart
  4. über duerenhoff GmbH, Raum Ostfildern

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 399,00€ (Bestpreis! zzgl. Versand)
  2. (u. a. RTX 2080 ROG Strix Gaming Advanced für 699€, RTX 2080 SUPER Dual Evo OC für 739€ und...
  3. (u. a. Asus Rog Strix X570-F + Ryzen 7 3700X für 555,00€, Asus Tuf B450-Plus + Ryzen 7 2700 für...
  4. 419,00€ (Bestpreis!)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Need for Speed Heat im Test: Temporausch bei Tag und Nacht
Need for Speed Heat im Test
Temporausch bei Tag und Nacht

Extrem schnelle Verfolgungsjagden, eine offene Welt und viel Abwechslung dank Tag- und Nachtmodus: Mit dem Arcade-Rennspiel Heat hat Electronic Arts das beste Need for Speed seit langem veröffentlicht. Und das sogar ohne Mikrotransaktionen!
Von Peter Steinlechner

  1. Electronic Arts Need for Speed Heat saust durch Miami

In eigener Sache: Aktiv werden für Golem.de
In eigener Sache
Aktiv werden für Golem.de

Keine Werbung, kein unerwünschtes Tracking - kein Problem! Wer Golem.de-Inhalte pur nutzen möchte, hat neben dem Abo Golem pur jetzt eine weitere Möglichkeit, Golem.de zu unterstützen.

  1. Golem Akademie Von wegen rechtsfreier Raum!
  2. In eigener Sache Wie sich Unternehmen und Behörden für ITler attraktiv machen
  3. In eigener Sache Unser Kubernetes-Workshop kommt auf Touren

Gardena: Open Source, wie es sein soll
Gardena
Open Source, wie es sein soll

Wenn Entwickler mit Zeitdruck nach Lösungen suchen und sich dann für Open Source entscheiden, sollte das anderen als Vorbild dienen, sagen zwei Gardena-Entwickler in einem Vortrag. Der sei auch eine Anleitung dafür, das Management von der Open-Source-Idee zu überzeugen - was auch den Nutzern hilft.
Ein Bericht von Sebastian Grüner

  1. Linux-Kernel Machine-Learning allein findet keine Bugs
  2. KernelCI Der Linux-Kernel bekommt einheitliche Test-Umgebung
  3. Linux-Kernel Selbst Google ist unfähig, Android zu pflegen

  1. Android 10: Google sollte sein Schweigen zur Android-Verbreitung beenden
    Android 10
    Google sollte sein Schweigen zur Android-Verbreitung beenden

    Zwei Monate nach dem Start von Android 10 ist immer noch komplett unklar, wie viele Nutzer die Version bereits verwenden. Grund dafür ist, dass Google seit einem halben Jahr wieder keine Zahlen zur Android-Verbreitung veröffentlicht. Damit befeuert das Unternehmen negative Vermutungen, die ihm schaden.

  2. Security Lab: Github sucht mit Partnern nach Lücken in Open Source Code
    Security Lab
    Github sucht mit Partnern nach Lücken in Open Source Code

    Mit seinem Security-Lab will der Code-Hoster Github künftig aktiv nach Sicherheitslücken in Open Source Code suchen und wird dabei von vielen Unternehmen unterstützt. Für Github-Nutzer soll zudem der Umgang mit Sicherheitslücken einfacher werden.

  3. SSD: Crucials BX500 erhält QLC- statt TLC-Speicher
    SSD
    Crucials BX500 erhält QLC- statt TLC-Speicher

    Die BX500 gibt es mittlerweile auch mit 1 TByte und 2 TByte Kapazität. Crucial verwendet bei den günstigen Sata-SSDs jedoch tendenziell langsameren Flash-Speicher als bei den kleineren Modellen.


  1. 10:45

  2. 10:28

  3. 10:13

  4. 10:00

  5. 09:45

  6. 09:26

  7. 09:08

  8. 08:02