# Angst vor Kotlin



## looparda (19. Mai 2017)

Ich habe mir vor einer Weile mal andere JVM Sprachen wie Scala, Groovy und Kotlin angeschaut. Aktuell wird nun auch offiziell Kotlin als Android Platform Sprache unterstützt. Ich mag viele Features aus Kotlin und würde gern tiefer darin einsteigen. Wenn ich in Zukunft bei einer Firma arbeiten werde, die meiner Meinung eher konservativ Java einsetzt als auf Kotlin zu gehen sehe ich, dass mir das Probleme machen könnte.

ich die Sprachen gedanklich vermischen könnte. 
ich könnte die Lust and Java verlieren, da man sich immer denkt: "In Kotlin könnte ich das hervorragen mit Feature x lösen anstatt in Java wieder Klimmzuge zu machen."
ich mir die Chance verbaue ein guter Java Entwickler zu werden, der Design-/Architekturprobleme mit Erfahrung lösen kann. Ich denke es macht etwas aus ob man 7 Jahre in der gleichen Sprache programmiert oder alle 3 Jahre die Sprache/Dialekt wechselt. Man wird so einfach nicht das Tiefenwissen erlangen können
Hat jemand Erfahrung in dem Bereich und kann berichten?


----------



## dzim (19. Mai 2017)

Kotlin und Java sind noch recht ähnlich. Kotlin wird, im Vergleich zu anderen JVM-Sprachen, noch als regelrecht konservativ beschrieben.
Es ist schwer zu sagen, was im Moment richtig und was falsch ist. Jedoch solltest du im Hinterkopf behalten, dass viele grosse Frameworks mit Kotlin anbändeln. Z.B. Spring und Vert.x. Nur um ein paar zu nennen, mit denen ich in jüngerer Zeit irgendwie Kontakt hatte.
Du hast schon recht, das es vielleicht nicht schaden kann, erst Java recht gut zu können - das ermöglicht dir, meiner Meinung nach, auch einen einfacheren Einstieg in Kotlin.
Wir haben bisher leider auch noch kein offizielles Produkt mit Kotlin erstellt, aber ich sehe in naher Zukunft die Notwendigkeit für einen DB-Service (Rest-Schnittstelle an eine DB), bei der ich zumindest die Interoperabilität verwenden werde. Das finde ich so toll an Kotlin: Es kann kooexistieren (nun auch die anderen Sprachen unterstützen das ähnlich, aber bei Kotlin finde ich es bisher noch am besten gelöst).
Ich denke mittelfristig kann es jungen Entwicklern nicht schaden, beide Sprachen zu beherrschen. Ich bin schon eher ein älterer Hase und werde mich eher aus dem persönlichen Wunsch nach Weiterbildung darum kümmern.
Ich weiss: Das hilft dir alles vielleicht nicht so viel, aber mit mer kann ich nicht dienen.


----------



## dzim (22. Mai 2017)

https://blog.mindorks.com/should-i-learn-kotlin-or-stick-to-java-3a73c3580ac3


----------



## krgewb (3. Okt 2017)

Wie gehst du nun vor?


----------



## dzim (3. Okt 2017)

Das eine kann ich schon, Damm andere lern ich, wenn ich passende Projekte hab. Ich denke, Kotlin ist eine gute Ergänzung zu Java. Ich werfe vermutlich damit beginnen, beides in Projekten mit aktiver Interoperabilität nutzen (wo beides drin vorkommt).


----------



## Tobse (3. Okt 2017)

Ob du das wirst verwenden können hängt stark vom Arbeitgeber ab. Ich habe mir die Sprache privat angeeignet und kann gut damit umgehen; wie ich Kotlin dann für ein Android-Projekt einsetzen wollte hieß es "wer kann das denn? Das müssen andere dann ja auch warten können; Nimm Java.".
Soll heißen: aktuell musst du es in kleinen Firmen oder Startups einsetzen bis es noch mehr Leute können und es auch bei den IT-Leitern bekannt ist. Das kann durchaus noch ein paar Jahre dauern.


----------



## dzim (3. Okt 2017)

Meine Firma ist a) klein und b) schnell bereit, mal was auszuprobieren. Mein Glück also.
Und was das überzeugen angeht: es gibt schon einige Big Player, write Pinterest, sure we schon verwenden. Und zwar noch bevor Google es offiziell gemacht hat.
Also denke ich, es gibt gute Argumente.


----------



## Tobse (3. Okt 2017)

dzim hat gesagt.:


> Und was das überzeugen angeht: es gibt schon einige Big Player, write Pinterest, sure we schon verwenden. Und zwar noch bevor Google es offiziell gemacht hat.
> Also denke ich, es gibt gute Argumente.



Das meine ich auch  Habe mich auch schon vor dem offiziellen Android Support näher mit der Sprache beschäftigt gehabt; der Verantwortliche für das Projekt war trotzdem anderer Meinung...
Deswegen: einfach ein paarmal nachfragen, auch wenn man beim ersten mal keine Zustimmung erhält; irgendwann nehmen Sie es an. Andere JVM Ghosts sind ja auch etabliert. Wenn in Zukunft mehr in Kotlin statt in plain Java geschrieben wird, bringt das allen einen Vorteil IMHO.


----------



## JStein52 (4. Okt 2017)

Tobse hat gesagt.:


> Wenn in Zukunft mehr in Kotlin statt in plain Java geschrieben wird, bringt das allen einen Vorteil IMHO.


Welchen denn ? Und was bringt das alles wirklich ? Warum muss man vor jede Funktion ein FUN schreiben? Was soll das sparen?
Diese Pascal-Artige, geschwätzige und doppelpunktverseuchte Syntax ist von großem Übel. Schon Scala nervt nach einiger Zeit. Kotlin sieht mir auch eher nach "Google hat Geld und wir pushen das Ding jetzt" aus, statt dass man mitdenkt.


----------



## Flown (4. Okt 2017)

Ich hab mir Kotlin angesehen, da war es noch in Version 1. MEINER MEINUNG NACH: Sieht aus wie Scala, fühlt sich an wie Scala, kann das gleiche wie Scala (natürlich mit kleinen Unterschieden).

Was mir negativ auffällt (Scala & Kotlin):
- Extension Methods
- Operator Overloading
- Implicit function parameter (`it`)

Das ist wie gesagt, meine eigene Meinung und wer mit leselicher kommt, denn werf ich mal das hin (aus den Tutorial Seiten):

```
fun result(args: Array<String>) =
  html {
    head {
      title {+"XML encoding with Kotlin"}
    }
    body {
      h1 {+"XML encoding with Kotlin"}
      p  {+"this format can be used as an alternative markup to XML"}
      // an element with attributes and text content
      a(href = "http://kotlinlang.org") {+"Kotlin"}
      // mixed content
      p {
        +"This is some"
        b {+"mixed"}
        +"text. For more see the"
        a(href = "http://kotlinlang.org") {+"Kotlin"}
        +"project"
        }
        p {+"some text"}
        // content generated by
        p {
          for (arg in args)
            +arg
          }
        }
      }
    //...
```


----------



## JStein52 (4. Okt 2017)

Das Beispiel ist cool.  Sieht aus als wäre ein Obfuscator drüber gelaufen, mit Einrückungen


----------



## Flown (4. Okt 2017)

JStein52 hat gesagt.:


> Sieht aus als wäre ein Obfuscator drüber gelaufen, mit Einrückungen


Per se ja eine nette kleine DSL aber dann mit den `+` dazwischen... Da soll sich noch jemand auskennen.


----------



## JStein52 (4. Okt 2017)

Auch eine ganz nette Seite: https://blog.mindorks.com/should-i-learn-kotlin-or-stick-to-java-3a73c3580ac3


----------



## InfectedBytes (4. Okt 2017)

Flown hat gesagt.:


> Was mir negativ auffällt (Scala & Kotlin):
> - Extension Methods
> - Operator Overloading
> - Implicit function parameter (`it`)


Also ich würde Extension Methods und Operator Overloading als Vorteil und nicht als Nachteil ansehen 
Ist aber natürlich geschmackssache


----------



## dzim (4. Okt 2017)

