Der X. Thread zur Zukunft von Swift

t-no · 11. November 2014, 10:31

Marco Feltmann schrieb:

Wer freiwillig in Java/C#/C++/PHP/Ruby/Python programmiert hat von schönen Sprachen ja auch anwendungsbedingt mangels Vorbildern absolut keine Ahnung.

Marco Feltmann schrieb:

Ja, es ist mein voller Ernst, dass ich Java/C++/C#/PHP absolut hässlich finde.

Zusammengefasst also: "Wer nicht meiner Meinung ist, hat absolut keine Ahnung"

Marco Feltmann schrieb:

Dein Anspruch, so scheint mir, ist die 'Bau die App in meinem Kopf für alle Plattformen' Knopf

Falsch. Ich sage, dass viele Leute möglichst niedrige Grenzen zwischen den Plattformen haben wollen - und dass mir lieber ist, wenn meine Plattform diese Grenzen einreisst.

t-no schrieb:

Schlichtweg falsch - falls es irgendwann mal ein Tool gibt, mit dem man aus einer beliebigen iOS-App ein halbwegs brauchbares Android-Gegenstück generieren kann, würde sich das verkaufen wie geschnitten Brot

Marco Feltmann schrieb:

Apple hat sein eigenes SDK vernünftig in Swift integriert bekommen?

Bewusst falsch zitiert (ich beziehe mich klar auf den Wunsch nach Plattformunabhängigkeit - und das der stark ist, hast du ja lang und breit bestätigt).
Ansonsten: Lässt sich nicht objektiv beantworten, aber ich arbeite schon jetzt lieber mit Swift als mit Objective-C.

Marco Feltmann · 11. November 2014, 12:00

t-no schrieb:

Marco Feltmann schrieb:

Wer freiwillig in Java/C#/C++/PHP/Ruby/Python programmiert hat von schönen Sprachen ja auch anwendungsbedingt mangels Vorbildern absolut keine Ahnung.

Marco Feltmann schrieb:

Ja, es ist mein voller Ernst, dass ich Java/C++/C#/PHP absolut hässlich finde.

Zusammengefasst also: "Wer nicht meiner Meinung ist, hat absolut keine Ahnung"

Interessante Zusammenfassung. Zumal man sie ganz genau so auf die von Dir angesprochenen Java/Ruby/C#/Python...–Programmierer passt.
Oder übersehe ich irgend eine fundierte rein objektive Tatsache abseits von 'Meiner Meinung nach ist Java/Ruby/C#/Python… schön und deshalb muss Objective-C hässlich sein'?

Übrigens wäre eine fundierte objektive Tatsache abseits meiner Meinung, dass Objective-C an Smalltalk angelehnt ist und Smalltalk eine der optisch schönsten Programmiersprache überhaupt ist, da sie der englischen Schriftsprache sehr ähnelt.
Ergo ist Objective-C eine optisch sehr schöne Sprache, da sie der (englischen) Schriftsprache sehr ähnelt und daher leichter zu lesen und zu verstehen ist.

