Echt krass, dieser Tesla-Chef Elon Musik

Tesla macht Apple doch zum Job-Friedhof – sagte Herr Musk.

Machen sie doch auch. Erst abwerben und dann feuern.

Tim Cook hat über Jahre hinweg zugelassen, dass Chris Lattner Swift verbricht, Elon Musk trennt sich von ihm nach 6 Monaten – ein sehr klares Indiz, welches Unternehmen den technisch verständigeren CEO hat.

Persönliche Vorlieben sollte man bei der Beurteilung von Programmiersprachen möglichst außen vorlassen. Lattner hat mit Sicherheit keinen schlechten Job gemacht, nur weil Du Swift nicht magst.

So sieht es aus...

Habe ich irgendwas über persönliche Vorlieben verlauten lassen?
Das ist sicher korrekt.

Umgekehrt wird ein Schuh daraus: Ich mag Swift nicht, weil Chris Lattner einen schlechten Job gemacht hat.

Du bist also der Auffassung, dass Herr Lattner Swift ganz alleine in seinem Kämmerchen zusammengezimmert hat und vor der Veröffentlichung niemand nochmals kurz draufgeschaut hat.
Dann gehörst du genau in die Kategorie Menschen, die glauben, das Design des iPhones beschränke sich auf die Formgebung.
Tipp: beide Hirnzellen aktivieren.
Oder: Trollmaul halten.

ps. vor deinem Avatarnamen fehlen noch ein A und ein U…

Chris Lattner ist eine junge Legende im Compilerbau, schon alleine durch LLVM. Ich glaube kaum, dass du qualifiziert bist, die Qualität von Swift zu bewerten.

Nein, habe ich das irgendwo behauptet?

Chris Lattner hat zunächst nach eigener Aussage in der Tat sehr lange alleine an Swift gearbeitet. Nachdem er es schließlich einem kleinen Kreis des Apple-Managements präsentierte und dieses beschloss, Swift zu einem Projekt Apples zu machen, verbreitete sich der Kreis der Mitarbeiter natürlich rasch.

Schon geraume Zeit vor Veröffentlichung kam es zu einigen folgenschweren Weichenstellungen, bei denen sich Apples Marketing-Abteilung um Phil Schiller, dem es um rasche Adaption unter Programmierern aller Couleur ging, gegen das Engineering-Team um Craig Federighi durchsetzte – leider.

Die Gesamtverantwortung für die Entscheidung trägt aber natürlich Tim Cook. Und ja, unter Steve Jobs wäre Swift in seiner jetzigen Form mit Sicherheit nicht passiert.

Ich muss im übrigen nicht lange rätseln, wem ich wohl mehr technischen Scharfblick zutraue – Tim Cook oder Elon Musk.
Tipp: Daraus, dass jemand Deine Auffassung nicht teilt, folgt nicht logisch zwingend, dass es ihm an Gehirnsubstanz mangelt.

Diese Schlussfolgerung wäre logisch nur dann zwingend, wenn sich voraussetzen ließe, dass Du unfehlbar bist und daher stets die ultimativ korrekte Einschätzung eines Sachverhalts hättest.

Beanspruchst Du das für Dich?
Am Umgangston feilen wir noch, gelle?

Und LLVM ist klasse.

Dummerweise ist Swift aber kein Compiler.
Dann glaubst Du’s halt nicht.

PS: Bemerkenswert, wie viele Forumsmitglieder sich bei MacTechNews auf den Schlips getreten fühlen, sobald Kritik an Swift laut wird …

@Weia
Ich hatte meinen Kommentar zu Tesla abgegeben weil da gerade einige Neuzugänge recht schnell den Fluchtweg antreten. Zum Teil eben angeblich ganz wichtige Figuren. Für mich ein Indiz, dass Musk bei Tesla eben extremst simpel auch nur mit Wasser kocht (und manche das eben recht spät festgestellt haben).

Egal. Was mich wirklich interessieren würde (und das vllt für einen programmiertechnischen Laien transparent erklärt): in wiefern steht Swift anderen Sprachen so dramatisch nach und wo siehst Du die Stärken? Wo sind Deine Kritikpunkte uns weshalb lieber was anderes … Ich habe da wirklich keine Ahnung, muss aber eben immer wieder mal eine Entscheidung in diese Richtung treffen … Wäre schön einmal von einem Externen zu hören was er so denkt.

LLVM ist auch kein Compiler, davon war aber auch nie die Rede. Das Entwickeln einer neuen Programmiersprache ist aber sehr wohl eine Disziplin des Compilerbaus.

Bist Du immer so konsistent?
OK, mit einem derart verengten Blick kann man vermutlich sogar Swift für gelungen halten …

Was hat denn das mit verengtem Blick zutun? Ich habe nur von dir noch keinerlei Argumentation gehört, warum aus compilerbau- oder architekturtechnischer Sicht Swift eine schlechte Sprache sein sollte?

