Mal 'ne dumme Frage: Warum soll eine Programmiersprache schneller sein als eine andere. Wenn man den gleichen Compiler nimmt und den Code in Maschinensprache übersetzt, ist doch eigentlich die ursprüngliche Sprache relativ egal.
Das ist ja nicht so, als ob das eine nativ ist und das andere wird nur in Bytecode übersetzt.

Und bei einer Sortierungsfunktion kommt es natürlich darauf an, wie gut der Compare-Callback programmiert ist.

Es hängt aber durchaus von der Programmiersprache mit ab, wie gut ein Compiler überhaupt optimieren kann und das scheint bei Swift besser zu funktionieren. Der Overhead bei Objective-C ist offenbar doch ziemlich groß, was sich negativ auf die Performance auswirkt.

Late Binding, Objekt-Handling, Delegates bremsen, da viel zur Laufzeit gemacht werden muss. Aber kommt das bei Sort-Algorithmen zum tragen?

Das wurde für den Zweck aber auch sehr unvorteilhaft implementiert. Absicht oder Unkenntnis?

Nein! Doch! Oh! Eine Sprache mit statischem Dispatch erzeugt schnelleren Code als eine Sprache mit dynamischen Dispatch. Hätte sich ja keiner Denken können. Fragt man sich nur, warum erst so viele Betas von Swift ins Land gehen mussten, bevor dieser Milestone erreicht wird.

Der Vergleicht hingt, hier werden Äpfel mit Birnen verglichen. Ein Vergleich von zwei Sprachen mit statischem Dispatch wie C++ und Swift wäre sinnvoller.

Es fasziniert viel mehr, wie es kommt, dass so ein unterdurchschnittlicher Blogpost durch so viele Nachrichtenportale gerollt wird.

Wie immer bei solchen Vergleichen sollte man genau wissen was verglichen wurde. Solche Tabellen ohne genaue Informationen sind vollkommen sinnfrei. Im Blog kann man dann nachlesen was verglichen wurde: Die Laufzeit des Sortierens eines NSArrays mit NSNumbers befüllt. Tja, das ist halt lahm. Interessant wäre es nun dazu ein stinknormales C Array zu sortieren, dann sähe man was möglich wäre.

aber sowas von. davon steht natürlich nirgends etwas.

genau das hab ich mir auch gedacht. mit den langsamsten methoden implementiert die er finden konnte.
Hätte er eine reine c-implementiertung dazugepackt wäre swift wohl meilenweit langsamer - aber das will man ja nicht

vor allem liegt es aber auch daran wie man etwas implementiert:

denn dort wird quasi "1+1" in swift mit "[[NSDecimalNumber numberWithInt:1] decimalNumberByAdding:[NSDecimalNumber numberWithInt:1]]" in obj-c verglichen obowhl man auch in obj-c "1+1" verwendet.

So lange ich Swift Code etwa 18x besser lesen und schreiben kann als ObjC, sind mir diese Performance-Ergebnisse ziemlich latte!

mir gehts umgekehrt. swift liest sich ja beschissen!

Mich haette ebenfalls der Vergleich zu C/C++ interessiert.

Dito.

Das nehme ich dir nicht wirklich ab. Auch ein eingefleischter Objective-C-Entwickler wird keine großen Probleme haben, Swift-Code zu lesen. Im Gegensatz dazu ist man jedoch als nicht-Objective-C-Entwickler kaum in der Lage, Objective-C-Code zu lesen.

Mach ihn einfach - der Swift-Code ist da. Der C++ Code ist tausendfach vorhanden. Die Werkzeuge im Überfluss ebenfalls.

Ich werde in ein paar Monaten mal ein Projekt mit Swift durchführen und bin gespannt, wie es läuft.

Doch, ich zum Beispiel. Ich finde die Swift-Syntax sehr schwer zu verstehen, sie verschleiert lauter Dinge, die ich auf einen Blick wissen möchte (Funktionen vs. Methoden, Strukturen vs. Klassen, Objekte vs. Skalare), ist ein unelegant zusammengeklaubter Gemischtwarenladen aus dem Horrokabinett verbreiteter, aber schrecklicher Sprachelemente und verwendet dann noch für alles und jedes die semantisch völlig kontrainuitive Dot-Syntax.
Objective-C liest sich wie Umgangssprache. Noch einfacher geht für eine objektorientierte Sprache wohl kaum. Ich habe jahrelang nur in C programmiert. Als ich Objective-C das erste Mal sah, war es Liebe auf den ersten Blick schon deswegen, weil es praktisch nichts zu lernen gab, nach wenigen Stunden erklärte sich alles von selbst.

Wie „verdorben“ von syntaktisch verhunzten Sprachen muss man sein, um Objective-C schwierig zu finden?

