Laden...

Interessante Features aus Kotlin, die sich auch C# gut machen würden

Erstellt von herbivore vor 6 Jahren Letzter Beitrag vor 6 Jahren 5.854 Views
herbivore Themenstarter:in
49.485 Beiträge seit 2005
vor 6 Jahren
Interessante Features aus Kotlin, die sich auch C# gut machen würden

Hallo zusammen,

ich habe gerade in der neuen c't 15/17, S. 164 einen Artikel über die Programmiersprache Kotlin gelesen, die wohl von Java abstammt und daher auch Ähnlichkeiten zu C# hat.

Kotlin hat durchaus einige interessante Features:* generelles Verbot von null-Referenzen (das explizit aufgehoben werden kann und muss, um null zu verwenden)

  • switch erlaubt beliebige boolschen Bedingungen
  • fast alles kann als Ausdruck verwendet werden, z.B. auch if
  • Wenn im if eine Variable mit is auf einen bestimmten Typ geprüft wird, betrachtet der Compiler die entsprechende Variable im Then-Teil automatisch als von diesem Typ.

Ansonsten gibt es noch eine Reihe weiter Verbesserungen gegenüber Java, die aber C# auch schon enthalten sind, z.B. Properties statt getter und Erweiterungsmethoden. Andersherum gibt es aber eben auch eine Reihe von Verbesserungen, die (noch) nicht in C# enthalten sind, z.B. die oben genannten.

Die Motivation für die Entwicklung von Kotlin waren wohl genau solche Produktivitätsverbesserungen gegenüber Java.

In der nächsten c't gibt es den zweiten Teil des Artikels. Wenn dort weitere interessante Features vorgestellt werden, werde ich berichten.

Hat jemand von euch schon Erfahrungen mit Kotlin gesammelt? Und wenn ja, wie sind diese ausgefallen?

herbivore

16.807 Beiträge seit 2008
vor 6 Jahren

Die Funktion bzw. des switch und des if mit der Variable kommt in C# mit der nächsten Version ebenfalls.
Ist ja nur Syntax Zucker.

T
2.219 Beiträge seit 2008
vor 6 Jahren

@herbivore
Danke für die Info.
Hatte total vergessen, dass heute/morgen die neue CT kommt.
Hol ich mir dann morgen mal und schau mir den Artikel an.
Klingt teilweise auch ganz gut.
Gerade das verbieten von null wäre bei manchen Stellen schon wünschenswert um Fehler besser abzufangen die im NullReferenceException enden.

Nachtrag:
Die Erweiterungsmethoden gibt es seit Java 8 auch schon.
Haben nur einen anderen Syntax/Namen als in C#
Dort heißen diese default Methods und erlauben entsprechende Erweiterungen, was auch teilweise schon in der API selbst gemacht wurde.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

W
872 Beiträge seit 2005
vor 6 Jahren

F# bietet vieles ähnlich wie Kotlin an.*Statt null benutzt man in F# Options *Statt Switch benutzt man Pattern Matching (auch um Option Types auszupacken) *F# hat Type Inference

Kotlin wird für Google wegen Android gepusht.
Für FSharp am besten mal bei fsharpforfunandprofit schauen - das ist eine tolle Seite.

T
2.219 Beiträge seit 2008
vor 6 Jahren

@weismat
F# ist eine Funktionale Programmiersprache und dürfte hier im Forum eher eine untergeordnete rolle spielen.
Mich würde aber interessieren wie weit verbreitet F# ist.
Hab bisher kaum was von der Sprache selbst gehört oder großartig gesehen.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

W
872 Beiträge seit 2005
vor 6 Jahren

F# ist nicht sehr verbreitet in Deutschland.
MS ist vor allem wegen jet.com an F# interessiert.
Es gibt halt klassische Domänen wie den Finanzbereich, die in Deutschland nicht so groß sind wie in London oder NYC, in denen es gerne eingesetzt wird. Mag vielleicht daran liegen, daß Mathematiker gerne funktionale Programmierung benutzen.

16.807 Beiträge seit 2008
vor 6 Jahren

Kurz als Vergleich:
Es gibt über 1500 Jobs in Stuttgart, die einen C# Entwickler suchen.
F#: Null (In Zahlen: 0).

Ich finde F# für viele Dinge spannend; aber es wird vermieden, weil die Ressourcen quasi nicht existent sind.
_Leider _finde ich aber auch, dass viele F# Evangelisten F# über alles stellen und wenig konstruktiv agieren - leider.
Sowas hilft einer Sprache nicht wirklich in Sachen Akzeptanz.

2.078 Beiträge seit 2012
vor 6 Jahren

generelles Verbot von null-Referenzen (das explizit aufgehoben werden kann und muss, um null zu verwenden)

Gabs die Idee nicht mal etwas anders für C#7?
Es war so gedacht, dass man eine Variable explizit als non-nullable deklarieren kann und die erlaubt dann nichts, was null ist oder sein könnte.

