Super, Apple! Das finde ich ganz klasse, bin schon relativ weit mit meinen Swift Kenntnissen. Der Blog ist eine super Ergänzung.

"Falls noch größere Umstellung an Swift vorgenommen werden, verspricht Apple Werkzeuge in Xcode, die entsprechende Änderungen am Quelltext vereinfachen."
@sb plural

Zu erwähnen wäre noch, dass XCode 6 jetzt für jeden (auch freiem Developer-Account) zur Verfügung steht.

Das ist eine viel wichtigere Meldung! Ist Swift da inclusive?

Edit: Swift ist dabei:
"Xcode 6 betas, that include Swift, are available to everyone. Sign-in to become a (free!) Registered Apple Developer https://developer.apple.com/news/"
https://twitter.com/SwiftLang/status/487654823722885121

Schade das Swift und XCode mit Swift erst ab Mavericks läuft.
Das ist doch richtig, oder?

Ja

Wan meint ihr, werden Swift Programme auch irgendwann auf anderen Platformen wie Linux oder Windows lauffähig sein? Apple hat doch bestimmt Interesse die Übersprache zu entwickeln, die Java und C von ihrer Spitzenposition verdrängt.

Was halten denn eigentlich die Damen und Herren Entwickler und Entwicklerinnen grundsätzlich von der neuen Sprache?
Da ich selbst kein Programmierer bin, würde mich zuallererst interessieren, ob oder was da für Euch einen Fortschritt darstellt… oder auch nicht.
Aber bitte "allgemein verständlich"

Als Entwickler sehe ich aktuell keine Vorteile bei Swift gegenüber Objective-C. Die Syntax von Swift ist allerdings echt ein Graus.

Ich werde somit auch weiterhin Objective-C für die Entwicklung verwenden.

Läuft schneller! (sagt Apple)

Alle Nicht-ObjCler sehen das vermutlich genau andersherum.
Nein. Warum sollten sie das Interesse dafür haben? Apple bringt es ganz im Gegenteil viel mehr Nachteile ein - und eigentlich keinerlei Vorteile.

Erste Microbenchmarks sagen etwas ganz anderes.
Die Performance ist allgemein noch ein großer Diskussionspunkt.

Die Frage ist halt wie aussagekräftig solche Microbenchmarks sind. Swift ist definitiv bei bestimmten Sachen langsamer und bei bestimmten Sachen schneller als obj. C.

Swift fehlt einiges von der Klarheit von Objective C.
Ich verstehe es ja, wenn jemand anfangs von den eckigen Klammern etwas verwirrt wird. Aber die meisten Leuten, den ich ObjC beigebracht habe, sind nach einer Woche damit klargekommen und haben es geschätzt.

Ich bin auch noch etwas skeptisch was Swift angeht, aber das ist nach ca. 15 Jahren Objective C auch kein Wunder

Swift bietet gute Ansätze aber auch vieles, das den Code weniger lesbar macht.

Deine Links bieten nur Ergebnisse, keinen Code wie es zu den Ergebnissen kam … darum sind die Benchmarks nutzlos.
Ausserdem macht es mich schon stutzig wenn ich Behauptungen nachträglich gestrichen werden … weiss ja jemand nicht, was er getestet hat?

Ja, das ist leider definitiv so.

Objective-C war ein ganz großer Wurf; einerseits eine extrem simple, klare, strikt objektorientierte Sprache, und andererseits die Möglichkeit, völlig problemlos auf das elementare C zurückfallen zu können, wenn Performance entscheidend war (oder man entsprechenden Open-Source-Code integrieren wollte).

Für die Nichtprogrammierer hier: Objective-C hat den enormen Vorteil, fast wie eine natürliche Sprache lesbar zu sein, und die Eigenart, dass jeder solcher "Satz" in eckige Klammern gesetzt wurde. Also z.B. (kein wirklicher Code, deutscher "Pseudo"-Code zur klaren Illustration):


Es ist wohl nicht zuviel behauptet, dass auch ein Nichtprogrammierer versteht, was hier passieren soll.

In praktisch allen anderen Programmiersprachen sähe das irgendwie so ähnlich wie hier aus:


Klar, in diesem simplen Beispiel kann man das als Nichtprogrammierer vielleicht auch noch irgendwie verstehen, aber ganz so klar ist es nicht mehr (was bedeutet das „JA“?).

Das liegt auch daran, dass praktisch alle anderen Programmiersprachen einen Hang dazu haben, Befehle mit mehr oder weniger kryptischen Abkürzungen zu bezeichnen (zeig_txt in meinem Pseudo-Beispiel). Wer das gewohnt ist, bezichtigt Objective-C umgekehrt der Geschwätzigkeit. Man kann aber gar nicht genug betonen, wie wichtig es ist, Code auch später gut lesen zu können (wenn man selbst nicht mehr genau weiß, was man damals gemacht hatte, oder den Code von jemand anderem bearbeitet), damit nicht nach Updates Sachen plötzlich nicht mehr funktionieren, die das schon einmal taten.

