Der soll erstmal seinen Laden aufräumen, das was Apple da an Software auf die Menschheit loslässt, ist inzwischen unterirdisch.

... dein geistiger Dünnschiss auch.

was willst du denn?
er hat doch recht

Nö, hat er nicht, ich mag OS X, Pages, Numbers, iTunes, Safari, GarageBand, …

Er hat trotzdem Recht

Um mal zurück zum Thema zu kommen:

Ist Swift wirklich so gut? Was macht das besser als andere Programmiersprachen?
Ist laaaaaange bei mir her mit dem Programmieren (COBOL, C und ein wenig Smalltalk)

Wenn sich der Kommentar auf Swift bezieht (und davon gehe mal bei einem Kommentar unter einer Swift-News aus), bleibe ich bei meiner Wortwahl.

NEIN.

Jesse Squires (Facebook software engineer) Blog (06.12.2015): Swift open source: Let the revolution begin und Open source Swift: weekly brief: What's been happening during the first full week on Swift.org?

Zudem interessant Chris Lattners Einlassungen zu Swift im Vergleich zu anderen Programmiersprachen, einen bestimmten Teilaspekt betreffend.

Swift Mailingliste (12.12.2015) [swift-evolution] Proposal: Universal dynamic dispatch for method calls

Wenn Microsoft ihr Windows erst mal in Swift programmiert hat, wird alles richtig cool!

ich finde auch das er recht hat! so schlecht wie die aktuelle software läuft (damit mein ich alle also iOS tvOS MacOS inkl der stabiliät der apps unter macOS und der benutzerführung) war apple. ich will sagen das sie schon immer mal hier und dort mal paar kleinigkeiten hatten die man bemängeln konnte. meist war das aber der funktionumfang. jetzt aber hat man ständig irgendwo probleme, auf ganzer breite. allein wie sich die musik app unter iOS entwickelt hat...schlechtlich

Weiss nicht, was ihr für Probleme habt. Bis auf iTunes, dessen Bedienung etwas zu gewöhnungsbedürftig und unklar ist, bin ich mit Apples Programmen/Apps und Betriebssystemen sehr zufrieden.

Wäre wünschenswert, wenn man Kritik mit ganz konkreten Mängeln belegen würde. Ansonsten gibts nur Polemik – und erst noch off topic.

2028 vielleicht.

Das spricht ehrlich gesagt nicht gerade für die Entwickler. Ich meine, die Sprache ist wirklich sehr selten der limitierende Faktor. Man kann in fast jeder modernen Programmiersprache sowohl sehr guten, als auch sehr schlechten Code schreiben. Mag sein, dass es manche Sprachen leichter machen guten Code zu schreiben, da sie bestimmte Konstrukte erst gar nicht zulassen oder aber bestimmte Konstrukte sich besonders einfach oder kompakt in dieser Sprache umsetzen lassen, aber wer so einen Sprach zwingend braucht, nur damit er guten Code schreibt, dem mangelt es einfach nur an Disziplin und wie gesagt, Disziplinlosigkeit spricht eben nicht gerade für die Entwickler.

Bei Fragen zur Architektur und dem Design, spielt die Sprache sogar meistens eine komplett untergeordnete Rolle, da man hier das ganze von vorne bis hinten planen kann (Ablaufdiagramme, Klassendiagramme, Datendiagramme) bevor man sich überhaupt entscheidet welche Sprache man jetzt für die Umsetzung nimmt. Hier ist es manchmal sogar so, dass sich die Wahl der Sprache am Plan orientiert (also je nachdem wie es geplant ist, nimmt man lieber die eine oder die andere Sprache), da es viel wichtiger ist, dass der Plan bestmöglich umgesetzt wird als dass der Code am Ende in einer ganz konkreten Sprache vorliegt.

Swift ist vom Grundkonzept wie das uneheliche Kind von C und Java. Es bietet funktionsorientierte Programmierung ähnlich wie in C (Funktionen, Structures) und es bietet OO Programmierung wie in Java (Klassen, Interfaces). Darüber hinaus hat es sich ein paar Features von anderen Sprachen abgeschaut (Tuples, Switches mit komplexen Datentype, Properties, Extensions) und bietet auch Features aus modernen Java sind vorhanden (Generics, Closures, Enums als Objekte). Man hat also nicht an Features gespart.