Ja, eben: Du kommst offenbar gar nicht auf die Idee, dass eine Programmiersprache aus anderer als compilerbau- oder architekturtechnischer Sicht schlecht sein könnte …

Weia

Herrlich, deine kantsche Rhetorik.

Swift ist dem Anschein nach eben mehr Marketinggag als der Versuch,
ein würdiger Nachfolger von ObjC zu sein.

Aber auch diese Aspekt muss man natürlich ganzheitlich in das sich wandelnde Unternehmensbild Apples einzuordnen wissen.

Seltsam, ich komme mit Swift super zurecht.

Oje … Ich fürchte, wenn ich auf diese Frage hier antworte, wird aus der bereits jetzt auflodernden Empörung einiger Forumsteilnehmer ein Flächenbrand …

Sei’s drum: Wie Du schon schriebst: egal. Ich werde versuchen, drei exemplarische Punkte in einer laienhaften Sprache zu beschreiben, auch wenn es dadurch manchmal natürlich notgedrungen etwas unscharf wird.

Zunächst mal: Ich sage nicht, dass Swift anderen Sprachen „dramatisch“ nachsteht. Im Gegenteil, mein Punkt ist eher, dass Swift leichtfertig Vorteile verspielt, die Objective-C (die bisherige Cocoa-Sprache, zu der Swift in Konkurrenz tritt) gegenüber allen anderen Sprachen hatte, und so gesehen zu einer Nivellierung führt.

Die Probleme von Swift, auf die ich mich beziehe, liegen nicht in den Interna der Implementation, also darin, dass eine ganz bestimmte Funktionalität nicht effizient genug oder gar unzuverlässig arbeitet etc. Solche Probleme mag es geben, aber die können in allen Programmiersprachen auftreten und müssen dann eben Schritt für Schritt im Rahmen von Optimierungsprozessen behoben werden.

Die Probleme liegen in der konzeptionellen Ausrichtung der Sprache und der API, also der Benutzerschnittstelle der Programmiersprache (wobei Benutzer in diesem Falle eben die Programmierer von Applikationen sind).


1. Swift ist inkompatibel zu C (und C++)

Um zu verstehen, was das bedeutet und warum Apple das wollte, ist ein kleiner historischer Exkurs nötig. Auch C war natürlich zunächst einmal eine Programmiersprache unter vielen, erlangte aber im Laufe der Zeit eine herausragende Bedeutung. Ein Grund dafür mag sein, dass Unix (und also auch Linux und der Kern von macOS) in C geschrieben sind, ein anderer die Qualität der Sprache selbst, ein anderer, dass in C (gut) geschriebene Programme sehr schnell sind, und es gibt sicher noch weitere. Wie auch immer: C ist seit den 70er Jahren so etwas wie die lingua franca des Programmierens. Es gibt daher eine schier endlose Menge von vorgefertigtem, oft frei verfügbarem Code für nahezu jedes noch so komplexe Problem, oftmals aus der akademischen Welt oder der Open-Source-Szene oder beidem.

C ist allerdings noch sehr nahe an der „Denke“ einer CPU orientiert. Als die Rechner leistungsfähiger und die zu bewältigenden Probleme abstrakter wurden, entstand daher ein zunehmender Bedarf an abstrakteren, mehr am menschlichen Denken orientierten Sprachen. Aus diesem Bedürfnis heraus entstand der Ansatz der objektorientierten Programmierung, die die in einem Programm zu bearbeitenden Probleme als Interaktion von Objekten modelliert (und nicht als Ablauf von Anweisungen in einer CPU), so wie wir das mit unserer Umwelt auch tun (im weitesten Sinne – unsere Mitmenschen sind dann sehr komplexe Objekte, mit denen wir interagieren).

Die Sprache, die dieses objektorientierte Paradigma begründete, heißt Smalltalk und ist eine durch und durch brillante akademische Leistung. Dass sie aus der akademischen Welt stammte, hieß nur leider, dass sie nicht unmittelbar in der kommerziellen IT-Welt verwendbar war.

Darauf entstanden als Reaktion zwei neue, auf C aufbauende Sprachen, die C um die Möglichkeit der objektorientierten Programmierung erweitern wollten: C++ und Objective-C.

C++ verwässerte die akaedmische Stringenz von Smalltalk und fügte C andererseits noch viele andere Funktionen hinzu, so dass daraus ein riesiger „Gemischtwarenladen“ entstand mit sehr vielen Möglichkeiten und auch performant, aber leider sehr unübersichtlich bis chaotisch.

