Hallo,

ich komme aus der Java-Welt und möchte mich ein bischen in C/C++ unter Mac OS einarbeiten.
Dazu habe ich ein paar Fragen:
- Hat jemand evtl. ein paar Tips für mich, welche Bücher gut sind? Die Bücher sollten Bäume, Tabellen und Bilder (wie man am besten Bilder in einem Fenster anzeigt) behandeln.
- Unter Microsoft gibt es doch die MSDN für Windows programmierung. Gibt es auch eine Art API/Hilfe für die Mac programmierung und kann man diese evtl. auch irgendwo downlaoden? Da hab ich bis jetzt nicht viel gefunden. Und unter xcode finde ich keine brauchbaren infos, ausser wenns um Objective-C geht.

Ich danke für alle Anregungen.

Gruß

Nein...wäre in Anbetracht von Obj-C und Swift auch unsinnig.

Hallo Seco, Du kannst Dir vielleicht mal Objective-C++ ansehen. Aber ganz ehrlich, wenn Du für die Apple-Plattform programmieren willst und eh eine neue Programmiersprache lernen musst, dann nimm Swift. Alles andere macht keinen Sinn.

Seco:

Evtl. hilfreich für Dich?

Apple Developer Library: C++ Runtime Environment Programming Guide

Apple Developer Library: Overflow of C++ Containers

Apple Developer Library: OSObject: OSObject is the concrete root class of the Libkern and I/O Kit C++ class hierarchy.

Apple Developer Library: Guides and Sample Code: IOKit Device Driver Design Guidelines: The libkern C++ Runtime

Apple Developer Library: Guides and Sample Code: Kernel Programming Style: C++ Naming Conventions

Lass die Finger von C++ wenn du es nicht wegen Source-kompatibilität brauchst. Objective-C ist da viel sauberer und das dynamische Linking zur Laufzeit ala SmallTalk ist genial.
Ansonsten gibt es viele der Standardbibliotheken wie SDL etc. auch für Mac. Zum Teil basieren die aber noch auf Carbon und ist ein Auslaufmodell.

Wenn du eine neue Programmiersprache lernen willst, dann ist es sicher besser Swift oder ObjectiveC zu lernen. Sonst eher C.

Uiuiui! Das sind völlig unterschiedliche Programmiersprachen für ganz unterschiedliche Zwecke. Vielleicht sollte man vor so einer Empfehlung erstmal nachfragen was denn das Ziel sein soll. Man fährt ja auch nicht mit nem Bagger über den Nürburgring.

ssb:

Kommt drauf an, was er machen will, wohin er will. Wenn er Kernel- bzw. Device-Treiber für macOS oder iOS schreiben oder analysieren/verstehen will, könnte es sein, dass er sich mit C++ auseinandersetzen muss, weil der Kernel von macOS/iOS, XNU, teilweise in C, Teile davon – zum Beispiel I/O Kit, jedoch in C++ geschrieben ist, Apple sich an der Stelle wohl ganz bewusst für C++ nebst entsprechender API entschieden hatte:




Entsprechend hat's Apple auch in seiner Developer Library dokumentiert und stellt die dafür notwendigen APIs und Infos zur Verfügung, siehe oben.

Hallo und danke für eure Infos,

also an der Stelle möchte ich mich mal kurz vorstellen:

Ich bin nur Straßenbahnfahrer und kein Programmierer, das Programmieren ist für mich nur ein Hobby. Ich habe mir in Java einen JExplorer, ähnlich dem Windows Explorer, geschrieben und dabei auf einige Einschränkungen in Java gestoßen. Z. B. die Benutzerrechte für Dateien/Festplatten besorgen, oder Festplatte Sektorweise auslesen. Und ich hatte gehofft, das in C/C++ besser in den Griff zu bekommen. Ein bischen C (auf Konsolenebene) kann ich ja bereits, ich suche auch einen leichten Einstieg in die Fensterprogrammierung unter Mac OS. Für mich wäre Swift oder Objective-C eine komplett neue Programmiersprache. Tja, so siehts aus, und ich hoffe Ihr könnt mir dabei helfen.

Gruß