Hm. Also ich würde diese DSL echtem HTML deutlich vorziehen. Das Operator-Overloading kann sicher hilfreich sein, im konkreten Fall sieht es auch eher so "naja" aus. Aber das ist dann ein Problem der HTML-Bibliothek. Muss man ja nicht so machen und ganz sicher auch nicht so brauchen.
Der grosse Vorteil, den ich an Kotlin sehe, ist: Der Code wird kompakter. Sicher kann man so etwas auch mit Libs wie Lombok erreichen, aber da find ich es wieder doof, dass so etwas nicht ein Spach-, oder wenigstens JDK-, Feature ist.


----------



## JStein52 (4. Okt 2017)

dzim hat gesagt.:


> Der grosse Vorteil, den ich an Kotlin sehe, ist: Der Code wird kompakter.


Dieses Argument, egal in welcher Sprache ist nur bis zu einem gewissen Punkt richtig. Ab dann leiden Lesbarkeit und Verständlichkeit.


----------



## dzim (4. Okt 2017)

Stimmt schon. Ich sehe es selbst bei mir, wenn ich viele Lambdas und Streams verwende...

#edit: ich bezog mich eher auf boilerplate code. z.b. wenn es um pojos oder so geht.


----------



## Tobse (4. Okt 2017)

JStein52 hat gesagt.:


> Welchen denn ? Und was bringt das alles wirklich ? Warum muss man vor jede Funktion ein FUN schreiben? Was soll das sparen?
> Diese Pascal-Artige, geschwätzige und doppelpunktverseuchte Syntax ist von großem Übel. Schon Scala nervt nach einiger Zeit. Kotlin sieht mir auch eher nach "Google hat Geld und wir pushen das Ding jetzt" aus, statt dass man mitdenkt.


Du hast aber auch keine Argumente parat, oder? Wir sollten hier Geschmack und Fakten klar trennen.

Das wichtigste Feature an der Sprache ist IMHO die Null-Safety. Deswegen glaube ich auch, dass es so viel mehr bringt, wenn zukünftig mehr Kotlin statt Java oder Scala geschrieben wird. Ich bin bzgl. null immer äußerst vorsichtig und passe immer auf, dass keine NPEs auftreten. Trotzdem findet Kotlin, wenn ich meinen Java Code von IntelliJ nach Kotlin übersetzen lasse, pro 100 Zeilen etwa 1 bis 2 Produktions-Relevante NPEs in meinem Code, welche auch meine Unit-Tests nicht aufgedeckt haben (Das ist abzüglich der Fälle, in welchen die NPE nur theoretisch auftreten kann, praktisch aber andere Checks das verhindern). In "schlechterem" Code findet Kotlin z.T. 5-6 wichtige NPEs pro 100 Zeilen. (sorry, klingt arrogant, ist aber so).
Perspektivisch macht es IMO sogar sinn, irgendwann null gar nicht mehr zu erlauben. Siehe dazu warum überhaupt erst das einführen von Null-Pointern ein schwerer Fehler war.

Außerdem halte ich die Properties ein unglaublich wichtiges Feature, das zudem auch noch besser umgesetzt ist als bei der Konkurrenz C#. Methoden sollten für Dinge verwendet werden, die aus Sicht des Nutzers eines Objektes tatsächlich etwas *tun*. Getter und Setter sind ja nur Mittel zum Zweck, weil Java nix anderes kann. Java hätte hier schon lange aufholen sollen.

Meiner Erfahrung nach macht Kotlin nur mit einer IDE Sinn. Gerade das Operator-Overloading und die Extension-Methods können sehr schwer nachvollziehbar sein, wenn man keine IDE zur Hand hat. Hat man das allerdings (und ernsthaft, wann habt ihr das letzte mal ernsthaften Code außerhalb einer IDE geschrieben?) ist es eine Sache von 2 Keystrokes und man weiss, welche Funktion aufgerufen wird; samt Docs dazu. Deshalb, in einer IDE, machen es diese zwei Features (Extension-Methods und Operator-Overloading) möglich, Code zu schreiben, der weniger Overhead hat und die eigentliche Sache des Codes viel schneller auf den Punkt bringt.

Beim impliziten it Parameter gebe ich @Flown Recht: der ist in komplizierteren Verkettungen von Lambda-Ausdrücken, wo nicht klar ist, auf was er sich jetzt bezieht, eher kontraproduktiv.


----------



## JStein52 (4. Okt 2017)

Tobse hat gesagt.:


> Das wichtigste Feature an der Sprache ist IMHO die Null-Safety.


Mhmm, wenn das die einzigen Fakten sind muss ich sagen dass das in meiner bisherigen Java-Praxis nie wirklich ein Problem war. Und "Geschmack" ist natürlich auch ein wichtiges Element. Ich unterhalte mich im täglichen Leben auch lieber in einer Sprache die ich verstehe und beherrsche. Vielleicht könnte man in Kisuaheli auch manche Dinge prägnanter und weniger missverständlich ausdrücken als ausgerechnet im deutschen wo wir ja manchmal tausend Ausdrücke für das Gleiche haben. Soll ich jetzt Kisuaheli lernen ? Ich traue mich mal vorauszusagen dass in 5 Jahren eine andere Sau durchs Dorf getrieben wird und Kotlin irgendein Nischendasein fristen wird.


----------



## Tobse (4. Okt 2017)

JStein52 hat gesagt.:


> Mhmm, wenn das die einzigen Fakten sind


Siehe die anderen Punkte zu Properties und Operator Overloading bzgl. Semantik.



JStein52 hat gesagt.:


> muss ich sagen dass das in meiner bisherigen Java-Praxis nie wirklich ein Problem war. Und "Geschmack" ist natürlich auch ein wichtiges Element. Ich unterhalte mich im täglichen Leben auch lieber in einer Sprache die ich verstehe und beherrsche.


Das ist ja auch vollkommen in Ordnung  Ich wollte nur klarstellen, dass man der Sprache auch objektiv einige Sachen abgewinnen kann, wenn man möchte. Wenn diese Dinge für deine Arbeit nicht relevant sind oder sich der Lernaufwand nicht rentiert ists eben so.



JStein52 hat gesagt.:


> Ich traue mich mal vorauszusagen dass in 5 Jahren eine andere Sau durchs Dorf getrieben wird und Kotlin irgendein Nischendasein fristen wird.


Die Möglichkeit besteht. Da die Sprache aber ähnliche Features wie Groovy und Scala hat glaube ich, dass Kotlin sich mindestens einige derer Marktanteile abgreift. Wenn Google den Support weiter ausbaut und in der OS Community Hilft, die Vorteile von Kotlin mit den etablierten Java Libraries nutzbar zu machen steht die Sprache nachher stärker da als Groovy und Scala jetzt. Java selbst ersetzen wird es auch IMO niemals.


----------



## Flown (5. Okt 2017)

Tobse hat gesagt.:


> Außerdem halte ich die Properties ein unglaublich wichtiges Feature, das zudem auch noch besser umgesetzt ist als bei der Konkurrenz C#.


Jaein. Ich habe es immer für ein Feature gehalten und auch Scala lange Zeit programmiert und ich finde es persönlich lästig, wenn man im Klassenkopf! nach Properties suchen muss. Auch wenn es in C# ein wenig bloated ist, ist es doch strutkturierter.


Tobse hat gesagt.:


> Siehe die anderen Punkte zu Properties und Operator Overloading bzgl. Semantik.


Sind auch Geschmacksache. Operator Overloading ist zwar nett, aber wer verwendet das wirklich. Ich kann nur von mir und meinen Kollegen ausgehen. Wir haben viele Projekte und richten die Technologien - oft nach Kundenwunsch - so aus, dass sie modern sind. Lange Zeit haben wir was mit C#/.net MVC/Dapper gemacht und da haben wir Operator Overloading genau 0 mal eingesetzt. Weil schlicht und ergreifend eine Methode mehr aussagekraft hat.

Im Allgemeinen sind Extension Methods kontraproduktiv, wenn es um OOP geht. Denn was sind sie? Static Singleton und ich glaube wir haben dazu mal ein richtig langes Gespräch geführt, dass es die Testbarkeit, DI, etc. vermindert.