Objective-C hingegen behielt die intellektuelle Stringenz von Smalltalk praktisch zu 100% bei und kombinierte die Sprache mit C mit einer einzigen, denkbar simplen Syntax: Alles was in eckigen Klammern steht, ist quasi Smalltalk, alles außerhalb ist normales C. (Vielleicht ist sogar zu Dir als Laien irgendwann mal durchgedrungen, dass im Zusammenhang mit Objective-C unter Programmierern oftmals erregt über die vielen eckigen Klammern debattiert wird – das ist der Hintergrund.) Dieser im Vergleich zu C++ spartanische Ansatz bedeutete, dass man praktisch die volle Abstraktionsleistung von Smalltalk zu Verfügung hatte (was richtig angewandt besonders intuitive, da menschlichem Denken entsprechend strukturierte Programme ermöglichte), andererseits aber die vielen Werkzeuge des Gemischtwarenladens C++ fehlten und auch die Geschwindigkeit nicht ganz so gut war (weil eben nichts an Smalltalk vereinfacht wurde).

Anhand dieser Wesensmerkmale ist es nicht weit hergeholt zu sagen, dass C++ sozusagen das Windows der objektorientierten Programmierung war und Objective-C der Mac der objektorientierten Programmierung.

Und wie bei Windows und Mac war/ist C++ viel verbreiteter, weswegen es neben der großen Menge an öffentlichem C-Code auch sehr viel C++-Code gibt. Mittlerweile versteht aber der Objective-C-Compiler von Apple auch C++ und man kann damit alle drei Sprachen problemlos in einem Programm mischen, wodurch man die beste aller drei Welten hat.

Warum wollte Apple dann eine nicht-C-kompatible Sprache?

Der Grund dafür liegt in der oben schon erwähnten Nähe von C zur „CPU-Denke“. Denn leider bedeutet das nicht nur maximale Geschwindigkeit der C-Programme, es gibt andererseits auch relativ wenig Schutzschilder vor Fehlern, weil C eben so „unmittelbar“ mit der CPU kommuniziert. Es ist mit C problemlos möglich, Abstürze zu erzeugen. Und da C immer Bestandteil von Objective-C ist, bleibt diese Gefahr auch immer bestehen, wenn man in Objective-C programmiert und nicht mit einer gewissen Sorgfalt arbeitet.

Im Gegensatz dazu hatten sich über die Jahrzehnte immer mehr „Skriptsprachen“ wie z.B. Perl entwickelt, gar nicht kompiliert werden müssen, sondern deren Programmtext direkt von einem so genannten Interpreter ausgeführt wird (der selbst dann meist in C geschrieben ist). Wenn der Interpreter ausgereift ist, kann falscher Skript-Programmcode zwar dazu führen, dass das Programm Unsinn macht, aber es kann nicht zu einem Absturz führen. Der Preis dafür ist, dass Skriptsprachen viel langsamer sind und begrenzter in ihren Möglichkeiten.

Die Idealvorstellung von Swift ist nun, Cocoa-Programme mit einer Sprache schreiben zu können, die so unkaputtbar wie eine Skriptsprache ist, aber so schnell wie eine kompilierte Sprache wie Objective-C. Das hört sich in der Theorie natürlich gut an. De facto bedeutet es aber, dass auf den gigantischen Pool an existentem C/C++-Code verzichtet wird, damit umgekehrt auch Programmierer mit wenig Vorkenntnissen und wenig Sorgfalt bei der Arbeit nicht abstürzende Programme schreiben können, die idealiter so schnell wie Objective-C sind (de facto sind sie das bislang nicht).

Swift ist also Apples Positionierung dafür, möglichst vielen Programmierern auch mit geringer Vorbildung das Programmieren vergleichsweise anspruchsloser kleiner „Apps“ fehlerfrei zu ermöglichen (die oft wenig mehr als eine GUI für eine Programmlogik darstellen, die ohnehin auf Servern läuft), während Programme mit größerer Substanz von Jahrzehnten von Programmcode abgeschnitten würden. (Logic Pro X z.B. oder Final Cut Pro in Swift zu schreiben wäre faktisch unmöglich.)

Es ist kein Zufall, dass die Weichenstellung für Swift in seiner heutigen Form getroffen wurde zu einer Zeit, da Tim Cooks Wahnvorstellung, das iPad könne den Mac ersetzen, ihr Maximum erreicht hatte.

Man könnte natürlich argumentieren, dass in einer zukünftigen Welt, in der der heute in C/C++ vorhandene öffentliche Code auch in Swift vorliegen würde, dieses Problem allmählich verschwinden würde. Nur ist diese Vorstellung unrealistisch. Viele wichtige Algorithmen aus der Finanzmathematik und Statistik liegen als öffentlicher Quelltext auch heute noch nur in FORTRAN vor, einer dafür in den 60er Jahren populären Sprache. C-Portierungen sind oftmals nur proprietär und hinter verschlossenen Türen vorgenommen worden, ein enormer Reibungsverlust schon hier.

Bis das weitaus größere Reservoir an öffentlichem C/C++-Code vielleicht dereinst einmal in Swift existieren wird, sind die meisten von uns schon lange tot …