Wenn du eine graphische Benutzeroberfläche auf dem Mac programmieren willst, nimm Cocoa (das native Framework von Apple) und Objective C oder Swift. Schau dir einmal Objective C und Swift in ein paar Beispielen an und wähle dann, für dein Hobby, die Sprache, die dir am meisten zusagt. Beide werden dich bei diesem Vorhaben (einen Dateibrowser schreiben) gut begleiten.

Dich auf dem Mac in C/C++ einzuarbeiten macht wenig Sinn, die ganzen aktuellen Frameworks für die grafische Oberfläche sind nativ nur mit Objective C und Swift kompatibel.

Volle Zustimmung zu Mendel, und noch ein Hinweis:

Es gibt ein paar Frameworks wie z.B. Qt, die versuchen, eine Kompatibilitätsschicht zu C/C++ anzubieten. Das klingt in der Theorie gut und führt in der Praxis zu Komplikationen an allen Ecken und Enden. Für Firmen, die große C++-Programme auch für den Mac anbieten wollen, mag das trotz aller Probleme eine Erwägung sein (als Nutzer nerven einen solche Programme, da sie sich nie „wirklich“ wie Mac-Programme verhalten, z.B. gerade beim Umgehen mit Zugriffsrechten Probleme machen). Aber wenn Du neu einsteigst, kann ich nur raten: Hände weg!

Also bleiben wirklich nur Objective-C und Swift. Objective-C baut auf C auf (jedes Objective-C-Programm ist im Kern ein C-Programm), Swift nicht. Wenn Du von C kommst, würde ich Dir zu Objective-C raten, weil ich das auch viel verständlicher als Swift finde – das sehen andere zum Teil aber genau umgekehrt.

In jedem Falle solltest Du der Sprache keine allzu große Bedeutung beimessen. Objective-C besteht aus ganz wenigen zusätzlichen Befehlen zu C, das kann man im Prinzip an ein, zwei Wochenenden lernen. Der viel (viel!) größere Lernaufwand ist, die ganzen Schnittstellen zu macOS und seiner grafischen Oberfläche (also Cocoa) zu überblicken, denn da gibt es buchstäblich Tausende von Befehlen, und man muss zumindest ein Gefühl dafür bekommen, wonach man konkret in der Dokumentation suchen muss.

Das ist die eigentliche Lernkurve, und die bleibt Dir nicht erspart, ganz egal, welche Programmiersprache Du benutzt, Objective-C oder Swift. Und Zwischenebenen wie Qt, um C++ nutzen zu können, würden da nur noch eine zusätzliche Komplexitätsebene einführen.

Ich möchte noch einen Hinweis bezüglich Objective-C und Swift geben. Wenn man als Neueinsteiger vor der Frage steht, ob Objective-C oder Swift, dann sollte man auf jeden Fall Swift nehmen. Einfach aus dem Grund, dass Swift die Zukunft unter macOS und iOS sein wird bzw. ist. Jegliche Bemühungen Apples bei Programmiersprachen zielen mittlerweile ausschließlich auf Swift. Außerdem sind alle Frameworks und Co mit Swift kompatibel, auch wenn sie selbst noch in Objective-C geschrieben sind. Objective-C wird definitiv nicht mehr von Apple getrieben, da als Neueinsteiger mit anzufangen wäre Unsinn (zumal ich persönlich die Syntax grässlich finde ).
Bei anderen Programmiersprachen kann ich nicht viel sagen, außer dass C oder C++ ungeeignet sind, wenn du nicht entweder Cross-Platform-Kompatibilität brauchst oder Low-Level arbeiten willst (was einem Hobby-Programmierer, wie du dich beschrieben hast, sowieso nicht zu empfehlen ist).

Da würde ich Dir energisch widersprechen.

Wie ich schon sagte: Bezüglich der Frage Objective-C vs. Swift gibt es große Meinungsunterschiede. Da sollte der Einzelne entscheiden, was besser zu ihm passt.
Dass etwas die Zukunft nicht nur sein wird, sondern sogar schon ist, ist ein philosophisch interessantes Statement.
Das stimmt. Ob das dazu führen wird, dass auch nur ein ernstzunehmendes Programm tatsächlich in Swift geschrieben wird, muss aber eben die Zukunft erst noch zeigen.