Was das Beispiel aber eben auch zeigt, ist, dass alle anderen Sprachen bei einem solchen Befehl keine eckigen Klammern verwenden. Eckige Klammern werden dort praktisch nur verwendet, um ein bestimmtes Element aus einer Liste von Elementen zu bezeichnen, z.B.:


Das geradezu absurde Faktum ist nun, dass viele Programmierer, die von anderen Sprachen kamen, sich endlos über die Verwendungen von eckigen Klammern Objective-C ereifern konnten und die Sprache mehr oder weniger nur deshalb ablehnten. Wies gesagt: das ist absurd, aber es ist so.

Böse gesagt ist Swift im Wesentlichen Apples Versuch, dadurch noch mehr Programmierer für die eigene Plattform zu gewinnen, dass man einen mediokren Mischmasch aus der Syntax anderer Sprachen zusammenschustert, der als „modern“ gilt und den Hassern von eckigen Klammern daher vertraut erscheint (warum erinnert mich das an die Yosemite-GUI??). Zudem sind auf Kosten der Performance (Swift ist, jedenfalls hier und heute, eben nicht schneller) diverse Überprüfungen eingebaut, die die Sprache „idiotensicher“ machen sollen. Gleichzeitig geht die intellektuelle Stringenz von Objective-C in der Swift-Syntax aber völlig verloren; teilweise höchst unterschiedliche programmatische Vorgänge werden mit einer zum Verwechseln ähnlichen Syntax beschrieben, so dass das Verständnis dafür verlorengeht, was im Hintergrund „eigentlich“ passiert.

Solange alles gut geht, mag das Programmiereinsteiger freuen, dass die unterschiedlichsten Dinge gleich = „einfach“ aussehen. Aber wehe, wenn es irgendwo hakt und man auf ein tieferes Verständnis angewiesen wäre …

Es gibt sicher einige wenige Goodies, die Objective-C fehlen (für Entwickler: ganz vorne dran Instanzvariablen in Kategorien), aber die hätte man auch in Objective-C ergänzen können und die klare Syntax dabei beibehalten.

So wie es ist, ist Swift hier und heute primär ein Marketinginstrument (Apple-Programmierung ohne eckige Klammern!) und ganz sicher noch nichts für anspruchsvollere Programme. Wie es weitergeht, muss sich zeigen …

Wer meint dass Objective-C ausdrücklicher ist als Swift hat das Swift Buch nicht richtig gelesen. Swift kann ebenso ausführlich sein, der Punkt ist aber dass der Programmierer nicht dazu gezwungen wird.

Nehmen wir mal ein Beispiel:
In Swift könnte man die Methode ebenso deklarieren dass sie so aussieht:
Aber, und das ist der Punkt, bei so einer Methode ist es eigentlich selbstverständlich wofür die Parameter stehen, der Programmierer könnte die Methode auch so deklarieren, dass man die Namen der Parameter nicht braucht:
Das ist so in Objective-C nicht möglich, beziehungsweise würde es sehr seltsam aussehen:
wir brauchen also immer noch irgendeinen Text zwischen den Parametern und sparen bloß zwei Buchstaben.

Um mal ein anderes Beispiel zu nehmen wo die benannten Parameter mehr Sinn machen:
Das ist ohne Probleme für jeden lesbar, und nicht weniger lesbar als in Objective-C. Natürlich könnte der Programmierer der die Methode deklariert die Syntax auch abartig hässlich machen, aber das liegt dann im Ermessen des Programmierers.



Es gibt aber einige andere punkte die mir bisher missfallen:

• Keine Header Dateien: Header Dateien sind eigentlich bloß eine Krücke um die Arbeit den Compiler Autoren einfacher zu machen, aber sie haben auch den schönen Nebeneffekt dass sie das "was" vom "wie" trennen. Wenn ich in C# meinen Code dokumentieren will, dann muss ich das direkt in der Implementation machen, das die Quellcodedatei immens anschwellen lässt. Mit Header Dateien kann ich die Dokumentation einfach dort schreiben und sie lenkt nicht von der implementation ab.
• Allgemein kein Präprozessor: das knüpft an das Obige an, in C kann man mit dem Präprozessor einige sehr elegante Tricks machen. Es stimmt zwar dass Tricks in einem sauberen Programm nichts zu suchen haben, aber wenn die Tricks nur auf eine einzige Quelldatei beschränkt sind sehe ich kein problem darin wenn sie den Code in dieser Datei dafür lesbarer machen.
• Keine Dokumentationstools: ich denke das wird sich mit der Zeit regeln, aber momentan wird Swift von keinem Tool unterstützt und in XCode sehe ich auch nichts dafür. In XCode konnte ich einfach Doxygen Kommentare in meine Header Dateien schreiben und XCode hat sie sofort erkannt in in den kleinen Info Blasen angezeigt.