Es hat wirklich keine "neuen", "innovativen" Features, aber wenn man sich darin wohl fühlt und für einen passt und dann auch noch ein Projekt damit realisieren kann, dann einfach: Do as you please!


----------



## CSHW89 (5. Okt 2017)

@Flown zu Operator Overloading: ob man es in eigenen Klassen einsetzt oder nur benutzt sind zwei verschiedene Dinge. Beim ersten Punkt glaube ich dir die 0, aber beim zweiten? Kein Indexzugriff über "[]"? Wenn eine Sprache Operator Overloading anbietet, kommt es ja auch der Standardlibrary zu gute. Warum muss man in Java "chararray[k]", "charlist.get(k)" und "string.charAt(k)" schreiben, wenn es quasi das gleiche macht? Die arithmetischen Operatoren bei BigInteger sind auch so ein Fall.
Man muss mit diesem Feature halt sehr behutsam vorgehen. Ein häufiger Anwendungsfall in eigenen Klassen sehe ich im übrigen bei Vergleichen. Das Erlauben von Vergleichsoperatoren bei Instanzen von Comparable (über die compareTo-Methode) wäre doch schön.

Grüße
Kevin


----------



## Flown (5. Okt 2017)

CSHW89 hat gesagt.:


> @Flown zu Operator Overloading: ob man es in eigenen Klassen einsetzt oder nur benutzt sind zwei verschiedene Dinge. Beim ersten Punkt glaube ich dir die 0, aber beim zweiten? Kein Indexzugriff über "[]"? Wenn eine Sprache Operator Overloading anbietet, kommt es ja auch der Standardlibrary zu gute. Warum muss man in Java "chararray[k]", "charlist.get(k)" und "string.charAt(k)" schreiben, wenn es quasi das gleiche macht? Die arithmetischen Operatoren bei BigInteger sind auch so ein Fall.