2002 machte die Einschätzung die Runde, Apple würde Objective-C einstellen zugunsten von Java. Wir wissen alle, was daraus wurde.
Und immer bleiben werden! Denn Core Foundation und der gesamte Unix-Unterbau ist C. Swift kann immer nur eine zusätzliche Sprache sein, solange es macOS in der heutigen Form (OPENSTEP-Weiterentwicklung) gibt; seine Zukunft ist daher offen, ganz egal, was Apples Werbestrategen im Augenblick forcieren.

Die Zukunft von Objective-C ist hingegen aus technisch zwingenden Gründen gesichert.
Gerade für Neueinsteiger gilt das nicht, da die Sprache für jeden, der nicht durch diverse Unsitten anderer Sprachen schon „verbildet“ ist, um so Vieles verständlicher ist.
Die Syntax ist brillant, ganz im Gegensatz zu Swift, einem grässlichen Gemischtwarenladen aus allem, was gerade en vogue ist, ohne jeglichen intellektuellen Horizont. Think alike statt Think different.
Wie bitte? C ist die lingua franca der Programmiersprachen und die Basis von Unix!

Das Folgende ist ein Beispiel, über das ich jüngst zufällig in Stackoverflow gestolpert bin.

Da hatte jemand die Frage, wie man ein NSDictionary (das ist eine Sammlung von Objekten, die jeweils über ein „Schlüsselwort“ (key) aufgerufen werden können) nach den keys sortieren könne, in Objective-C so beantwortet:


Jahre später hat er dann eine Swift-Version hinzugefügt:


Wie zum Teufel kommt man auf die Idee, dass Letzteres für einen Einsteiger leichter zu verstehen wäre als Ersteres?

Geht mir auch so .
Bei Objective C erfreue ich mich immer an der Eleganz des Nachrichtenkonzeptes.
Bei Swift-Code: keine Eleganz, keine Schönheit, keine Klasse (aber Klassen schon, ha, ha ), da es wie ein konzeptloses Sammelsurium von allem, was gerade angesagt ist, wirkt.

Da so gut wie alle Apple-Apps und auch 9x% des high-level-codes von macOS noch in Objective-C geschrieben sind, wird Apple mit Sicherheit Objective-C noch eine Dekade unterstützen müssen. Da es sich beim Fragesteller um ein Hobby handelt, sollte er demnach einfach nach Sympathie die Sprache auswählen. Er muss ja jetzt kein Projekt beginnen, dass ihn 20 Jahre begleitet (dann wäre wohl Swift die bessere Wahl).

Also, dann mal danke an Mendel und Weia.

Ich war bisher immer der Meinung, dass die Grafische Oberfläche immer in C++ bei ALLEN Betriebssystemen ist. War wohl auf dem Holzweg.

Wenn ich das nun richtig verstanden habe, ist Cocoa für die Benutzeroberfläche einzusetzen und für alles andere Objective C. Aber eine Frage hab ich dann doch noch, kann ich denn auch mit Ob.-C die Festplatte Sektorweise auslesen, oder was brauche ich dazu?

Übrigens, werd ich mir mal Ob.-C und Cocoa anschauen.

Um es mal etwas zu ordnen:

Die API heißt Cocoa.
Die primäre Sprache seit den 80ern, um damit/dafür zu entwickeln, heißt Objective-C (Kurz: Obj-C)
Die neue, moderne Sprache, um damit/dafür zu entwickeln,heißt Swift.

Objective-C ist eine strikte Obermenge von C, das bedeutet, dass jedes C-Programm mit einem Objective-C-Compiler kompiliert werden kann. (Zitat: )

Was (seit sehr langer Zeit) stimmt, ist, dass für grafische Oberflächen immer objektorientierte Sprachen eingesetzt werden. Das liegt daran, dass deren Konzept, den Code in einzelne Objekte aufzuteilen, bei den grafischen Oberflächen ganz besonders nahe liegt, da die ja immer aus lauter solchen Objekten (Tasten, Textfelder, Fenster, …) bestehen. Eine objektorientierte Sprache ist da also die „natürliche“ Wahl.