Wer so in seiner bekloppten Punkt- und Klammernotation festgefahren ist, dass er die optische Schönheit der Schriftsprache nicht erkennt, dem ist einfach nicht mehr zu helfen.
(Oder wie erklären sich die Java/Ruby/C#/Python…–Programmierer die Existenz von YAML, Cucumber und ähnlichen an der menschlichen Schriftsprache orientierten Projekten sowie dem Vorstoß der DSL im Allgemeinen?)

t-no schrieb:

Marco Feltmann schrieb:

Dein Anspruch, so scheint mir, ist die 'Bau die App in meinem Kopf für alle Plattformen' Knopf

Falsch. Ich sage, dass viele Leute möglichst niedrige Grenzen zwischen den Plattformen haben wollen - und dass mir lieber ist, wenn meine Plattform diese Grenzen einreisst.

Na dann hophop frisch ans Werk. Bei Apple beworben, Deinen ultimativen Masterplan vorgestellt und in die Tat umgesetzt. Ich bin gespannt.
Oder, weniger sarkastisch und mehr offen ausgedrückt: Meiner Meinung nach nimmst Du Dich und Deine Plattform viel zu wichtig.

Apple ist austauschbar. Android ist austauschbar. Blackberry ist austauschbar. Windows ist austauschbar.
Sobald eine Plattform seine Grenzen dahingehend öffnet, der Austauschbarkeit Vorschub zu leisten, kann das irgendwann durchaus das Ende dieser Plattform sein.
Wenn man in Swift toll für Android programmieren kann, warum dann noch die ~80€ jährlich für den Developer Account bei Apple zahlen und sich dem Reviewstress aussetzen? Drauf geschissen und nur noch für Android in Swift programmiert.
Wenn man in Java toll für iOS programmieren kann, warum dann noch für Android entwickeln? Der Store ist seltsam, die Anwender haben eine Nehmermentalität und die Fragmentierung nervt nur. Dann doch lieber das halbswegs homogene iOS Umfeld ohne neue Programmiersprache.
Wenn man in Objective-C so gut für Android programmieren kann, warum dann noch dieses grauenhafte iOS Gelöt benutzen?
(Glaub mir, sobald Programmierer nicht mehr an der Sprache rumnörgeln, dann an den Konzepten der Plattform.)

t-no schrieb:

t-no schrieb:

Schlichtweg falsch - falls es irgendwann mal ein Tool gibt, mit dem man aus einer beliebigen iOS-App ein halbwegs brauchbares Android-Gegenstück generieren kann, würde sich das verkaufen wie geschnitten Brot

Marco Feltmann schrieb:

Apple hat sein eigenes SDK vernünftig in Swift integriert bekommen?

Bewusst falsch zitiert (ich beziehe mich klar auf den Wunsch nach Plattformunabhängigkeit - und das der stark ist, hast du ja lang und breit bestätigt).

Eigentlich habe ich lang und breit ausgeführt, warum der Wunsch Schwachsinn ist und diese Tatsache dem Auftraggeber so vermittelt werden muss.
Nehmen wir ein paar plattformunabhängige Projekte – Blender, Gimp, Komodo IDE. Sieht auf allen Plattformen gleich beschissen aus und funktioniert auf keiner Plattform wie eine native Anwendung.
Auftraggeber, die so etwas wollen, wurden schlichtweg falsch beraten. Anwender wollen so etwas im Allgemeinen* nicht.

*) Klar. Java/Ruby/C#/Python...–Programmierer, die es nicht einsehen, sich auf Windows, Ubuntu und Mac OS X jeweils mit anderen Bedienkonzepten herumschlagen zu müssen. Der durchschnittliche Anwender kennt und nutzt nur ein Betriebssystem. Und der will, dass gefälligst alles so läuft wie er es kennt. Weiterhin ist es ihm scheißegal was sich der Auftraggeber der App dabei gedacht hat.

FWerewolf · 11. November 2014, 13:33

Naja ich als Anfänger in OS X und iOS Programmierung kann da was zur Diskussion beitragen

Warum ist Swift beliebt und es gibt einen Hype ? Ganz einfach, weil man es auf Anhieb lesen kann. Schau dir eine ObjC Klasse und eine Swift Klasse an. Der Anfänger sieht die ObjC Klasse und denkt wtf ? Massenweise [] und {} und mal ein - am Anfang der Methode, mal ein +. Da bekommt man wenig Lust, sich das anzutun. Auch wenn man wie ich massenweise Erfahrung im Programmieren hat. Sieht man dann die Swift Klasse, denkt man Jahhhh es wird lesbar