Speichermanagement ist Reference Counting (wie in Perl, PHP oder Python), ist meistens schneller als Garbage Collection und führt zu Apps mit weniger Speicherverbrauch, ist dennoch viel einfacher als manuelles Management wie in C/C++; allerdings nicht ganz Sorgenfrei, anders als bei GC muss man aufpassen, keinen "Zirkelbezug" (so heißt das wirklich in deutsch!) zu erzeugen, also ganz planlos kann man nicht vorgehen, so wie in Java, wo man fast nichts falsch machen kann.

Was die Sprache relativ sicher macht ist, dass sie forciert fast überall Konstanten zu verwenden (was sich kaum im Speicherverbrauch oder Performance bemerkbar macht, da moderne Compiler alle dadurch entstehenden Nachteile problemlos weg optimieren), sie extrem Wert auf Typensicherheit legt (deutlich mehr als fast alle anderen Sprachen), dass Objekttyp und Objekttyp-oder-nil unterschiedliche Typen sind (und man explizit zwischen denen casten muss), sogar Integerüberläufe standardmäßig Laufzeitfehler produzieren (wenn man dem Compiler nicht explizit sagt, dass eine Rechenoperation überlaufen darf), dass man gezwungen ist kritische Fehlerfälle abzufangen (ob man will oder nicht, baut sonst nicht) und dass das was in den meisten Sprachen nur einen Warnung ist (die Programmierer gerne ignorieren, baut ja trotzdem) in Swift harte Fehler sind.

Gut, jetzt kann man sagen: Gibt doch auch andere Sprachen, die alles das bieten. Bestimmt gibt es die. Aber wie viele von denen haben standardmäßig einen echten Compiler, der echten Maschinencode (also direkt CPU Instruktionen) produziert, so dass man am Ende ein echtes Binary hat, das ohne einen Laufzeitumgebung wie die JVM und ohne Interpreter oder JIT Compiler direkt auf einem System lauffähig ist? Und der Code, den der Swift Compiler erzeugt steht jetzt C Code in Geschwindigkeit wirklich in nichts nach (Objekte mal außen vor, weil die gibt es ja in C nicht; kann sein das C++ hier schneller ist, weil die Sprache weniger dynamisch ist und weniger zur Laufzeit macht; was aber manchmal auch ein Nachteil ist).

Eventus

Nun ja, ich bin bei Apple hängen geblieben, weil die Sachen einfach funktioniert haben. Seit einiger Zeit funktioniert vieles einfach nicht. AirDrop ist da ein gutes (oder eher trauriges) Beuspiel.

+1

Danke an Mecki für die ausführliche Erläuterung.

Was mich als kompletten Programmier-Laien interessieren würde: kann man mit Swift programmieren lernen? Wie fängt man an? Oder sagt ihr gleich: Viel Spaß, vergiss es?

Tatsächlich funktioniert AirDrop gar nicht so schlecht wie sein Ruf. Was viele nur nicht wissen ist, dass es so was wie AirDrop 1.0 und AirDrop 2.0 gibt. Alle iOS Geräte können nur AirDrop 2.0, was nur mit anderen iOS Geräten oder neueren Macs funktioniert. iOS Geräte sind nicht zu AirDrop 1.0 kompatibel! Ältere Macs können leider nur AirDrop 1.0, was nur mit anderen AirDrop 1.0 Macs gut funktioniert. Neuere Macs beherrschen neben AirDrop 2.0 tatsächlich auch noch AirDrop 1.0, was aber nur aktiv ist, wenn man dort AirDrop für alle Nutzer freigibt (also jeder dich sehen darf); gibt man es nur für Kontakte frei (ist bei AirDrop 2.0 am Mac glaube ich Standard), dann geht das gar nicht, denn dieses Feature kannte 1.0 noch überhaupt nicht.