C++ ist eine solche objektorientierte Sprache, Objective-C eine andere. Beide bauen auf C auf, um Objektorientierung zu implementieren, allerdings auf sehr unterschiedliche Weise.
Nicht ganz. Objective-C ist die (objektorientierte) Sprache, in der Cocoa geschrieben ist und mit der man auf Cocoa zugriffen kann.

Cocoa selbst ist eine Ansammlung von (Objective-C-)Klassen, also vorgefertigten Bausteinen, die man für die Programmentwicklung braucht.

Das sogenannte AppKit (Application Kit) enthält Klassen/Bausteine für die Entwicklung von Programmen mit grafischer Oberfläche braucht, also insbesondere für die grafische Oberfläche selbst, aber nicht nur.

Das sogenannte Foundation Kit bietet hingegen Klassen für ganz grundsätzliche Funktionalitäten an, Datenstrukturen, Zahlen usw. Du könntest mit Objective-C und Klassen aus dem Foundation Kit z.B. auch ein Kommandozeilenprogramm fürs Terminal schreiben.

Cocoa ist wie gesagt der Oberbegriff für Application Kit, Foundation Kit und noch einige weitere in Objective-C geschriebene Klassen-Sammlungen.

Richtig ist, dass für ein Mac-Programm, dass sich „richtig“ anfühlt, mindestens die grafische Oberfläche in Cocoa/Objective-C geschrieben sein muss. Der Rest könnte (gerade bei Cross-Plattform-Programmen) dann auch in C oder C++ sein.
Das hängt immer davon ab, was genau Du tun willst.

Da Objective-C auf C aufbaut, kannst Du problemlos im selben Programmcode auf C zurückfallen, wenn Du low-level-Funktionen brauchst. Du kannst, wenn nötig, auch C++-Code nach Bedarf integrieren. Treiber in macOS werden z.B. in C++ geschrieben.

Die generelle Hierarchie bei macOS ist wie folgt:

Höchste Abstraktionsstufe
Cocoa (Application Kit / Foundation Kit / …)

Core Foundation (dieselben Funktionalitäten wie Foundation Kit, aber als reiner C-Code, umständlicher zu handhaben, aber teils detailliertere Eingriffsmöglichkeiten und performanter; ebenso gibt es andere Core…-Bibliotheken, z.B. Core Graphics – das Prinzip ist immer dasselbe, mehr low level als Cocoa, reines C, oft Entsprechung zu Cocoa-Klassen, aber umständlicher zu handhaben als Cocoa)

Unix-Ebene – reines C
Niedrigste Abstraktionsstufe

Und wie gesagt, alle Ebenen lassen sich in ein und demselben Code problemlos mischen.

Ist es eigentlich möglich ein UI in Swift zu schreiben und dann auf ein C++ Framework zuzugreifen für Modell und die Logik?

Nur mit Verrenkungen. Du musst C++ erst in Objective-C oder C kapseln und das dann wiederum von Swift ansprechen.

Guck dir einfach die Doku an. Ich finde die Swift-Version wesentlich besser. Aber bei sowas kommt es halt immer drauf an, was man gewohnt ist. Ich kenne das selbst ganz gut. Ich arbeite auf der Arbeit zum Beispiel mit der Programmiersprache Delphi. Während viele Leute Delphi grauenhaft finden, finde ich Delphi einfach super. So finde ich die Syntax von Objective-C einfach grausam (mehrere Versuche, damit klar zu kommen, sind kläglich gescheitert), während du das super findest. Meiner Meinung nach ist die Punkt-Schreibweise deutlich übersichtlicher als die Klammer-Schreibweise, was aber sicherlich auch eine Sache der Gewöhnung ist.Für den Kommentar würde ich dir gerne an den Kopf hauen. Bitte lese vollständige Sätze, bevor du irgendwas kommentierst! Mein Satz war da noch lange nicht vorbei!

Ansichtssache

Offtopic für den (hoffentlich nicht allzu verwirrten) Thread-Starter!
In der Doku steht nichts darüber, inwiefern Swift für Einsteiger verständlich ist.

Es geht ja nicht darum, ob ich das verstehe. Es geht darum, dass Apple Swift als eine für jedermann, insbesondere auch Einsteiger leicht verständliche Sprache propagiert. Und das ist, sorry, absurd.