Das ist die "klassische" Notation, wie man sie aus vielen anderen Programmiersprachen kennt. Man denkt: hmm, Apple hat sich was dabei gedacht, wenn sie eine neue Sprache gebastelt haben. Das wird die Zukunft. Dazu ist es "intuitiver", also lernt man gleich Swift. .... und dann kommt das böse Erwachen *muahaha*
Man schreibt in Xcode und die IDE kackt ab. Der Quellcode, der vorher schön bunt formatiert war, ist nur noch einfarbig und beim Tippen kommt keine automatische Ergänzung mehr. Also Speichern, Xcode neu starten. Macht man keinen Restart, ist Xcode irgendwann so, dass man 1 oder 2 Buchstaben tippt und es kackt ab. Das nervt einfach nur auf Dauer. Dazu kommt das ewige Rumgecaste.
Man schreibt ein längere Zeile und der Compiler motzt. .. ah, da fehlt ein ?. Ok, eingebaut und .... nochmal motzen ... ah da fehlt noch ein ? und .... noch mal gemotzt ... oh da fehlt ein ! .... und nochmal gemotzt ... hä ? das eben eingebaute ! ist auf einmal zuviel und muss weg ? wtf ... ah da fehlt ein ? beim Typ der Variable .... Wahhh ich kotze gleich, jetzt muss das eingefügte und wieder gelöschte ! natürlich wieder hin. Das kostet einfach irre Zeit und Nerven. Klar passiert das nur jemanden, der noch wenig Erfahrung mit Swift hat, aber genau das ist das, was am Anfang nervt. Man wird frustriert und überlegt, alles hinzuschmeissen.

Dazu googlet man sich dauernd den Wolf

, wie die Funktion, die in ObjC so und so benutzt wird, denn jetzt in Swift benutzt wird oder wie man das in Swift macht, was es da schlichtweg nicht mehr gibt, in ObjC aber trivial ist usw. usw.
Sucht man guten Einstieg in die OS X und iOS Programmierung, fällt man sehr schnell auf die Vorlesung "Developing iOS7 Apps for iPhone and iPad" von der Stanford University, die meiner Meinung nach genial ist. Damit lernt man es von klein auf richtig gut ... ja ... ObjC

Für Swift sitzt man dann wieder da und baut das um.

Lange Rede kurzer Sinn: Swift liegt bei mir wieder in der Kühltruhe und ich lern gleich ObjC. Wenn alle guten Tutorials eh in ObjC sind, kann ich das auch gleich lernen.
FALLS Apple ObjC mal in die Tonne treten wird ( was ich nicht glaube ), werden die das nicht von heute auf morgen machen. Dann kann ich immer noch Swift lernen - dann hoffentlich mit viel Infos aus dem Netz und einer IDE, die nicht dauernd abkackt und gleich dem Wissen, wie die Frameworks alle gehen. Wahrscheinlich dann gleich Swift 2.0

t-no · 11. November 2014, 13:58

Müßige "Diskussion"...

Marco Feltmann schrieb:

Nehmen wir ein paar plattformunabhängige Projekte – Blender, Gimp, Komodo IDE. Sieht auf allen Plattformen gleich beschissen aus und funktioniert auf keiner Plattform wie eine native Anwendung.

Stimmt genau - merkst du, dass das ein spitzenmäßiges Argument dafür ist, Cocoa auf anderen Plattformen auszurollen?

Marco Feltmann schrieb:

Na dann hophop frisch ans Werk. Bei Apple beworben, Deinen ultimativen Masterplan vorgestellt und in die Tat umgesetzt. Ich bin gespannt.

Was für ein Unsinn: Wie wäre es, wenn du dich bei Apple vorstellst, denen klar darlegst, warum Swift (und so ziemlich alle Programmiersprachen, die es gibt... wie stehst du eigentlich zu Lisp?) ein fataler Irrweg war, und man schleunigst alles auf AppleScript umstellen muss (das ist nämlich der englischen Schriftsprache noch ein gutes Stück näher - und das ist ja angeblich schön).
Ich wünsch' mir übrigens auch den Weltfrieden - muss ich dafür jetzt auch einen Masterplan haben und zur UNO gehen?

Marco Feltmann schrieb:

