http://www.heise.de/newsticker/meldung/Apples-Programmiersprache-Swift-Eine-Bilanz-ein-Jahr-nach-der-Vorstellung-2678194.html


Seht ihr das auch so?

(Ich selbst kann nix dazu sagen, bin aber interessiert...)

Swift geht definitiv in die richtige Richtung. Momentan bin ich noch großer Freund von Objective-C, setze private Projekte jedoch mittlerweile mit Swift um.
An der WWDC soll Swift 2.0 vorgestellt werden, mal schauen welche Neuerungen kommen.
Das größere Problem momentan ist Xcode. Da kommt es in Verbindung mit Swift zu den tollsten Problemen.

Das finde ich interessant, denn bislang kannte ich pro-Swift-Aussagen hauptsächlich von Leuten, die zu blöd (Entschuldigung …) waren, um Objective-C zu verstehen.

Du schreibst hingegen, Du seist („noch“) ein großer Freund von Objective-C. Kannst Du etwas dazu sagen, warum Du dann Swift für die richtige Richtung hältst?

(Ich tue das definitiv nicht.)

Ich bin auch ein großer Freund von ObjC und Entwickle damit seit dem Erscheinen von OS X. Vor einiger Zeit habe ich mich aber auch in Swift eingearbeitet und schreibe gerade damit zum ersten mal ein ernsthaftes OS X Programm. Der Grund dafür ist, dass ich entwicklertechnisch am Ball bleiben will und mir ein Bild über die Sprache machen will. Außerdem gehe ich davon aus, dass es langfristig auf Swift als favorisierte Sprache bei Apple hinaus läuft.
Prinzipiell halte ich Swift für nicht notwenig. Swift mag syntaktisch auf den ersten Blick gefälliger wirken (typische ObjC Anfängerfrage: "Warum sind denn das alles Arrays?" ). Andererseits finde ich, dass Swift aktuell einige Dinge noch enorm verkompliziert und teilweise grotesk handhabt.

Nur 4 Beispiele:

1. Optionals
Die Sache mit den Optionals (also die Datentypen mit dem '?', z.B. String?). Es nervt tierisch, im Code die mit @IBOutlet definierten Controls immer über Forced-Unwrap ansprechen zu müssen.
Das gibt eine regelrechte '!' Inflation. Auch kommen dadurch z.B. solche Ausdrücke zustande:
flag ist hier ein optional bool daß in dem Ausdruck force-unwrapped und verneint wird. Super toll...
Warum nicht Force-Unwrap für Optionals als default verhalten beim Zugriff definieren? Das würde die ganzen blöden '!' ersparen. Greife ich darauf zu und das Ding ist nil, kracht es. Ansonsten muss ich halt mit '?' arbeiten oder auf nil prüfen.

2. convenience inits
Ja gütiger Himmel, wer hat den quatsch denn erfunden? Wozu soll das gut sein? Warum nicht einfach normale Konstruktoren schreiben die ggf. an andere Konstruktoren delegieren und gut iss?
Und der Knaller: bei Abgeleiteten Klassen kann ich auf der super Klasse zum initialisieren die convenience inits nicht aufrufen! WTF??? Liefern denn die convenience inits kein proper initialisiertes Objekt oder was?
Vor allem das doofste ist, wie Apple convenience inits selbst im Cocoa Framework einsetzt. So ist z.B. init mit NibName des NSWindowController ein convenience init. d.h. ich kann in abgeleiteten Klassen der Superklasse nicht das nibfile mitgeben! Herrjeh - wer hat sich denn das ausgedacht?
Wer sich alleine mal die Swift Doku zu den convenience inits im Zusammenhang mit Vererbung anschaut (Fallbeispiele), der merkt, dass ja jemand den Boden unter den Füssen verloren hat.

3. Type Inference
Ja, tolles Feature. Ich persönlich nutze es nicht. Warum? ganz einfach, wenn die Codebasis mal größer als die "Hello World" App ist und komplizierte Funtionen existieren die komplexe Objekte zurück geben, und mehrere Leute an etwas arbeiten - sprich, der Entwickler den Code nicht selbst geschrieben hat, dann ist es eben nicht immer direkt ersichtlich, was für ein Datentyp zurück gegeben wird. Schön, wenn der Compiler den Typ herausfinden kann - das interessiert mich aber nicht. Der Entwickler muss sehen, was er da hat und nicht der Compiler.

4. Swift Array
Arrays in Swift haben verschiedene Methoden, um z.B. ein Element an der Stelle x einzufügen oder zu entfernen etc. - ganz wie es sich für ein Objekt gehört. Will ich aber den aktuellen Index eines Elements im Array wissen, muss ich schreiben. Bye bye objektorientierte Programmierung...!? Was soll das?

Alles in allem ist meine bisherige Meinung, dass man die Resourcen statt in die Entwicklung von Swift besser in die Weiterentwicklung des Cocoa und der Foundaten API gesteckt hätte. Syntaktisch hätte man auch ObjC weiter ausbauen können, z.B. durch die Einführung von Lambda Ausdrücken, Generics, Return von Tuples etc...

Mein Fazit: Swift, schön dass es da ist, gebraucht hätte man es nicht. Ich hoffe Swift 2.0 räumt mit einigem Käse auf.

Das deckt sich exakt mit meiner Einschätzung.
Das hingegen würde ich weniger freundlich formulieren.

ExMacRabbitPro

