Je suis en train de confirmer ma position de "swift est un langage de merde pas sec et pas utilisable pour de vrai projet" :-p
Pour ce faire je me suis mis en tête que j'aller porter mon outils ARD Inspector en Swift. J'ai un peut de tout dedans. De la lecture de fichier, des UI avec delegate, des tri, des conversion de type, de la crypto. Bref, tous les truc à la con dans un petit projet.
J'y suis depuis 18h et j'ai toujours pas fini de réécrire le AppDelegate tellement Swift est pas sec (plein de plantage de Xcode lorsque j'écris les boucles for, du casting à gogo qui casse les burnes, etc.)
J'en suis à un truc con, très con même compte tenu que la Keynte disais "c'est 30x plus performant sur les sort d'objet complexe". Je n'arrive pas à comprendre comment je suis censé trier un NSArray qui contient des NSDictionary.
(self.internalComputerDatabase.allValues as NSArray).sortedArrayUsingComparator({ (obj1: AnyObject!, obj2: AnyObject!) -> NSComparisonResult in
return ((obj1 as NSDictionary).objectForKey("name") as NSString).compare(((obj2 as NSDictionary).objectForKey("name") as NSString))
})
Je n'ai pas d'erreur renvoyé par le JIT. Par contre je build j'ai trois erreurs sorties de nul part. Si je vite la ligne de tri, je n'ai plus l'erreur.
Bitcast requires both operands to be pointer or neither
%1829 = bitcast i64 %1828 to %objc_object*, !dbg !818
LLVM ERROR: Broken function found, compilation aborted!
Command /Applications/Xcode6-Beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swift failed with exit code 1
ditto: can't get real path for source '/Users/yoanngini/Library/Developer/Xcode/DerivedData/ARD-Inspector-gzyuihwhsyoupybncrjebvopvutn/Build/Intermediates/ARD-Inspector.build/Debug/ARD-Inspector.build/Objects-normal/x86_64/ARD_Inspector-Swift.h'
Command /usr/bin/ditto failed with exit code 1
ld: file not found: /Users/yoanngini/Library/Developer/Xcode/DerivedData/ARD-Inspector-gzyuihwhsyoupybncrjebvopvutn/Build/Intermediates/ARD-Inspector.build/Debug/ARD-Inspector.build/Objects-normal/x86_64/AppDelegate.o
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Nan mais les gens quand est-ce que vous comprendrez que Swift c'est encore une beta ? Evidemment qu'il y a encore des choses à améliorer (au niveau du casting, des plantages, etc), donc évidemment que c'est vachement trop tôt pour faire du Swift "en production" sur un vrai projet !!
Pour ton tri, pourquoi vouloir encore mixer des types Objective-C genre NSArray et NSDictionary (et du coup avoir du Cast à faire partout) alors que tu es en Swift ?
Nan mais les gens quand est-ce que vous comprendrez que Swift c'est encore une beta ? Evidemment qu'il y a encore des choses à améliorer (au niveau du casting, des plantages, etc), donc évidemment que c'est vachement trop tôt pour faire du Swift "en production" sur un vrai projet !!
Pour ton tri, pourquoi vouloir encore mixer des types Objective-C genre NSArray et NSDictionary (et du coup avoir du Cast à faire partout) alors que tu es en Swift ?
myValues.sort { a, b in
let (an,bn) = (a["name"] as String, b["name"] as String)
return an < bn
}
println("sorted = \(myValues)")
Je suis d'accord avec toi, cependant si on essaye pas de faire de vrai projet pour de faux avec il n'y a aucune chance que cette merde soit déboguer et on se retrouvera dans un an avec Apple qui nous force la main sur un outil inutilisable.
Pour ton tri, pourquoi vouloir encore mixer des types Objective-C genre NSArray et NSDictionary (et du coup avoir du Cast à faire partout) alors que tu es en Swift ?
Par ce que le contenu viens d'un plist tout simplement.
Maintenant il y a un vrai soucis ici. Si les objets Cocoa ne se comportent pas de la même manière en Swift et en ObjC ça casse toute comptabilité avec l'existant.
Que le langage ait des features différentes est une chose, mais que le même framework selon le langage utilisé ait des comportement différent, c'est dangereux !
Maintenant si quelqu'un trouve comment on est censé faire un simple tri à la con avec des collections NS en Swift, je suis preneur.
Maintenant il y a un vrai soucis ici. Si les objets Cocoa ne se comportent pas de la même manière en Swift et en ObjC ça casse toute comptabilité avec l'existant.
Que le langage ait des features différentes est une chose, mais que le même framework selon le langage utilisé ait des comportement différent, c'est dangereux !
Où vois-tu un comportement différent ? J'ai pas suivi...
Interessant... mais dis donc, t'avais mangé du lion !
Pour ma part, je vais attendre avant de m'y mettre de toute façon ! J'ai déjà du mal à maitriser toutes les subtilités d'un langage, alors c'est encore tôt pour moi d'en ingurgiter un nouveau. Tout au plus, je m'informe tout doucement en attendant que çà murisse...
Swift n'est pas fait pour porter une appli existante en ObjC vers du Swift, du moins pas dans sa version actuelle. Déjà c'est trop tôt (comme tu le soulignes c'est une alpha), mais en plus c'est utiliser un framework qui n'a pas été pensé en Swift (Cocoa) avec du Swift : forcément va y avoir du bridging, des APIs à la tronche bizarre... ça me rappelle les __bridge cast à faire de partout pour passer de Cocoa à CoreFoundation, du moins dans les premières version du compilateur où il n'y avait pas ARC et où il n'arrivait pas à inférer les bridge-cast.
Pour moi la bonne expérience à faire pour réellement faire un retour qui a du sens, c'est d'écrire toute une partie d'une application neuve en Swift. Pas de porter une app existante déjà codée, mais de se lancer dans un nouveau projet, de choisir d'écrire par exemple le Modèle et les Controlleurs en Swift, et juste d'utiliser Cocoa pour la partie Services d'un côté et UI de l'autre. Ce genre de truc.
Là tu as un meuble déjà construit et tu essayes d'enlever des pièces en métal une par une pour les remplacer par des pièces en bois, sur un meuble qui a été pensé en métal lors de sa conception. Du coup tout ce qui a été pensé lors de la conception, résistance, solidité, tout ça ne va pas être forcément adapté. Si tu construits un nouveau meuble from scratch en pensant dors et déjà certains éléments en bois et d'autres en métal, ça se passera bien mieux que d'essayer d'enlever une pièce en métal et de bidouiller un remplaçant en bois en essayant de le faire rentrer.
Sinon dans l'ensemble je ne suis pas vraiment d'accord avec ton sentiment. Mais c'est pour moi dû au fait justement que tu as essayé de porter une appli existante plutôt que partir from scratch.
Je suis tout à fait d'accord avec toi pour dire que c'est une alpha, que c'est méga instable et que Xcode plante souvent et ça c'est assez frustrant voire honteux.
Par contre moi je suis séduit par la syntaxe du langage, le côté simple du langage je le trouve également logique. Depuis que j'ai découvert Swift, je trouve la syntaxe plutôt logique dans tout ce que je crée. Pas forcément dans les APIs qui ont été portées directement des APIs Cocoa et traduites à la volée, car du coup certaines APIs ne conviennent pas forcément, mais les APIs pensées de base en Swift par contre tout est cohérent.
Pour ton exemple de sort, je pense que d'une part tu n'as pas assez travaillé les Generics, mais tu n'as pas non plus encore découvert le fait que les fonctions et les closures sont interchangeables ? Du coup si tu as déjà une méthode qui prend deux T en paramètres et retourne un Bool "(T,T)->Bool", tu peux directement la passer en paramètre de "sort". Par exemple tu peux écrire tab = ["A","B","D","E","C"]; tab.sort(>) Et ça va trier ce tableau par ordre décroissant, parce que l'opérateur ">" est déjà une fonction = une closure qui sait prendre 2 String et retourner un Bool. Donc contrairement à ce que tu clames, on a déjà un fonctionnement exactement comme "sortedArrayUsingSelector:" qui prend un selector. "sort" sait prendre un nom de fonction en paramètre.
Paragraphe sur le "cast" : là encore, c'est parce que tu as essayé de démonter ton meuble en métal pour remplacer des bouts de pièce en bois. Si tu fais une toute nouvelle appli et que tu codes des pans entiers de l'app (partie Modèle, ou Controller, etc) en Swift, et que tu fais ta conception avec ces idées en tête, tu n'auras pas autant de Cast de partout. L'idée du "Mix & Match" Swift/ObjC c'est justement ça, avoir toute une partie en Swift et une autre en ObjC et ne les faire communiquer qu'au niveau des interfaces à mettre entre les 2 modules. Faut pas faire une grosse boite qui contient un gros mélange des 2 langages, faut faire une grosse boite pour tel truc en Swift, une grosse boite pour tel autre truc en ObjC, et tu fais juste communiquer les 2 boites avec du Mix&Match. Tu n'essayes pas de construire un bloc moteur avec un mélange de bois et de métal comme un plat de spaghettis, mais tu fais ton bloc moteur tout en métal, et tu l'intègres dans un chassis en bois.
Donc là où je suis entièrement d'accord, c'est pour dire que le langage et surtout le compilateur (LLVM/Xcode) est trop jeune pour s'y mettre maintenant. C'est clairement une alpha, y'a des manques, y'a surtout des plantages qui saoulent grave. Là où je ne suis pas d'accord c'est que moi ce que j'ai essayé pour l'instant avec des modules bien séparés sur une nouvelle app pensée from Scratch, Swift a pas mal d'avantages, le côté simple et type-safe j'aime assez bien (sans doute mon côté "carré" et mon côté "architecte"), j'ai pas eu des casts à faire de partout (parce que je n'essayais pas d'utiliser des objets ObjC en plein milieu du code Swift sous forme plat de spaghettis, mais juste au niveau des interfaces d'échange avec mes autres modules). Et du coup j'ai bcp moins de griefs sur Swift en travaillant comme ça. Les seuls griefs qui me restent c'est contre le compilateur qui plante tout le temps, et qui parfois nous dit que ça compile pas nous laissant penser qu'on a fait un truc qui va pas ou qu'on a oublié un cast, alors qu'il est sensé l'inférer et que si on attend un peu le JIT a le temps de refaire une passe et de faire disparaitre l'erreur qui n'en n'était pas une... donc oui avec un outillage comme ça si peu au point ça n'aide vraiment pas pour faire son apprentissage du nouveau langage.
C'est peut être une beta oui, mais là il y a tout à réécrire et, contrairement à ce qu'ils ont annoncé à la WWDC, la compatibilité binaire ne pourra être conservé (ça c'est déjà acté).
Et de mon point de vue, s'ils veulent résoudre les problème du langage, ils vont devoir tout refaire. Donc le code produit entre temps ne sera plus du tout bon.
Maintenant ce n'est pas du tout être violent que de rappeler à tout le monde qu'il est totalement débile de chercher à se former à ce langage. Quand je vois les sites de news grand public et leur commentaire gentil avec Swift, je me dois de faire contre poids. D'autant que les demandes de formations tombent déjà et que certains osent accepter.
Et Ali, Swift est vendu pour être le nouveau langage du framework Cocoa.
Swift is an innovative new programming language for Cocoa and Cocoa Touch with concise yet expressive syntax that produces lightning-fast apps. It makes writing code interactive and fun, and works side-by-side with Objective-C.
Ce n'est pas censé être un langage à part avec une lib à part. Ce que j'ai cherché à faire ici c'est justement ce qui nous a été vendu. J'ai choisi volontairement cela pour voir si on peut faire un projet complet et réel avec, utilisant Swift pour tout le projet et non juste pour le peu de sous fonction porté dans libswift.
Or c'est assez flagrant, Swift et Cocoa s'intègrent très mal, et pourtant c'est ce que l'on devra impérativement utiliser pour faire 99% des applications.
Alors se dire ont fait tout en ObjC / Cocoa et on colle du Swift juste pour les templates et les sort, non, faut arrêter les blagues, c'est totalement inutile.
Et de mon point de vue, s'ils veulent résoudre les problème du langage, ils vont devoir tout refaire. Donc le code produit entre temps ne sera plus du tout bon.
Heu ça ça a déjà été annoncé même à la WWDC. Le langage va fortement évoluer d'ici les mois à venir, ils attendent justement les retours des Devs (ils les demandent, même, dans plusieurs sessions WWDC)
Maintenant ce n'est pas du tout être violent que de rappeler à tout le monde qu'il est totalement débile de chercher à se former à ce langage. Quand je vois les sites de news grand public et leur commentaire gentil avec Swift, je me dois de faire contre poids. D'autant que les demandes de formations tombent déjà et que certains osent accepter.
Là par contre je suis entièrement d'accord (mais tu le sais, je le répète déjà assez). Swift est bien trop jeune, comme je viens de le rappeler il va de toute façon évoluer dans les prochains mois (c'est déjà acté dès le début), et la version qu'on a c'est juste pour se faire les dents et voir à quoi ça ressemble, surtout pas à utiliser en production. S'il y a à se former en Swift, ça ne sera pas avant la fin de l'année minimum, quand Xcode6 sera sorti de sa beta et LLVM aussi, et encore à mon avis il va encore pas mal évoluer dans les mois à venir après la sortie de la beta.
Perso je ne compte pas me mettre à Swift avant au minimum la sortie de la beta et alors dans ce cas que pour mes petits projets internes (applis juste pour moi que je ne compte pas publier ni vendre), et ne passer à Swift sur les applications client que dans un an au minimum.
Et Ali, Swift est vendu pour être le nouveau langage du framework Cocoa.
Oui mais comme je le répète déjà , d'une part les APIs Cocoa en Swift vont évoluer, le traducteur à la volée d'APIs de LLVM n'est pas encore optimal (par exemple il ne traduit même pas les méthodes à nombre variable d'arguments, etc) donc on sait qu'il y a encore du boulot de ce côté pour LLVM
Et encore une fois, le type cast inference n'est pas non plus encore au point sur la version beta actuelle de LLVM, ce qui fait que le parseur a encore du mal à inférer correctement lors du bridging. Exactement comme on a eu lors de l'arrivée d'ARC où il fallait bridge-caster dans tous les sens et que c'était une horreur. Alors que maintenant pour bcp de cas c'est implicite/inféré et les gens ont déjà oublié la galère que c'était au lancement.
Alors se dire ont fait tout en ObjC / Cocoa et on colle du Swift juste pour les templates et les sort, non, faut arrêter les blagues, c'est totalement inutile.
Heu justement c'est ce que je n'arrête pas de répéter ! C'est pas du tout fait pour "on fait tout en ObjC et on colle du Swift juste pour les templates et les sort", c'est pas la philosophie du truc !
Je pense avoir résolu le problème (mais j'ai pas pu tester puisque je n'ai pas réussi à faire la partie crypto ni à me coller au code ObjC existant).
var sortedList = sort(self.internalComputerDatabase.allValues, {(obj1: AnyObject!, obj2: AnyObject!) -> Bool in
return ((obj1 as NSDictionary).objectForKey("name") as String) < ((obj2 as NSDictionary).objectForKey("name") as String)
})
Et effectivement, comme le disait Ali, ça peu aussi s'écrire comme cela :
var sortedList = self.internalComputerDatabase.allValues.sort({(obj1: AnyObject!, obj2: AnyObject!) -> Bool in
return ((obj1 as NSDictionary).objectForKey("name") as String) < ((obj2 as NSDictionary).objectForKey("name") as String)
})
C'est typique de l'incohérence que je reproche au langage, la manière de faire n'est pas consistante.
Moi, je n'aime pas trop la façon dont sont signées les méthodes. Je trouve qu'Objective-C était plus clair.
L'exemple d'outlineView est très parlant: quand on regarde vite, on ne sait plus où est le nom de l'argument du milieu, le nom de la variable associée et son type car ces 3 facteurs sont espacés 2 fois. C'est pas très beau.
En ce qui me concerne j'ai pas commencé Objective C il y a longtemps et encore moins Cocoa Touch, j'aime bien mais avec Swift j'aime encore plus surtout l'idée du Playground. Ca m'empêchera pas de continuer à approfondir Objective C et je pense que l'union des 2 pourrait avoir des effets bénéfiques plus que chacun pris séparément.
Personnellement j'apprécie ce langage, même j'ai un peu de difficulté à assimiler vite toutes les nouveautés mais je considère ça comme une faiblesse de ma part et pas du language.
C'est la première fois que j'assiste à une naissance d'un langage en tant que développeur, peut être qu'ils sont obligés de passer par cette étape d'instabilité et d'avoir des retours des développeurs, mais je suppose que tout ça est étudié par Apple ( la road map de mise en production du langage). D'ailleurs je ne sais pas
Et la syntaxe ne me choque pas de tout, au contraire j'ai plus de facilité avec Swift que avec Objective C.
Je l'aurais plutôt déplacé dans la rubrique "c'était mieux avant", avec tous les premiers sujets sur ARC.
En tous cas il y a de quoi être triste car c'est le début de la fin pour l'objective-C.
J'ai connu Objective-C en 2009. Sa syntaxe m'a paru un peu bizarre au départ mais après quelques mois, elle est devenue très naturelle. C'était parfois un peu pénible de devoir trouver un nom de méthode qui forment une phrase cohérente avec tous ses paramètres et j'avoue que j'ai parfois j'ai pris des raccourcis en prefixant les paramètres par leur nom.
J'ai peur de ne plus faire l'effort de faire des méthodes phrasées en Swift.
Tu peux pas prendre conscience de l'ensemble des problèmes du langage si tu ne cherche pas à faire un projet complet existant tout neuf avec
Le existant te permet juste d'aller beaucoup plus vite dans ton test. La logique applicative ne dépend pas du langage mais du framework. Vu qu'ici le framework est le même, tu peux totalement traduire un code, c'est censé marcher.
Réponses
Salut la compagnie,
Je suis en train de confirmer ma position de "swift est un langage de merde pas sec et pas utilisable pour de vrai projet" :-p
Pour ce faire je me suis mis en tête que j'aller porter mon outils ARD Inspector en Swift. J'ai un peut de tout dedans. De la lecture de fichier, des UI avec delegate, des tri, des conversion de type, de la crypto. Bref, tous les truc à la con dans un petit projet.
J'y suis depuis 18h et j'ai toujours pas fini de réécrire le AppDelegate tellement Swift est pas sec (plein de plantage de Xcode lorsque j'écris les boucles for, du casting à gogo qui casse les burnes, etc.)
J'en suis à un truc con, très con même compte tenu que la Keynte disais "c'est 30x plus performant sur les sort d'objet complexe". Je n'arrive pas à comprendre comment je suis censé trier un NSArray qui contient des NSDictionary.
Voici le code Objective-C originel :
Et voici ma traduction Swift :
Je n'ai pas d'erreur renvoyé par le JIT. Par contre je build j'ai trois erreurs sorties de nul part. Si je vite la ligne de tri, je n'ai plus l'erreur.
Est-ce que quelqu'un aurait une idée ?
Pour ton tri, pourquoi vouloir encore mixer des types Objective-C genre NSArray et NSDictionary (et du coup avoir du Cast à faire partout) alors que tu es en Swift ?
Je suis d'accord avec toi, cependant si on essaye pas de faire de vrai projet pour de faux avec il n'y a aucune chance que cette merde soit déboguer et on se retrouvera dans un an avec Apple qui nous force la main sur un outil inutilisable.
Par ce que le contenu viens d'un plist tout simplement.
Maintenant il y a un vrai soucis ici. Si les objets Cocoa ne se comportent pas de la même manière en Swift et en ObjC ça casse toute comptabilité avec l'existant.
Que le langage ait des features différentes est une chose, mais que le même framework selon le langage utilisé ait des comportement différent, c'est dangereux !
Maintenant si quelqu'un trouve comment on est censé faire un simple tri à la con avec des collections NS en Swift, je suis preneur.
Il est différent car il dit que le code marche en obj-C mais pas en Swift malgré les casts...
Il est différent car allValues ne renvois plus un NSArray mais un tableau Swift.
J'ai réussi à faire un truc qui compile en réécrivant le tout avec le sort des tableau Swift.
Je n'ai cependant toujours pas pu tester l'application vu qu'il semble impossible d'appeler les fonctions C de CommonCrypto depuis Swift...
Salut la compagnie,
Je viens de publier mon point de vue sur Swift après un projet test assez violent.
http://blog.inig-services.com/archives/1574
Disposé à en discuter ici si ça vous branche.
Je ne vois rien également sur l'appel de fonctions C sur cette page:
https://developer.apple.com/library/prerelease/ios/documentation/swift/conceptual/buildingcocoaapps/InteractingWithCAPIs.html
Non, il y a ce qu'il faut pour écrire du C ANSI en gros, mais pas pour appeler des lib C...
Interessant... mais dis donc, t'avais mangé du lion !
Pour ma part, je vais attendre avant de m'y mettre de toute façon ! J'ai déjà du mal à maitriser toutes les subtilités d'un langage, alors c'est encore tôt pour moi d'en ingurgiter un nouveau. Tout au plus, je m'informe tout doucement en attendant que çà murisse...
T'es super violent, toi .. C'est une BETA ! Il vaut mieux attendre quelques mois pour se faire une opinion !
Déjà c'est trop tôt (comme tu le soulignes c'est une alpha), mais en plus c'est utiliser un framework qui n'a pas été pensé en Swift (Cocoa) avec du Swift : forcément va y avoir du bridging, des APIs à la tronche bizarre... ça me rappelle les __bridge cast à faire de partout pour passer de Cocoa à CoreFoundation, du moins dans les premières version du compilateur où il n'y avait pas ARC et où il n'arrivait pas à inférer les bridge-cast.
Pour moi la bonne expérience à faire pour réellement faire un retour qui a du sens, c'est d'écrire toute une partie d'une application neuve en Swift. Pas de porter une app existante déjà codée, mais de se lancer dans un nouveau projet, de choisir d'écrire par exemple le Modèle et les Controlleurs en Swift, et juste d'utiliser Cocoa pour la partie Services d'un côté et UI de l'autre. Ce genre de truc.
Là tu as un meuble déjà construit et tu essayes d'enlever des pièces en métal une par une pour les remplacer par des pièces en bois, sur un meuble qui a été pensé en métal lors de sa conception. Du coup tout ce qui a été pensé lors de la conception, résistance, solidité, tout ça ne va pas être forcément adapté.
Si tu construits un nouveau meuble from scratch en pensant dors et déjà certains éléments en bois et d'autres en métal, ça se passera bien mieux que d'essayer d'enlever une pièce en métal et de bidouiller un remplaçant en bois en essayant de le faire rentrer.
Sinon dans l'ensemble je ne suis pas vraiment d'accord avec ton sentiment. Mais c'est pour moi dû au fait justement que tu as essayé de porter une appli existante plutôt que partir from scratch.
- Je suis tout à fait d'accord avec toi pour dire que c'est une alpha, que c'est méga instable et que Xcode plante souvent et ça c'est assez frustrant voire honteux.
- Par contre moi je suis séduit par la syntaxe du langage, le côté simple du langage je le trouve également logique. Depuis que j'ai découvert Swift, je trouve la syntaxe plutôt logique dans tout ce que je crée. Pas forcément dans les APIs qui ont été portées directement des APIs Cocoa et traduites à la volée, car du coup certaines APIs ne conviennent pas forcément, mais les APIs pensées de base en Swift par contre tout est cohérent.
- Pour ton exemple de sort, je pense que d'une part tu n'as pas assez travaillé les Generics, mais tu n'as pas non plus encore découvert le fait que les fonctions et les closures sont interchangeables ? Du coup si tu as déjà une méthode qui prend deux T en paramètres et retourne un Bool "(T,T)->Bool", tu peux directement la passer en paramètre de "sort". Par exemple tu peux écrire tab = ["A","B","D","E","C"]; tab.sort(>) Et ça va trier ce tableau par ordre décroissant, parce que l'opérateur ">" est déjà une fonction = une closure qui sait prendre 2 String et retourner un Bool. Donc contrairement à ce que tu clames, on a déjà un fonctionnement exactement comme "sortedArrayUsingSelector:" qui prend un selector. "sort" sait prendre un nom de fonction en paramètre.
- Paragraphe sur le "cast" : là encore, c'est parce que tu as essayé de démonter ton meuble en métal pour remplacer des bouts de pièce en bois. Si tu fais une toute nouvelle appli et que tu codes des pans entiers de l'app (partie Modèle, ou Controller, etc) en Swift, et que tu fais ta conception avec ces idées en tête, tu n'auras pas autant de Cast de partout. L'idée du "Mix & Match" Swift/ObjC c'est justement ça, avoir toute une partie en Swift et une autre en ObjC et ne les faire communiquer qu'au niveau des interfaces à mettre entre les 2 modules. Faut pas faire une grosse boite qui contient un gros mélange des 2 langages, faut faire une grosse boite pour tel truc en Swift, une grosse boite pour tel autre truc en ObjC, et tu fais juste communiquer les 2 boites avec du Mix&Match. Tu n'essayes pas de construire un bloc moteur avec un mélange de bois et de métal comme un plat de spaghettis, mais tu fais ton bloc moteur tout en métal, et tu l'intègres dans un chassis en bois.
Donc là où je suis entièrement d'accord, c'est pour dire que le langage et surtout le compilateur (LLVM/Xcode) est trop jeune pour s'y mettre maintenant. C'est clairement une alpha, y'a des manques, y'a surtout des plantages qui saoulent grave. Là où je ne suis pas d'accord c'est que moi ce que j'ai essayé pour l'instant avec des modules bien séparés sur une nouvelle app pensée from Scratch, Swift a pas mal d'avantages, le côté simple et type-safe j'aime assez bien (sans doute mon côté "carré" et mon côté "architecte"), j'ai pas eu des casts à faire de partout (parce que je n'essayais pas d'utiliser des objets ObjC en plein milieu du code Swift sous forme plat de spaghettis, mais juste au niveau des interfaces d'échange avec mes autres modules). Et du coup j'ai bcp moins de griefs sur Swift en travaillant comme ça. Les seuls griefs qui me restent c'est contre le compilateur qui plante tout le temps, et qui parfois nous dit que ça compile pas nous laissant penser qu'on a fait un truc qui va pas ou qu'on a oublié un cast, alors qu'il est sensé l'inférer et que si on attend un peu le JIT a le temps de refaire une passe et de faire disparaitre l'erreur qui n'en n'était pas une... donc oui avec un outillage comme ça si peu au point ça n'aide vraiment pas pour faire son apprentissage du nouveau langage.C'est peut être une beta oui, mais là il y a tout à réécrire et, contrairement à ce qu'ils ont annoncé à la WWDC, la compatibilité binaire ne pourra être conservé (ça c'est déjà acté).
Et de mon point de vue, s'ils veulent résoudre les problème du langage, ils vont devoir tout refaire. Donc le code produit entre temps ne sera plus du tout bon.
Maintenant ce n'est pas du tout être violent que de rappeler à tout le monde qu'il est totalement débile de chercher à se former à ce langage. Quand je vois les sites de news grand public et leur commentaire gentil avec Swift, je me dois de faire contre poids. D'autant que les demandes de formations tombent déjà et que certains osent accepter.
Et Ali, Swift est vendu pour être le nouveau langage du framework Cocoa.
Ce n'est pas censé être un langage à part avec une lib à part. Ce que j'ai cherché à faire ici c'est justement ce qui nous a été vendu. J'ai choisi volontairement cela pour voir si on peut faire un projet complet et réel avec, utilisant Swift pour tout le projet et non juste pour le peu de sous fonction porté dans libswift.
Or c'est assez flagrant, Swift et Cocoa s'intègrent très mal, et pourtant c'est ce que l'on devra impérativement utiliser pour faire 99% des applications.
Alors se dire ont fait tout en ObjC / Cocoa et on colle du Swift juste pour les templates et les sort, non, faut arrêter les blagues, c'est totalement inutile.
Là par contre je suis entièrement d'accord (mais tu le sais, je le répète déjà assez). Swift est bien trop jeune, comme je viens de le rappeler il va de toute façon évoluer dans les prochains mois (c'est déjà acté dès le début), et la version qu'on a c'est juste pour se faire les dents et voir à quoi ça ressemble, surtout pas à utiliser en production. S'il y a à se former en Swift, ça ne sera pas avant la fin de l'année minimum, quand Xcode6 sera sorti de sa beta et LLVM aussi, et encore à mon avis il va encore pas mal évoluer dans les mois à venir après la sortie de la beta.
Perso je ne compte pas me mettre à Swift avant au minimum la sortie de la beta et alors dans ce cas que pour mes petits projets internes (applis juste pour moi que je ne compte pas publier ni vendre), et ne passer à Swift sur les applications client que dans un an au minimum.
Salut,
Peut-etre une soluce ici http://stackoverflow.com/questions/24099520/commonhmac-in-swift
Et encore une fois, le type cast inference n'est pas non plus encore au point sur la version beta actuelle de LLVM, ce qui fait que le parseur a encore du mal à inférer correctement lors du bridging. Exactement comme on a eu lors de l'arrivée d'ARC où il fallait bridge-caster dans tous les sens et que c'était une horreur. Alors que maintenant pour bcp de cas c'est implicite/inféré et les gens ont déjà oublié la galère que c'était au lancement.
Heu justement c'est ce que je n'arrête pas de répéter ! C'est pas du tout fait pour "on fait tout en ObjC et on colle du Swift juste pour les templates et les sort", c'est pas la philosophie du truc !
Je pense avoir résolu le problème (mais j'ai pas pu tester puisque je n'ai pas réussi à faire la partie crypto ni à me coller au code ObjC existant).
Je déplace le sujet dans Swift: l'intégration.
Et effectivement, comme le disait Ali, ça peu aussi s'écrire comme cela :
C'est typique de l'incohérence que je reproche au langage, la manière de faire n'est pas consistante.
Moi, je n'aime pas trop la façon dont sont signées les méthodes. Je trouve qu'Objective-C était plus clair.
L'exemple d'outlineView est très parlant: quand on regarde vite, on ne sait plus où est le nom de l'argument du milieu, le nom de la variable associée et son type car ces 3 facteurs sont espacés 2 fois. C'est pas très beau.
me semble 100 fois plus clair que:
et encore, j'ai viré tout ce qu'il y a autour.
En ce qui me concerne j'ai pas commencé Objective C il y a longtemps et encore moins Cocoa Touch, j'aime bien mais avec Swift j'aime encore plus surtout l'idée du Playground. Ca m'empêchera pas de continuer à approfondir Objective C et je pense que l'union des 2 pourrait avoir des effets bénéfiques plus que chacun pris séparément.
Hello,
Personnellement j'apprécie ce langage, même j'ai un peu de difficulté à assimiler vite toutes les nouveautés mais je considère ça comme une faiblesse de ma part et pas du language.
C'est la première fois que j'assiste à une naissance d'un langage en tant que développeur, peut être qu'ils sont obligés de passer par cette étape d'instabilité et d'avoir des retours des développeurs, mais je suppose que tout ça est étudié par Apple ( la road map de mise en production du langage). D'ailleurs je ne sais pas
Et la syntaxe ne me choque pas de tout, au contraire j'ai plus de facilité avec Swift que avec Objective C.
Apple semble avoir release en iBook ce qu'on pouvait déjà voir sur leur site :
Objective-C + Swift
Bien loin de toutes vos compétences, mais quel est l'intérêt de migrer un projet dans l'état actuel des choses ?
L'ébauche d'un nouveau projet peut se comprendre.
Je l'aurais plutôt déplacé dans la rubrique "c'était mieux avant", avec tous les premiers sujets sur ARC.
En tous cas il y a de quoi être triste car c'est le début de la fin pour l'objective-C.
J'ai connu Objective-C en 2009. Sa syntaxe m'a paru un peu bizarre au départ mais après quelques mois, elle est devenue très naturelle. C'était parfois un peu pénible de devoir trouver un nom de méthode qui forment une phrase cohérente avec tous ses paramètres et j'avoue que j'ai parfois j'ai pris des raccourcis en prefixant les paramètres par leur nom.
J'ai peur de ne plus faire l'effort de faire des méthodes phrasées en Swift.
[code=auto:0]
[programmer timetoLearn:swift sadlyForgetting:objectiveC withAnger:NO];
[\code]
Tu peux pas prendre conscience de l'ensemble des problèmes du langage si tu ne cherche pas à faire un projet complet existant avec.
existanttout neuf avecLe existant te permet juste d'aller beaucoup plus vite dans ton test. La logique applicative ne dépend pas du langage mais du framework. Vu qu'ici le framework est le même, tu peux totalement traduire un code, c'est censé marcher.