Ich kann's gerade nicht im VS2017 testen, aber wann ich das lese:
https://blogs.msdn.microsoft.com/dotnet/2017/03/09/new-features-in-c-7-0/
... finde ich nichts mehr dazu.

Wo ist der Gedanke geblieben?
Das würde einiges vereinfachen.

W
872 Beiträge seit 2005
vor 6 Jahren

Masse ist nicht gleich Klasse.
In Deutschland suchen gerade McKinsey und ThoughtWorks F# Entwickler.
Ich benutze es vor allem wegen der Type-Provider für CSV und XML. Da bin ich bedeutend schneller im Entwickeln als in C#.

16.807 Beiträge seit 2008
vor 6 Jahren

Es gibt für jede Ansicht ein Spruch, weismat 😉

Ja, F# ist für einige Dinge wirklich einfacher - aber es wird nicht der Weisheit letzter Schluss sein, wie es leider ganz oft auf Twitter und Co von bestimmten Leuten (teilweise wirklich Influencer) zu lesen ist.
Man liest ganz oft "F# ist immer besser als C#"; man liest "F# sei das bessere C#" - nicht wörtlich aber im Kontext; und das pauschal.
Und pauschal ist das halt nicht wahr, in keine Richtung.

herbivore Themenstarter:in
49.485 Beiträge seit 2005
vor 6 Jahren

Hallo zusammen,

mir wäre lieb, wenn wir den Ausflug in F# hier beenden und wieder zu Kotlin (und C#) zurückkehren könnten.

Hallo Palladin007,

ich weiß nicht, ob du vielleicht das meinst, was ich in C# 6 - Übersicht der Neuigkeiten vorgeschlagen hatte:

Der Null-conditional operator ist praktisch. Eigentlich sogar so praktisch, dass man überlegen könnte, das Verhalten zum Standard zu machen, wenn das denn nicht ein Beaking Change wäre. In den wenigen Fällen, in denen tatsächlich eine NullReferenceException geworfen werden soll, könnte man die "umgekehrte" Syntax einführen:

int length = customers!.Length;  

Diesen Vorschlag habe ich aber nur auf myCSharp.de gemacht und nirgends eingereicht. Um zu verhindern, dass es ein Beaking Change wäre, könnte man das Default-Verhalten über eine neue Compiler-Option steuern. Ich vermute, dass sowas in C# trotzdem nicht kommt.

herbivore

W
872 Beiträge seit 2005
vor 6 Jahren

Dein Beispiel liefert int? und nicht int zurück.
Das ist so in C# 6 drin - bei mir wurde es sogar schon als Refactoring Tip angezeigt nachdem ich auf VS2017 umgestiegen bin.

D
985 Beiträge seit 2014
vor 6 Jahren

@weismat

Das Beispiel funktioniert so gar nicht und wenn, dann würde es ein int liefern.

@hervibore

So eine Umstellung halte ich nicht für gut. Eine NullReferenceException kann man sehr leicht lokalisieren (wo ist das denn aufgetreten). Ein seltsames Ergebnis eher nicht.

Darum finde ich das bewusste Verwenden eines Null-Conditional-Operators richtiger.

T
50 Beiträge seit 2014
vor 6 Jahren

Statt **null **benutzt man in F# Options
...

Kurz als Vergleich:
Es gibt über 1500 Jobs in Stuttgart, die einen C# Entwickler suchen.
F#:** Null **(In Zahlen: 0).
....

sorry, konnte ich mir nicht verkeifen 😃

2.078 Beiträge seit 2012
vor 6 Jahren

@herbivore:

Ich meine sowas:

Man nehme eine Methode mit dem Operator:

void DoSomething(MyClass! obj)
{
    // ...
}

Dazu ein paar Nutzungen:

MyClass obj = new MyClass();
DoSomething(obj); // ok

// ====================

MyClass! obj = null; // Fehler
DoSomething(obj);

// ====================

MyClass! obj = new MyClass();
DoSomething(obj); // ok

// ====================

MyClass obj = null;
obj = new MyClass();
DoSomething(obj); // ok

// ====================

MyClass obj = null;
DoSomething(obj); // Fehler

// ====================

void Foo(MyClass obj)
{
    DoSomething(obj); // Fehler
}

// ====================

void Foo(MyClass obj)
{
    if (obj == null)
        throw new NullReferenceException();

    DoSomething(obj); // ok
}

// ====================

void Foo(MyClass obj)
{
    obj = obj ?? new MyClass();
    DoSomething(obj); // ok
}

// ====================

void Foo(MyClass! obj)
{
    DoSomething(obj); // ok
}

Sowas in der Art
Gerne auch nicht ganz so klug, hauptsache der Compiler verbietet mir, eine Variable zu nutzen, die null sein könnte.
Natürlich auch explizit, damit vorhandener Code weiterhin funktioniert. Bei neuem Code könnte dann aber der Compiler aufpassen, dass wir kein null haben.

Ich hab z.B. dort davon gelesen:
Kenneth Truyers: C# 7: New Features
Es gibt aber noch andere Quellen, aber alle älter.
Kann auch sein, dass die Idee nur zu beliebt war und ich sie daher für eine Idee von Microsoft gehalten habe.

