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

Anmerkung zu Java

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema
  1. 1
  2. 2
  3. 3

Neues Thema


  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


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Geodatenmanager / Geodatenmanagerin und Administrator / Administratorin (m/w/d) im Bereich ... (m/w/d)
    Stadt Kempten (Allgäu), Kempten (Allgäu)
  2. Mitarbeiter*in (m/w/d) für den technischen Support Medientechnik/IT
    VAV Medientechnik GmbH, Buxtehude, München, Landsberg
  3. SAP-Applikationsmanager (m/w/d) Basis-Administration
    Kölner Verkehrs-Betriebe AG, Köln
  4. Softwareentwickler Lagerverwaltung (m/w/d)
    STOPA Anlagenbau GmbH, Achern-Gamshurst

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. Humankind für 27,99€, Tennis Manager 2022 für 29,99€, Haven für 9,99€)
  2. (u. a. MSI 32 Zoll WQHD 175 Hz für 559€ statt 899€, BenQ Curved 32 Zoll 4K UHD 144 Hz für...
  3. (u. a. Palit RTX 3090 Ti für 1.391,98€, Zotac RTX 3090 für 1.298,99€, MSI RTX 3080 Ti für 1...
  4. (u. a. Computer, TV, Smartphone, Gaming, Haushalt)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Rollerdrome im Test: Ballern beim Rollen
Rollerdrome im Test
Ballern beim Rollen

Wer Bunny Hop oder Rocket Jump schon kann, wirft einen Blick auf Rollerdrome: Das Actionspiel bietet Kämpfe mit fortgeschrittener Steuerung.
Von Peter Steinlechner


    In eigener Sache: Golem Karrierewelt feiert ersten Geburtstag
    In eigener Sache
    Golem Karrierewelt feiert ersten Geburtstag

    Wir feiern ein Jahr Golem Karrierewelt und wollen virtuell mit euch darauf anstoßen - mit 25 Prozent Rabatt auf alle Fachtrainings und E-Learning-Kurse!

    1. In eigener Sache Golem.de startet Plus-Angebot
    2. In eigener Sache Golem.de sucht Hardware-Guru (m/w/d)
    3. In eigener Sache Webinar zu Pentesting und Hacking zum Nachgucken

    Scraping des Handelsregisters: Wir machen das ja nur aus Notwehr
    Scraping des Handelsregisters
    "Wir machen das ja nur aus Notwehr"

    Eine ehrenamtliche Gruppe plant, die Daten des Handelsregisters automatisiert in maschinenlesbare Formen zu bringen. Wofür dieser Aufwand?
    Ein Interview von Lennart Mühlenmeier

    1. Neues Handelsregister Private Daten ermöglichen Identitätsdiebstahl
    2. Google Fonts Abmahnungen an Webseitenbetreiber mit Google-Schriftarten
    3. Umsetzung von Gesetzesnovelle Handelsregister ist nun öffentlich und kostenlos