Als Craig Federighi Swift auf der WWDC vorstellte, nannte er es Objective-C ohne den Ballast von C. Dass C als Ballast und nicht als wertvolle Ressource gesehen wurde, beschreibt das Problem ziemlich gut: Für jemanden, der in ein paar Monaten ohne viel Gehirnschmalz und Vorkenntnisse eine kleine iOS-App programmieren möchte, mag C Ballast sein. Für anspruchsvollere Programme ist es eine wertvolle Ressource.

Das ist entfernt vergleichbar mit Macs mit Intel-Prozessoren. Die können die Vorteile von Macs ausspielen, aber gegebenenfalls auch Windows oder Linux ausführen. Ebenso kann Objective-C gegebenenfalls auf C und C++ zurückgreifen. Swift wäre dementsprechend ein Mac mit Apple-Prozessor.

Apple hätte auch Objective-C und Xcode für Einsteiger freundlicher machen können. Stattdessen hat es sich mit Swift für Masse statt Klasse entschieden und damit auch noch die Open-Source-Szene beschädigt, die auf das Reservoir öffentlichen Codes besonders angewiesen ist.


2. Swift erschwert das Verständnis dessen, was man tut

Nun könnte man ja argumentieren, eine leicht zu nutzende Einsteiger-Sprache sei doch nicht von Nachteil (zumindest wenn sie optional ist), um Menschen an das Programmieren heranzuführen.

Das ist prinzipiell sicherlich richtig. Das Problem ist, dass Swift gerade aus didaktischer Sicht problematisch ist (obwohl Apple gerade diesen Aspekt im Augenblick ja pusht). Ich hatte ja bereits erwähnt, dass Objective-C sehr klar macht, ob man sich gerade im „herkömmlichen“ („prozedural“ genannten) oder objektorientierten Teil der Sprache befindet. Bei Swift verwischen diese Unterschiede weitgehend, teils, weil die Syntax sie nicht offenkundig macht, teils, weil Swift sie tatsächlich nivelliert.

Das ist sehr schwer zu veranschaulichen, ohne in tatsächliches Programmierer-Chinesisch zu verfallen (weswegen dieser Abschnitt kurz ist). Swift ist in der Tat hilfreich und simpel für die allerersten Gehversuche, aber bald darauf wird zum Problem, dass man nicht wirklich versteht, was strukturell passiert. Ein wenig wie bei einem Automatik-Wagen: Ganz zu Beginn des Autofahrens ist es eine Erleichterung, nicht schalten zu müssen, aber wenn man später darauf angewiesen ist, die optimale Performance aus dem Auto durch manuelles Schalten herausholen zu müssen, merkt man nicht nur, dass man das gar nicht kann, sondern auch, dass, selbst wenn das Auto es erlauben würde, man nie gelernt hätte, wie es geht.

An diesem Punkt hilft es einer Sprache wenig, wenn, wie G4 94 betont, ihr Entwickler eine Legende im Compilerbau ist: Denn Compilerbau ist die vermutlich esoterischste aller Programmierdisziplinen, mit wenigen über die Welt verteilten Cracks. Wer tief in dieser esoterischen Welt steckt, hat möglicherweise eher wenig Zugang zu den „didaktischen“ Aspekten seiner Sprache. (Ausnahmen bestätigen die Regel: Als Brian Kernighan und Dennis Ritchie C entwickelten, schrieben sie auch gleich das Lehrbuch zu dieser Sprache, ein dünnes Bändchen, das bis heute das einzige Buch ist, das man lesen muss, um C zu verstehen.)

Swift fördert jedenfalls das Geht und stürzt nicht ab. Mir doch egal warum!-Denken beim Programmieren.


3. Swift hat eine katastrophal inkonsistente Syntax

Dieser Aspekt hängt mit dem didaktischen zusammen, betont aber eher die intellektuelle Konsistenz der Sprache.

Ich hatte ja schon geschrieben, dass Smalltalk, der Vorfahr von Objective-C, eine auch von ihrer intellektuellen Konsistenz her brillante Sprache ist.

Für die Mehrzahl der gängigen Programmiersprachen gilt dies leider nicht. Ihre Syntax ist ein pragmatisch entstandenes Kauderwelsch, das Linguisten die Haare zu Berge stehen lässt. Ein gutes Beispiel dafür ist Javascript. Netscape konzipierte diese Sprache mit heißer Nadel in wenigen Monaten, um ihrem Webbrowser eine Skriptsprache und damit einen Marktvorteil verschaffen zu können. Niemand bei Netscape dürfte damals auch nur annähernd geahnt haben, dass dieses „Provisorium“ dank der Internet-Entwicklung 20 Jahre später eine der meist verwendeten Programmiersprachen der Welt sein würde.

Auf diese Art und Weise entstanden zahllose Syntax-Erblasten, die von neuer Sprache zu neuer Sprache weitergeschleppt wurden.