Schade, weil mir hat die Idee gut gefallen

W
872 Beiträge seit 2005
vor 6 Jahren

Schau Dir mal Optional an - das ist ein Optional Implementierung auf Basis eines Structs (der als Value Type nicht null werden kann).
Vielleicht ist das etwas für Dich....

herbivore Themenstarter:in
49.485 Beiträge seit 2005
vor 6 Jahren

Hallo Sir Rufo,

Das Beispiel funktioniert so gar nicht und wenn, dann würde es ein int liefern.

richtig!

So eine Umstellung halte ich nicht für gut.

Der Vorschlag ist alt (um nicht zu sagen veraltet) und war auch damals nur ein Gedankenspiel im Zusammenhang mit der Einführung des Null-conditional operator in C#. Der Ansatz von Kotlin, null gar nicht erst zuzulassen, ist da tatsächlich viel konsequenter. Dann fliegt auch keine NRE, aber weil gar keine entstehen kann.

Hallo Palladin007,

ok, ich glaube, den Vorschlag kannte ich nicht. Hätte durchaus was für sich.

herbivore

6.911 Beiträge seit 2009
vor 6 Jahren

Hallo Palladin007,

du hast vermutlich C# 7 New Features: Non-Nullable references, Local Functions, Immutable Objects gemeint.

In Proposal for C# Non-Nullable Reference Types gibt es einen offiziellen Vorschlag dazu.

Schauen wir einmal ob (bin mir ziemlich sicher dass das kommt) und wie genau das eingeführt wird.

mfG Gü

Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.

"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"

2.078 Beiträge seit 2012
vor 6 Jahren

Genau diesen Feature-Wunsch meine ich - ich hab wohl überlesen, dass es "nur" ein Feature-Wunsch war.

Jetzt fällt mir aber auch auf, dass in dem von mir verlinkten Artikel folgendes steht:

Update 22/07/2016: Non-nullable reference types are probably not coming in C# 7, but will have to wait until the next version (supposedly c# 8)

Wie sagt man so schön: Wer lesen kann ist klar im Vorteil 😄

F
10.010 Beiträge seit 2004
vor 6 Jahren

Wenn man die Vorträge der diesjährigen Google Konferenz zu Kotlin anschaut fällt einem schon auf das sie in jedem 2. Satz sagen so wie in C#.

Habe jetzt auch ein Projekt in Kotlin angefangen ( Xamarin unterstützt ja leider keine MIPS prozessoren wie in meine Amazfit pace) und da ist schon einiges anders als in Java.
Ob das alles besser ist, naja, darüber lässt sich streiten.

Aber die IDE Unterstützung ist derzeit noch grottig, vor allem wenn man VS gewohnt ist, und die Beispiele sind leider auch noch recht rar gesät.

C
2.121 Beiträge seit 2010
vor 6 Jahren

Freut mich dass ich nicht der einzige bin der neue Features gerne in einer bekannten Sprache sehen würde statt in jeweils einer eigenen neuen 😉
Influencer ist ein gutes Wort. Ständig kommt was neues raus und natürlich ist das neue dann das beste. Dass sich die Entwicklergemeinde dagegen nicht wehrt wundert mich.

R
228 Beiträge seit 2013
vor 6 Jahren

Wenn ich mich recht entsinne, gibt es eine Diskussion unter dem Titel: "Nullable reference types".

https://github.com/dotnet/csharplang/issues/36

https://github.com/dotnet/csharplang/blob/master/proposals/nullable-reference-types.md

F
10.010 Beiträge seit 2004
vor 6 Jahren

@chilic:
Ich denke bei Kotlin war es ein anderer Hintergrund.

Java wird von Oracle und einigen Konsortien "bestimmt", weshalb Neuerungen hier sehr langsam durchschlagen.
Bei C# ist es nur MS das die Richtung und Implementierung vornehmen, also geht einiges schneller.

Aber Kotlin ist von Google aus einem anderen Grund mit offenen Armen aufgenommen worden.
Oracle America, Inc. v. Google, Inc.

T
154 Beiträge seit 2009
vor 6 Jahren

Switch mit generellen bool'schen Ausdrücken ist doch schon in C#7 drinnen. Kurz: Pattern Matching.

herbivore Themenstarter:in
49.485 Beiträge seit 2005
vor 6 Jahren

Hallo zusammen,

In der nächsten c't gibt es den zweiten Teil des Artikels. Wenn dort weitere interessante Features vorgestellt werden, werde ich berichten.

ich hab den zweiten Teil schon vor einiger Zeit gelesen, eigentlich nur überflogen. Die dort vorgestellten Feature fand ich nicht so überzeugend, teilweise sogar unpassend bzw. kontraproduktiv. Ich habe aber nicht die Zeit gefunden das näher auszuführen. Falls jemand anders den zweiten Teil gelesen hat und darin Features gefunden hat, die er interessant fand, kann er das gerne schreiben.

herbivore