Unter den beiden Maßgaben, dass jemand, der programmieren will, leidlich Englisch versteht, und dass er schon weiß, was ein Array und ein Dictionary sind, kann er das obige Beispiel in Objective-C unter Missachtung von eckigen Klammern und ähnlichem fast wie einen natürlichsprachigen Satz lesen und zumindest erahnen, worum es geht.

Bei der Swift-Variante ist das weitgehend ausgeschlossen.

Ganz simple Frage: Was heißt let? (Und damit meine ich nicht die funktionale Bedeutung in Swift (die kann ich nachschlagen), sondern, warum da let steht und nicht paf.)
Lass die eckigen Klammern weg, die im Wesentlichen einfach die Grenze zwischen C und Objective-C markieren, und Du hast fast natürlichsprachige englische Sätze. Was kann daran schwer zu verstehen sein?
Nein, es ist Sache des Verständnisses.

In C und Swift steht ein Punkt (Dezimalpunkt jetzt mal außen vorgelassen) für ein Mitglied einer Struktur.

Wenn Du dasselbe Zeichen auch für Methoden einer Klasse benutzt, verwischt Du komplett den semantischen Unterschied zwischen Strukturen und Klassen. (Und Swift macht das ja mit Absicht, es unterscheidet ja nicht mal zwischen Funktionen und Methoden ).

Jetzt kannst Du natürlich entgegnen, dass Klassen auch in Objective-C ja durch Strukturen implementiert werden. Das stimmt, aber die Grundpointe objektorientierten Programmierens ist die Abstraktion von der konkreten Implementation. Wenn mich aber die Syntax mit der Nase auf die Implementation stößt, dann werde ich immer wieder in Gefahr kommen, prozedural statt objektorientiert zu denken, von der Implementation statt der Semantik her. Ich sende kein Nachricht an das Objekt, sondern ich rufe eine Funktion in einer Struktur auf. Und diese mangelnde Abstraktion macht sich in der konzeptionellen Qualität des Programmcodes mit großer Wahrscheinlichkeit bemerkbar.

Gehst Du von dem Vater von Objective-C, Smalltalk, aus und dessen Anlehnung an natürliche Sprachen, wird das Ganze noch absurder, denn in natürlichen Sprachen steht der Punkt überall für das Satzende.

Wir schreiben eben
Peter schließeDasFenster: großesFenster
und nicht
Peter.schließeDasFenster: großesFenster

Schließlich ist Swift auch noch in sich inkonsistent.

Die Wertezuordnung zu Funktionen ist europäisch in der Definition (von links nach rechts, funktion() –> resultat), aber arabisch (wie üblich in der Arithmetik) bei der Implementation (von rechts nach links, resultat = funktion()). Wie kann man als Schöpfer einer Kunstsprache derartig konfus denken?

Swift mag pragmatisch funktionieren, für manche sogar gut, aber intellektuell ist die Sprache verwahrlost. Und ja, unter Steve Jobs wäre Swift nicht passiert (ich weiß, wie sehr er Objective-C hochhielt …).
Ich habe Deinen ganzen Satz gelesen, und der nicht zitierte Rest ändert nichts an meiner Antwort.

Wer ein ernsthaftes Verständnis vom Programmieren erwerben will, muss zumindest ein Grundverständnis von C haben. Punkt.

Ich habe vor etlichen Jahren ganz neu angefangen auf dem Mac zu programmieren.

Weias Ausführungen zu Objective-C für Anfänger decken sich vollständig mit meiner Erfahrung!

Und wie schon erwähnt wurde, ist das Lernen der Sprache ja nur ein Bruchteil des Lernpaketes im Gegensatz zu den Frameworks.

Wenn du von Java kommst solltest du C++ und macOS vergessen und gleich mit Swift anfangen. Für Java Entwickler ist der Umstieg darauf sehr einfach und Swift ist in der Apple Welt (und vielleicht auch woanders) die Zukunft. D.h. alle zukünftigen Frameworks und APIs werden mit Swift umgesetzt sein.

Und welche Bücher würdet ihr da empfehlen?
Jetzt mal ganz abgesehen ob Neueinsteiger oder nicht?
Was würdet Ihr z. B. zu diesen Beiden Bände sagen:

