Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
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?
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.
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).
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.
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.
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.
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.
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):
Code:
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
}
}
}
//...
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.
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.
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.
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.
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.
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.
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!
@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.
@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).
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).
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.
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, ...)
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...
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.
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.
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.
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.
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.
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
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...
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.
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".
Code:
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())
}
Java:
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<>());
}
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.
Java:
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 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:
Java:
String name = "value";
final String name = "value";
Code:
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:
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?
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?
Code:
public String GetName()
{
return name;
}
public void SetName(String name)
{
_name = name;
}
Oder
Code:
public String Name
{
get { return _name; }
set { _name = value; }
}
Oder
Code:
public String Name
{
get => _name;
set => _name = value;
}
Oder
Code:
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:
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:
Java:
String name = "value";
Code:
Dim name As String = "value"
Da habe ich sogar zwei unnoetige Woerter in der Deklaration.
public String Name
{
get => _name;
set => _name = value;
}
Code:
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
Code:
public string Name => "bob";
dann hast du eine expression body readonly property ... und seit neuestem c# kannst du auch noch init only setter machen ...
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.
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.
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.
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?
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.
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.
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?
