1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Kotlin: Das bessere Java
  6. Them…

Wie alles auf der Welt - Geschmackssache

Für Konsolen-Talk gibt es natürlich auch einen Raum ohne nerviges Gedöns oder Flamewar im Freiraum!
  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Re: Nein, sorry.

    Autor: wasdeeh 06.11.20 - 16:35

    pioneer schrieb:
    --------------------------------------------------------------------------------
    > wasdeeh schrieb:
    >
    > > Nein, hier gehts um die (lange überfällige) Etablierung von best
    > practices
    > > als first principles (ums mal überspitzt zu formulieren).
    >
    > Und wie machte man das früher? Sessions, Session Replication, man hat den
    > State über die Server verteilt. man hat es früher anders gelöst. Hier ist
    > klar ein Paradigmenwechsel verzogen worden. Also nichts mit war im
    > Enterprise schon immer so und längst überfällig.Es handelt sich hier um
    > eine Entwicklung der letzten 10 Jahre. Vereinzelte frühere Anfänge zähle
    > ich dabei nicht. Es kommt auf die Durchsetzung in der Breite an.

    Ganz genau: Es kommt auf die Durchsetzung in der Breite an - und das ist es, was längst überfällig ist.

    Früher? Ja klar, es war nicht die Lösung schon "immer so", aber die Probleme.
    Und wenn einem die Vermeidung eins dieser Probleme wirklich wichtig war, hat man sich dafür manchmal sogar eigene Programmiersprachen gebaut, die diese practices besser abbilden (Frag mal Ericsson...). Oder zumindest spezialisierte Frameworks innerhalb etablierter Technologien, etc.

    Aber eben: Ausserhalb der Nischen mit genügend Interesse/KnowHow/Geld resultierte es halt auch in einer Riesenflut an verbuggten Ausgeburten von LOB-Anwendungen, wo ganze Fehlerklassen durch eine andere Sprachbasis gar nicht passieren hätten können. Es gibt schon einen Grund, warum Tony Hoare den (von ihm "erfundenen") Nullpointer als billion dollar mistake bezeichnet.

    > > > - Java 14 bringt records (vermutlich in 16 nicht mehr preview)
    > > > - @NotNull exisiert schon länger
    > > > - Immutable Lists ebenfalls
    > > > - Java 8 Streams, insbesondere die parallelen sind schon ziemlich
    > cool.
    > >
    > > Etwas mit Annotations oder vereinzelten Datenstrukturen nachzuliefern
    > ist
    > > ein bissl was anderes als die Sprache grundlegend darauf aufzubauen.
    >
    > Die Änderungen in Java sind alles andere als "vereinzelt".

    Achso? Wurde jetzt das SDK (inkl. Implementierung) auf immutable-Strukturen als Default umgestellt? Ist es - wenigstens weitgehend - durchannotated? (Vom Garantielevel bzgl. enforcen der Annotations gar nicht mal zu reden...)

    > Zudem: wie will man eine 25 Jahre alte Sprache grundsätzlich neu aufbauen
    > und dabei Kompatibilität bewahren. Aha geht nicht. Aber das Handwerkszeug
    > ist verfügbar und wer es nutzt wird davon profitieren.
    >
    > >
    > > > Java trägt die Last 25 Jahre alt zu sein und kompatibel sein zu
    > müssen,
    > > das
    > > > ist eine schwere Last und die Fortschritte, die dennoch erzielt
    > werden,
    > > > kann man ruhig mal würdigen.
    > >
    > > Stimmt ja durchaus zu - aber was hat das mit dem Argument zu tun?
    >
    > Mit welchem Argument jetzt genau?

    Dass die Änderungen "Geschmackssache" seien?



    1 mal bearbeitet, zuletzt am 06.11.20 16:37 durch wasdeeh.

  2. Re: Nein, sorry.

    Autor: minnime 06.11.20 - 23:23

    Ich verstehe nicht warum die Leute Angst vor Nullpointern haben. Es kommt nunmal vor, dass manchmal Daten da sind und manchmal nicht und das muss man prüfen. Ob man da nun einen Nullcheck macht oder den Optional fragt ob er Daten enthält ist jetzt nicht so richtig ein Unterschied.

  3. Re: Nein, sorry.

    Autor: Trockenobst 07.11.20 - 03:49

    pioneer schrieb:
    --------------------------------------------------------------------------------
    > - Java 14 bringt records (vermutlich in 16 nicht mehr preview)
    <,,,>
    > Java trägt die Last 25 Jahre alt zu sein und kompatibel sein zu müssen, das
    > ist eine schwere Last und die Fortschritte, die dennoch erzielt werden,
    > kann man ruhig mal würdigen.

    Würdigen kann man alles. In der Praxis sehe ich Java 8 Code mit 11er Sprinkeln wenn mal einer dran saß der Streams versteht. Immutability und Functional Thinking kann man zwar irgendwie hin zwingen, aber wenn das restliche Ecosystem ala EJB und Co. das nicht unterstützt hilft dann alles nichts. 14 wird einiges von Kotlin in das System bringen, aber das irgendwer das aktiv nutzt ist dann eher fraglich, weil das Ecosystem von Testtools, Codeanalyse, UML Diagrammer etc. das alles auch können muss. Viele dieser Tools können 11 noch nicht richtig!

    Die tiefe Dissonanz kriegt man nicht weg, dafür gibt es andere Sprachen und Werkzeuge. Viele springen auf Kotlin auf, weil man ggf. auch gleich den ganzen alten Enterprise "Zopf" mit abschneiden kann. In einem Projekt hatten wir Java (Backend), C#, Java (Android) und Swift (IOS). Dort arbeiten jetzt vier Leute intensiv daran Swift und C# loszuwerden und alles in Kotlin zu machen. Wird in den nächsten Jahren nicht ganz klappen, aber die Reduktion von 50% ist machbar. Und das ist ein ganz knallhartes finanzielles Argument das hier die Implementation treibt und nicht weil Leute "functional programming" und "higher order functions" plötzlich so toll finden.

  4. Re: Nein, sorry.

    Autor: Trockenobst 07.11.20 - 04:41

    minnime schrieb:
    --------------------------------------------------------------------------------
    > Ob man da nun einen Nullcheck macht oder den Optional fragt ob er
    > Daten enthält ist jetzt nicht so richtig ein Unterschied.

    Der Student vergisst den Nullcheck, das Optional nicht.
    Genau das Argument das ja die Rust Freunde immer anbringen, die Freiheit der C/C++ Freunde beim Objekt Ownership und wildes Speicher Management haben uns sehr viele Milliarden an "Schaden" gekostet.

    Ich bin noch am Anfang der "Funktionalen" Reise, aber Fehlerhandling von fachlichen Code zu trennen ist in Java nicht wirklich 100% sauber möglich, speziell wenn es über mehrere Namespaces, Codebereiche, Threads etc. geht. Also in der täglichen Praxis.

    Die Idee ist ja nicht einfach nur Java hübscher zu machen, sondern einen anderen Ansatz zu wählen, wie man überhaupt Fachlichkeit in Code abbildet. Ich finde den funktionalen Ansatz, die Reduktion auf Interfaces und Higher Order Funktionen sehr sauber; der Nachteil ist das es kaum belastbare Bibliotheken für bestimmte Zwecke in Kotlin gibt die das End zu End erlauben.

  5. Re: Nein, sorry.

    Autor: minnime 07.11.20 - 15:32

    Ja und? Dann wird der Nullcheck eben vergessen, dann krachts halt, das fällt dann schon auf. Das ist ja kein Fehler wo es Wochen und Monate später zu Datenverfälschungen kommt, die keiner mitbekommt. Ich habe vor NullPointerExceptions keine Angst, die fallen auf uns sind leicht zu finden.

  6. Re: Nein, sorry.

    Autor: Trockenobst 07.11.20 - 16:12

    minnime schrieb:
    --------------------------------------------------------------------------------
    > Ich habe vor NullPointerExceptions keine Angst, die fallen auf uns sind leicht zu
    > finden.

    Bis der Build und die Prüfung durch sind, ist der halbe Sonntag durch.
    Was ich für Stories hier im Forum von Leuten während der Pandemie gelesen habe muss man das wohl auch weil man es sich häufig nicht "aussuchen" kann.

    Funktional gibt einem mehr Sicherheit in Verbindung mit TDD.
    Wor allem wenn der Fehler in einer externen Komponente ist die politisch mehr Dampf hat und der einfache Fix "du am Sonntag" bist, während die anderen noch eine Woche bekommen um ihren Müll weg zuräumen.

  7. Re: Nein, sorry.

    Autor: mnementh 07.11.20 - 18:04

    minnime schrieb:
    --------------------------------------------------------------------------------
    > Ja und? Dann wird der Nullcheck eben vergessen, dann krachts halt, das
    > fällt dann schon auf. Das ist ja kein Fehler wo es Wochen und Monate später
    > zu Datenverfälschungen kommt, die keiner mitbekommt. Ich habe vor
    > NullPointerExceptions keine Angst, die fallen auf uns sind leicht zu
    > finden.
    Ich habe mal für viele Stunden frustriert nach einem Bug gesucht. Stellte sich heraus, dass mein Vorprogrammierer einfach eine Catch-All-Anweisung für Exceptions gehabt hat und kommentarlos weitermachte. Noch nicht mal ein Log. Die Daten waren danach inkonsistent und an anderer Stelle kam es zu einem Fehler, der an der Stelle halt nicht verständlich war.

    Ist jetzt nicht ganz das gleiche, aber ein durch den Compiler erzwungener Nullcheck bringt deutliche Verbesserungen in realen Code. Und viel weniger Quark den ich Monate oder Jahre später debuggen muss.

  8. Re: Nein, sorry.

    Autor: wasdeeh 08.11.20 - 11:36

    "Angst"? Die ist hier völlig irrelevant. Hier gehts um Professionalismus.

    Es hat sich schlicht in vielen Jahrzehnten Erfahrung (und zahllosen entsprechenden Analysen) gezeigt, dass null pointer-Bugs (nach Buffer overflows) zu den häufigsten und schädlichsten Fehlerklassen gehören.

    Da sollte es eigentlich gar keine große Diskussion drüber geben, wenn bestrebt wird, die verwendeten Werkzeuge gegenüber dieser Fehlerklassen resilienter zu machen.

  9. Re: Nein, sorry.

    Autor: pioneer 08.11.20 - 12:21

    minnime schrieb:
    --------------------------------------------------------------------------------

    > prüfen. Ob man da nun einen Nullcheck macht oder den Optional fragt ob er
    > Daten enthält ist jetzt nicht so richtig ein Unterschied.

    Wenn du Optional nur mit isPresent() und get() benutzt, hast du es noch nicht richtig verstanden. Es so zu benutzen ist ein Antipattern. Du solltest dich mal mit den anderen Methoden beschäftigen, die Optional bereitstellt.

    Oder schau einfach https://youtu.be/Ej0sss6cq14



    1 mal bearbeitet, zuletzt am 08.11.20 12:24 durch pioneer.

  10. Re: Nein, sorry.

    Autor: pioneer 08.11.20 - 12:30

    Trockenobst schrieb:

    > Functional Thinking kann man zwar irgendwie hin zwingen, aber wenn das
    > restliche Ecosystem ala EJB und Co. das nicht unterstützt hilft dann alles nichts

    Spring 5 und Spring Boot 2 existieren. Wenn man an einem sterbenden Ecosystem festhält, dann hilft es alles nichts. Das stimmt wohl.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


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. Volkswagen Vertriebsbetreuungsgesellschaft mbH, Berlin, Wolfsburg
  2. Volkswagen Vertriebsbetreuungsgesellschaft mbH, Wolfsburg
  3. Bundesanstalt für Landwirtschaft und Ernährung, Bonn
  4. OFFIS - Institut für Informatik, Oldenburg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. 59€ (Bestpreis)
  2. 1.099€ (Bestpreis)
  3. (u. a. Super Seducer 3 - Uncensored Edition für 10,79€, Total War: Rome - Remastered für 26...
  4. 399,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Programm für IT-Jobeinstieg: Hoffen auf den Klebeeffekt
Programm für IT-Jobeinstieg
Hoffen auf den Klebeeffekt

Aktuell ist der Jobeinstieg für junge Ingenieure und Informatiker schwer. Um ihnen zu helfen, hat das Land Baden-Württemberg eine interessante Idee: Es macht sich selbst zur Zeitarbeitsfirma.
Ein Bericht von Peter Ilg

  1. Arbeitszeit Das Sechs-Stunden-Experiment bei Sipgate
  2. Neuorientierung im IT-Job Endlich mal machen!
  3. IT-Unternehmen Die richtige Software für ein Projekt finden

Weclapp-CTO Ertan Özdil: Wir dürfen nicht in Schönheit und Perfektion untergehen!
Weclapp-CTO Ertan Özdil
"Wir dürfen nicht in Schönheit und Perfektion untergehen!"

Der CTO von Weclapp träumt von smarter Software, die menschliches Eingreifen in der nächsten ERP-Generation reduziert. Deutschen Perfektionismus hält Ertan Özdil aber für gefährlich.
Ein Interview von Maja Hoock


    Fiat 500 als E-Auto im Test: Kleinstwagen mit großem Potenzial
    Fiat 500 als E-Auto im Test
    Kleinstwagen mit großem Potenzial

    Fiat hat einen neuen 500er entwickelt. Der Kleine fährt elektrisch - und zwar richtig gut.
    Ein Test von Peter Ilg

    1. Vierradlenkung Elektrischer GMC Hummer SUV fährt im Krabbengang seitwärts
    2. MG Cyberster MG B Roadster mit Lasergürtel und Union Jack
    3. Elektroauto E-Auto-Prämie übersteigt in 2021 schon Vorjahressumme