Objective-C und Cocoa Band 1 und Band 2
Amin Negm-Awad

Oder doch lieber dieses:
Einstieg in Objective-C 2.0 und Cocoa
ISBN 978-3-8362-1933-4

Oder doch lieber etwas ganz anderes?

Übrigens hab ich mir xcode ein bischen angesehen und da mal die Hilfe der Klasse NSMutableString zufällig herausgepickt. Das ganze ist schon richtig goldig gemach, aber wie ist den die Hilfe zu benutzen? Habe ich da keine Darstellung aller Konstruktoren mit allen Methoden, oder wie muss ich das verstehen?

??? Wie soll er macOS vergessen, wenn er auf dem/für den Mac programmieren will?
Womit sie umgesetzt sind, ist letztlich egal, da die API immer für Swift und Objective-C existiert.

Zumindest viele systemnahe Frameworks werden intern aber bei Objective-C bleiben, da nur Objective-C die unmittelbare Interaktion mit C erlaubt, und Unix und damit macOS nunmal in C geschrieben sind (Swift übrigens auch).

Ich kenne aus eigener Anschauung leider nur englischsprachige Bücher.

Da ist Hillegass, Cocoa Programming for Mac OS X der „Klassiker“. Man muss aber auf die Auflage achten, je nachdem, was man will: Die vierte Auflage benutzt Objective-C für die Beispiele, die 5. Auflage Swift.
Ich bin mir nicht ganz sicher, was genau Du gesehen hast – die Quick Help für die aktuelle Methode am rechten Fensterrand?

Die „ausführliche“ Hilfe erreichst Du mit Help → Developer Documentation, und natürlich sind da alle Methoden für jede Klasse aufgelistet

Ich höre immer gute Sachen hierüber:
Eines der ersten Sachen, die du lernen wirst, ist: Die Apple-Dokumentation ist SCHEISSE. Sie ist unvollständig, geht meist nicht in die Tiefe, oft werden Details vergessen und manchmal ist sie auch nicht-existent für diverse Frameworks. Häufig findet man auch in Header-Dateien wild verstreut wichtige Kommentare der Entwickler....es ist einfach ein Graus. Die APIs an sich sind meist sinnvoll benannt, so dass sich mit einiger Übung die Nutzung einer Apple-Klasse sich direkt aus dem Header erschließt (guck dir NSString an, anhand der Methodennamen erkennt man gut was man machen muss).

Sorry. Das sollte heißen C++ AUF macOS.

Ah, OK!

Ich kann C mit nicht einer Silbe, aber dennoch habe ich ein sehr gutes Verständnis vom Programmieren. Das wurde mir schon von verschiedenen Personen bestätigt, mal abgesehen davon, dass ich als Software Engineer mit Programmierung mein Geld verdiene. Und für das, was ich in meinem Job programmiere, braucht man ein ziemlich hohes Verständnis vom Programmieren. Lasse deine These damit als falsifiziert gelten (Eine These gilt dann als falsifiziert, wenn es mindestens ein Gegenbeispiel gibt , dass hast du jetzt).

Und nebenbei brauchst du nicht in endlos großen Antwortet versuchen zu erklären, was Programmierung ist und wo die Unterschiede zwischen Objective-C und Swift liegen. Ich kenne das schon.

Nur noch hierzu:Natürlich verstehe ich die Objective-C Syntax, ich habe damit schließlich auch schon programmiert. Aber trotzdem konnte ich mich nicht daran gewöhnen. Andersherum konnte ich mich zum Beispiel extrem schnell an die (heutzutage) ungewöhnliche Syntax von Delphi gewöhnen, während andere schon bei deren Erwähnung beinahe einen Herzinfarkt bekommen. Ich kenne Leute, die lange Zeit mit Delphi programmiert haben, aber die Syntax dennoch grauenhaft finden.
Wenn ich eine Syntax grauenhaft finde, dann ist das meine Meinung, und ich habe das stets auch so formuliert. Da bringen deine Argumentationen nichts, ich werde es trotzdem grauenhaft finden.

