Swift, un langage déjà courant
Tous les voyants sont au vert pour Swift. Le langage de programmation présenté par Apple à la WWDC a été bien accueilli par les développeurs et il n'a pas fallu attendre longtemps pour voir de nombreux projets et expérimentations émerger.
Pour citer quelques exemples, Brent Simmons, le développeur à l'origine de MarsEdit et NetNewsWire, a annoncé qu'il allait écrire la version Mac de Vesper entièrement en Swift. À une autre échelle, Facebook a ajouté la prise en charge de Swift à Parse, sa suite d'outils et de services à destination des développeurs.
Swift n'apparait pas encore dans l'index TIOBE, un classement mensuel de popularité des langages, pour la simple et bonne raison que ce nouveau langage n'a pas encore un mois. La société TIOBE, qui mesure la popularité en se basant sur les requêtes effectuées sur différents moteurs de recherche (Google, Wikipedia, Amazon...), s'attend à ce qu'il apparaisse dès le mois prochain dans le top 20. Une performance qui n'aurait rien d'étonnant étant donné que, comme toute nouveauté, il attire la curiosité, et donc de nombreuses recherches sur le web.
Le plus intéressant sera d'observer la progression de Swift dans ce classement au cours des prochains mois. À l'heure actuelle, c'est le C qui est le plus populaire, suivi par Java et Objective-C — rappelons que l'index TIOBE ne prend pas en compte le volume de lignes de codes écrites, mais l'intérêt que les langages suscitent sur le web.
Le logo représente un oiseau ?
@ovea :
Oui, Swift peut être traduit par martinet en français...
Vous allez mettre votre app en swift?
Les apps d'Apple sont en swift?
Juste pour vous prévenir mais la pub vidéo avec le son à fond qu'on ne peut pas saper pendant 5 secondes ça m'énerve vraiment la!
En plus des bugs en tout genre de l'app.
@fousfous :
L'application de la WWDC est en Swift.
Sinon, personne ne peut sortir une application en Swift tant que Xcode 6 n'est pas en version finale…
C'est marrant parce que j'ai l'impression que ce nouveau la gagné enthousiasme plus les utilisateurs que les devs (plein de commentaires à base de "vous allez réécrire l'appli en swift ?"). Il faut quand même être clair, ça n'a aucun intérêt pour les utilisateurs, c'est transparent. C'était le but de l'update de l'appli WWDC, montrer que c'était déjà fonctionnel et que c'était invisible.
À titre perso, je ne réécrirai pas mes applis en swift, en revanche j'essaierai d'utiliser ce langage pour écrire de nouvelles applis.
@Rez2a
Bah on doit bien gagner en vitesse et en diminution de la taille de l'app non?
@fousfous :
C'est vrai, y a un peu de perfs en plus sur certaines opérations en swift, mais dans une appli mal codée en ObjC ou mal codée en Swift, ça ramera toujours. Ça va pas être le jour et la nuit quoi.
Pour le code je suis pas sûr que ça change grand chose, les fichiers de code ne sont certainement pas inclus dans les bundles des applis, c'est du code compilé qui est là, et vu que le compilateur est le même entre ObjC et swift, potentiellement ça changera rien. De toute façon le code compte pour une portion ridicule de la taille d'un bundle pour la plupart des applis.
@Rez2a :
Il faudrait vraiment que je me mette au développement un jour pour comprendre ce jargon :)
Idem pour moi!
<|8o} J'suis un vrai clown, quand il s'agit de lignes de code!
Au delà d'html, je coule!
Il faut se souvenir du temps qu a pris Apple pour réécrire ses propres apps en cocoa.... ITunes l est il pleinement?...
Non, iTunes ne l'est pas complètement.
Mais il paraît maintenant logique que les parties Carbon seront réécritent en Swift.
Il ne faut pas confondre framework et langage de programmation. Un soft actuellement écrit en Objective-C repose sur Cocoa. Un système écrit en swift fera appel aux mêmes éléments du système. À la différence de Carbon qui était un autre framework, passer en Cocoa demandait une toute nouvelle manière d'écrire une application et vraiment partir de zéro.
Par contre il faut se préparer à ce qu'un jour, certaines nouvelles APIs ne soient uniquement disponible qu'en Swift.
Sinon, iTunes n'est pas en Cocoa et cela n'aide pas à sa lourdeur...
Je n'y connais pas grand chose en langage informatique, du coup j'ai une question : swift peut il totalement remplacer les autres langages, ou il vient s'additionner à l'objective-C ?
@FreeDa :
Les deux si je ne me trompe pas et que j'ai bien compris l'explication sur Swift.
Ça ne remplace en rien un autre langage.
C'est juste une autre façon d'écrire un programme.
Le compilateur derrière est le même. Donc même perf.
Ce nouveau langage est juste (d'après Apple) plus simple a utiliser. Car penser pour le dev iOS.
C'est un peu comme si vous écriviez un texte en français ou en anglais.
C'est la même chose au final pour quelqu'un qui comprend les deux langues.
@FreeDa :
Swift est fait par Apple et uniquement pour les frameworks d'Apple, en clair ça ne sera utilisé que pour coder des applis iOS et OS X.
ObjC est libre et existe depuis des dizaines d'années, même si en pratique il n'est utilisé quasiment que dans l'écosystème Apple.
Swift a vocation à remplacer ObjC pour faire des applis iOS et OS X, mais les deux vont encore cohabiter pendant quelques années.
Mais il est déjà possible de coder des applis uniquement en swift.
@Rez2a :
Merci pour les explications ;-)
Donc dans un futur proche on pourrait avoir OS X, iOS et toutes leurs apps codées en swift, donc un langage plus léger, et donc des logiciels bien plus petits ? OS X ne ferait plus que 500Mo par exemple ? Puisque beaucoup moins de lignes de code... ?
Non, la taille d'un binaire n'a rien à voir avec le nombre de lignes de code.
Autant Objective-C que Swift sont compilés, et la taille du binaire dépend du code machine généré. En l'occurrence, Objective-C et Swift utilisent le même runtime et le même compilateur (LLVM); autrement dit, le langage ne représente que la couche d'abstraction de haut niveau, mais les transformations effectuées ensuite par le compilateur résultent en un code équivalent. A la différence qu'il y a beaucoup d'optimisations effectuées sur le code Swift afin de rendre l'exécutable plus rapide.
Aujourd'hui, la taille d'un logiciel dépend essentiellement de ses ressources (images, sons, etc.) et non du binaire lui-même. Et avec les écrans Retina, les images sont de taille considérablement plus grandes depuis quelques temps, ce qui alourdit les logiciels. Et pour réduire cela, il existe différentes méthodes de compression (utilisées par Apple sur les png par exemple).
Pour vulgariser, c'est comme si tu pouvais écrire un texte en anglais, français ou allemand, chaque langue ayant ses spécificités, mais qu'ensuite ton texte était transformé en une même langue, difficile à lire, mais parfaitement comprise par la machine.
Le travail réalisé sur Swift a notamment été permis justement par les caractéristiques de LLVM.
@6ix :
Post à encadrer, heureusement qu'il y a encore des dev qui savent expliquer les choses :D
@6ix :
Merci, je saisis mieux ! Ce que j'ai compris : en gros le code est une sorte de "raccourci" vers un truc invariablement plus gros, donc pas de différence de taille en fonction du langage...
Pas de différence en fonction du langage est un trop gros raccourci qui n'est pas forcément juste.
Mais disons que ce qu'il faut retenir, c'est que la taille du binaire optenu dépendra surtout de ce que fait le compilateur, i.e. le "transformateur" entre le code que le développeur écrit (langage généralement haut niveau comme Objective-C, Swift, C, Java, etc.) et le langage machine que l'ordinateur sera capable de comprendre et exécuter.
Bien souvent, un compilateur est capable de transformer le langage pour lequel il est prévu, et on se retrouve donc avec un compilateur par langage. Ce qui fait par exemple que Java n'a pas du tout le même compilateur qu'Objective-C.
Ce qui est intéressant avec Swift, c'est qu'Apple ne l'a pas créé comme un langage totalement indépendant, mais s'est reposé sur toute une couche déjà existante pour Objective-C, notamment en utilisant le compilateur Clang, basé sur LLVM, qui permet entre autres une grande flexibilité.
C'est cela qui permet de dire que finalement, Swift ou Objective-C, cela ne change pratiquement rien pour l'exécutable résultant.
Ce qui me déçoit c'est de ne pas pouvoir publier des à présent des applis utilisant swift alors que ios 7 le supporte très bien. Dommage qu'xCode 5 ne le gère pas.
J'ai hâte de pouvoir soumettre mes applis (ex Hundredious) que j'ai déjà commencé à traduire !
Je suis en désaccord avec @6ix.
Le code machine généré ainsi que la gestion de la mémoire dépendent entièrement de la logique du langage. La ou C fait appel à la pile Java fait appel au tas en mémoire ce qu'il est plus optimisé.
De même, le fait que swift s'exempter de liens entre header et .m, de déclarations intermédiaires affectant l'objectiveC a un impact direct sur le nombre d'instructions processeur générées à la compilation et ainsi sur l'efficacité du programme.
Il est clair que cet impact n'est pas aussi importante que celui lié à la gestion des éléments graphiques mais ça sera à mon avis très palpable.
@Insorior
Le nombre d'instructions processeur générées à compilation ne reflètes pas l'efficacité d'un programme. Il y a plein d'autre facteur en jeu.
Par exemple, les fonctions auto vectorization sur les loops génerent plus d'instructions, consomment plus de mémoire mais sont nettement plus rapide que l'implémentation normal.
Ce n'est pas parce que ton langage a une syntaxe plus simple, que le code compilé est plus simple.
Le vrai gain de Swift, c'est un temps de developpement rapide, adapté a l'écosystème Apple.
@Insorior :
Je n'ai pas dit qu'il n'y avait absolument aucun impact, on est bien d'accord.
Mais ici, on compare Swift avec Ojective-C, qui tous deux reposent sur les mêmes "fondations" avec LLVM et sur le même runtime.
C'est d'ailleurs celui qui permet leur interoperabilité.
@Insorior :
Alors autant j'ai presque tout compris aux explications de 6ix, autant toi j'ai rien capté... Comme quoi la pédagogie est un art ;)
Quelle confusion entre la pile et le tas !
Bien sur que le langage C utilise aussi un tas sinon où irait se loger la mémoire créée par malloc ? La seule différence de ce point de vue entre C et Java c'est que C ne dispose pas, en standard, d'un ramasse-miettes (GC : Garbage Collector) pour la gestion du tas (C++ non plus) alors que Java en dispose (c'est d'ailleurs pour ça qu'il n'y a pas de "delete" en Java car c'est la JVM (Java Virtual Machine) qui fait le ménage dans le tas). De plus Java est un langage semi-compilé. Il ne génère pas du "binaire machine" mais du bytecode interprété par la JVM.
Quand à la pile dont tu parles pour C, je suppose que tu parles de la pile d'exécution dans laquelle sont allouée les variables locales (auto) et les informations concernant les appels de fonction. Sache que tout langage utilise une pile d'exécution que ce soit C, C++? ADA, Objective-C, Java, Pascal, etc. Simplement, dans des langages semi-compilés, c'est l'interpréteur du langage intermédiaire (JVM pour Java, LLM3 pour LeLisp, par exemple) qui gère la pile d'exécution en fonction des ordres figurant dans le langage intermédiaire généré par le compilateur.
J'ai l'impression qu'on ne parle que peut de la logique de programmation du nouveau langage d'Apple qui si je ne me trompe pas est fonctionnelle ce qui en soit est un progrès majeur pour les développeurs du dimanche qui code avec leurs pieds malgré tout le mérite qui leur revient.
Serait-on arrivé à oublier de comparer dans un premier temps Swift à :
- Caml et OCaml voir à F#,
- Scala pour Java,
- CoffeScript pour JavaScript
et dans un deuxième temps la programmation fonctionnel à programmation procédurale qu'elle soit objet ou non ???
@ovea :
Swift n'est pas un langage à proprement fonctionnel, dans le sens où tout n'est pas fonction, contrairement à un langage fonctionnel (ce qui d'un point de vue mathématique est très intéressant).
On ne peut pas donc pas totalement le comparer à Haskell ou Scala, mais il en reprend certains principes et quelques éléments de syntaxique, et apporte un côté fonctionnel avec des fonctions du genre "map" sur les tableaux.
En tout cas on voit que cela ouvre clairement de nouvelles possibilités, là où il fallait sans doute ruser pour proposer de nouvelles fonctionnalités à Objective-C, vu son historique.
Pour tous ceux qui sont intéressé par Swift voici un énorme travail en cours de francisation !
http://www.swiftcode.fr
Off topic :
Sinon,la photo du sujet et le travail de Yuko Honda sont assez incroyable…
De toute façon, avant de tout voir réécrit en swift, il faut tenir compte de certain trucs : si la keynote était destinée aux développeurs, alors swift était la plus grosse annonce de la journée, et ça n'a PAS fuité, ce qui est assez incroyable pour une nouveauté comme ça.
Ça peut vouloir dire qu'une chose : le projet était vraiment secret, donc il y avait seulement une poignée de personnes au courant, et donc ça exclut une grande majorité des développeurs de chez Apple. Par conséquent, y a une grande partie des devs d'Apple qui ont été au courant de l'existence du langage plus ou moins en même temps que nous, et donc on est pas près de voir tout iOS et OS X recodés de zéro en swift.