Es ist nicht unmöglich. Angeblich wurde einigen Leuten auf der WWDC von Apple Ingenieuren gesagt dass die Sprache offen gelegt wird sobald sie fertig ist, aber es gibt noch keine konkrete Stellungnahme dazu. ich würde es prinzipiell nicht ausschließen, vor allem da es durchaus helfen würde wenn auch Entwickler von außerhalb Apple zur Sprache beitragen könnten.

Was definitiv nicht geöffnet werden wird ist Cocoa und die übrigen Apple Frameworks, aber dafür gibt es bereits eine offene Alternative namens GNUStep:
http://www.gnustep.org
GNUStep hat bereits angekündigt dass sie mit Swift kompatibel sein möchten. Der nächste Schritt liegt bei Apple, wenn sie die Sprache offenlegen dann ist ales in Butter, ansonsten muss GNUStep eine eigene Swift Implementation schreiben. Wir werden sehen.

Das sind keine richtigen Programmierer. Ein echter Programmierer weiß dass die Syntax einer Sprache nebensächlich ist, es zählen die Features der Sprache. Sie entscheiden was die Sprache kann und wie schnell der erzeugte Code ist. Syntax kann man lernen, mit Sprachfeatures muss man arbeiten.

Es hat auch niemand bestritten, dass man in Swift Parameter nicht auch benamen kann.
Und dein Beispiel ist leider sehr subjektiv gewählt.

Was (mir) an Swift aber missfällt ist in deinem Beispiel gut ersichtlich.
Die Mechanik in ObjC war, dass es einen receiver (ein Objekt) gibt, der eine Message (der methoden-aufruf) erhält. Und das war sauber getrennt.

Nun ist das alles etwas wischiwaschi. Ein Teil der Benamung wandert in den Funktionsnamen (vor die Klammer) der andere in die Parameterliste (in die Klammer).

Wie gesagt, ObjC ist da klarer.
Und da die Benamung der Parameter in der Parameterliste in optional ist, wird "javaesquer" Code leider bald zum alltag gehören.

Auch finde ich die Sache mit Optionals "halbgar". Denn es muss noch sehr oft auf nil (auch wenn nil in swift etwas anderes bedeutet als in ObjC) prüfen und die Syntax dazu ist nur bedingt lesbar, aber auch hier kann es nur an der Gewöhnung liegen.

Eben, und genau das ist das Problem. Denn alle, die Objective-C geschwätzig fanden – und das sind die, die sich zuvorderst auf Swift stürzen werden – werden diese optionalen Angaben wegfallen lassen, und man wird einen Haufen unlesbaren Code vorfinden.

Abgesehen davon ist meine Darstellung natürlich grob vereinfachend, aber ich wollte mich damit ja auch gerade an Leser wie Nutriaschädel wenden, die um eine allgemeinverständliche Darstellung gebeten hatten.

Es gibt ja noch x andere Punkte: Klassen und Strukturen, Methoden und Funkionen, alles verschmiert syntaktisch …
Öhm …
Wie heißt es so schön: Wenn etwas in Objective-C kompliziert scheint, dann hat man es falsch gemacht.
Zustimmung. Ein gutes weiteres Beispiel für die Tendenz von Swift, strukturiertes Arbeiten zugunsten von auf den ersten Blick einfacheren Vorgaben fallen zu lassen.
Schon klar. Aber sag das denen mal.

Jein. Schon klar, wenn jemand die Syntax kennt, stimmt das.

Aber
entspricht einer natürlichen Sprache mit Subjekt, Prädikat und Objekt doch weit mehr als
Es ist einfach eleganter. (Für Leute mit solch merkwürdigen Perspektiven wie denen von Steve Jobs, der noch von Platinen forderte, sie sollten ästhetisch aussehen. Das ist übrigens eine interessante Frage, die sonst x-fach, im Zusammenhang mit Swift aber meines Wissens noch nie aufgeworfen wurde: Hätte es Swift mit dieser Syntax unter Steve Jobs gegeben?)

Objective-C und Cocoa hatten auch schon oft genug Dinge verschmiert. Eine Klasse (NSNumber), ein Struct (NSRange) und ein Typedef (NSInteger) zum Beispiel sind unterschiedliche Klassen von Typen, hatten in Cocoa aber alle die gleichen Namenskonvention. Ohne extra Nachlesen in der Dokumentation hat man keine Ahnung was was ist. Und ob ich nun schreibe
oder
ist eigentlich egal. Die Punkt-Notation hatte es auch unter Objective-C für Properties gegeben. Man muss bedenken dass die meisten Sprachen der Konvention von C++ folgen, aber Objective-C ist älter als C++ und folgt der Syntax von Smalltalk. Ich würde nicht sagen dass eins besser ist als das andere, lediglich die Benennung der Parameter ist wirklich klasse. In C++ müsste man das etwa so machen:
Das ist hässlich.