In 90% der Fälle, wo jemand schimpft, dass sein Mac nie sein iPhone bei AirDrop sieht, oder umgekehrt, und er somit nie Dateien zwischen den beiden austauschen kann und AirDrop ja so ein Dreck ist, hat er einen AirDrop 1.0 Mac und das kann gar nicht funktionieren und wird es auch nie. Denn AirDrop braucht spezielle Hardware. Bei AirDrop müssen beide Geräte eben nicht im selben WLAN sein, das ist ja der Witz an der Sache, sondern beide können mit unterschiedlichen WLANs verbunden sein (oder gar nicht mit einem WLAN verbunden sein), sogar gerade über diese WLANs Daten empfangen/senden und dennoch parallel Daten per AirDrop senden/empfangen. AirDrop geht über einen Side Channel moderner WLAN Chips (und die müssen für AirDrop 2.0 bestimmte Fähigkeiten haben, die eben ältere WLAN Chips in Macs nicht hatten).

Außerdem beschweren sich viele bei AirDrop mit iOS Geräten über die geringe Reichweite, aber das ist kein Bug, das ist ein Feature. Apple beschränkt die Reichweite hier absichtlich. Wenn du am Flughafen AirDrop anmachst, dann sollen nicht alle Menschen im Umkreis von 200 Metern sehen bzw. du Plötzlich 50 Leute im Teilen Dialog. Du sollst auch ohne Kontaktbeschränkung nur die Leute in deiner direkten Umgebung sehen und nur diese Leute auch dich. Deswegen reicht es eben nicht, dass dein iPhone und dein Mac im selben WLAN sind (das müssen sie für AirDrop sowieso nicht), sondern sie müssen auch (physikalisch) in der Nähe zueinander sein. Um die Entfernung zu kontrollieren verwenden die Geräte Bluetooth (falls mal jemand sich gefragt hat, wozu man das einschalten muss... die Daten werden nicht per BT übertragen). AirDrop 1.0 braucht und nutzt überhaupt kein BT, schon alleine daran sieht man, dass das ein ganz anderes Protokoll war.

Apple hätte hier wirklich einfach den Namen ändern sollen oder so. Dass mein Mac nur AirDrop 1.0 kann, das habe ich auch erst heraus gefunden, nachdem ich schon mehrfach geflucht habe, dass mein Mac nie mein iPhone sieht und umgekehrt. Aber zwischen zwei iPhones in direkter Nachbarschaft schicke ich häufig per AirDrop Bilder hin und her - kostet kein Datenvolumen, meine Bilder werden nicht zweimal um die Welt gesendet und schlägt selbst eine gute LTE Verbindung in Geschwindigkeit um Längen.

Warum?

Mecki

Ich habe AirDrop damals, als es neu war ein paarmal ausprobiert und es hat, wenn überhaupt, nur schlecht funktioniert.

Habe es neulich mal wieder mit zwei Macs probiert und es war noch immer traurig.

Von iOS brauche ich da noch garnicht anfangen.

Airdrop hat bei mir seit 10.10.0 nie funktioniert, auf zwei von drei supporteten Macs, dann hat es mehr als ein Jahr gedauer bis 10.11.1 bis es endlich auf allen 3 funktionierte!

Zuerst mal holst du dir das kostenlose Swift Buch von Apple Ist zwar jetzt kein Must-Have für Programmierer an sich, sprich: "Um generell programmieren zu lernen, würde ich definitiv ein anderes Buch empfehlen", aber um den Syntax und die Sprachkonzepte von Swift zu erlernen ist es ganz brauchbar. Ich hab da bei anderen Programmiersprachen auch schon deutlich schlechtere Bücher gesehen. Ist halt auf Englisch. Wenn das ein Problem ist, dann müsste ich erst mal schauen, was es so an deutschen Büchern gibt.

Dann holst du dir Xcode , ist ja kostenlos, und dort startest du mit einem Playground. Playground sind Spielplätze, wo du dich austoben kannst. Du hast einfache eine Datei vor dir und schreibst dort direkt irgendwelchen Swift Code und sieht sofort was er tut. Du kannst ihn sogar live umbauen, also während das Programm läuft und siehst sofort was dann passiert oder wie dass sich auf das Programm auswirkt. Hier ein paar Beispiele: Tob' dich aus und spiel einfach mal mit der Sprache bzw. der API rum.