Swift hätte einen radikalen Strich unter diese Entwicklung ziehen können und als erste „skriptartige“ Programmiersprache die Klarheit von Smalltalk/Objective-C fortführen können. Craig Federighi wollte das, aber Phil Schiller wollte das nicht – ihm war wichtiger, dass Swift denjenigen, die schon durch andere gegenwärtig existierende Skriptsprachen präformiert waren, so vertraut wie möglich vorkam: das gibt kurzfristig mehr iOS-Entwickler. Also das exakte Gegenteil von Think different! – machen, was alle machen, weil alle es gewohnt sind, nicht weil es besser wäre.

In dem Versuch, es allen recht zu machen, erklomm Swift dabei aber bislang ungeahnte Höhen der syntaktischen Inkonsistenz.

Ein besonders hanebüchenes Beispiel von schier endlos vielen:

Im Alltag fällt vielen von uns vielleicht gar nicht auf, dass wir europäisch schreiben (von links nach rechts), aber arabisch rechnen (von rechts nach links):
(y, das Ergebnis der Rechenoperation, also das Spätere, steht links.)

Der Grund ist natürlich klar: Die Arithmetik, von den Griechen begründet, wanderte zunächst in den arabischen Kulturraum und erst von dort zurück nach Europa.

Auch wenn wir das problemlos in unseren Alltag integrieren können, kann man natürlich prinzipiell auch auf die Idee kommen, das Kalkül der regulären europäischen Schreibrichtung anzupassen. Worauf man aber bei einigermaßen klarem Verstand nicht kommen kann, ist, beides zugleich zu tun.

Swift bringt dieses Kunststück an Inkonsistenz problemlos fertig.

Ein Befehl zur Anzeige der aktuellen Temperatur sähe in Objective-C so aus:
Das Ergebnis, eine Fließkommazahl, steht links – also arabisch.

Und bei der Anwendung dieses Befehls ist das ebenso:
Wieder arabisch, also konsistent. (Und man beachte, dass sich das Objective-C zwischen den eckigen Klammern fast wie ein natürlichsprachiger Satz lesen lässt.)

Swift hingegen ist bei der Definition eines Befehls europäisch:
(Man beachte auch Hässlichkeiten wie das syntaktisch erforderliche Kürzel func und die in diesem Falle (in dem der Befehl keine Parameter benötigt) völlig überflüssigen Klammern, die aber aufgrund der Swift-Syntax dennoch erforderlich sind.)

Doch die Anwendung dieses Befehls in Swift ist wieder arabisch:
Wie kann man einen Befehl in ein- und derselben Sprache europäisch definieren und arabisch anwenden und sich einen Kehricht um Konsistenz scheren? Das ist (zuallermindest) ein Maß an Gedankenlosigkeit und/oder Bewusstlosigkeit, das mich sprachlos macht.

(Ganz abgesehen von den erneuten übrigen Hässlichkeiten schon in diesem kleinen Beispiel: Wieder die unnötigen nötigen leeren Klammern, und ein Punkt zur Trennung von Subjekt und Prädikat, der in jeder natürlichen Sprache mit lateinischen Buchstaben zum Satzabschluss dienen würde, während jede natürliche Sprache zur Trennung ein Leerzeichen benutzen würde …)

Man kann natürlich argumentieren, dass das Programmieren mit Swift trotz seiner intellektuell verwahrlosten Syntax pragmatisch betrachtet funktioniert. Aber das ist ein bisschen wie mit PC-Towern und klassischen Mac Pros:

PC-Tower sind ein Massenmarkt, so wie sich Swift an aktuell massenhaft verbreitete Syntax-Unarten anlehnt. Ihr Innenleben ist chaotisch, aber funktionieren tut es.

Das Innenleben eines klassischen Mac Pro ist dagegen eine ganz andere Liga. Aber zunächst mal funktioniert ein Mac Pro pragmatisch deswegen nicht besser.

Dagegen kann man zweierlei einwenden:

Dass der durch und durch saubere Aufbau im Problemfall am Ende eben doch Vorteile bringt.

Oder – und das war Steve Jobs’ Argument – dass der saubere Aufbau selbst dort, wo ihn niemand sieht, ein Wert an sich ist, Ausdruck einer Geisteshaltung, die am Ende auf das ganze Produkt ausstrahlt.

Wie kann ein Unternehmen, das sich „am Schnittpunkt von Technik und Geisteswissenschaften“ verortet, auf eine Programmiersprache setzen, die so bar jedes geisteswissenschaftlich gespeisten Gespürs ist?

Die intellektuelle Brillanz von Objective-C war eine der Kernsäulen, auf die Jobs seinerzeit NeXt aufgebaut hat. Bei Apple hatte er einen langen Masterplan, um Cocoa und damit Objective-C dann doch noch zum lang erhofften Durchbruch zu verhelfen; mit dem Schachzug, dass Carbon-Applikationen nicht 64-Bit-fähig gemacht werden konnten, und natürlich mit der Popularität von iOS gelang das schließlich. Es ist schon eine bittere Ironie, dass kurze Zeit nach der festen Etablierung von Cocoa und Objective-C und unmittelbar nach Jobs’ Tod Apple damit begann, Objective-C von innen heraus infrage zu stellen.

