-
++
Autor: zwangsregistrierter 01.03.16 - 12:20
>Bisher geplant ist zum Beispiel, einige Syntaxelemente zu streichen. Das sind zum Beispiel die "C-Style for- Schleife" (for ...; ...; ...) und die Operatoren "++" bzw. "-".
Warum? Ist doch Schwachsinn?! -
Re: ++
Autor: TheUnichi 01.03.16 - 12:22
zwangsregistrierter schrieb:
--------------------------------------------------------------------------------
> >Bisher geplant ist zum Beispiel, einige Syntaxelemente zu streichen. Das
> sind zum Beispiel die "C-Style for- Schleife" (for ...; ...; ...) und die
> Operatoren "++" bzw. "-".
>
> Warum? Ist doch Schwachsinn?!
Könnte aber wohl durchaus für stabileren Code sorgen.
Glaube aber nicht, dass sie es tun. -
Re: ++
Autor: JanBrinkmann 01.03.16 - 12:36
Doch, das kommt. Der Antrag wurde genehmigt. Hier kannst Du die Details finden:
https://github.com/apple/swift-evolution/blob/master/proposals/0004-remove-pre-post-inc-decrement.md
Ich fand es zuerst auch befremdlich, die Argumentation ist aber schlüssig. -
Re: ++
Autor: humpfor 01.03.16 - 12:59
Das kommt halt raus, wenn Coder immer dümmer werden, bzw. sich jeder einbildet er kann coden, weil er mit einer GUI eine App sich zusammen klickt.
Alleine der erste Punkt.. Is a "burden"?? ERNSTHAFT??? WENN SOWAS ein schon so SCHWER ist, warum dann noch weitermachen? -
Re: ++
Autor: non_sense 01.03.16 - 13:28
humpfor schrieb:
--------------------------------------------------------------------------------
> Alleine der erste Punkt.. Is a "burden"?? ERNSTHAFT??? WENN SOWAS ein schon
> so SCHWER ist, warum dann noch weitermachen?
Erinnert mich an eine Berufsschule für Fachinformatiker in Hamburg, wo man explizit die While-Schleife weglässt, weil sie zu kompliziert sei...
Was bitte sehr an Pre-, und Post-Increment so schwer sein soll, verstehe ich auch nicht. Wer das nicht kapiert, soll es halt nicht benutzen. Manchesmal ist es aber sehr nützlich und macht den Code übersichtlicher.
Demnächst will man dann auch noch das switch-Statement entfernen, weil man es auch mit if-statements abbilden kann, oder wie?
1 mal bearbeitet, zuletzt am 01.03.16 13:30 durch non_sense. -
Re: ++
Autor: Noppen 01.03.16 - 14:29
non_sense schrieb:
--------------------------------------------------------------------------------
> Was bitte sehr an Pre-, und Post-Increment so schwer sein soll, verstehe
> ich auch nicht. Wer das nicht kapiert, soll es halt nicht benutzen.
> Manchesmal ist es aber sehr nützlich und macht den Code übersichtlicher.
++ bzw. -- sind Syntactic Sugar für // TODO: FIX THIS UGLY CODE
;) -
Re: ++
Autor: non_sense 01.03.16 - 14:48
Noppen schrieb:
--------------------------------------------------------------------------------
> ++ bzw. -- sind Syntactic Sugar für // TODO: FIX THIS UGLY CODE
>
> ;)
Nein, ist es eben nicht ;)
Gerade in meinem Anwendungsfall ist es äußerst hilfreich. Ich habe es besonders häufig mit Excel-Dateien zu tun. Sprich, ich erstelle mittels C#-Code Excel-Dateien.
Ich bekomme also eine Liste mit Objekten und ich will die Werte untereinander in eine Excel-Datei transferieren. Dafür benutzen wir immer eine Zelle als "Ankerpunkt" und definieren von diesem Ankerpunkt einen Spalten-, und Zeilen-Offset, wo der Wert nun reingeschrieben werden soll.
Ich muss also nicht immer:
foreach(Foo foo in FooListe)
{
TransferToExcel("A1", spaltenOffset, zeilenOffset, foo.wert)
zeilenOffset += 1;
}
sondern kann:
foreach(Foo foo in FooListe)
TransferToExcel("A1", spaltenOffset, zeilenOffset++, foo.wert)
schreiben. Das obere finde ich unschön.
Für mich hat schon das Pre-, und Post-Increment seine Daseinsberechtigung. -
Re: ++
Autor: onek24 01.03.16 - 14:51
Noppen schrieb:
--------------------------------------------------------------------------------
> non_sense schrieb:
> ---------------------------------------------------------------------------
> -----
> > Was bitte sehr an Pre-, und Post-Increment so schwer sein soll, verstehe
> > ich auch nicht. Wer das nicht kapiert, soll es halt nicht benutzen.
> > Manchesmal ist es aber sehr nützlich und macht den Code übersichtlicher.
>
> ++ bzw. -- sind Syntactic Sugar für // TODO: FIX THIS UGLY CODE
>
> ;)
static int incrementIntTypeNumberByOne(int number) {
int newNumber = number;
newNumber = newNumber + 1;
return newNumber;
}
Wunderschön -
Re: ++
Autor: Noppen 01.03.16 - 15:05
non_sense schrieb:
--------------------------------------------------------------------------------
> foreach(Foo foo in FooListe)
> TransferToExcel("A1", spaltenOffset, zeilenOffset++, foo.wert)
Sehr gutes Beispiel, Danke. In einem foreach loop selber einen index zu erhöhen gehört umgehend gefixt =P -
Re: ++
Autor: Noppen 01.03.16 - 15:14
onek24 schrieb:
--------------------------------------------------------------------------------
> static int incrementIntTypeNumberByOne(int number) {
> int newNumber = number;
> newNumber = newNumber + 1;
> return newNumber;
> }
>
> Wunderschön
Ganz toll. Zur Belohnung darfst Du diese Reihe so lange fortführen, bis Du die Qualität deines Gegenbeispiels selber verstehst... -
Re: ++
Autor: Trollversteher 01.03.16 - 15:25
Wie wär's mit
foreach( var foo in FooListe.Select((x, i) => new { Value = x, Index = i})) {
TransferToExcel("A1", spaltenOffset, zeilenOffset+foo.Index, foo.Value.wert)
} -
Re: ++
Autor: DrWatson 01.03.16 - 15:32
humpfor schrieb:
--------------------------------------------------------------------------------
> Das kommt halt raus, wenn Coder immer dümmer werden, bzw. sich jeder
> einbildet er kann coden, weil er mit einer GUI eine App sich zusammen
> klickt.
>
> Alleine der erste Punkt.. Is a "burden"?? ERNSTHAFT??? WENN SOWAS ein schon
> so SCHWER ist, warum dann noch weitermachen?
Erinnert mich an die Diskussion, als man angefangen hat GOTO nicht mehr in Sprachen einzubauen.
Traurigerweise setzten sich solche Erkenntisse erst durch, wenn die alte Programmierergeneration stirbt und neue Leute an ihre Stelle treten. -
Re: ++
Autor: DrWatson 01.03.16 - 15:45
non_sense schrieb:
--------------------------------------------------------------------------------
> foreach(Foo foo in FooListe)
> TransferToExcel("A1", spaltenOffset, zeilenOffset++, foo.wert)
FooListe.foreach( (foo, zeilenOffset) ->
TransferToExcel("A1", zeilenOffset, foo.wert) ) -
Re: ++
Autor: JanBrinkmann 01.03.16 - 15:53
Ich finde die gesamte Art und Weise zu diskutieren hier sehr befremdlich. Allerdings sollte jeder hier mal neidlos anerkennen, das zu einer sauberen Syntax, bei der eine Zeile am besten nicht zwei-drei Mal gelesen muss, eben auch Kompromisse gehören. Ich habe oben den Änderungsvorschlag verlinkt. Und diese Operatoren können halt sehr unsauberen Code produzieren, bei kaum Mehrwert:
foo(++a, a++)
Wenn nun in foo(_:_) etwas mehr steht und ggf. 50-60 Zeilen im Methodenkörper stehen, ist das eben nicht immer einleuchtend was genau passiert.
Zudem ist es eher traurig zu sehen, wie gleich andere Menschen angegangen werden. Der Schöpfer und Projektleiter steht mal locker mehrere Stufen in seinem Können über einem durchschnittlichen Entwickler. Compilerbau und der Entwurf von Programmiersprachen ist aus meiner Sicht auch ein Teil Magie. Chris Lattner hat LLVM einfach mal als Projekt im Studium gestartet... Das ist nicht ohne Grund heute die Basis in Xcode. Apple hat den guten Mann einfach mal eingestellt.
Gerade von Entwicklern kenne ich eigentlich eine eher reflektierende Haltung. Niemand soll hier irgendetwas glauben oder einfach für bare Münze nehmen. Im Gegenteil: Die Dinge hinterfragen. Das bedeutet aber vor allem auch sich selbst! Wieso könnte ein so erfahrener Mann wie Chris Lattner bzw. die Swift Community einem solchen Antrag statt geben? Ganz sicher nicht weil er nicht in der Lage ist, einen Operator zu interpretieren...
Diskurs und andere Meinungen? Immer gern! Aber auf diesem Niveau macht das wirklich keinen Spaß. -
Re: ++
Autor: non_sense 01.03.16 - 15:54
Trollversteher schrieb:
--------------------------------------------------------------------------------
> Wie wär's mit
>
> foreach( var foo in FooListe.Select((x, i) => new { Value = x, Index = i}))
> {
> TransferToExcel("A1", spaltenOffset, zeilenOffset+foo.Index,
> foo.Value.wert)
> }
Es wird sich beschwert, dass Post- und Pre-Increment zu kompliziert sei und dann kommt man mit Lambda-Ausdrücken bzw. Linq? O_o
Ja, so ist es auch realisierbar, aber war für mich erst seit kurzem möglich, da wir nun endlich die Kunden davon überzeugen konnten, mal auf .NET 3.5 zu aktualisieren (was aber immer noch veraltet ist). Wir dümpelten noch mit .NET 2.0 rum. Ja, die Banken sind ein merkwürdiger Verein...
1 mal bearbeitet, zuletzt am 01.03.16 15:55 durch non_sense. -
Re: ++
Autor: DrWatson 01.03.16 - 16:05
non_sense schrieb:
--------------------------------------------------------------------------------
> Es wird sich beschwert, dass Post- und Pre-Increment zu kompliziert sei und
> dann kommt man mit Lambda-Ausdrücken bzw. Linq? O_o
Seine Version bescrheibt WAS getan werden soll: Iteriere durch die Liste und schreibe foo in aufeinanderfolgende Tabellenspalten.
Deiner Version beschreibt, WIE etwas getan werden soll: Iteriere durch die Liste und erhöhe eine Zählervariable, nachdem du foo in eine Tabellenspalte mit der entsprechenden Nummer geschrieben hast.
Deine Version mag in Code kürzer sein, ist aber semantisch komplexer.
> Ja, so ist es auch realisierbar, aber war für mich erst seit kurzem
> möglich,
Das ist ein Problem der aktuellen Implementierung, aber kein Grund es in Zukunft nicht besser zu machen. -
Re: ++
Autor: Trollversteher 01.03.16 - 16:11
>Es wird sich beschwert, dass Post- und Pre-Increment zu kompliziert sei und dann kommt man mit Lambda-Ausdrücken bzw. Linq? O_o
Ische liebe Linq & Lamda ;-)
Stimmt schon, das erfordert erst mal einiges an Umdenken - aber wenn das erst mal einigermassen sitzt, will man es nie wieder missen! Der Vorteil gegenüber Deinem Beispiel ist eben, dass hier nicht mehr "händisch" an einer Zählervariable herummanipuliert wird, und zeilenOffset sowohl nach als auch innerhalb der Schleife noch seinen ursprünglichen Wert beibehält.
>Ja, so ist es auch realisierbar, aber war für mich erst seit kurzem möglich, da wir nun endlich die Kunden davon überzeugen konnten, mal auf .NET 3.5 zu aktualisieren (was aber immer noch veraltet ist). Wir dümpelten noch mit .NET 2.0 rum. Ja, die Banken sind ein merkwürdiger Verein...
Kenne ich - wir sind immerhin auf .Net 3.5, warten aber schon seit gefühlten Ewigkeiten auf den Umstieg auf 4.0. -
Re: ++
Autor: Trollversteher 01.03.16 - 16:15
>FooListe.foreach( (foo, zeilenOffset) -> TransferToExcel("A1", zeilenOffset, foo.wert) )
Jepp, so ist's noch eleganter, weil Linq noch konsequenter eingesetzt wird.
Dazu darf FooListe aber kein beliebiges IEnumerable sein, sondern muss ggf. in ein List-Objekt umgewandelt werden. (FooListe.ToList().foreach...)
1 mal bearbeitet, zuletzt am 01.03.16 16:22 durch Trollversteher. -
Re: ++
Autor: onek24 01.03.16 - 17:36
Noppen schrieb:
--------------------------------------------------------------------------------
> onek24 schrieb:
> ---------------------------------------------------------------------------
> -----
> > static int incrementIntTypeNumberByOne(int number) {
> > int newNumber = number;
> > newNumber = newNumber + 1;
> > return newNumber;
> > }
> >
> > Wunderschön
>
> Ganz toll. Zur Belohnung darfst Du diese Reihe so lange fortführen, bis Du
> die Qualität deines Gegenbeispiels selber verstehst...
Aber so mach ich das in jeder Industrieanwendung :O
1 mal bearbeitet, zuletzt am 01.03.16 17:37 durch onek24. -
Re: ++
Autor: Gamma Ray Burst 01.03.16 - 18:41
onek24 schrieb:
--------------------------------------------------------------------------------
> Noppen schrieb:
> ---------------------------------------------------------------------------
> -----
> > non_sense schrieb:
> >
> ---------------------------------------------------------------------------
>
> > -----
> > > Was bitte sehr an Pre-, und Post-Increment so schwer sein soll,
> verstehe
> > > ich auch nicht. Wer das nicht kapiert, soll es halt nicht benutzen.
> > > Manchesmal ist es aber sehr nützlich und macht den Code
> übersichtlicher.
> >
> > ++ bzw. -- sind Syntactic Sugar für // TODO: FIX THIS UGLY CODE
> >
> > ;)
>
> static int incrementIntTypeNumberByOne(int number) {
> int newNumber = number;
> newNumber = newNumber + 1;
> return newNumber;
> }
>
> Wunderschön
Du übertreibst ;-) ein return number + 1 tut es auch...
Der Inkrement ist wirklich hässlich an der Stelle, viel besser wäre ein:
execList.addAll( fooList )
Also in Scala würde es ungefähr so aussehen (ok außen rum kommt da noch was hin), aber im Prinzip ist es nicht mehr.
Finde die Collections in Swift allerdings noch ausbaufähig, Scala und Clojure sind da definitiv viel weiter (F# auch denke ich).
Ja und Java8 zeigt sich bemüht...