version 2 ist weder rückwärtskompatibel noch aufwertskompatibel.
alter code funktioniert also nicht mit neuem compiler und umgekehrt.
und das gleiche kommt auch wieder mit version 3. Man muss code also wieder manuell ändern sodass er überhaupt kompiliert werden kann. der code lässt sich dann natürlich mit dem alten compiler (zb auf einem anderen system zum debuggen) nicht mehr compilieren.
Auch kann man es nicht mit C++ mischen was mir sehr wichtig ist weil große teile einiger meiner projekte platformunabhängig in cpp sind.
Auch wurden features eingebaut die sie jetzt plötzlich (ohne wirklichen grund) wieder entfernen wollen (zb die ++ un -- operatoren und for-schleifen...)
die sprache soll erstmal ausreifen und stabil werden, dann reden wir weiter!

Das macht die Sprache nicht schlecht. Das nur eine persönliche Referenz.

Mecki

Danke für die hilfreiche Antwort!

Herr im Himmel...ich weiß gar nicht, wo ich anfangen soll. Ich hoffe, dass du Programmierung nur hobbymäßig machst.

Was ist denn falsch daran, was gritsch sagt?

Das Swift sich noch ein bisschen entwickeln muss stimmt und das unnötige entfernen von -- und ++ versteh auch wer will.

Willst du jetzt etwa sagen, dass man auf sowas als professioneller Softwareentwickler (was gritsch im übrigen ist) mit sowas umgehen muss?

Das stimmt... finde ich aber persönlich nicht weiter schlimm. Mit aller Gewalt zu alten Source Code kompatibel zu bleiben hindert nur sinnvolle und manchmal sogar notwendige Entwicklungen der Sprache, der Compiler und auch des Codes. Was habe ich denn davon, dass ein moderner C Compiler noch Source Code aus den 70ern bauen kann? Computer sehen heute ganz anders aus als in den 70ern und Code der damals optimal war, ist es heute bei weiten nicht mehr (z.B. weil CPUs fast alle mehrer Cores haben, weil sie mindestens 32, wenn nicht 64 Bit sind, weil CPUs viel mehr Register haben und daher auch viel mehr Variablen direkt in Registern gehalten werden können, weil RAM heute massig vorhanden ist, weil Stacks auch viel größer sind und viel mehr Rekursionen zulassen, weil SSDs heute ganz andere Zugriffscharakteristiken haben als Disketten oder Bandlaufwerke, usw.) Und in dem Moment wo es heißt: "Wir können Feature XYZ nicht einbauen, das bricht Kompatibilität mit Ansi-C" und XYZ aber ein wirklich wichtiges und sinnvolles Feature ist, in dem Moment ist Kompatibilität nur noch ein Hemmschuh.

Die Unterschiede von Swift 1 zu Swift 2 sind nicht groß bezogen auf die Sprache selber. Ich meine, da hat sich schon was getan, aber das meiste sind neue Features und neue Features brechen keinen bestehenden Code. Die meisten Änderungen haben gar nichts direkt mit der Sprache zu tun, sondern betreffen die Standard API (nicht API mit Sprache verwechseln!), die sich eben aufgrund von neuer Sprachfeatures geändert hat und jetzt viel verständlicher, aufgeräumter und sauberer aussieht. Und einen Großteil der nötigen Änderungen kann Xcode sogar automatisiert durchführen Zugegeben, ist die Migration nicht perfekt, aber doch erstaunlich gut für ein automatisches Tool.