Ich bin (anhand Deiner Äußerungen) nicht davon überzeugt, dass es dieses Gegenbeispiel gibt.
Wir befinden uns hier in einem Thread, der von einem Einsteiger gestartet wurde, und ich wollte meine Antwort so verständlich wie möglich auch für ihn halten. Dass Du weißt, was ein NSDictionary ist, ist mir klar.
Wenn Dir das alles so klar ist, dann beantworte mir doch bitte noch meine Frage von vorhin:

Was heißt let? (Und damit meine ich nicht die funktionale Bedeutung in Swift (die kann ich nachschlagen), sondern, warum da let steht und nicht paf.)
Und kannst „C mit nicht einer Silbe“?
Verständlich. Über diesen Punkt habe ich auch lediglich meinerseits mein Erstaunen geäußert.

Na zum Glück sind Geschmäcker verschieden. Ich für meine Teil kann behaupten das meine Swift Programme das eleganteste sind was ich je umgesetzt habe. Kann aber auch am wirklich guten Cocoa(Touch) Framwork liegen.

Ich für meinen Teil find Swift die bisher beste Syntax mit der ich arbeiten konnte. Alleine das Konzept der internen und externen bezeichnet von Übergabeprametern hat mir einen häufen Dokumentation gesparrt. Ist schon geil wenn da am Ende fast ein echter Satz beim aufrufen herauskommt.

Das verstehe ich jetzt gar nicht, denn das wäre ja gerade eines der Argumente, die ich für Objective-C und gegen Swift ins Feld führen würde. Kannst Du ein Beispiel nennen für das, was Du meinst?

Dann bin ich wohl ein Geist und existiere nicht.Ehrlich gesagt, ist es mir ziemlich egal, was let für eine Übersetzung hat. Ich weiß, wozu es benutzt wird und das reicht mir vollkommen aus. (Und jetzt komme bitte nicht mit "weißt du denn was if, for und while bedeuten?"). Und wenn ich let im Google Übersetzer eingebe macht die Übersetzung für mich doch eigentlich ziemlich viel Sinn im Kontext mit nicht änderbaren Variablen.Eigentlich sollte das für dich die Bestätigung sein, dass ich keine Ahnung von C habe.Für mich klang das eher so, als versuchest du mich zu überzeugen, dass die Syntax nicht grauenhaft sei. Aber sei's drum.

Swift. Ganz klar. Obj-C wird sterben. Erst recht, wenn man erst damit anfängt.

Du unterschlägst dabei, daß man mit sowas nicht anfängt. Am Anfang wäre mir das auch schwer vorgekommen. Jetzt nicht mehr.


Seko
Schaue Dir die kostenlosen Kurse von Prof. Paul Hagerty, Stanford University an. Die sind saugut. Entweder über iTunes U oder YouTube.

Für den Nutzer der Klasse sieht das dann so aus


Durch kann man den öffentlichen Bezeichnern mehr Klarheit geben, intern in der Funktion aber verkürzte Namen verwenden. Somit gestaltet sich ein Functionsaufruf lesbarer m. M.
Das ist jetzt ein sehr reduziertes Beispiel. Aber bei mehreren Parametern muss man doch schon dokumentieren was die Parameter so alles machen. Da ich bei Swift aber dann denn öffentlichen Namen beim Aufruf angeben muss wenn er definiert worden wäre kann man ohne Syntaxassitenten das trotzdem halbwegs lesen.

Das allerschlimmste an Objectiv-C ist das jede Klasse ein Interface braucht. Hallo? 1985 hat angerufen und will seine Sprache wieder haben.

Objective-C:

Swift:

Tut mir leid. Für mich ist Obj-C kranker Mist.

Glaub mir, da gewöhnt man sich mit der Zeit dran. In Delphi (auch eine schon sehr lange existente Sprache, kommt von Pascal) ist das auch so. Ich habe mich eigentlich ziemlich schnell dran gewöhnt. Und in der Tat finde ich persönlich das extrem praktisch, vor allem in sehr großen Klassen. Den dadurch hat man eine super Übersicht über alle Methoden, globalen Variablen und Propertys. Aber wie oben schon oft gesagt, ich kenne genug Leute die Delphi u.a. deswegen grauenhaft finden

Das mit der Übersicht sollt das IDE erledigen und nicht durch überflüssigen Code.