Oder, weniger sarkastisch und mehr offen ausgedrückt: Meiner Meinung nach nimmst Du Dich und Deine Plattform viel zu wichtig.

Also "meine" Plattform ist momentan Cocoa - was ist denn deine? Und was soll überhaupt "viel zu wichtig nehmen" bedeuten? Stört es dich denn auch, wenn du dich im Ausland auf Englisch unterhalten kannst?

Marco Feltmann schrieb:

Oder übersehe ich irgend eine fundierte rein objektive Tatsache abseits von 'Meiner Meinung nach ist Java/Ruby/C#/Python… schön und deshalb muss Objective-C hässlich sein'?

Mit "schön" hasst du angefangen... und wie kommst du überhaupt darauf, dass mir beispielsweise Python gefällt? Muss man jetzt Objective-C hassen, weil man andere Sprachen nicht verteufelt?

Marco Feltmann schrieb:

Interessante Zusammenfassung. Zumal man sie ganz genau so auf die von Dir angesprochenen Java/Ruby/C#/Python...–Programmierer passt.

Aha... diese fiesen Java/Ruby/C#/Python...–Programmierer: Haben nicht nur absolut keine Ahnung, sondern verachten auch diejenigen, die die einzige Wahrheit kennen - was für Ignoranten. Wie sieht's denn mit anderen Gruppen aus?
Forth -> Volltrottel?
Scala -> Fachidiot?
C++ -> Massenmörder?
Damit könnte man aus der Psychologie endlich eine richtige Wissenschaft machen!

Marco Feltmann · 11. November 2014, 14:03

FWerewolf schrieb:

Ganz einfach, weil man es auf Anhieb lesen kann.

Naja, man kann es auf Anhieb lesen, wenn man es gewohnt ist.

Wissen John und Jane Doe auf Anhieb, was mit printer.printMultiplication(15, 23); gemeint ist?
Oder wäre printer printResultOf:15 multipliedWith:23 sprechender?
Ja, die geschweiften Klammern sind auf den ersten Blick ungewöhnlich.

In Smalltalk fehlen sie ganz und sind ein unerschöpflicher Quell purer Freude.
printer print: calculator resultOf: gameBoard rows multipliedWith: gameBoard columns

Gibt mitunter ein heilloses Durcheinander, weil von rechts nach links aufgelöst wird und rows nicht definiert ist beziehungsweise sicherlich keine Methode multipliedWith kennt.
Hier muss man in Smalltalk also klammern:
printer print:( calculator resultOf: ( gameBoard rows ) multipliedWith: ( gameBoard columns ) )

Also hat Apple sich folgerichtig gedacht: das versteht der durchschnittliche Entwickler doch nie. Zwingen wir ihn, das Ganze in Klammern zu setzen – und nehmen dafür eckige Klammern, die sind ja zur Definition von Scopes noch frei.

[printer print:[ calculator resultOf: [gameBoard rows] multipliedWith: [gameBoard columns] ] ];
Sind jetzt nur zwei Klammern mehr als im Smalltalk Beispiel.