Oooops, sorry, da war ein Fehler in dem Beispiel für eine Swift-Defintion:

Stattmuss es heißen:
Dass man die zurückgegebene Fließkommazahl bei der Anwendung des Befehls dann Temperaturwert nennt, passiert erst im eigenen Code.

Ändert nix am Argument, nur, falls es jemanden verwirrt …

@Weia: Du sagst dass man mit Swift auf die ganzen C Bibliotheken verzichten muss, aber tatsächlich kann man sie doch noch verwenden und mit Swift-Projekten über eine Brücke mischen kann. Ist das kein guter Kompromiss?

Das mit der Syntax in deinem dritten Punkt ist zwar schade, aber ob es am Ende des Tages wirklich so sehr einen Unterschied macht? Schwer zu sagen.

Dass das Programmieren immer weiter abstrahiert wird ist doch eine normale, voraussehbare Entwicklung. Vielleicht führt das tatsächlich dazu dass die Menschheit irgendwann gar nicht mehr weiß was da unten tatsächlich passiert. Ob das nun gut oder schlecht ist, weiß ich nicht. Wir wissen ja auch nicht wie unser Gehirn bis ins letzte Detail funktioniert und vollbringen beeindruckende Dinge, die wir wohl kaum vollbringen würden wenn wir auf alles bis ins letzte Detail verstehen müssten um es zu erreichen.

@Weia
Top Argumentation! Sehr stringent! Ich oute mich nun auch mal als Programmierer
Aktuell schreibe ich immer noch in Objective C.

Und noch zur Ergänzung (zu Weia):
Schon die Inkimpatibilitäten zwischen Swift 1.0, 2.0, 3.0 und 4.0 haben in den Entwicklerkreisen nicht gerade für Begeisterungsstürme gesorgt, sondern eher für entsetztes Stöhnen...

Es war und ist ja schon bemerkenswert, daß Apple sich nicht sofort dran gemacht hat und die grundlegenden Frameworks in Swift umschreiben läßt....
Solange das nicht geschieht, wird niemand in der Szene umsteigen.

Nun ja. Swift wird kommen. Ob ihr wollt, oder nicht. Ich für meinen Teil habe entschieden, mich gleich daran zu gewöhnen.

Also Einstig kann ich die Kurse von der Stanford University empfehlen. Mit Prof. Paul Hagerty. Die sind sehr gut. Und frei verfügbar.

Das sind dann aber komische Entwickler. Dass es zu Inkompatibilitäten kommt wenn noch so viel an der Sprache (mit der Community) rumgeschraubt wird, ist doch klar. Ich habe liebe eine Sprache auf die man anfangs noch ordentlich Einfluss nehmen kann, als irgendwas was vielleicht heute erst fertig währe und nur so aussieht wie Apple sich das gedacht hat.
Zwischen Swift 3 und 4 besteht übrigens keine Inkompatibilität, die sich nicht umgehen ließe.

@Weia: Toller Beitrag! Danke!

@Weia, Hut ab, sehr schön geschrieben. So kommt auch mal deine wirkliche Meinung hervor, die ging in den anderen Beiträgen etwas unter.

Ja, das ist so ein Punkt, wo ich der Lesbarkeit halber vereinfacht habe. Es stimmt, C kannst Du importieren. Wenn Du einfach eine C-Bibliothek nutzen willst, reicht Dir das vielleicht. Wenn Du aber nur Code-Fragmente z.B. zur Implementation von Methoden in Deinen eigenen Klassen verwenden willst, kannst Du sie halt nicht einfach in Deinen eigenen Code mit Copy&Paste einfügen, sondern musst sie in eine C-Datei auslagern – es wird auseinandergerissen, was sachlich zusammengehört.

Und mit C++ geht das gar nicht. Du musst erst einen Objective-C- oder C-Wrapper schreiben, der dann seinerseits wieder von Swift überbrückt wird.

Das alles erzeugt eine Menge Komplexität. Ja, man kann das als Kompromiss gelten lassen. Die Frage ist nur, wozu das alles? Es ist ja nicht so, dass Swift auf der Habenseite z.B. eine enorme Geschwindigkeitssteigerung oder was anderes Tolles bieten würde, für die man das in Kauf nimmt. Das Argument für Swift ist, dass die Sprache einfacher sein soll. Und das alles ist das genaue Gegenteil.
Ja, das ist eben die Frage, tut’s ein PC-Tower mit chaotischem Innenleben nicht genauso?

Ich neige dazu, dass alles, was gedankliche Klarheit und Präzision ausstrahlt, beim Programmieren jedenfalls komplexerer Programme hilfreich ist.