Apple hat ja von Anfang an gesagt, dass Swift noch nicht fertig und nicht final ist. Der Grund warum man Swift so früh veröffentlicht hat war ja, dass man Rückmeldung von Entwicklern wollte. Und das geht aber nur, wenn Entwickler die Sprache wirklich, und damit meine ich auch produktiv, einsetzen. Profis sind sowieso bei Obj-C geblieben für kommerzielle Entwicklungen. Nach aktuellen Plänen wird Swift 3 dann die "fertige Swift Sprache" sein (bis auf weiteres). Wer also mit der finalen Version arbeiten will, der muss sich gedulden und auf Swift 3 warten. Mit Swift 3 soll dann auch die API stabil werden und gebauter Code "binär-kompatibel" sein und bleiben. Und ja, Swift 3 wird ein paar Syntaxänderungen haben, aber sogar noch viel weniger als von 1 auf 2 und auch hier ist für jedes Features bereits jetzt ein Migrationsplan vorhanden für eine automatische Migration.
Doch, kann man schon, man muss es nur so wie bei Java machen und ein C Interface dazwischen schalten. Was bei Code der nach deiner Aussage "platformunabhängig" ist, aber kein echtes Problem sein dürfte. Du könntest auch Obj-C++ probieren, weil der Obj-C Teil wäre auch direkt von Swift nutzbar. Ansonsten kann ich C++ auch mit diversen anderen Sprachen nicht mischen. C++ ist IMHO eine Krankheit, ich kann dieser Sprache nichts Gutes abgewinnen und jetzt wo Swift OpenSource ist, gibt es hoffentlich bald Compiler für jede Plattform (unter Windows hat ja C# auch C++ schon lange den Rang abgelaufen). C mag altmodisch, primitiv und limitiert sein, aber es hat definitiv seine Daseinsberechtigung, C++ eigentlich nicht mehr - d.h. sofern es jemals wirklich eine hatte: C++ nimmt all die Fehler und Schwächen von C und portiert sie in eine unnötig komplexe OO Welt, der es dann auch neu neue Fehler und Schwächen hinzufügt. Zitat von Alan Kay: "Actually I made up the term object-oriented, and I can tell you I did not have C++ in mind."

Keine Ahnung was du damit for-Schleifen meinst. Die existieren in Swift 2 und sie werden auch in Swift 3 existieren. Und nichts wird ohne wirklichen Grund entfernt. Würdest du die Pläne zu Swift 3 lesen, dann würdest du auch eine sehr detaillierte Begründung finden, warum man ++/-- entfernen will. Zusammengefasst kann man sagen, dass der Grund der ist, dass zum einen someVar++ nicht wirklich kürzer ist als someVar+=1 was ja genau das Gleiche macht (nur man halt auch leicht um 2, 5 oder 14 erhöhen kann) und zum anderen dass in einem Ausdruck wo das Ergebnis direkt verwendet wird, ++someVar zu einem wesentlich anderen Ergebnis führt als someVar++. Fundamental unterschiedliche Verhaltensweisen sollten aber in Code auch fundamental unterschiedlich aussehen und dass sieht hier verdammt ähnlich aus und jemand der nicht aus der C/Java Welt kommt und dessen Sprache so ein Konstrukt nicht kennt oder ein kompletter Neuling kann hier leicht darauf reinfallen und die falsche Variante wählen. Hier ist die vollständige Begründung

Ein wesentlicher Designaspekt von Swift war es Programmierfehler durch den Sprachsyntax von vornherein auszuschließen so gut wie es geht. Es gibt einige Sprachen, die keinen ++ Syntax kennen und das ist weiß Gott kein großes Problem in der Praxis (außer vielleicht für C++ Programmiere, die diesen Syntax wirklich überstrapazieren und das fast immer mit vorangestellten ++/--).

Er meint, dass es ein bereits akzeptiertes "Proposal" für Swift 3 gibt, auch die C-Variante der for-Schleifen also
for(...init... ; .... condition ... ; ... increment ...)
zu entfernen. Schließlich hat Swift "for each" und "for in" und die C-Variante ist auch nur eine "Altlast" .
Ich finde das nur konsequent unter den bereits von Dir aufgeführten Design-Zielen.

Im Grunde ist Swift wie Typescript. Nur das Tyescript nach Javascript compiliert und nur als Zwischenlösung gedacht ist. Swift jedenfalls hat sehr vieles von JavaScript in sich vereint und folgt damit dem Trend Richtung JavaScript. Als JavaScript Entwickler wird man sich sofort heimisch fühlen.