Wann hast Du Dir Swift das letzte mal angesehen? Vor einem Jahr?

[quote]Die Sache mit den Optionals (also die Datentypen mit dem '?', z.B. String?). Es nervt tierisch, im Code die mit @IBOutlet definierten Controls immer über Forced-Unwrap ansprechen zu müssen.[\quote]

Dafür gibt es die "implicit unwrapped optionals", die machen genau was Du willst und insb. die IBOutlets sind inzwischen genauso definiert!

Danke für die interessanten Einschätzungen und Beispiele!

Ich war erstaunt, wieviel Ablehnung Objective C im Heise-Forum entgegenschlägt.
Im Heise-Artikel selbst wird ja auch "Mistbude" zitiert - ohne nähere (u. fundierte) Gründe kann man aber jeden mit irgendwas zitieren.
(Sehe gerade, der Shipley hat's auch nicht begründet, war ein Twitter-Eintrag. Aber immerhin nutzt er Obj-C schon seit 26 Jahren)

Wenn ich mir Swift-Code ansehe, gibt es mir bislang keine Lust, die Sprache zu lernen ... wirkt auf mich etwas billig und stillos, ein Sammelsurium.

cfkane
Im Heise Forum schlägt so ziemlich allem Ablehnung entgegen, das hat dort gewissermaßen Tradition das würde ich nicht so ernst nehmen.

Natürlich hat sich seit der Definition von ObjC die Softwareentwicklung zum Teil grundlegend geändert. Viele modernere Design Patterns sind entstanden und die technischen Möglichkeiten haben sich enorm weiter entwickelt. Dem kann ObjC aktuell nur zum Teil gerecht werden.

Aber ich gebe dir recht, Swift wirkt zum Teil so, als hätte man sämtliche aktuelle Technologie und Syntaxmöglichkeiten miteinander verquirlt. Als ich mich damals in ObjC eingearbeitet habe, gab es bei Apple ein Dokument, ich glaube der Name war "Objective C Primer", da war die komplette Languagedefinition von ObjC auf 4 Seiten beschrieben. Zwar sehr kompakt, aber es war alles da, inkl. den Regeln zum Memory Management- ARC gab es damals noch nicht. Die logische Kompaktheit der Sprache hat mich damals sehr beeindruckt. Swift dagegen ist der reinste Technologie Zoo.

Hättest du da ein Beispiel?
Das vorherrschende Paradigma ist ja (meines Wissens nach) immer noch die Objektorientierung (auch wenn Javascript den Prototypenansatz populärer gemacht hat)? Darin sollte ObjC ja glänzen. Auch wenn es neue Patterns gibt - so groß wie bei prozedural oo sollte der Sprung aber nicht sein, oder?
Die Eleganz der ObjC-Konzeption mit ihrer Einfachheit und Klarheit gefiel mir auch immer. Ein paar Schlüsselwörter, die Nachrichten in den eckigen Klammern, Dynamisierung - fertig .
Und dazu noch eine Prise Extravaganz (sonst quälten sich alle in C++) -- paßte insgesamt viel besser zu Apple (und natürlich zum elitären NeXT) als das 0815-Swift.

Grüße

Leute, die an ihre intellektuellen Grenzen kommen, weil eckige Klammern für etwas anderes als Arrays verwendet werden … :'(

Dabei ist die konzeptuelle Klarheit und Schlichtheit ein hervorstechendes Merkmal von Objective-C.
Die Syntax jedenfalls ist leider das absolute Gegenteil von “Think Different”. Alles mögliche, was gerade irgendwo angesagt oder auch nur gewohnt ist, zu einem Gemischtwarenladen zusammengeschüttet.

Pars pro toto: Man kann ja argumentieren, dass wir, arabische Ziffern und mathematische Tradition hin oder her, eine Kultur sind, die von links nach rechts liest, und das Ergebnis daher rechts und nicht links stehen sollte.

Aber wenn, dann doch bitte nicht nur bei der Methodendeklaration, sondern auch beim Aufruf der Methode. So wie bei Swift ist das nur halbgar und konzeptionell konfus.

Wenn das repräsentativ ist für den intellektuellen Zuschnitt der Generation, die bei Apple nachwächst …
Das würde mich auch interessieren.

Naja, z.b. Das Konzept der Generics. Damit lassen sich schon sehr elegante und effiziente Sachen machen. ObjC erledigt das zum Teil über das Dynamic Dispatching. Was aber dann nicht sein müsste.

Ein weites sind z.B Namespaces. Gerade bei Verwendung von vielen 3rd Party Frameworks, wenn die Klassenpräfixe kollidieren, dann ist das echt blöd. Selbst schon erlebt.

Das wären nur zwei einfache Beispiel.

Hmm …
Die lösen doch aber nur ein Problem, dass Objective-C dank nicht obligatorischer Typisierung erst gar nicht hat?
Namespaces finde ich einfach nur gruselig ungelenk. Erinnern mich irgendwie an Design by Committee.
Das stimmt, aber …
Mir ist das in 20 Jahren noch nicht untergekommen.

Insofern wären das für mich keine Argumente pro Swift.

Weshalb warst Du erstaunt? Objective-C hat außerhalb der Apple Welt keinerlei Bedeutung, und das hat seinen guten Gründe.

Es hat Gründe, aber keine guten.

Es hat keinerlei Bedeutung, dass Objective-C ausserhalb der Apple Welt keine Bedeutung hat, und das hat auch seine guten Gründe.