Ich habe die Klagen über die Lesbarkeit von Objective-C nie verstanden, angefangen bei der absurden Beschwerde über die rechteckigen Klammern. Meine Vermutung ist, dass die Klagen primär von Leuten kommen, die dynamische Objektorientierung nicht wirklich verinnerlicht haben und in ihrem Herzen noch immer prozedural denken.

Ich liebe Punkt-Notation. Es muss halt vernünfig umgesetzt sein. Zwar kommt Swift dahingehend noch nicht an C# heran, aber der Weg ist schon ganz gut. Besser jedenfalls als es Apple mit ObjC seit 2.0 versucht hat. Siehe auch

Die Lesbarkeit ist natürlich eine Sache der Gewöhnung. ObjC-Code jedoch _hasse_ ich zu lesen. Ich mache iOS-Entwicklung nur als Hobby. Wenn mir etwas keinen Spaß macht, lasse ich es. Apple hat es, obwohl ich seit Beginn des iOS-Entwicklerprogramms immer wieder einen Account hatte, nicht geschafft mich für ObjC zu begeistern. Ich lese ja auch kein Buch was ich langweilig oder gar doof finde.
Swift gefällt mir da schon weitaus besser, allerdings merkt man doch dass es unfertig ist. Auch ist die Priorisierung welche Methoden und Funktionen direkt an Object hängen, nicht wirklich gelungen. So finde ich dort (durch die Punkt-Notation) Unmengen an Funktionen die man nur selten braucht, wesentliche Dinge wie z.B. das Ermitteln einer String-Länge (.length in ObjC) finden sich an der String-Instanz z.B. wiederum gar nicht (es sei denn Apple hat es gestern seit der Beta 6 wieder drin). Dafür darf ich dann Funktionen wie countElements o.ä. auswendig lernen.

Und zwar weil?

Ein Punkt schließt in natürlichen Sprachen Sätze ab. Was ist der Vorteil davon, dieses Satzzeichen in Programmiersprachen derart kontrainutitiv gegen den Strich zu bürsten?

word-length
word length
word/length

– all das (und vermutlich noch einiges andere) ergäbe Sinn.

Aber

word.length

???

Ist das sinn.voll?
Und zwar weil?

Was kann verständlicher sein als

object createWorldPeaceAtDate:now

???

object.createWorldPeaceAtDate(now) sicher nicht. Wer nicht schon beim Punkt zu lesen aufhört, wird sich spätestens bei der Angabe des Zeitpunkts fragen, warum diese entscheidende Angabe eingeklammert (also nur erläuternd oder anmerkend) ist. Selbst den Punkt als eine Art „Untergliederung“ aufzufassen, funktioniert hier nicht, denn createWorldPeaceAtDate ist schließlich keine Eigenschaft des Objekts, sondern ein Auftrag, den man ihm erteilt.
Das verstehe ich sehr gut. Was ich absolut nicht verstehe, schon gar nicht bei einem Hobby, ist, wie einem Objective-C keinen Spaß machen kann.

Und zwar weil?

Was kann verständlicher sein als

object createWorldPeaceAtDate:now[/quote]