Auf jeden Fall ist die Frage, ob’s der PC-Tower nicht genauso tut, sehr Apple-unlike.
Da hast Du recht, aber das Problem mit Swift ist ja nicht, dass die Sprache ein höheres Abstraktionslevel erklimmt. Das wäre völlig in Ordnung (und insofern ist der Vergleich mit dem Automatik-Auto schief, mir fiel kein besserer zur Veranschaulichung ein); Objective-C abstrahiert ja ganz schön, wenn Du dir anschaust, was aus C-Sicht bei einem Methodenaufruf alles passiert.

Nur Swift abstrahiert eben nicht weiter, eher das Gegenteil: Bei Objective-C ist eine Klasse etwas vollkommen anderes als eine Struktur, auch wenn eine C-Struktur intern zur Implementierung einer Klasse dient. Und eine Methode ist etwas völlig anderes als eine Funktion, auch wenn eine C-Funktion intern zur Implementierung einer Methode dient.

Bei Swift verschwimmt das alles. Herrje, vor den Methoden einer Klasse muss sogar explizit func stehen. Und der unselige Punkt zwischen Subjekt und Prädikat ist Ausdruck der Implementation (dass die Methode eben ein Element der die Klasse implementierenden Struktur ist), während die Objective-C-Syntax von der Implementation völlig abstrahiert (wie es in der Objektorientierung sein sollte) und sich stattdessen um linguistische Konsistenz bemüht.

Von objektorientiertem in prozedurales Denken zurückzufallen, wie es gerade beim Einstieg nur allzu leicht passiert, wird durch diese Unschärfen natürlich befördert. Und das kann sich dann sehr wohl insbesondere auf die architektonische Qualität des eigenen Codes auswirken.

Es stellt sich mir immer wieder die Frage: Warum das alles? Was ist der Gewinn? Cocoa ist konzeptionell so ein grandioser Wurf, aber seit längerem viel zu buggy. Es gibt Frameworks, die seit über einem Jahrzehnt nicht fehlerfrei tun, was sie laut Dokumentation tun sollten. Wäre Einsteigern nicht um eine Vielfaches mehr geholfen worden, wenn man die Energien, die man in Swift gesteckt hat, stattdessen einer Pflege (und Erweiterung um „Komfortmethoden“) von Cocoa hätte angedeihen lassen?

In meinen pessimistischsten Momenten schrumpft das alles auf die Vorstellung zusammen: Compiler-Nerd zeigt technisch planlosem Management sein Steckenpferd, und das sagt begeistert Ja, weil es meint, damit viele Javascript-Programmierer zu Cocoa zu bekehren zu können und somit bei Apps aus cross-platform-tauglichem Javascript-Code mit einem dünnen iOS-Wrapper reinen iOS-Code zu machen, der dann an Apples Plattform bindet …

Ja, so ein Beitrag schreibt sich leider nicht „mal eben so“ …

Guter Beitrag Weia auf der anderen Seite lassen sich durch die Suche Swift vs Objektiv C viele andere Situationen und Probleme die bei Swift vs C ergeben einfacher verifizieren als in diesem Forenbeitrag.. trotzdem Hut ab davor... mir liegt Swift mehr alleine schon von der Lesbarkeit der Source Codes was aber wieder daran liegt das mir C von Haus aus spanisch vor kam und wenn ein Entwickler nicht ist sein Code ebenso unlesbar wie assemler

Du hast hier aber nicht Swift sondern Chris Lattner kritisiert.

Zum Thema Swift vs. Objective-C
1. SmallTalk
SmallTalk ist ein Xerox PARC Projekt und stammt nicht direkt aus der Universität. Jobs hat übrigens bei seinem denkwürdigen Besuch von Xerox PARC die Bedeutung von SmallTalk sowie der vorhandenen Vernetzung nicht erkannt.
2. C++ ist die OO-Sprache Apples
Apple hatte zuerst ObjectPascal verwendet. Man findet im Netz faktisch keinerlei Informationen zu Apples ObjectPascal und wird beim Suchen auf andere Projekte verlinkt, die komplett anders sind. Damit wurde das erste MacApp entwickelt. Als sich dann in Laufe der Zeit herausstellte, dass ObjectPascal nicht so der gelungene Entwurf ist, wurde auf C und C++ umgestellt. MacApp wurde nach C++ portiert - Version 3. MacApp blieb zusammen mit den FrameWorks von Symantec TCL (nur auf 68k Macs wurde nie auf PowerPC portiert) und PowerPlant von Metrowerks das FrameWork für die Mac Applikationsentwicklung.
3. NeXT
Nachdem Jobs Apple verlassen hatte, hat er NeXT begründet. Dort wurde dann ein eigenes Betriebssystem auf Basis des Mach Kernels mit BSD Personality entwickelt. Der Grund dafür war, dass Apple keine Lizenzgebühren an irgend jemanden zahlen wollte. Als GUI hat man leider proprietären Ansatz gewählt, der zu nichts kompatibel war. Das war einer der wesentlichen Gründe weshalb NeXT im Workstation Markt gescheitert war. Das Glück von Jobs war, dass Apple in der Zwischenzeit kein eigenes neues Betriebssystem auf die Reihe brachte. Das hat NeXT gerettet, da NeXT zuletzt nur noch vom Verkauf von WebObjects lebte und das wurde durch SUNs Java2EE endgültig vom Markt gefegt.
4. Designfehler von Objective-C
Objective-C krankt an fundamentalen Designfehlern, die sich auch nicht durch Hacks umschiffen lassen. Wegen des einen OOP-Ansatzes, dass alles dynamisch dispatcht wird, sind Methodenaufrufe immer langsam. Das ist zwar von der Logik her schön einfach und stringent, aber wenn man echte Applikationen entwickeln will in denen die Ausführungsgeschwindigkeit ein reales Problem ist, führt das zu erheblichen Problemen. Das ist auch einer der Gründe weshalb Cocoa-Applikationen (und nur noch die gibt es auf Macs) so träge sind.