Zum Vergleich:
printer.print( caculator.multiply( gameBoard.getRows(), gameBoard.getColumns() );

Mal davon ausgehen, Du hast absolut keine Vorbelastung mit Programmiersprachen: was liest sich eher nach einem verständlichen Text?

Um die Objective-C Notation zu verstehen, muss man wissen, woher sie rührt – und den ganzen anderen Scheiß, den C++, Java und Konsorten in die Welt geschleppt haben, mal kurz vergessen.

FWerewolf · 11. November 2014, 14:29

Ja ja. Ich bin da ganz deiner Meinung. Aber stell dir jemand vor, der keine Ahnung davon hat, woher das kommt und wieso die Syntax in ObjC so ist.
Der wird bei

Quellcode

printer.printMultiplication(15, 23);

eher was verstehen, als bei

Quellcode

[printer print:[ calculator resultOf: [gameBoard rows] multipliedWith: [gameBoard columns] ] ];

Hat man sich mal damit auseinander gesetzt, ist auch der ObjC Code klar, einfach und verständlich.

Es geht aber um den Erstkontakt mit der Sprache. Ich fang an, da was zu programmieren und schaue da erstmal ein bisschen Code an, um ein Gefühl zu kriegen. Der wird bei ObjC erstmal abgeschreckt. Er sieht Swift, denkt sich : cool, damit kann ich das gleiche wie mit ObjC machen. Warum sollte ich dann ObjC nehmen. Da nehme ich gleich Swift. Und genau darum springen so viele Neueinsteiger auf Swift an.

Ich habe interessanterweise die Erfahrung gemacht, dass es sich danach ins Umgekehrte wendet. Zumindest im aktuellen Status von Swift. ich kann sehr gut verstehen, dass Leute, die jahrelang in ObjC programmiert haben, jetzt kotzen, wenn sie Swift nehmen sollen und dagegen sind. Ich setze mich jetzt seit etwa einem Monat mit der Materie Programmieren für iOS und Mac OS auseinander und habe aus genau den genannten Gründen erstmal mit Swift angefangen. Dann bin ich über die Vorlesung von Stanford gestolpert und habe seither immer mehr das Erlebnis: Boah, ObjC ist klar und einfach und in Swift wird es komplizierter. Genau darum bin ich auf ObjC geschwenkt und programmiere ObjC statt Swift. Man muss sich halt mal durch ObjC "durchkämpfen".

nussratte · 11. November 2014, 14:32

wenn er in die Dokumentation guckt
bei vernünftig benannten Methoden in Objective-C brauch man das nicht, da ist klar wofür parameter 1 und wofür nummer 2 ist

das "bennenen" der Parameter hat mir den Einstieg in Objective-C deutlich leichter gemacht, als ich von Java gekommen bin

macmoonshine · 11. November 2014, 14:36

Marco Feltmann schrieb:

FWerewolf schrieb:

Warum ist Swift beliebt und es gibt einen Hype ? Ganz einfach, weil man es auf Anhieb lesen kann.

Naja, man kann es auf Anhieb lesen, wenn man es gewohnt ist.

Das sehe ich genauso.

Kommen dann noch die kurzen, ausdrucksschwachen Methodennamen hinzu, wie sie in der Java- / C++-Welt üblich sind, bekommt man schnell Schwierigkeiten, Methoden mit mehreren Parametern zu verstehen. Richtig lustig wird es mit überladenen Operatoren (und Methoden). Was bedeutet noch mal a & b oder x *=* y? Dank Type-Inference funktioniert ein CMD-Klick auf den Operator auch nicht mehr, um zu dessen Deklaration zu gelangen. Sehr schön ist auch die Array-Notation: Ursprünglich war die wie in anderen Programmiersprachen auch (z. B. Int[]) und wurde dann zu [Int]. Wahrscheinlich nur, damit die Tippfaulheit-Schreibweise für assoziative Arrays als [String:Int] passt.

FWerewolf · 11. November 2014, 14:39

Genau darum geht es aber. Wenn man es gewohnt ist

Hat man noch keinen Schimmer von einer Sprache, dann ist :

Quellcode

printer.printMultiplication(15, 23);

intuitiver. Es wird das Ergebnis der Multiplikation von 15 und 23 an den Drucker geschickt. Das versteht man, wenn man Programmiererfahrung hat und ein bisschen nachdenkt.

Sieht man :

Quellcode

[printer print:[ calculator resultOf: [gameBoard rows] multipliedWith: [gameBoard columns] ] ];

denkt man : wtf ?
Wenn man es gewohnt ist, ist es klar, dass da Nachrichten an Objekte geschickt werden. Dazu muss man sich aber mit ObjC auseinander setzen und wenn man das mit Swift macht, wird man sich am Anfang leichter tun. Wie gesagt, das kippt schnell um

macmoonshine · 11. November 2014, 14:44

FWerewolf schrieb:

Quellcode

[printer print:[ calculator resultOf: [gameBoard rows] multipliedWith: [gameBoard columns] ] ];

Kann man auch als

Quellcode

[printer print:[ calculator resultOf:gameBoard.rows multipliedWith:gameBoard.columns ] ];

schreiben. Solche verschachtelten Anweisungen sind aber in allen Sprachen unschön:

Quellcode

printer.print(calculator.resultOf(gameBoard.rows, multipliedWith: gameBoard.columns));

ist auch nicht besser.

Wenn Code unleserlich ist, sollte man ihn umformulieren, und das gilt für alle Programmiersprachen.

EDIT:

FWerewolf schrieb:

denkt man : wtf ?

Nein: Da denke ich, warum vergleichst du zwei vollkommen unterschiedliche Anweisungen.

Marco Feltmann · 11. November 2014, 14:57

t-no schrieb:

Müßige "Diskussion"...

In der Tat.

Es hier um die Frage Swift oder Objective-C in Bezug auf die Zukunft der App-Entwicklung unter iOS.
All das Gelaber über die Schönheit hier hat damit überhaupt nichts zu tun, insofern stelle ich es ein.

Swift hat in seinem aktuellen Zustand und in Verbindung mit den Frameworks aus produktiver Sicht nur Nachteile.
Sobald Apple das ändert (und AnyObject rausgeflogen ist

) werden die Karten neu verteilt.

Bis dahin kam man Swift so schön und Objective-C so grauenhaft finden, wie man will: unproduktiv ist nicht zukunftssicher.

FWerewolf · 11. November 2014, 15:34

Marco Feltmann schrieb:

Swift hat in seinem aktuellen Zustand und in Verbindung mit den Frameworks aus produktiver Sicht nur Nachteile.
Sobald Apple das ändert (und AnyObject rausgeflogen ist ) werden die Karten neu verteilt.

Da stimme ich dir zu. Ich habe nur versucht, aus der Sicht eines Neueinsteigers zu beschreiben, warum man da versucht ist, zu Swift zu greifen statt ObjC zu lernen.
Verführerisch und einfach scheint die dunkle Seite der Macht

macmoonshine · 11. November 2014, 15:46

FWerewolf schrieb:

Verführerisch und einfach scheint die dunkle Seite der Macht

Schnell du lernst, junger Padavan. Doch hüte dich vor der dunklen Seite, auch wenn sie mit Generics und Überladung lockt.

+scnr+

kmr · 11. November 2014, 19:17

t-no schrieb:

Schlichtweg falsch - falls es irgendwann mal ein Tool gibt, mit dem man aus einer beliebigen iOS-App ein halbwegs brauchbares Android-Gegenstück generieren kann, würde sich das verkaufen wie geschnitten Brot; selbst die existierende Werkzeuge, die mehr schlecht als recht arbeiten, haben schon gewissen Erfolg.

Da schließe ich mich Marco an. Aufgrund der mitunter komplett unterschiedlichen Bedienparadigmen von Android und iOS ist das Ergebnis entweder auf beiden Plattformen totaler Murks oder auf einer Plattform toll und auf der anderen für die Hose. Es fängt mit Kleinigkeiten an, wie der Wischgeste zum Löschen. Unter iOS vollkommen normal. Unter Android absolut unüblich. Bei iOS befindet sich eine Tabbar am unteren Display-Rand. Bei Android oben. Unten würde man nämlich ständig draufpatschen, wenn man den Back-, Home- oder Menü-Button drückt, die im Gegensatz iPhone keine Hardware-Buttons sind. Unter Android musst Du dem Back-Button eine besondere Bedeutung beim Aufbau der App-Navigation schenken. Bei iOS gibt es diesen Button überhaupt nicht. Die Liste lässt sich beliebig fortführen. Es ist wie immer, wenn irgend etwas verspricht, eine Lösung für alles zu sein: im besten Fall hast Du den kleinsten gemeinsamen Nenner. Im schlechtesten Fall hast Du einen Haufen Müll, den kein Mensch bedienen will. Ein guter Dienstleister macht seinem Kunden das klar. Ein schlechter Dienstleister programmiert stumpft die Anforderungen vom Kunden runter.

zerm · 11. November 2014, 20:02

Marco Feltmann schrieb:

Wer so in seiner bekloppten Punkt- und Klammernotation festgefahren ist, dass er die optische Schönheit der Schriftsprache nicht erkennt, dem ist einfach nicht mehr zu helfen.

Ich bevorzuge es.
Wobei ich ja (halb-)funktionale Sprachen noch am liebsten habe, was dir ja sicherlich vollkommen abstrus vorkommen muss

Marco Feltmann schrieb:

Nehmen wir ein paar plattformunabhängige Projekte – Blender, Gimp, Komodo IDE. Sieht auf allen Plattformen gleich beschissen aus und funktioniert auf keiner Plattform wie eine native Anwendung.
Auftraggeber, die so etwas wollen, wurden schlichtweg falsch beraten. Anwender wollen so etwas im Allgemeinen* nicht.

Photoshop, Nuke, Houdini, .. finde ich eigentlich nicht "beschissen". Schau halt nicht auf das OpenSource gefrickel

Marco Feltmann · 12. November 2014, 10:26

zerm schrieb:

Marco Feltmann schrieb:

Wer so in seiner bekloppten Punkt- und Klammernotation festgefahren ist, dass er die optische Schönheit der Schriftsprache nicht erkennt, dem ist einfach nicht mehr zu helfen.

Ich bevorzuge es.

Du bedarfst ja auch im Allgemeinen keiner Hilfe und würdest sie so oder so nicht annehmen.

zerm schrieb:

Wobei ich ja (halb-)funktionale Sprachen noch am liebsten habe, was dir ja sicherlich vollkommen abstrus vorkommen muss

Hatte mal versucht für Blackberry 10 zu entwickeln. Mit deren komischen Eclipse-Abklatsch 'Momentics' und ihrer C++/QML Verknüpfung
war ich echt überfordert. Noch schlimmer als Androids Java/XML Geraffel.
Insofern: ja, tust Du. Mach Dir nix draus, mein Bekanntenkreis besteht fast ausschließlich aus abstrusen Menschen. Und so ganz 'straight forward' bin ich ja nun auch nicht gerade.

zerm schrieb:

Marco Feltmann schrieb:

Nehmen wir ein paar plattformunabhängige Projekte – Blender, Gimp, Komodo IDE. Sieht auf allen Plattformen gleich beschissen aus und funktioniert auf keiner Plattform wie eine native Anwendung.
Auftraggeber, die so etwas wollen, wurden schlichtweg falsch beraten. Anwender wollen so etwas im Allgemeinen* nicht.

Photoshop, Nuke, Houdini, .. finde ich eigentlich nicht "beschissen". Schau halt nicht auf das OpenSource gefrickel

Woher weißt Du, dass die alle dieselbe Codebase haben, also nur ein einziges mal geschrieben wurden, und nicht für jedes OS spezifische Anpassungen implementieren?
Das OpenSource Gefrickel hat halt den Vorteil, dass man sehen kann, dass es nur eine Codebasis ist.

Amin Negm-Awad · 12. November 2014, 12:05

t-no schrieb:

Meine Einschätzung ist, dass Swift sich sehr schnell durchsetzen wird - nicht nur, weil Apple sehr entschlossen an die Sache rangeht, sondern auch, weil das meiste Feedback von Entwicklern positiv ist (so ziemlich die einzigen, die hier aus verständlichen Gründen ausscheren sind ein paar "nostalgische" Objective-C-Fans).
Natürlich wird Objective-C noch lange (zumindest ein paar Jahre) ein Thema sein, aber mich würde überraschen, wenn 2016 noch viele neue Projekte ohne Swift gestartet werden.
Wenn Apple zur Abwechslung mal alles richtig macht und die Sprache pusht (möglichst viel Open source, direkt andere Plattformen unterstützen...) sehe ich sogar Potential, die ganze Industrie umzukrempeln:
Es gibt viele neue Sprachen, aber bei den meisten sieht es bei der Infrastruktur ziemlich düster aus - Apple hat mit Dingen wie den Playgrounds aber schon jetzt ordentlich vorgelegt und muss eigentlich nur noch Xcode weiter optimieren.

Ein Produkt auf den Markt zu werfen, welches unbrauchbar ist, nennst du energisch vorgehen?

Übrigens liegt die Begeisterung von Swift nur in den ersten paar Tagen, vielleicht Wochen, je nach Lerntempo. Danach kommt die große Ernüchterung.

Amin Negm-Awad · 12. November 2014, 12:09

Michael schrieb:

macmoonshine schrieb:

(Wenn Apple das so toll findet, warum verwendet Apple dann an allen möglichen Stellen AnyObject? Meiner Meinung nach besteht zwischen beiden Paradigmen auch ein gewisser Widerspruch.)

Deshalb bin ich auch der Meinung, dass Swift Objective-C nur ersetzen kann, wenn Apple wieder eine Transition wie vom Mac OS Classic (Carbon) zu OS X (Cocoa) macht, also auf ein komplett neues, auf Swift basiertes API (dann auch ohne AnyObject) umstellt. Mit der Konsequenz, dass alle heutigen OS X und iOS Programme dann irgendwann nicht mehr laufen werden.

Wird bloß etwas schwierig, generische Lösungen anzubieten, die sich erst zur Laufzeit installieren lassen. Aber wer braucht schon generische Undo-Manager, Responder-Chain, Forward-Invocation, Core-Animation, …

Meine Lieblinge sind da KVO und Core-Data. Wenn man ein eigenes Schlüsselwort in der Sprache braucht, um überhaupt diese zentralen Technologien irgendwie anzubieten, scheint die Sprache ja unglaublich flexibel zu sein. In etwa so flexibel wie "Geht nicht!"

Witzig beim Vortrag von Alex & Tammo:

Irgendwie ganz vorne: Ein Zitat, welches belegen soll, dass Objective-C ausrangiert werden soll. (Was das Zitat überhaupt nicht hergibt.)
Am Ende dann: Dynamik bleibt erhalten, weil man ja weiter Objective-C-Klassen verwenden kann.

Da wusste man wohl am Ende des Vortrages nicht mehr, was man am Anfang noch gesagt hat.

t-no · 12. November 2014, 14:23

Amin Negm-Awad schrieb:

Ein Produkt auf den Markt zu werfen, welches unbrauchbar ist, nennst du energisch vorgehen?

Falsch zitiert? In dem Absatz ist weder von unbrauchbaren Produkten noch von energischem Vorgehen die Rede. Davon abgesehen: Kennst du eine andere Sprache, die ein paar Wochen nach ihrer Veröffentlichung auch nur halb so viel Infrastruktur hatte?

Was ich mich wirklich frage:
Glaubt ernsthaft jemand, dass Swift wieder eingestampft wird? Und wenn nein: Wozu dann das ganze Gejammer? So ein bisschen Foren-Mimimi wird Apple jedenfalls nicht vom Kurs abbringen, und wenn man sich mit seiner Einschätzung wirklich sicher ist, kann man auch einfach abwarten - wenn Objective-C so überlegen ist, wird es sich schon durchsetzen.

Auf der macoun hätte ich statt der ganzen Vorträge ja am liebsten eine Podiumsdiskussion mit Abstimmung gehabt - das wäre mal interessant geworden.

DBocksteger · 12. November 2014, 14:47

Amin Negm-Awad schrieb:

weil Apple sehr entschlossen an die Sache rangeht,

Ich vermute Amin hat da "energisch" heraus gehört...

Quellcode

Quellcode

Quellcode

Quellcode

Quellcode

Quellcode

Quellcode

Ähnliche Themen