Warum erbt der WeltfriedenAtDate-Creator von einem Date/NSDate/DateTime-Objekt??
So anders kann Wahrnehmung halt sein. In allen Sprachen mit denen ich zu tun habe (C#, Javascript, Java - ja selbst diverse Skriptsprachen wie Actionscript oder unsere ERP-interne Skriptsprache) nutzen die Punktnotation. Ich habe mich so daran gewöhnt dass für mich der 'Punkt' schon ewig kein Ende mehr bedeutet, sondern das Zeichen mit dem ich per Intellisense o.ä. alle untergeordneten Funktionen, Methoden und Eigenschaften angezeigt bekomme und aurufen kann. Zudem liegt der Punkt auch auf der deutschen Tastatur so dass ich kein Shift drücken muss (etwas was mich z.B. auf der deutschen Tastatur an Zeichen wie :, {, [ stört (auch weil deren Belegung sich teilweise von Windows unterscheidet.

???
Richtig, hier wäre es eine Funktion/Methode. Eine Eigenschaft von der ich per = Werte empfange oder zuweise, hat keine Klammern(). Für mich liest es sich exakt so wie Du es beschreibst - ganz natürlich.
Ich kenne so einige denen es genauso geht. Von daher finde ich es sehr gut dass es nun eine Alternative gibt. Gleichzeitig verstehe ich dadurch auch immer mehr von ObjC - von "mögen" bin ich allerdings noch sehr weit entfernt.
Ein Fan von Swift bin ich allerdings auch noch lange nicht. Dafür sind mir zu viele Dinge noch nicht gut genug dokumentiert oder man findet zu wenig Infos darüber... aktuell z.B.: Wie erstelle ich eine Klasse die von Dictionary oder Array erbt das auf einer eigenen Klasse basiert? Die Beispiele die ich finde, sehen teilweise zwar durchaus logisch aus, funktionieren allerdings nicht... das ist teilweise mühsam. Auch dass Apple bei jeder Beta Kleinigkeiten abändert und ich bei jedem Update derzeit den Code meines aktuellen Projekts ein paar Stunden von nichtssagenden Compiler-Fehlermeldungen bereinigen darf. An den dummen "Apple Mach-O Linker"-Fehlern innerhalb meiner SHA-256-Klasse habe ich gestern bis 23 Uhr gesessen...

Ja, das ist wohl der springende Punkt. Die Syntax all dieser Sprachen, die Du nennst, ist vollkommen und ohne Not gegen die Syntax natürlicher Sprachen gebürstet (auch ein Doppelpunkt hat in natürlichen Sprachen niemals eine der Vererbung äquivalente Bedeutung, sondern eben ziemlich genau die, die er auch in Objective-C hat). Aber wenn man sich daran gewöhnt hat, findet man halt das „natürlich“.

Bei Sprachen wie C, auf einer Abstraktionsebene, die ohnehin der Mathematik näher als der Erfahrungswelt ist, kann ich das auch gut nachvollziehen. Aber zu objektorientierten Sprachen, die strukturell unsere Erfahrungswelt abbilden sollen, passt das eben überhaupt nicht. Da passt Smalltalk und in Folge Objective-C weit besser.
Dieser Satz ist ein schönes Beispiel für das, was ich meine. Du schaffst es, Funktionen und Methoden in einem Satz so zu verwenden, als ob die mehr oder weniger das gleiche wären. Für mich liegen die Welten auseinander und es sträuben sich mir die Nackenhaare, wenn ich so einen Satz wie diesen lese. Funktionen und Methoden haben aus meiner Sicht nichts miteinander zu tun. Methoden sind der „Wortschatz“ eines Objekts, der es ihm erlaubt, die Botschaften zu verstehen, die ich ihm sende. Funktionen sind einfach gekapselte Algorithmen.

Du kannst natürlich die Brille des Technikers aufsetzen und hervorheben, dass Objective-C Methoden mit Funktionen implementiert. Aber das wäre so, als würdest Du einen Mac auf den eingebauten Prozessor reduzieren.

Du magst das für eine Spinnerei halten, aber ich habe die Erfahrung gemacht, dass diejenigen, die die „Objektwelt“ von Objective-C verinnerlicht haben, bessere Lösungen in Cocoa zustande bringen als diejenigen, die in Methoden bloß irgendeine Abart von Funktionen sehen und mehr die hinter den Objekten stehende Implementation im Kopf haben als deren „Objekthaftigkeit“.
Das finde ich sehr interessant. Kannst Du ein Beispiel nennen, wo Swift auch etwas an Objective-C verständlicher machte?
Oje, mein Beileid – die Freuden des Early Adaptors …

Es tippt sich auf deutscher Tastatur einfach schlechter.
Rechteckige Klammern haben in C ein feste Bedeutung, und in Objective-C wird dieser konterkariert. Zum greift man in C mit dem Punkt auf Elemente eines Structs zu, so daß die Punktsyntax durchaus im Sinne vom C Design ist.

Wobei auch Objective-C so einige Stilblüten hat.

• [a foo: 1];
• Aber
• [A foo: 1 Para2: 2];

Weshalb läßt sich nicht der erste Parameter benennen? Dazu mißfällt mir mittlerweile generell die in vielen OO Sprachen verwendete Sytanx, daß eine Methode abhängig von einer Klasse aufgerufen wird. Ich sähe gerne Multiple Dispatch generell in OO Sprachen, und dann hat [A foo: 1] oder A.foo(1) keinen Sinn mehr. foo(A, B) wobei A und B Klassen aus Klassenhierachien sind, und abhängig von beiden Parametern die passende Methode ausgesucht wird.

Deine Probleme hätte ich gerne. So schnell sind meine Gedanken leider nicht, dass sie durch das Tippen eines Zeichens mit Doppelgriff ausgebremst würden. (Im übrigen kann man ja einfach auf englische Tastaturbelegung umstellen.)
Das stimmt, aber das ist ein prinzipielles Problem von Sprachen, die C mitnehmen, aber die Syntax ihren Gegebenheiten anpassen wollen. Es gibt halt nur begrenzt viele ASCII-Sonderzeichen. Die Alternative wäre für solche Sprachen, eine Syntax zu verwenden, die de facto die technische Implementation der neuen Sprache aus C-Sicht artikuliert (also Klassen als Strukturen, Dot-Syntax) – und das finde ich persönlich viel schlimmer.

Ich kam wie gesagt von C, und ich fand das nie ein Problem – der Einsatz von eckigen Klammern in C ist so vollkommen anders, dass da aus meiner Sicht nicht die geringste Verwechslungsgefahr besteht.

Aber wer weiß, vielleicht ist das gerade für Leute, die auch C erst mit Objective-C lernen, anders. Das könnte ich mir vorstellen.
Das ist eben der Punkt, wo ich Dir energisch widersprechen würde. Eine Klasse ist konzeptionell (nicht von der Implementation her) etwas völlig anderes als eine Struktur, und ich will, dass die Sprache den Unterschied hervorhebt und gerade nicht verwässert.

Anders formuliert: Lieber syntaktische als semantische Mehrdeutigkeiten.
Hm, wie soll das gehen? Das wäre wie ein Satz ohne Subjekt.

addElement:element

Ja gut und schön, aber wer soll das Element bitte wo hinzufügen?

Diese Analogie ergibt im Zusammenhang mit Multiple Dispatch keinerlei Sinn.

Nehmen wir mal das Beispiel, Matrizen. Man kann eine Matrix mit einer Matrix multiplizieren und eine Matrix mit einem Skalar. In Pseudocode ergäbe das nun M=Matrixobjekt, S=Skalarobjekt

• multiply(M,M) ließe sich auch als M.multiply(M) schreiben.
• multiply(M,S) ließe sich auch als M.multiply(S) schreiben.
• multiply(S,S) ließe sich auch als S.multiply(S) schreiben.
• Aber multiply(S,M) kann man eben nicht mehr als S.multiply(M) schreiben, denn ein Skalarenkörper hat keinerlei Ahnung von einer Matrix. Es ergibt keinerlei Sinn da so zu schreiben. Da aber die Skalarenmutliplikation mit einer Matrix kommutiert, muß es syntaktisch erlaubt sein.

Das ergibt so keinen Sinn. Wenn schon dann so addElement(Liste, Element) oder auch addElement(Element, Liste).

Oder umgekehrt: Multiple Dispatch ergibt im Zusammenhang mit OO keinen Sinn.
Bezeichnenderweise verwendest Du bei Deinem Beispiel eine prozedurale Syntax. Klar, wenn Du mathematisch denkst, hast Du recht.

Aber in OO hieße das eben:

[skalar multiplyWith:M];

Und wenn Deine Skalar-Klasse keine Ahnung von Matrizen hat, dann geht das eben nicht, sondern Du musst

[matrix mutltiplyWith:S];

schreiben (oder Deine Skalar-Klasse erweitern). Kommunikation von Objekten ist etwas anderes als eine mathematische Operation; deshalb ist es völlig wurscht, ob das mathematisch kommutiert oder nicht.

Aber Deine prozedurale Syntax verwischt diesen Unterschied, und dann kommt es zu diesem gedanklichen Pseudo-Problem. Genau deshalb finde ich die klar OO-orientierte Smalltalk-artige Syntax von Objective-C so wichtig.
… womit wir erneut bei einer prozeduralen Syntax wären.

Es gibt Regalmeterweise Literatur zum Thema, und es ist natürlich OO. Für den Anfang reicht wohl ein Blick in Object-Oriented Analysis and Design with Applications Grady Booch, und für den schnellen Einstieg .
Du bist zu sehr der Denke "Schicke dem Objekt M die Nachricht foo" verhaftet, und das ergibt in Zusammenhang mit Multimethoden (der deutsche Name dafür) keinen Sinn. Denn abhängig von allen polymorphen Argumenten wird die passende Methode ausgewählt und nicht nur abhängig von einem polymorphen Objekt. Es ist eine Verallgemeinerung des OOP Gedankens und wird auch häufiger benötigt, so daß man es in nicht Multimethoden fähigen Sprachen nachprogrammieren muß, mit einem nicht unerheblichen Aufwand.
Versuche das Problem zu verstehen. Lies Dir den Artikel durch und dann suche nach Objective-C & Multiple Dispatch bzw. Mulitmethods.

Diese „Denke“ ist für mich aber das Definiens von OO. Keine Kommunikation zwischen Objekten, keine OO (jedenfalls keine, die ich wollen würde). Multiple Dispatch in der Form addElement(Liste, Element) ist prozedural gedacht – die von Dir verwendete Syntax bringt das ja klar zum Ausdruck.
Ich verstehe das Problem. Ich verstehe nur nicht, warum das Problem ein Problem ist.

Denn Kopfzerbrechen bereitet die Sache doch nur, wenn Du ggf. sowohl Objekte als auch C-Typen als mögliche Argumente würdest haben wollen. OK, die Möglichkeit, OO und C zu mischen ist einer der großen Vorteile von Objective-C, aber dann ist es halt keine reine OO mehr. Wenn Du bei OO bleibst, also nur Objekte als Argumente hast, wo ist dann die Schwierigkeit?