Swift, un langage déjà courant

Stéphane Moussie |

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.

Crédit Yuko Honda CC BY-SA

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.

Tags
avatar ovea | 

Le logo représente un oiseau ?

avatar redchou | 

@ovea :
Oui, Swift peut être traduit par martinet en français...

avatar fousfous | 

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.

avatar redchou | 

@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…

avatar Rez2a | 

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.

avatar fousfous | 

@Rez2a

Bah on doit bien gagner en vitesse et en diminution de la taille de l'app non?

avatar Rez2a | 

@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.

avatar AppleLov | 

@Rez2a :
Il faudrait vraiment que je me mette au développement un jour pour comprendre ce jargon :)

avatar Almux | 

Idem pour moi!
<|8o} J'suis un vrai clown, quand il s'agit de lignes de code!
Au delà d'html, je coule!

avatar Tronculaire | 

Il faut se souvenir du temps qu a pris Apple pour réécrire ses propres apps en cocoa.... ITunes l est il pleinement?...

avatar JoKer | 

Non, iTunes ne l'est pas complètement.
Mais il paraît maintenant logique que les parties Carbon seront réécritent en Swift.

avatar Seccotine | 

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...

avatar FreeDa | 

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 ?

avatar Dark-mac | 

@FreeDa :
Les deux si je ne me trompe pas et que j'ai bien compris l'explication sur Swift.

avatar Chamalo | 

Ç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.

avatar Rez2a | 

@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.

avatar FreeDa | 

@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... ?

avatar 6ix | 

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.

avatar Rez2a | 

@6ix :
Post à encadrer, heureusement qu'il y a encore des dev qui savent expliquer les choses :D

avatar FreeDa | 

@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...

avatar 6ix | 

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.

avatar Insorior | 

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 !

avatar Insorior | 

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.

avatar Stardustxxx | 

@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.

avatar 6ix | 

@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é.

Pages

CONNEXION UTILISATEUR