Bjarne Stroustrup (dem Schöpfer von C++) versuchte für seine Promotion ein Programm zu schreiben und wählte dafür Simula, nach Deiner Auffassung reine OOP-Sprache ganz ähnlich zu SmallTalk, und so nebenbei noch sieben Jahre älter als SmallTalk. Das Projekt scheiterte und er musste von vorne anfangen, weil die Ausführungsgeschwindigkeit einfach unterirdisch war. Die ganze Geschichte ist in "The Design an Evolution von C++, Stroustrup, 1994" nachzulesen, und es entstand in der Folge "C with Classes" woraus sich dann C++ entwickelte.

Wenn man sich die Mühe macht und die Geschwindigkeit von Methodenaufrufen in C++ und Objective-C vergleicht sieht man dramatische Geschwindigkeitsunterschiede. Auf PowerPCs waren das mindestens drei Größenordnung (sprich minimal Faktor 1000). Da es etliche Methodenaufrufe in Cocoa gibt, die immer die gleiche Struktur (das wohl wichtigste Beispiel sind die retain und release Messages für die Speicherverwaltung) haben, verbrennt man hier unnötig Rechenzeit die man nicht mehr wieder bekommt.

Mal zahlt halt einen Preis, wenn man nur einen Hammer im Werkzeugkasten hat und die Schrauben mit ihm in die Wand prügelt. C++ ist deshalb eine Multiparadigmenprogrammiersprache, die es erlaubt hocheffiziente Programme zu schreiben. Sowohl unter Windows wie auch Linux (hier ist C++ neben C die am meisten genutzte Sprache) ist sie die Basis für die Entwicklung von GUI-Applikationen. Es gibt auf beiden Plattformen auch noch reichlich andere Möglichkeiten GUI-Applikationen zu entwicklen, man denke hier nur an C# oder den Sprachenzoo (C, C++, Vala, JavaScript, Genie, Java, Perl, Python, …) den Gtk+ unterstützt.

Apple hat wegen dieser Problematik in den letzten Jahren immer mehr Objective-C++ unterstützt, damit man Großteile des Codes mit C++ schreiben konnte und auch so den Portierungsaufwand von Windows- oder Linux-Applikationen minimieren konnte. Nur sind die Objektmodelle von Objective-C und C++ inkompatibel, so dass man immer zwei Objektgraphen im Programm hat bzw. ständig Wrapper für Objekte benötigt. Das erhöht die Komplexität in real existierenden Programmen deutlich. Es nützt auch nichts, wenn man immer darauf beharrt Objective-C sei der einzig glücklichmachende Ansatz Cocoa-Programme zu schreiben. Dogmatismus ist auf Dauer nicht hilfreich.

Dazu krankt Objective-C an den bekannten C-Altlasten wie etwa Zeigerarithmetik, die immer für einen Exploit gut ist.

5. Neue OO-Sprache für macOS
Wenn man diese real existierenden Probleme betrachtet war klar, dass Apple früher oder später eine neue OO-Sprache benötigen würde, die die Altlasten und Probleme von Objective-C nicht aufweist. Man kann nun lange darüber diskutieren, ob Swift dies erfüllt, aber die Möglichkeit C-Code NICHT in Swift einfügen zu können, ist ein wesentlicher Schritt in die Zukunft, weil endlich der C-Müll entsorgt wird. Da es Interfaces für C gibt, kann man den C-Code noch immer problemlos weiterverwenden, wenn man ihn kapselt und auslagert.

6. Nachtrag
Objective-C ist für viel schlechter als SmallTalk, da letzteres in einer VM ausgeführt wird und die auftretenden Probleme durch JIT und Laufzeitcodeanalyse minimieren kann. Objective-C kennt solche Optimierungen zur Laufzeit nicht. Es ist die Linearkombination der Nachteile von C und SmallTalk und hat sich aus guten Grund außerhalb von NeXT nie verbreiten können, da es eine richtige schlechte Sprache war und ist.