"nan" ist ja auch viel verständlicher als "NaN" (welches wohl in jeder anderen Programmiersprache verwendet wird)...

https://de.wikipedia.org/wiki/NaN

wer denkt sich bloß solch einen mist für Swift aus?

Ja schade, dass du nicht an Swift beteiligt bist, sonst wäre die Welt noch in Ordnung.

Zumindest wäre NaN noch NaN und nicht nan! (ich könnte mich ja beteiligen, aber solange ich nicht entscheiden kann nützt der Welt das nichts... )

Swift ist dein persönliches Feindbild, oder?

Nö, ich schau mir nur die Entwicklung an, muss aber immer wieder den Kopf schütteln wenn ich sowas sehe. Warum muss es "nan" sein wenn die ganze Entwicklerwelt NaN verwendet und auch swift bisher NaN verwendet hat. Da muss wohl jemand einen krankhaften Drang haben alles "kaputtzuoptimieren"...

nimm doch einfach an der Entwicklung teil? ist ja immerhin openSource. Könnte ja sein das die ganzen Entwickler etc sich was dabei gedacht haben...

Das problem ist dass "die ganzen entwickler" teilnehmen und denken können was sie wollen. entschieden wird dann bei apple und das von einem ganz kleinen personenkreis und wenn da einer meint dass nan sich schneller tippt als NaN dann wird das auf biegen und brechen durchgesetzt. Egal ob es sinnvoll oder eher doch komplett sinnlos oder gar schädlich ist!

An Swift kann man ja aber eigentlich auch nur verzweifeln …

Das Ganze hat schon Sinn und Verstand. Das Ding ist, wer nicht bereit ist von gewohnten Schreibweisen abzuweichen, weil er jahrelang OBJC gecoded hat, wird es schwer haben. Die neuen Generationen an Codern und die flexiblen Alt-Coder kratzt es nicht. Man sollte sich also selbst an die Nase fassen und für sich entscheiden ob man auf dem alten Zug bleibt (der irgendwann in Rente geht) oder sich auf den neuen einlässt. Ewig rummosern nützt in erster Linie mal nichts. Apple wird das durchziehen. Mitmachen oder es lassen, mehr Auswahl habt ihr nicht!

Nö. Ich nicht. Warum auch? Endlich mal was neues.

Hat es eben nicht, das ist ja mein Problem. Swift ist ein zusammengewürfelter Gemischtwarenladen aus Syntax-Versatzstücken jüngst angesagter Programmiersprachen ohne jede semantische Konsistenz, weit, weit weg von der konzeptuellen Stringenz von Smalltalk.

Und wie man auf einem Unix-System ohne C auskommen soll, ist mir auch ein Rätsel.

Gegen Neues als solches habe ich überhaupt nix. Es sollte halt gut sein. Mitmachen hingegen finde ich einen geradezu angsteinflößenden Wert …

Und neu ist gut, weil …?

Weil es immer gut ist, sich neues Wissen anzueignen. Im Gegensatz zu dir, denke ich das sich die Entwickler sehr genau was dabei gedacht haben. Mir viel es jedenfalls außerordentlich leicht, damit zurecht zu kommen.

Klar haben sie sich was dabei gedacht. Aus meiner Sicht halt leider genau das Falsche.

Drei klare Ziele waren:

• Leichter Einstieg für Entwickler, die von den augenblicklichen „Modesprachen“ kommen, also viel Syntax von denen übernehmen, egal wie unausgegoren die ist
• Einschränkung der Sprachmächtigkeit (z.B. keine Zeiger), um auch Dummies zu ermöglichen, Programme zu erstellen, die nicht crashen
• C loswerden

Mit allen drei Zielvorgaben stimme ich entschieden nicht überein, jedenfalls, wenn Swift Objective-C ersetzen und nicht nur ergänzen soll.

Ok. Weia und Swift werden dann wohl nie Freunde

Hmm, ein Swift-Projekt hier:

Übersetzung mit Xcode 7: 0 errors, 0 warnings
mit Xcode 8: 358 errors und warnings. Der Migrationsassistent erzeugt teilweise Code, der sich nicht übersetzen lässt.

Also, lasst mal das "sehr wahrscheinlich" weg.

Das hat nichts mit Obj-C zu tun denn JEDE verdammte programmiersprache dieser welt verwendet NaN und hat swift bisher ja auch gemacht. Und jetzt muss das plötzlich "nan" werden mit der begründung dass man "nan" schneller tippt als "NaN" oder was?

Generell ist ja Swift von dem, was Objective-C-Hasser Geschwätzigkeit nannten, zu dem zurückgekehrt, was Objective-C-Freunde als AbKüFi aus unseligen 8-Zeichen-Dateinamen-Zeiten empfanden.

Jetzt haben wir wieder so Sachen wie var und let. (Ich weiß bis heute nicht, was Letzteres abkürzen soll – kann mir da jemand auf die Sprünge helfen?)

Ich denke let a = 1; soll für sowas wie "belasse a bei 1;" stehen.

Es werde Licht!

Ja, das wäre auch mein Erklärungsversuch.

Dann wäre der eine Typ (var, das ja wohl klar variable heißen soll) ein Substantiv, der alternative Typ (let) hingegen ein Verb.

Das und die Tatsache, dass wir darüber rätseln müssen, ist für mich eine Miniatur, die bezeichnend ist für die intellektuelle Stringenz von Swift. ( PaulMuadDib: es sind bloß Namen, schon klar, aber auch da könnte man ja Klarheit walten lassen, und wenn selbst da bereits von den Autoren wirr gedacht wird … )