EDIT Ein Vorteil der Punt-Notation für uns: die Eckigen Klammern sind wirklich unangenehm zu tippen auf einer deutschen Tastatur.

Die Punktnotation in ObjC einzuführen war kompletter Unsinn.
Damit sollte C#/Java-Entwicklern der entgegengekommen werden, aber hat die Sprache zum erstenmal wirklich verwässert.

1. Es kann nur noch schwer zwischen struct und property unterschieden werden.
2. Viele Entwickler (auch in bekannten 3rd-Party frameworks!) bekommen es nicht auf die Reihe die Punktnotation durchgängig zu verwenden und oft sieht man sachen wie

Und das ist einfach inkonsequent und unsauber.

Du suchst dir aber auch immer nur simple und wenig aussagekräftige Beispiele... ist das absicht?

Hm, die Namen geben ja eher Hinweise auf das zugehörige Framework – ist da eine Typenunterscheidung wichtig?

Sobald ich im Code irgendwas damit mache, wird der Unterschied doch sofort mehr als offensichtlich, d.h. der Code bleibt gut lesbar:
Kann man eigentlich nicht verwechseln, oder? Mit Strukturen vs. Klassen und Funktionen vs. Methoden in Swift sieht das schon ganz anders aus …
Kommt auf die Perspektive an. Pragmatisch vordergründig magst Du recht haben.

Aber
is eben näher an der natürlichen Sprache als

Das mag übertrieben sein wie die ästhetische Platine, aber eben vielleicht doch nicht nur:

Die zweite Variante suggeriert über die Verkettung mittels Punkt eher, dass bitteHolMirFolgendes eine Eigenschaft von Franz ist, als eine Mitteilung, die ich Franz sende.

Auf der Ebene technischer Implementation ist das mit der Eigenschaft natürlich richtig, weil das Objekt Franz eben nur Mitteilungen versteht, die ihm implementiert wurden (= Eigenschaft). Aber das ist von der Implementation her gedacht. Von der objektorientierten Semantik her gedacht senden wir Franz eine Mitteilung, und das wird durch die erste (Objective-C-)Variante viel klarer zum Ausdruck gebracht. Die erste Variante legt objektorientiertes Denken nahe, die zweite verwässert es.

Was ich aber im Alltag des Code-Lesens auf jeden Fall für wichtig halte, ist, dass man bei Objective-C selbst bei einem flüchtigen Überfliegen niemals einen Methoden-Aufruf (eckige Klammern um gesamten Ausdruck) mit einem Funktionsaufruf (runde Klammern um Parameter) verwechseln kann – bei Swift ist das anders …
Ja – fast wäre ich versucht zu sagen: leider.

Gemäß meinen obigen Gedanken ergibt das schon einen gewissen semantischen Sinn, da Properties ja eben Eigenschaften sind, die hierarchisch sein können (keypath), und wo man davon absehen kann, dass man für den Zugriff auf sie eine entsprechende (standardisierte) Methode braucht. Aber das gilt semantisch eben nur für Properties, nicht für Methoden allgemein.
Schon klar, und genau das ist eben das Unheil.

C++ baut auf Simula auf, meines Wissens die erste OO-Sprache überhaupt, die noch entsprechend roh war. Smalltalk versuchte dann aus den Fehlern von Simula zu lernen und war weit avancierter. Daraus entsprang Objective-C. Auch wenn es früher erschien als C++, hat es doch den fortschrittlicheren Stammbaum.

Dass sich der Gemischtwarenladen C++ dennoch erstmal erfolgreicher etablierte, ist die ewige, traurige VHS-vs-Betamax-Geschichte.

Historisch hätte ich um 2000 herum verstanden, wenn Apple mit Objective-C unglücklich gewesen wäre. Aber warum jetzt, wo Objective-C dank iOS eine der meistverwendeten Sprachen geworden ist, auf das Niveau von C++ zurückfallen? (Ich rede hier nicht von dem Swift-Projekt generell, sondern nur von der Syntax.)

Und (bezeichnenderweise?) vor allem falsch.

Aber Du hast natürlich prinzipiell recht, auch das (korrekte)
ist gruselig.

Hihi.. der editor hier hat keine Syntax-highlighting und ich habs nur schnell getippt... wie gesagt.. ich mag keine punktnotation und darum ist die Klammern "im Blut".

Und ja, ich meinte das was du als Verbesserung geschrieben hast und sowas kommt mir leider zu oft vor die Augen