Wenn du Indexer zu Operator-overloading dazuzählst, ok. Trotzdem nicht in den eigenen Klassen implementiert, da die Standardbibliothek einfach mächtig genug war (C# - exzessives Linq).


CSHW89 hat gesagt.:


> Die arithmetischen Operatoren bei BigInteger sind auch so ein Fall.


Wäre nett wenn man das hätte oder vielleicht sogar als Standardtyp behandelt.


CSHW89 hat gesagt.:


> Man muss mit diesem Feature halt sehr behutsam vorgehen


Exakt, sonst siehst aus wie in Scala mit den Tausend "Operatoren" :+, +:, <:<, etc.. Das ist nicht aussagekräftig und nicht lesbar.


CSHW89 hat gesagt.:


> Ein häufiger Anwendungsfall in eigenen Klassen sehe ich im übrigen bei Vergleichen. Das Erlauben von Vergleichsoperatoren bei Instanzen von Comparable (über die compareTo-Methode) wäre doch schön.


Das könnte ich mir gut vorstellen, aber in Produktionscode habe ich selten Comparable/Comparator implementiert (meist weil die UI Komponenten das schon selbst können - Tables).


----------



## Flown (5. Okt 2017)

Ich möchte das ja keinem madig reden. Jeder sollte das für sich entscheiden was lesbar und leicht zu verstehen ist. Ich wollte eigentlich nur ausdrücken, dass kürzer oft nicht lesbarer bedeutet. Auch das eine Methode oft aussagekräftiger ist, als ein Operator. Natürlich gibt es da Ausnahmen, wie Indexer, oder Operatoratoren für mathematische Komponenten (e.g. BigInteger).

Aber eigentlich geht es um Kotlin und ich bin der Meinung, dass es keine Innovation bietet und nur eine kurze Hype-Welle ist. Aber mal schauen, vielleicht werde ich ja eines Besseren belehrt.


----------



## Tobse (5. Okt 2017)

Flown hat gesagt.:


> ich bin der Meinung, dass es keine Innovation bietet


Sehe ich auch so - verglichen mit anderen Sprachen ist es nur eine weitere ohne Alleinstellungsmerkmal. Aber es enthält viele Dinge, die ich in Java vermisse, und welche in der Community gut ankommen (siehe C#, TypeScript, @NonNull-Annotation Preprocessoren für Java, ...)


----------



## Flown (5. Okt 2017)

Nicht direkt vermissen, sondern mit Mehraufwand verbunden ist.


----------



## dzim (6. Okt 2017)

Sagen wir es doch so: "Konkurrenz belebt das Geschäft." Vielleicht erhält dadurch - und durch den versprochenen Boost in der Release-Geschwindigkeit - Java endlich mal die Möglichkeit, auch mit moderneren Features nachzuziehen.
Man kann sich zwar streiten, ob all die Features in einer primär OOP-Sprache etwas zu suchen haben, aber da Java ja auch nur bedingt OOP ist, wird dadurch auch nichts "verseucht". Undegal, ob Kotlin persönlich gefällt, oder nicht: Wenn der einzelene Entwickler dadurch sich besser "fühlt" oder effizienter wird, dann lasst es doch zu. Sonst könnte man ja gleich sagen, alle anderen Sprachen haben auf der JVM nichts zu suchen. Kotlin hat seinen Hype und auch wie bei Groovy u.ä. wird sich das wieder etwas geben. Ok. Vielleicht nicht ganz, denn durch den "Ritterschlag" durch Google werden es natürlich sehr viele auf Android nutzen...


----------



## temi (8. Jul 2022)

JStein52 hat gesagt.:


> Ich traue mich mal vorauszusagen dass in 5 Jahren eine andere Sau durchs Dorf getrieben wird und Kotlin irgendein Nischendasein fristen wird.


Die fünf Jahre sind fast um, wie ist die Lage? Ist ja ganz spannend, dass die damalige Zukunft inzwischen zur Gegenwart geworden ist. 

Ich beschäftige mich auch gerade etwas mit Kotlin und mache erste Gehversuche damit. Grundsätzlich gefällt mir die Sprache und ihre Features ganz gut, obwohl ich natürlich noch nicht sehr aussagefähig dazu bin.


----------



## Robertop (8. Jul 2022)

Wenn ich in meiner Freizeit mal kleine Apps programmiere, benutze ich eigentlich nur noch Kotlin. Obwohl ich schon seit vielen vielen Jahren Java programmiere, kommt es mir so vor, als würde sich Code in Kotlin flüssiger von der Hand schreiben lassen. 

Wobei ich oft, wenn ich Java-Entwicklern von Kotlin erzähle, höre, dass die aktuellsten Java Versionen wohl auch viele der Features von Kotlin übernommen haben. Ich glaube, einer hat mir sogar mal gesagt, dass man an Kotlin immer erkennen kann, wie das übernächste Java aussehen wird. 😂 Weil ich selber aber noch meist mit Java 8 und Legacy Code arbeite, kann ich da nicht wirklich viel zu sagen.


----------



## yfons123 (8. Jul 2022)

es ist halt ein andauerndes geben und nehmen... manche nehmen halt die ganze


----------



## mihe7 (8. Jul 2022)

Robertop hat gesagt.:


> Ich glaube, einer hat mir sogar mal gesagt, dass man an Kotlin immer erkennen kann, wie das übernächste Java aussehen wird. 😂


Ah, da spielt nicht nur Kotlin eine Rolle. Es gibt z. B. einen JEP-Entwurf für String Templates. Da werden 9 Sprachen aufgezählt, in denen es dieses Feature gibt.


----------



## dzim (13. Jul 2022)

Also ich schreibe inzwischen alle Anwendungen - egal ob klein oder gross - im JVM-Umfeld nur noch mit Kotlin.

Z.B. habe ich unsere bisherige Desktop-Anwendung von Grund auf neugeschrieben. Etwas Java-Legacy ist übrig geblieben, worauf ich keine Lust hatte es umzuwandeln, aber das gesamte GUI und die meisten Services, Modelle, etc. sind alles Kotlin.

Java beginnt tatsächlich einige Ideen zu übernehmen, bleibt aber immer noch deutlich mehr verbos, als Kotlin. Und lokale Funktionen und Extension Functions, etc. fehlen mir einfach. Für mich ist es daher eher mühsam Anwendungen, die auf Java setzen, zu warten.


----------



## Robert Zenz (13. Jul 2022)

dzim hat gesagt.:


> Java beginnt tatsächlich einige Ideen zu übernehmen, bleibt aber immer noch deutlich mehr verbos, als Kotlin.



Ich habe noch nie verstanden wieso das etwas negatives ist. Fuer mich ist das so als wuerde jemand argumentieren dass "grdSlRws" ein besserer Variablenname ist als "gridSelectedRows". Die _Deutlichkeit_ von Java ist ja gerade das gute an der Sprache, weil als Negativ-Beispiel fuer "da muss ich nicht so viel tippen" kann man immer Perl/Raku anfuehren. Also in meiner Erfahrung ist "die Menge welche man tippen oder lesen muss" in Java noch nie eine Limitierung in irgendeiner Form gewesen.

Aber gut, ich dachte da gerade an die Syntax selbst.


----------



## yfons123 (13. Jul 2022)

dzim hat gesagt.:


> Extension Functions


diese kannst du dir ganz einfach selber bauen in java



dzim hat gesagt.:


> lokale Funktionen


du hast eine funktion die du aufteilen willst in mehrere lokale funktionen... dann teil sie halt auf in private oder protected methods ? deine method tut ja mehr als 1e ansonten würdest du es nicht aufteilen


----------



## KonradN (13. Jul 2022)

Erst einmal sorry, bin auf Absenden gekommen, als ich alles löschen wollte um neu anzusetzen ....

Zu Extension Function: Diese sind so nicht in Java erstellbar. Da bleibt nur der Weg über statische Methoden, wie man an den ganzen Util-Klassen erkennen kann.

Hier ist aber einfach das Problem. dass hier die Eindeutigkeit nicht gewährleistet ist. Daher ist bei .Net von Microsoft eine Art Vorgabe / Best Practice, dass diese nicht in Libraries verwendet werden sollen. Von so lustigen Ungereimtheiten wie keine NPE bei Aufrufen auf null mal ganz zu schweigen.

Operatoren überladen - so toll wie das auf den erste Blick erscheint: Das ist schnell nicht mehr zu überblicken. Was ist "abc" / "b"? Und "abc" % "c"? Das kann auch recht verwirren. Es gibt Fälle, wo man sich sowas wünschen würde (z.B. BigInteger) weil ein Datentyp vom Verhalten her da durchaus klar ist, aber das sind in der Regel ja doch eher die Ausnahmen.

Lokale Funktionen sind aus meiner Sicht schlicht sinnlos. Das ist ein Zeichen, dass da jemand den Bedarf hat, etwas zu strukturieren und zu kapseln aber keine neue Klasse erstellen will. Wir wollen im clean Code ja Methoden klein und übersichtlich halten. Aber dann machen wir es so groß, dass wir Funktionen in Funktionen haben wollen. Und das wird dann noch als "Clean Code" verkauft weil das tolle Kapselung sein soll? Also irgendwie kann ich dem nicht wirklich folgen.

Das sind also so Entwicklungen, die ich nicht brauche und die auch eher zu Problemen führen können...


----------



## yfons123 (13. Jul 2022)

wi was vieles was


----------



## KonradN (13. Jul 2022)

yfons123 hat gesagt.:


> wi was vieles was


Ja, wenn man anfängt was zu schreiben ... dann beim Löschen irgendwie auf Antwort erstellen klickt ... schon doof ... ist aber editiert


----------



## yfons123 (13. Jul 2022)

KonradN hat gesagt.:


> Zu Extension Function: Diese sind so nicht in Java erstellbar. Da bleibt nur der Weg über statische Methoden, wie man an den ganzen Util-Klassen erkennen kann.


wenn du in c# eine extension method erstellst zb


```
public static class RectExtension{
    public static void bob(this Rect rect){
    }
}
```
ermöglicht es dir das zu tun


> rect.bob();


bei einem rectangle objekt aber das wird umgewandelt in


> RectExtension.bob(rect);


also hast du nur während dem tippen was "einfacheres" aber under da hood.. ist das genau das gleiche wie man sie aus den util klassen kennt.. 

mir wurde aberr gesagt dass man diese nicht wie streusel ins programm tun sollte sondern nur wenn man es wirklich braucht


----------



## mihe7 (13. Jul 2022)

KonradN hat gesagt.:


> Operatoren überladen - so toll wie das auf den erste Blick erscheint: Das ist schnell nicht mehr zu überblicken. Was ist "abc" / "b"? Und "abc" % "c"? Das kann auch recht verwirren. Es gibt Fälle, wo man sich sowas wünschen würde (z.B. BigInteger) weil ein Datentyp vom Verhalten her da durchaus klar ist, aber das sind in der Regel ja doch eher die Ausnahmen.


Ja, nur wären das schon sehr schöne Ausnahmen  Das Argument, dass man "Schindluder" damit betreiben kann, halte ich für irrelevant, das gilt ja für alles.

Apropos Schindluder... lokale Funktionen kann man in Java über lokale Klassen und ggf. Lambdas "lösen".

```
fun dfs(graph: Graph) {
    fun dfs(current: Vertex, visited: MutableSet<Vertex>) {
        if (!visited.add(current)) return
        for (v in current.neighbors)
            dfs(v, visited)
    }

    dfs(graph.vertices[0], HashSet())
}
```


```
void dfs(Graph graph) {
    class DFS {
        static void visit(Vertex current, Set<Vertex> visited) {
            if (!visited.add(current)) return;
            for (Vertex v : current.neighbors)
                visit(v, visited);
        }
    };

    DFS.visit(graph.vertices[0], new HashSet<>());
}
```
Mir ist nur nicht klar: was soll das bringen?!?


----------



## yfons123 (13. Jul 2022)

mihe7 hat gesagt.:


> Mir ist nur nicht klar: was soll das bringen?!?


haaalt stopp... man spart sich das class dfs..


----------



## dzim (14. Jul 2022)

Ich verwende Extension Functions z.B. dann oft, wenn ich durch eine Library etwas vorgegeben habe, wo mir aber Funktionalität fehlt.

Einfaches Beispiel: Ich habe Klasse mit Konfigurationsdaten für einen MQTT-Broker. Ich habe Bibliothek X, die mir einen MQTT-Client bietet. So baue ich mir eine einfache Extension, die aus der Konfig einen Client auspuckt. (Es gibt sicher bessere Beispiele, aber das kam mir gerade als erstes in den Sinn, weil ich so was tatsächlich kürzlich mal gebraucht habe.)
Oft verwende ich es aber auch nur Lokal innerhalb einer Klasse. Also so dass nur diese darauf Zugriff hat.
Öffentliche Extensions sind bei mir meistens tatsächlich nur Convenience, um mir irgendeine API einfacher zu machen.

```
fun Long.toLocalDateTime(): LocalDateTime = LocalDateTime.ofInstant(Instant.ofEpochMilli(this), ZoneId.systemDefault())
fun LocalDateTime.toEpochMillis() = atZone(ZoneId.systemDefault()).toInstant().toEpochMilli()
```
Kotlin im JVM-Umfeld macht übrigens am Ende auch nur das, was @yfons123 über C# gesagt hat. Unter der Haube sind es Utility-Klassen. Aber es geht ja darum, wie es die Sprache löst, nicht was unten drunter auf Ebene der JVM abgeht.

Und lokale Funktionen können schon sinnvoll sein - zugegeben selten, aber sie können.
Natürlich ist die Gefahr von Cognitive Overload oder schlicht schlechtem Design gegeben, aber, in Maßen eingesetzt sind die sinnvoll. Wenn du z.B. innerhalb dieser Funktion auf alles Variablen in dem Scope zugreifen möchtest (z.B. die Parameter der äusseren Funktion).
Was Java angeht, kann man lokale Funtionen ja auf verschiedene Art realisieren. Am einfachsten sind sicher die Interfaces aus java.util.function in Kombination mit Lamdas ein Ersatz, wenn man es braucht.

Und Operatoren zu überladen traue ich mich ehrlich gesagt auch nicht, weil die Gefahr, dass niemand mehr den Code versteht, warum etwas wie funktioniert, sehr schnell gross wird.

@Robert Zenz ich sage übrigens nicht, dass Java uneindeutig ist. Ist Kotlin per se ja auch nicht. Ich sage nur, dass ich manches zeremoniell als störend empfinde. Bestes Beispiel sind optionale Parameter einer Methode. In Java heisst das: du musst so viele Methoden anlegen, um alle Fälle abzudecken. In Kotlin kannst du defaults and den Funktionsparameters setzen. Beim Aufruf musst du nur das setzen, was zwingend notwendig ist, den Rest _kannst _du über benannte Parameter setzen (wenn du nur einzelne der optionalen Parameter ändern willst).

Es kam wahrscheinlich etwas falsch rüber: Ich finde nach wie vor Java nicht "doof" oder obsolet oder so was, nur für *mich persönlich* ist es so, dass ich Kotlin auf der JVM als bequemer und schlicht besser empfinde.


----------



## Robert Zenz (14. Jul 2022)

dzim hat gesagt.:


> @Robert Zenz ich sage übrigens nicht, dass Java uneindeutig ist. Ist Kotlin per se ja auch nicht. Ich sage nur, dass ich manches zeremoniell als störend empfinde. Bestes Beispiel sind optionale Parameter einer Methode. In Java heisst das: du musst so viele Methoden anlegen, um alle Fälle abzudecken. In Kotlin kannst du defaults and den Funktionsparameters setzen. Beim Aufruf musst du nur das setzen, was zwingend notwendig ist, den Rest _kannst _du über benannte Parameter setzen (wenn du nur einzelne der optionalen Parameter ändern willst).
> 
> Es kam wahrscheinlich etwas falsch rüber: Ich finde nach wie vor Java nicht "doof" oder obsolet oder so was, nur für *mich persönlich* ist es so, dass ich Kotlin auf der JVM als bequemer und schlicht besser empfinde.



Du kannst moegen was du willst, mir ging es um das Konzept "Sprache X ist besser weil ich da weniger tippen oder lesen muss und alles kompakter schreiben kann". Das ist etwas was immer gerne herumgeworfen wird als Argument, aber meiner Meinung nach willst du genau das in Projekten nicht. Viele kommerzielle Projekte leben mehrere Dekaden, und auch mittlere bis kleinere Projekte koennen schonmal durch 50+ Haende gehen in ihrer Lebenszeit. Da willst du so wenige Sonderfaelle wie moeglich und auch so eine klare Syntax und Struktur wie moeglich.

Ein relativ einfaches Beispiel ist `var` und `val`. In Java verwenden wir `final`:


```
String name = "value";
final String name = "value";
```


```
var name = "value";
val name = "value";
```

Es ist relativ schwer in Java zu uebersehen dass die Variable entweder `final` ist oder nicht, der Unterschied in Kotlin ist da nur ein Zeichen. In Erweiterung dazu ist die fehlende Typ-Deklaration auch etwas was ich persoenlich als problematisch sehe, weil man hat nicht immer eine IDE welche einem die Typen aufloest. Explizit zu sein ist immer besser als Implizit zu sein. Aber gut, die kann man ja nachtragen:


```
MyCoolObjectThatDoesNotImplementList items = getAllTheItems():

items.add(myItem);
```


```
var items: MyCoolObjectThatDoesNotImplementList = getAllTheItems():

items.add(myItem);
```

Wenn man die Typen nicht explizit angibt, hat man immer den "richtigen" Typen, das kann schonmal problematisch sein wenn man eigentlich immer die Schnittstellen verwenden sollte.

Was ebenfalls nicht hilft ist wenn die Sprache viele Moeglichkeiten hat Dinge zu tun, und dann auch noch in einer "kompakten" Weise vielleicht. Ich muss da eventuell etwas ausholen. Nehmen wir zum Beispiel Getter und Setter. Wie definiert man Getter und Setter in Java?


```
public String getName() {
    return name;
}

public void setName(String name) {
    this.name = name;
}
```

Genau so. Es gibt keinen anderen Weg von der Sprache aus. Wenn wir eine Write-Only Eigenschaft haben, lassen wir den Getter weg, wenn wir eine Read-Only Eigenschaft haben, lassen wir den Setter weg. Ganz einfach. Wenn wir jetzt aber mal zu C# schauen, wie definiert man dort Getter und Setter?


```
public String GetName()
{
    return name;
}

public void SetName(String name)
{
    _name = name;
}
```

Oder


```
public String Name
{
    get { return _name; }    
    set { _name = value; }
}
```

Oder


```
public String Name
{
    get => _name;
    set => _name = value;
}
```

Oder


```
public String Name
{ get; set; }
```

Wir haben also schon 4 unterschiedliche Moeglichkeiten in C# nur um Getter und Setter zu schreiben (das sind alles Wege die in der offiziellen Dokumentation angegeben werden). Je nach Umstand und persoenlicher Vorliebe wird eine andere Art verwendet. Das ist nicht hilfreich weil du immer mit 4 moeglichen Konstrukten zu tun hast. Und sehen wir der Wahrheit ins Auge, wenn das Projekt uebergeben wird, wird der nachfolgende Programmierer vermutlich eine andere Meinung haben und nicht die notwendigen Resourcen (oder Willen) haben das gesamte Projekt zu aendern. Damit divergiert der Code dann und man hat zwei oder mehr Wege im Projekt Dinge zu tun. Das hilft nicht.

In Kotlin gibt es da auch mehrere Wege, wenn ich das richtig sehe.

Etwas weiteres was ich an Java sehr schaetze ist, dass es ohne viele Sonderzeichen oder "Markierungswoerter" auskommt und dabei doch sehr explizit ist. Zum Beispiel Funktionsdeklarationen:


```
String getHello(String name) {
    return "Hello " + name + "!";
}
```


```
fun getHello(name: String): String {
    return "Hello " + name + "!";
}
```

Wieso brauche ich `fun` als Schluesselwort? Man kann doch aus der Deklaration sehen das es eine Methode ist. Und wieso der Doppelpunkt? Die Deklaration in Kotlin ist dadurch sogar laenger als die in Java. Da empfinde ich die Syntax von Kotlin eher als unnoetig kompliziert.

Ein extremeres Beispiel in der Hinsicht ist VB.NET bei Variablen:


```
String name = "value";
```


```
Dim name As String = "value"
```

Da habe ich sogar zwei unnoetige Woerter in der Deklaration.

...bin etwas abgedriftet, glaube ich...


----------



## yfons123 (14. Jul 2022)

```
public String Name
{
    get => _name;
    set => _name = value;
}
```


```
public String Name
{
    get { return _name; }   
    set { _name = value; }
}
```
das hat nichts mit getter und setter zu tun dass sie unterschiedlich sind... das ist einfach nur die eigenschaft dass man expression bodies in c# hat .. also einzeiler methoden

du kannst eine readonly dann sogar zwei mal expression bodien


```
public string Name => "bob";
```
 dann hast du eine expression body readonly property ... und seit neuestem c# kannst du auch noch init only setter machen ... 


Robert Zenz hat gesagt.:


> var name = "value"; val name = "value";



lombok hat java um val ergänzt... also gibts das auch in java


----------



## KonradN (14. Jul 2022)

Das ist dann zwar jetzt OFF Topic weil nicht mehr auf Kotlin bezogen, aber das will ich doch einmal kurz nutzen um zu projectlombok paar Worte zu sagen.


yfons123 hat gesagt.:


> lombok hat java um val ergänzt... also gibts das auch in java


Aber will man das auch nutzen? Ich bin vor ca. 2 Jahren mal projectlombok durchgegangen und habe die Features etwas sortiert in

positiv bewertet (kann/soll man nutzen)
neutral bewertet (könnte man nutzen, wenn man unbedingt will. Aber eigentlich gibt es keinen Grund dafür)
negativ bewertet (Auf keinen Fall nutzen!)

var ist negativ bewertet, da es einfach keinen Mehrwert bringt. Dann doch lieber ein `final var` - wobei ich kein Fan von var bin. Das ist zwar kürzer aber bringt nicht mehr Lesbarkeit.

Ähnlich das @Cleanup - dazu gibt es try with resources. Und da diese in der Regel auch mit Exceptions verbunden sind, gewinnt man nicht wirklich was.

Unter dem Strich sind nur eine Hand voll Annotations interessant - halt wenn es um Getter / Setter geht oder toString(). Auch Builder lassen sich damit schön aufbauen. Equals / Hashcode kann interessant sein, aber sobald man die Elemente persistent hält, wird man vermutlich eine eigene Implementation haben (die ich dann in einer AbstractEntity habe).

Das aber nur als kleine Anregung, weil es da etwas angeklungen ist. Man kann das gerne in einem eigenen Thread thematisieren (Hatten wir auch schon einmal vor einiger Zeit meine Ich und wenn ich mich richtig erinnere, dann gab es da auch einige kritische Stimmen, die sich so Code dann auch lieber per IDE erzeugen liessen.


----------



## dzim (15. Jul 2022)

Egal was Lombok macht oder kann, das keyword "var" ist teil von Java 11+ und hat nichts mit Lombok zu tun, sondern fügt halt nur lokale Type Inferenze ein. Das kann man problemantisch sehen, aber _lokal_ bedeutet ja eben, dass man normalerweise als Entwickler hier eindeutig nachvollziehen kann, was es nun eben ist.


----------



## KonradN (15. Jul 2022)

dzim hat gesagt.:


> Egal was Lombok macht oder kann, das keyword "var" ist teil von Java 11+


Sorry, aber wir haben deutlich über das "val" von Lombok gesprochen.  Daher frage ich mich jetzt gerade, was du genau willst. Evtl. einfach den Beitrag nicht verstanden?



dzim hat gesagt.:


> Das kann man problemantisch sehen, aber _lokal_ bedeutet ja eben, dass man normalerweise als Entwickler hier eindeutig nachvollziehen kann, was es nun eben ist.


Nur weil man meint, dass "ein Entwickler das nachvollziehen kann" darf man nicht meinen, dass es gut ist. Ein Entwickler kann auch schlechten Code nachvollziehen. Daraus ist aber dann doch nicht abzuleiten, dass es kein Clean Code braucht.

Daher: ja, ich sehe das durchaus kritisch.


----------



## yfons123 (15. Jul 2022)

KonradN hat gesagt.:


> var ist negativ bewertet,





KonradN hat gesagt.:


> Sorry, aber wir haben deutlich über das "val" von Lombok gesprochen. Daher frage ich mich jetzt gerade, was du genau willst.


ich frage mich auch vieles... so viele fragen


----------



## KonradN (15. Jul 2022)

Ahh ... da hatte ich einen Tippfehler und in der Auflistung versehentlich einmal var statt val geschrieben. Danke für die Aufklärung.

Wobei Lombok auch ein var bietet.


----------



## temi (15. Jul 2022)

KonradN hat gesagt.:


> var ist negativ bewertet, da es einfach keinen Mehrwert bringt. Dann doch lieber ein `final var` - wobei ich kein Fan von var bin. Das ist zwar kürzer aber bringt nicht mehr Lesbarkeit.


Ich persönlich halte den Ansatz von Unveränderbarkeit als Standard für sehr gut. Insofern würde ich für die Lösung von Rust plädieren, wo man Mutablilität explizit definieren muss. Insofern ist der Ansatz von Java mit "verwende möglichst immer final, wo es nur geht" genau verkehrt herum.

Interessanterweise wird in C++ geraten möglichst immer "var" zu verwenden und Typen nicht explizit zu definieren. Aber ich halte C++ auch nicht für besonders "gut".

Interessante Diskussion hier, aber meines Erachtens kommen hier die, zumindest vermeintlichen, Vorteile von Kotlin etwas kurz. Kotlin wirbt ja (wie auch Rust) damit eine sichere(re) Sprache zu sein und manche Programmierfehler zu vermeiden, z. B. Nullsafety.

Hier darauf herum zu reiten, ob man "fun", "var" oder "val" schreiben muss, halte ich für etwas Kleinbürgerlich und Clean Code gibt es durchaus auch in anderen Sprachen als Java. Das ist ein eher sprachunabhängiges Konzept.


----------



## yfons123 (15. Jul 2022)

temi hat gesagt.:


> , z. B. Nullsafety.


joa... aber braucht man das  ? 

c# hat auch den caoalescing operator zb



> obj ??= new ();


oder


> obj?.do();


braucht man das ? ... nicht wirklich und unity ist da auch noch in ein problem gelaufen wenn 2 sprachen die objekte nutzt ...

es kann sein dass auf engine seite das objekt schon tod ist aber auf c# seite noch nicht dann funktioniert die nullsafety nicht.. wann wäre es den null?


----------



## mihe7 (15. Jul 2022)

yfons123 hat gesagt.:


> joa... aber braucht man das ?


Schon mal in BASIC eine NPE gehabt?


----------



## KonradN (15. Jul 2022)

Aber es gab ja schon Ansätze, dass man NPE über reine statische Codeanalyse verhindern könnte. Aber irgendwie hat das nie jemanden interessiert.
Daher scheint das kein wirklichen Bedarf dafür zu geben. 

Zumindest ich habe in freier Wildbahn sowas noch nicht gesehen.


----------



## LimDul (15. Jul 2022)

yfons123 hat gesagt.:


> joa... aber braucht man das  ?


Ja!
NPEs sind mit die häßlichsten Exceptions, weil die gerne mal "random" auftreten.

Wir haben bei uns einen Wrapper (Decimal) um BigDecimal, wo es auch ein NULL-Objekt gibt. So dass ich folgendes machen kann:


```
Decimal.valueOf(20).add(Decimal.NULL)
```
Das macht Rechnungen so viel einfacher, wenn man nicht dauernd auf != null prüfen muss. 

Wir arbeiten auch viel mit SpotBugs CheckForNull / NonNull um einfach früh auf Fehler hingewiesen zu werden.


----------



## yfons123 (15. Jul 2022)

mihe7 hat gesagt.:


> Schon mal in BASIC eine NPE gehabt?


nein ich hatte das vergnügen nur einmal mit visual basic zu arbeiten als ich makros für word dokumente im 6ten semester erstellen durfte... ach wie ich basic vermisse... so eine einfache übersichtliche sprache

und dass alles halb deutsch und englisch gemischt ist... einfach herrlich 
dass in excel alles deutsch ist und in word alles englisch macht es auch natürlich viel einfacher


----------



## KonradN (15. Jul 2022)

LimDul hat gesagt.:


> Wir arbeiten auch viel mit SpotBugs CheckForNull / NonNull um einfach früh auf Fehler hingewiesen zu werden.


Ja, sowas macht durchaus Sinn und wie du gesehen hast: Ich habe mich gewundert, denn ich habe das bisher so richtig in Projekten noch nicht gesehen und das hat mich halt gewundert.

Hast Du Dir den Kotlin schon im Detail angesehen und würde das hier wirklich so viel verändern?
Vielleicht habe ich da auch bisher nur schlechten Code gesehen, denn da war das dann meist nur etwas, das man als if (x != null) x.doSomething();. Aber ich sehe es nicht als wirklichen Vorteil, keine NPE zu bekommen, denn in der Regel ist das ja nur ein weitermachen, wo vorher bereits ein Fehler passiert ist.

Aber da ich mich da noch nicht so tief mit beschäftigt habe, kannst Du da ggf. noch etwas mehr dazu sagen.


----------



## LimDul (15. Jul 2022)

Ich hab von Kotlin null Ahnung, daher kann ich dazu nix sagen. Aber eine NPE vermeiden kann man glaub ich nicht nur mit Sprachfeatures, sondern nur mit gescheiter Softwarearchitektur + Sprachfeatures die das fördern.


----------



## mihe7 (16. Jul 2022)

yfons123 hat gesagt.:


> nein ich hatte das vergnügen nur einmal mit visual basic zu arbeiten als ich makros für word dokumente im 6ten semester erstellen durfte... ach wie ich basic vermisse... so eine einfache übersichtliche sprache


In BASIC wirst Du Dich schwer tun, denn die Sprache kennt kein null. Kein null -> keine NPE


----------



## KonradN (16. Jul 2022)

mihe7 hat gesagt.:


> In BASIC wirst Du Dich schwer tun, denn die Sprache kennt kein null. Kein null -> keine NPE


Das stimmt so nicht. Es gibt viele Basic Varianten und Visual Basic .Net kennt auch ein null. Heißt dort aber Nothing.









						Nothing-Schlüsselwort - Visual Basic
					

Weitere Informationen: Nothing-Schlüsselwort (Visual Basic)



					docs.microsoft.com


----------



## mihe7 (16. Jul 2022)

KonradN hat gesagt.:


> Das stimmt so nicht. Es gibt viele Basic Varianten und Visual Basic .Net kennt auch ein null. Heißt dort aber Nothing.
> 
> 
> 
> ...


Darum habe ich ja auch von BASIC geschrieben, nicht von irgendwelchen Dialekten oder VB. 

Der Punkt ist doch: wo nichts auf null zeigen kann, kann es auch keine NPE geben. Klar, man kann alles mögliche dagegen tun, aber genau genommen, ist das doch schwachsinnig. Hätten wir in den Sprachen kein null, bräuchte man sich darum nicht zu kümmern. 

Kotlin macht das in vielen Fällen, wobei ich mich frage, warum man nicht ganz auf null verzichtet hat. Stattdessen spendiert man der Sprache noch einen not-null-assertion-Operator, der dazu dient, im Fall von null eine NPE zu werfen.


----------



## Jw456 (16. Jul 2022)

> Kotlin macht das in vielen Fällen, wobei ich mich frage, warum man nicht ganz auf null verzichtet hat.


weil es sonnst noch schwerer wäre Kotlin und Java Code zu mischen. Der Aufruf eine Java Klasse / Methode wäre schwieriger.


----------



## Jw456 (16. Jul 2022)

Der !! Operator dient auch dazu um zb. beim Aufruf einer Java Methode die null zurückgeben kann.  Das Ergebnis aber  in eine nicht nullbaren  Variablen gespeichert werden soll. 
Das würde der Kompiler  sonst gar nicht zu lassen. In Kotlin hast du nun die Möglichkeit auf die NPE  zu reagieren.


----------



## mrBrown (16. Jul 2022)

KonradN hat gesagt.:


> Ja, sowas macht durchaus Sinn und wie du gesehen hast: Ich habe mich gewundert, denn ich habe das bisher so richtig in Projekten noch nicht gesehen und das hat mich halt gewundert.


Jetbrains nutzt es relativ viel, und IntelliJ hat recht gute Unterstützung dafür.


----------



## KonradN (16. Jul 2022)

mrBrown hat gesagt.:


> Jetbrains nutzt es relativ viel, und IntelliJ hat recht gute Unterstützung dafür.


Ok, Quellcode, der von Jetbrains kommt, habe ich bisher noch nicht gross gesehen. Die Unterstützung in IntelliJ kenne ich. Das habe ich mir damals alles mal angesehen als wir vor paar Jahren mal eine Diskussion rund um Clean Code hatten. Ist aber schon lange her ... Nur das findet man sonst fast nie. Ich mag da nur ein sehr eingeschränkten Bereich sehen, aber wenn ich dann in jedem Maven Projekt direkt das PMD Plugin drin habe macht mich gefühlt schon fast zum Ausgegrenzten.


----------



## mihe7 (16. Jul 2022)

Jw456 hat gesagt.:


> weil es sonnst noch schwerer wäre Kotlin und Java Code zu mischen. Der Aufruf eine Java Klasse / Methode wäre schwieriger.


Stimmt, man könnte kein null übergeben...


----------



## mihe7 (16. Jul 2022)

Jw456 hat gesagt.:


> Der !! Operator dient auch dazu um zb. beim Aufruf einer Java Methode die null zurückgeben kann. Das Ergebnis aber in eine nicht nullbaren Variablen gespeichert werden soll.


Dafür gäbe es ja z. B. den Elvis-Operator.


----------



## KonradN (16. Jul 2022)

In der Sprache Kotlin sehe ich auch nicht so sehr die großen Vorteile. Ich habe es mir damals auch einmal angesehen und war kurz davor zu wechseln. Aber was auf den ersten Blick toll und gut aussah hatte dann doch nicht den Vorteil, den man sich erhofft hat. Ich bin damals auch über ein Blog Eintrag gestolpert, der das ein kleines bisschen beschreibt. Ist so nicht ganz meine Sicht, aber ich gebe den Link einfach einmal rein: https://blog.allegro.tech/2018/05/From-Java-to-Kotlin-and-Back-Again.html

Man kann vieles Diskutieren. Und ja, manches ist besser. Legacy Code war ein Problem, aber da gibt es dann Lösungen wie z.B. Project Lombok. Und wenn einem die Probleme mit null so problematisch scheinen: https://spotbugs.github.io/ ist ja schon erwähnt worden und man kann @CheckForNull und @Nonnull nutzen und hat dann auch eine sehr gute zusätzliche Sicherheit.


----------



## temi (16. Jul 2022)

KonradN hat gesagt.:


> Und wenn einem die Probleme mit null so problematisch scheinen: https://spotbugs.github.io/ ist ja schon erwähnt worden und man kann @CheckForNull und @Nonnull nutzen und hat dann auch eine sehr gute zusätzliche Sicherheit.


Es ist schon ein entscheidender Unterschied, ob eine Sprache es zwar ermöglicht bestimmte Dinge besser (und sicherer) zu lösen, aber es "im Standard" nicht tut oder ob eine Sprache bestimmte Sachen von Haus gar nicht zulässt, oder man es explizit erlauben muss.

Rust geht da z. B.  ja noch einen Schritt weiter.


----------



## KonradN (16. Jul 2022)

temi hat gesagt.:


> Es ist schon ein entscheidender Unterschied, ob eine Sprache es zwar ermöglicht bestimmte Dinge besser (und sicherer) zu lösen, aber es "im Standard" nicht tut oder ob eine Sprache bestimmte Sachen von Haus gar nicht zulässt, oder man es explizit erlauben muss.
> 
> Rust geht da z. B.  ja noch einen Schritt weiter.


Da Kotlin aber immer noch vieles zulässt bringt es unter dem Strich eben nicht wirklich eine Besserung. Dafür, dass es sonst we groß angepriesen wird war es unter dem Strich in meinen Augen enttäuschend und führte dazu, dass dann galt keine NPE kommt aber halt einfach etwas nicht gemacht wurde... Das ist dann diese ? Syntax oder erinnere ich mich falsch? Ist schon zu lange her.

Bitte mich nicht missverstehen: Das ist durchaus eine Entwicklung, die ich begrüße und ich will es nicht zerreden. Meine Punkte sind schlicht:

das kann man mit Java auch haben wenn man es will.
die Wichtigkeit sehe ich in der Praxis nicht, denn ich sehe dies bei kaum einem Entwickler. Ich finde es extrem befremdlich, wenn hier Java Entwickler auftreten und sagen "Das ist ein wichtiger Punkt, das muss man haben", aber dann werden die Möglichkeiten nicht genutzt.

Und das ganze Thema Clean Code ist wichtig, aber wie viele Projekte haben das nicht? Auch hier im Forum haben wir Diskussionen mit Entwicklern mit vielen Jahren Erfahrung, die dann Unit Tests ablehnen. Das ist kein Argument, dass es sowas nicht braucht. Aber die Gewichtung ist da dann wichtig.

Und wir reden hier darüber, die Sprache zu wechseln. Warum zu Kotlin wechseln? Evtl. sind dann andere Sprachen besser. Rust hast du erwähnt. Go hat teilweise interessante Ansätze. Dart schien mir auch einige Dinge zu haben, die ich interessant fand (Habe mir da die Spezifikation aber auch nur kurz angesehen). Generell gibt es sehr kluge Köpfe die ständig dran sind, Sprachen zu verbessern oder gar neue Sprachen von Grund auf zu erstellen. Und da wäre ich dann deutlich offener auch was die Paradigmen angeht.

Die JVM als Basis war evtl. mal eine Zeit lang wichtig, aber das ist ja durch die Plattformunabhängigkeit der anderen Sprachen obsolet. Selbst Java verläßt diese ja mehr oder weniger mit GraalVM würde ich (etwas ketzerisch) sagen.


----------



## yfons123 (16. Jul 2022)

KonradN hat gesagt.:


> ? Syntax oder erinnere ich mich falsc


ein frage zeichen ist 


> if(obj != null) obj.DoStuff()





> obj?.DoStuff()


das ist gleichwertig soweit ich weis


----------



## yfons123 (16. Jul 2022)

c# hat das gleiche mit dem fragezeichen und ganz ehrlich:  es ist für den arsch

ich kann ja sowieso den vergleichs operator überschreiben und dann zb sowas tun


```
if(obj)
{
    obj.DoStuff();
}
```
dann ist das halt wieder unnötig dass man den fragezeichen operator hat wenn man auch die operator überladung hat... dann hat man wieder 10 möglichkeiten

in unity wird der ? operator von denen die ihren code in discord posten nie benutzt... das sind paar 100 leute täglich und keine sau nimmts her genauso wie die operator überladung...die meisten machen eine Add methode

die einzige "operator" überladung die man nutzt ist die die unity geschrieben hat mit zb 


> vector + vector





> vector * float





> vector / quaternion





> vector / float


da halt rider was die "beste" IDE ist auch nicht drauf klar zusätzlich.. entweder man weis es oder man ist am arsch.. bei methoden wirds einem angezeigt

aber da der CEO von unity scheiße gebaut hat ist das interesse vieler sowieso weg von unity und bei godot genauso wie bei mir.. die haben auch c# und kotlin .. trollolol


----------



## mrBrown (16. Jul 2022)

yfons123 hat gesagt.:


> c# hat das gleiche mit dem fragezeichen und ganz ehrlich:  es ist für den arsch


JavaScript und Typescript haben es auch, ist super und wird meiner Erfahrung nach sehr häufig genutzt.


----------



## dzim (16. Jul 2022)

Ich klinke mich jetzt hier aus. Ich habe lange genug Java programmiert und mache es noch immer und bilde mir meine Meinung nicht nur anhand von "ich habe es mir damals mal angeschaut und fande es nicht so toll wie angepriesen" (dann muss man halt zu Rust wechseln!).

Ich finde es ok, wenn nicht jeder das so empfindet und manche Java als mehr Expressiv (oder was auch immer) wahrnimmt.

Gerade die Null-Safety und die Scoped Functions (und alles drum herum) - und auch speziell die Extension Functions - machen für mich diese Sprache um einiges eleganter. Natürlich ist das im JVM-Umfeld nicht Bombensicher, da die JVM das selbst nicht wirklich untersützt. Es ist nur Compile-Zeit-Analyse (und jede Menge entsprechender Checks im ByteCode am Ende).

Kotlin eignet sich vor allem gut für DSLs - etwas, was mit Java natürlich auch geht, aber um Welten weniger elegant. Beispiel JavaFX mit TornadoFX. Ich geh nicht mehr zurück zu FXMLs und Controllern oder hanebüchenen Libraries, damit man irgendwie MVVM oder so was hinbekommt...

Auch Coroutinen sind für mich im Moment sehr wichtig im alltäglichen Geschäft. Klar kann man das mit Java auch... gewissermassen... solange Project Loom noch nicht durch ist aber auch nur über Hlfsmittel wie Akka.

So long.


----------



## yfons123 (16. Jul 2022)

mrBrown hat gesagt.:


> JavaScript und Typescript haben es auch, ist super und wird meiner Erfahrung nach sehr häufig genutzt.


der ? funktioniert in unity nicht da es sein kann dass die engine das objekt nicht mehr hat aber c# hat das objekt noch dh du hast bei dem ? ein true obwohl es false sein müsste

das betrifft nur objekte im spiel... aber niemand nimmts her für "normale objekte"


----------



## yfons123 (16. Jul 2022)

dzim hat gesagt.:


> Beispiel JavaFX mit TornadoFX. Ich geh nicht mehr zurück zu FXMLs und Controllern oder hanebüchenen Libraries,


hättest ja rapidfx hernehmen können von mir 

das müsste ich auch noch überarbeiten irgendwann..


----------



## KonradN (17. Jul 2022)

Und es war nicht das ? sondern tatsächlich die notwendigen ! in Verbindung mit (Java) Libraries. Das hatte verhindert, dass Kotlin den Vorteil richtig ausspielen konnte.

Wobei sich da evtl. einiges verändert haben könnte durch womöglich weniger ‚Java‘ Abhängigkeiten.


----------



## yfons123 (17. Jul 2022)

du hast halt "multi setter" deklarationen die es auch in c# gibt die halt das builder pattern "unwichtiger" machen

zb 

```
blabla... VBox{
    height=100,
    width=200,
    managed=false,
}
```
was dir alle setter aufruft.. ist halt angenehm .. ka was die syntax in kotlin ist aber da gibts das auch


----------



## temi (17. Jul 2022)

Die Diskussion ging jetzt schon ziemlich ins Detail. Ich wollte eigentlich eher in die Richtung "Wo steht Kotlin gerade?" "Soll ein Neueinsteiger lieber Kotlin lernen?" diskutieren, siehe "Ich traue mich mal vorauszusagen dass in 5 Jahren eine andere Sau durchs Dorf getrieben wird". Ein Nischendasein hat Kotlin offenbar weiterhin. Anscheinend gibt es aber dennoch Menschen, die Kotlin nutzen.

Meiner Ansicht nach ist es die bessere Variante, wenn eine Sprache versucht inhärent sicher(er) zu sein, als vom Programmiere zu verlangen, eine potentiell unsichere Sprache, durch geeignete Techniken sicherer zu machen. Das ist auch ein wichtiges Prinzip in der Unfallverhütung (fällt mir gerade nebenbei so ein). Jeder Fehler, der gar nicht gemacht werden kann, tritt auch nicht auf. Ob das Kotlin ist, sei mal dahingestellt. Es versucht auf jeden Fall in die richtige Richtung zu gehen.

Jenseits der möglichen Sicherheitsaspekte: Was ist von den anderen Ansätzen Kotlins zu halten, wie "Kotlin for JavaScript" oder "Kotlin Native"? Hat da jemand Erfahrungen mit gesammelt?

@dzim Kannst du mir sagen, ob das in Kotlin "schöner" geht?
Java:

```
setOnMouseDragged(this::mouseDragged);
```
So habe ich es in Kotlin:

```
onMouseDragged = EventHandler<MouseEvent> {
            mouseDragged(it)
        }
```
Ich hab nach Methodenreferenzen gesucht, aber nichts gefunden...


----------



## KonradN (17. Jul 2022)

Da stimmen wir ja überein @temi. Die Uneinigkeit ist lediglich bei der Bewertung der Konsequenzen.

Variablen können Methoden beinhalten. Es geht in Kotlin etwas wie

```
val someFuncVar1 = ::otherFunc

val someFuncVar2 = { .... }
```

Ersteres ist die Methodenreferenz und das Zweite die Lambda Expression.

Aufruf ist einfach die Variable mit ().

Ansonsten tiefer ins Detail z.B. bei





						Use function types and lambda expressions in Kotlin  |  Android Developers
					

Learn how to use lambda expressions and higher order functions in Kotlin.




					developer.android.com
				




Und da ggf auch interessant








						Functional (SAM) interfaces | Kotlin
					






					kotlinlang.org
				




Aber gibt bestimmt noch bessere Quellen aber bin hier am Smartphone und da ist es eine Wual so eine Quelle zu verifizieren.


----------



## KonradN (17. Jul 2022)

Und dann doch noch einmal schnell an den Computer - denn die Language Specification ist auf dem Smartphone nicht wirklich angenehm anzusehen.

Wichtige Punkte in der Kotlin Language Specification:
- Function Types: https://kotlinlang.org/spec/type-system.html#function-types
mit Beispielen wie:


> // A valid assignment w.r.t. function type variance
> // Function1<in Int, out Any> :> Function1<in Number, out Number>
> val fooRef: (Int) -> Any = ::foo





> // A valid assignment w.r.t. function type variance
> // Receiver is just yet another function argument
> // Function1<in Int, out Any> :> Function1<in Number, out Number>
> val barRef: (Int) -> Any = Number::bar



In dem Zusammen nebensächlich aber auch betroffen:
Function literals: https://kotlinlang.org/spec/expressions.html#function-literals

Was ich jetzt auf Anhieb nicht finden konnte war die tatsächliche Erläuterung der Methodenreferenz. Aber ist halt doch etwas her, dass ich mir das angesehen hatte.


----------