Du existierst ziemlich sicher , aus meiner Perspektive nur nicht als jemand, der (um meine Worte zu wiederholen, auf die Du reagiertest) „ein ernsthaftes Verständnis vom Programmieren erwerben will“ (und daher, so meine These, eine Ahnung von C haben müsse). Wie sich unmittelbar zeigt:
Und genau das ist mein Punkt. Dir reicht es, dass Du die Sprache pragmatisch erfolgreich einsetzen kannst, der Rest ist Dir egal. Entstehungsgeschichte, intellektuelles Konzept, kulturelle Hintergründe, Eleganz und Ästhetik: alles schnurz, solange die Programme funktionieren.

Das ist nicht mein Begriff von einem ernsthaften Verständnis vom Programmieren. Das wäre, wie wenn jemand meint, er hätte erfolgreich Romanistik studiert, weil er sich in Paris ohne Probleme ein Hotel buchen oder ein Essen bestellen oder meinetwegen auch komplizierte Vertragsverhandlungen führen kann.

Oder, um einen Hardware-Vergleich zu bemühen: Wie wenn jemand einem (alten) Mac Pro angesichts seiner ästhetisch aufgeräumten Innereien nichts besonderes abgewinnen kann, weil ein PC-Tower mit Kabelverhau schließlich genauso gut funktioniert. Nicht sehr Mac-like.
Nur dass let so verstanden als Verb gebraucht wird, der Antipode var hingegen eine Abkürzung für ein Substantiv ist. Dir ist diese völlig hirn- und grundlose Inkonsistenz vermutlich wieder egal – denn es funktioniert ja –, mir bereitet sie Kopfaua. Wenn ein Autor einer Sprache nicht einmal fähig ist, auf einer so basalen Ebene konsistent zu sein, was soll ich dann wohl von ihm erwarten, wenn es kompliziert wird?

Und das ist ja kein Ausrutscher, sondern eine von zahlreichen Inkonsistenzen in Swift.

Objective-C stirbt besonders schnell, wenn Menschen gerade erst anfangen, es zu nutzen?

Ja klar ist das prima. Nur ist das doch lediglich ein halbgarer Abklatsch von Objective-C, wo die noch störenden „Implementationsreste” wie die Klammern, die auf den Funktionscharakter der Methode verweisen, völlig fehlen:


Die Swift-Syntax ist diesbezüglich sicher besser als alle anderen Sprachen – außer Objective-C

Das ist erstens falsch und zweitens ein großer Vorzug.

Eine der elementarsten Konzepte der objektorientierten Programmierung ist die Kapselung der Implementation.

Wie anders als durch eine von der Implementation getrennte Header-Datei kann ich festlegen, welche Methoden zum Interface gehören und welche nur zur Implementation?

Und für objektinterne Methoden brauchst Du übrigens kein Interface; Du kannst die Methodenimplementation einfach irgendwo innerhalb von @implementation hinschreiben und sofort aufrufen.
Weil es das Interface von der Implementation trennt? Dann hast Du entweder Objektorientierung nicht verstanden oder findest sie auch „kranken Mist“ …

Es wird sterben. Kapier das endlich.

Du bist so hellsichtig wie freundlich …

Weia Ich schreibe dir eine PN, denn was jetzt kommt, hat hier nichts mehr zu suchen.

Nein. Man kann diese "Swift ist Scheiße"-Gejammer langsam nicht mehr ertragen. Auf der Macoun 2015 (oder so) gab es da auch so ein paar Jammerlappen. Da wurden schöne Beispiele konstruiert, die dann besonders dämlich aussahen. Leider sind ja die Videos aus dem letzten Jahr nicht online. Mich hätte interessiert, ob sich da die Lage gebessert hat und es da interessantere Informationen zum Thema Swift gegeben hätte.

Man gewöhnt sich an alles. Aber besser ist eben die Sprache, die man auch schon zu Beginn verstehen kann.

Kann ich nicht unterschreiben, auch wenn ich selber C sogar gut beherrsche. Aber ich habe auch genug Kollegen, die als Hochsprache nur Java kennen oder sogar noch weniger und mit Python oder PHP qualitativ gute Ergebnisse abliefern und über ein hervorragendes Programmierverständnis verfügen.

Deine Aussage s.o. ist deutlich zu apodiktisch.