Also ich musste nicht eine Sekunde darüber Rätseln. Im Ernst. Stand ja auch in der Doku. Aber das ich Swift-Kompatibel bin war mir nach einer Stunde, als anfing damit zu beschäftigen, klar.

Worüber musstest Du nicht rätseln bzw. was stand in der Doku? Dass let statische Variablen bezeichnet? Ja, das ist mir schon auch klar.

Aber stand da auch die Etymologie? Die ist mein Problem, und die habe ich nirgendwo gefunden. Falls die auch in der Doku steht, wäre ich für einen genauen Verweis dankbar.

Du machst Dir irgendwie zu viel Gedanken, über, meiner Meinung nach, nicht so wichtige Dinge.
Keine Ahnung wo das her kommt. Nie drüber nachgedacht.

Ich gestehe Dir gerne zu, dass wir da unterschiedlich „ticken“ und mir sprachliche Präzision um ihrer selbst willen ein Wert ist, mehr, als das vielleicht pragmatische gerechtfertigt wäre (wie bei der Groß-/Kleinschreibung auch).

Wenn es bei der linguistischen Unschärfe von var vs. let bliebe, könnte ich diesem Deinem Pragmatismus vielleicht zustimmen. Aber es bleibt eben nicht dabei. Diese mangelnde gedankliche Präzision zieht sich durch Swift wie ein roter Faden.

Ein anderes Beispiel:

In der Arithmetik verwenden wir auch im westlichen Kulturkreis die arabische Schreibrichtung von rechts nach links:
Das Resultat steht links, die Ausgangssituation rechts.

In der formalen Logik hingegen schreiben wir wie sonst im Westen auch von links nach rechts:
Die Ausgangssituation steht links, das Resultat rechts.

Das ist zwar seltsam, aber historisch natürlich gut zu erklären (das arithmetische Kalkül haben wir aus der arabischen Welt übernommen (samt den Ziffern), die formale Logik hingegen aus der griechischen Antike), und da Logik und Arithmetik klar getrennt sind, funktioniert das im Alltag auch ohne große Probleme.

Die „klassischen“ Programmiersprachen (jedenfalls die, die ich kenne) haben allesamt die arithmetisch-arabische Schreibweise übernommen, was angesichts der Tatsache, dass Computer „Rechner“ sind, ja auch Sinn ergibt:

Swift hingegen bringt das bemerkenswerte Kunststück fertig, die Funktionsdefinition westlich zu schreiben und den resultierenden Funktionsaufruf arabisch:
1. Zeile: Resultat rechts
2. Zeile: Resultat links

Wie zum Teufel kommt man auf eine derart hirnrissige Idee? Hier entwickelt offenkundig jemand ohne jedes linguistisches Gespür eine Programmiersprache.

Ja, klar, man kann auch das irgendwie verdauen und pragmatisch damit umgehen. Nur: warum??? Diese Inkonsistenz ist so komplett unnötig, man hätte es ebenso gut konsistent machen können. Und je mehr derartiger Fehlkonstruktionen aufeinandertreffen, desto wahrscheinlicher wird halt auch, dass es zu Verwirrungen kommt, die nicht dann mehr trivial sind.

Mein Hauptpunkt ist aber: Wenn jemand schon derart unfähig ist, eine konsistente Syntax zu konstruieren, wie wahrscheinlich ist dann, dass die Implementation der Sprache rundum gelingt?

Und genau das ist mir völlig Latte. Vielleicht ändert es sich noch. So richtig fertig ist Swift ja nicht.

Dir ist völlig Latte, dass Swift von Leuten fabriziert wird, die offensichtlich Schwierigkeiten mit stringentem Denken haben?

Außerdem, wie merkst Du dir eigentlich Dinge? Ich merke mir Dinge am besten, indem ich sie verstehe. Und das ist schwierig, wenn es nichts zu verstehen gibt.

Tja, und während du grübelst warum jetzt unbedingt "let" verwendet wird, habe ich das erste Programm damit geschrieben ...

… was aber nicht sehr komplex ist. Und was, wenn Du 3 Jahre an einem sehr komplexen Programm arbeitest und dann feststellen musst, dass sich die Inkonsistenzen von Swift akkumulieren und dieser Komplexität am Ende nicht mehr gewachsen sind?

Kurz: Ich kann nicht verstehen, wie man einer Sprache Vertrauen schenken kann, die gleich auf den ersten Blick nicht konsistent gebaut ist. Dass Du schnell ein kleines Progrämmchen damit zimmern kannst, geschenkt …

Und noch ein zweiter Punkt: Du propagierst die pragmatische Herangehensweise; auf Hardware-Ebene entspräche das einer zusammengepfrimelten Kiste, die aber läuft, wie sie soll.

Wir wissen beide (vermute ich), dass Steve Jobs hingegen darauf bestand, dass selbst Teile der Hardware, die nie jemand zu Gesicht bekommt, ästhetischen Ansprüchen genügen, von denen, die alle sehen, ganz zu schweigen. Das entspräche eher meiner Herangehensweise.

Sicher ist Deine pragmatische Herangehensweise legitim. Nur dass sie hier ausgerechnet von Apple kommt, ist ein eklatanter Bruch mit dem, was Apple ehemals ausgemacht hat.

Ich weiß aus erster Hand, dass Steve Jobs die intellektuelle Brillanz von Objective-C geliebt hat. Insofern kann ich hier mit großer Bestimmtheit den abgenudelten Spruch anbringen: Unter Steve Jobs hätte es Swift so nicht gegeben. :'(

Das mag Dir egal sein, mir ist es halt nicht egal.