Swift : les enjeux du nouveau langage annoncé par Apple

Swift : les enjeux du nouveau langage annoncé par Apple

Séduire les développeurs coûte que coûte

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

13/06/2014 14 minutes
50

Swift : les enjeux du nouveau langage annoncé par Apple

Le 2 juin, parmi les annonces dédiées à iOS 8 et OS X Yosemite, Apple a créé la surprise en annonçant un nouveau langage de programmation : Swift. Une décision qui peut paraître étonnante, mais que nous avons voulu analyser. L'occasion de faire le point, et de demander à des développeurs et des entreprises vivant de l'écosystème Apple ce qu'elles en pensent.

swift 

 

On peut se demander pourquoi Apple avait besoin d’un nouveau langage. On ne sait pas exactement ce qui a poussé réellement la firme à se diriger vers cette solution, mais on connait en revanche les limitations auxquelles elle faisait face et les bénéfices qu’elle devrait en tirer.

 

Pour développer une application sur iOS et OS X, les développeurs emploient le plus souvent un mélange de deux langages : le C et l’Objective-C. Le premier est impératif, procédural et est plus proche du langage machine, tandis que le second est orienté objet et, bien que hérité du C, tend vers le fonctionnel : le développement se fait par l’intermédiaire de fonctions emboitées les unes dans les autres.

Pourquoi un nouveau langage et pas un langage existant ?

Devant le succès rencontré par la plateforme mobile d’Apple, on peut se demander pourquoi introduire un nouveau langage alors que les développeurs iOS sont nombreux. Il faut savoir en fait que l’Objective-C est très largement basé sur le C et en garde donc une bonne partie des problèmes. C’est en particulier le cas des pointeurs, qui sont tout simplement les adresses mémoire du premier octet d’un objet. Plus la taille d’une application augmente, plus leur nombre croît en proportion. Lorsqu’une erreur survient avec un pointeur, il y a essentiellement deux conséquences : un crash de l’application ou l’ouverture d’une faille de sécurité.

 

Pourquoi alors ne pas utiliser directement un langage existant et plus moderne ? Parce que l’utilisation d’Objective-C a réellement explosé avec l’avènement des frameworks Cocoa et Cocoa Touch, pensés et développés pour lui. Ce sont pour rappel les deux infrastructures réunissant les API (Application Programming Interface) pour OS X et iOS. Aussi, utiliser un autre langage n’est pas si simple car il aurait fallu revoir les interactions avec ces deux infrastructures.

 

Apple a donc choisi de créer un langage répondant spécifiquement à ses besoins, et il ne faudra pas s’y tromper : Swift a bien été créé par Apple et pour Apple. Il a pour ambition de devenir la voie royale (et sans aucun doute à terme la seule voie) pour créer des applications sur iOS et OS X. Un langage unifié reprenant en fait à son compte plusieurs paradigmes de programmation et des idées provenant d’autres langages. Mais au bout du chemin, Apple contrôle toute la chaine du développement pour ses systèmes : son IDE (Xcode), son langage, ses API, son compilateur.

Avant tout, un code plus sûr 

Swift doit permettre à terme un développement plus rapide des applications et surtout plus sûr. La rapidité vient en partie de la réduction de code nécessaire pour obtenir le même résultat qu’avec Objective-C. Elle vient également d’une compilation optimisée au maximum via LLVM, déjà utilisé dans Objective-C. Autre reprise, la gestion de la mémoire par ARC (Automatic Reference Counting) Mais le grand but de Swift est avant tout de rendre le développement plus sûr en éliminant les problèmes inhérents au C et à l’Objective-C.

 

Swift restreint ainsi l’accès aux pointeurs mémoires, éliminant d’office de nombreux risques d’erreurs et de failles de sécurité. Une sûreté de typage est également introduite via l’inférence de types, qui permet de déduire, au moment de la compilation, les types associés aux expressions utilisées. Il s'agit d’une caractéristique que l’on retrouve souvent dans les langages fonctionnels, mais pas seulement puisque le C# de Microsoft (pourtant impératif) le permet également. D’autres ajouts concernant la sécurité ont été faits, notamment l’initialisation obligatoire des variables, l’utilisation par défaut des points d’arrêts conditionnés ainsi que la vérification des limites des zones mémoire pour réduire le risque de dépassement de mémoire tampon.

 

Apple tente évidemment l’opération séduction massive auprès des développeurs qui connaissent déjà l’Objective-C en indiquant que Swift reprend des concepts modernes de programmes, dont certains existent en fait déjà dans Objective-C. C’est le cas notamment des clôtures ou encore de l’interpolation des variables. Apple aime également comparer certains aspects de Swift au Python et on retrouve ainsi les tuples, qui sont des collections de données.

Éléments d’autres langages et compilation dynamique

Apple vante également la facilité induite par Swift avec un argument de poids : le développeur peut observer directement le résultat produit par son code grâce à une compilation à la volée (mode Playgrounds). Il est intéressant d’observer qu’une annonce similaire a eu lieu du côté de Microsoft récemment avec la compilation dynamique pour la future version d’ASP.NET. Un apport qui peut clairement faire gagner du temps aux développeurs existants mais qui pourrait également motiver de nouveaux venus. Et c'est sans doute là son objectif.

 

Mais qu’on ne s’y trompe pas : Swift n’est pas une grande cassure avec l’existant. Les développeurs qui connaissent Objective-C retrouveront rapidement leurs marques, même s’ils devront repasser par une phase obligatoire d’apprentissage. Ceux qui n’aimaient pas l’aspect peu lisible du langage ne risquent pas plus d’aimer Swift, les points virgules et les parenthèses étant par exemple totalement optionnels dans le code, même si Apple les recommande fortement. En fait, le langage autorise des « facilités » d’écriture qui, si elles permettront de gagner du temps, pourraient se faire au détriment de la lisibilité générale du code.

 

Le nom même du langage signifiant « rapide », il y a des chances qu’Apple ait conçu sa technologie pour aller directement à l’essentiel. Le renforcement de la sécurité est clairement un élément positif qui servira d’autant mieux les développeurs qu’ils seront moins expérimentés. Il ne faut pas oublier en outre qu’il s’agit dans tous les cas d’une première version du langage, qui nécessite la bêta de Xcode 6.0 pour fonctionner.

 

Pour mieux cerner l'impact potentiel d'un nouveau langage, nous avons demandé à des développeurs et des entreprises de nous donner leur avis sur l’arrivée de Swift. Comme on va le voir, certains aspects reviennent souvent, mais chacun s’oriente vers des réflexions propres, en fonction de l’utilisation qu’il pourrait en faire.

EVERYDAYiPLAY : le besoin de solutions multi-plateformes

Nous nous sommes entretenus avec Vincent Vergonjeanne, fondateur et PDG de la société EVERYDAYiPLAY, spécialisée dans le jeu mobile. L’avis général est plutôt mitigé, et ce pour une raison simple : « c’est encore un nouveau langage ». Il estime qu'il « aura du mal à trouver un large public ». Pour le PDG, la question du multiplateforme se pose en permanence.

 

Le constat général est en effet que le marché obéit à certaines pressions : « Dans le marché d’aujourd’hui, presque tous les jeux sont développés grâce au moteur Unity, Coco2D et ainsi de suite. Parce que le besoin d’exister sur iOS, Android et sur le web simultanément est un élément clé de la survie de leurs éditeurs » indique Vincent Vergonjeanne. Il ajoute d’ailleurs : « Nous utilisons Unity de notre côté », illustrant la nécessité pour lui de pouvoir coder partout à la fois.

 

L'éditeur était en revanche beaucoup plus intéressé par la technologie Metal, annoncée en même temps que Swift, et d'ailleurs soutenue par Unity. Pour le PDG, la technologie va permettre d’augmenter le nombre de polygones à l’écran ainsi que d’images par seconde. Il aborde également un point intéressant de l’impact de Metal : il est réservé à la puce A7 et ses versions ultérieures, ce qui devrait pousser les utilisateurs vers des modèles récents d’appareils afin de profiter des avantages offerts. La technologie pourrait réduire la fragmentation, et Vincent Vergonjeanne en rappelle tout l’intérêt : « Nous sommes toujours sur un marché avec une forte segmentation d’appareils. Nous aurons toujours besoin de nous appuyer sur le plus petit dénominateur commun ».

 

vikings gone wild everydayiplay

Vikings Gone Wild, édité par EVERYDAYiPLAY

VideoLAN : une syntaxe étrange, mais des avantages notables

Du côté de l’association VideoLAN, qui édite le célèbre lecteur multimédia VLC, le ton est plutôt optimiste. Felix Paul Kuehne, l’un des principaux développeurs, trouve ainsi que Swift est « clairement inspiré de Go et d’autres langages modernes ». Rappelons que Go est inspiré du C et avait été annoncé par Google il y aura bientôt cinq ans.

 

Pour Kuehne, l’arrivée de Swift va manifestement se faire en douceur : « Il est entièrement compatible avec les bibliothèques Objective-C. Il ne possède pas directement de ramasse-miettes mais utilise quand même ARC ». Il estime également le langage « plus rapide que l’Objective-C », notant au passage la possibilité de « le mélanger avec du code Objective-C et C ». On peut « même l’utiliser comme un langage de script dans le compilateur JIT du terminal ». Le développeur semble particulierement apprécier le mode Playgrounds dans Xcode, « qui permet de déboguer le code sans l’exécuter d’abord ». Du coup, « vous pouvez voir les erreurs logiques tout de suite quand vous écrivez votre code ».

 

Concernant l’utilisation proprement dite, Kuehne trouve que « la syntaxe est peu étrange » mais précise qu’il s’y « fera ». Il note en tout cas un point qui met décidément tout le monde d’accord : « Objective-C était terriblement verbeux mais la syntaxe est énormément raccourcie avec Swift », ajoutant qu’il « n’a pas besoin des points-virgules comme dans Go ». En tant que tel, il estime que Swift sera le langage d’Apple « pour au moins les dix prochaines années ».

 

Il reste cependant du chemin d’ici la version finale, « attendue pour l’automne après quatre ans de développement ». Il indique en effet : « Je connais une quinzaine de façons de faire planter le compilateur jusqu’ici ».

 

ios vlc

VLC sur iOS

Stéphane Sibué : Objective-C n'est pas mort

Stéphane Sibué est un développeur chevronné, habitué aux plateformes mobiles depuis longtemps, et est le directeur technique de la société SoftElite. Il a été MVP Microsoft de 2003 à 2012 mais développe sur l’ensemble des systèmes mobiles, notamment via sa structure Guyzmo. Il nous indique à ce titre s’être tout de suite intéressé à Swift et a d’ailleurs commencé à ingérer la documentation d'environ 500 pages sur le langage, publiée par Apple sur iBooks.

 

Sibué note un certain nombre de points positifs au sujet de Swift, notamment son aspect « moderne et pratique ». Lui aussi note « le code beaucoup plus court » quand on le compare à Objective-C. Tout comme la « vraie gestion de la mémoire », la « disparition des pointeurs » et un « compilateur très intelligent ». Des améliorations qui pourraient d’ailleurs « inciter les nouveaux développeurs à s’y intéresser ».

 

Mais en tant que langage parmi d’autres, la place de Swift n’est pas acquise. Pour Stéphane Sibué, le langage est notamment « une réponse d’Apple aux problématiques d’asynchronisme » dans les applications. Swift suppose par ailleurs de « laisser la main à certaines automatisations, notamment dans la gestion de la mémoire ». De fait, le langage, même s’il permet de coder plus rapidement (une fois maîtrisé), pourrait avoir un impact négatif sur les performances. Le développeur indique cependant que l’on manque de recul et que « la version 1.0 finale ne doit pas arriver avant plusieurs mois ». Il estime dans tous les cas que « l’Objective-C sera là encore longtemps ».

 

La concurrence face aux autres langages sera donc un point intéressant. Pour Stéphane Sibué, Apple veut peut-être « ramener à elle les développeurs indécis ». Car selon lui, l’une des questions importantes à se poser est : « Que choisiront les nouveaux développeurs qui sortiront de l’école ? Que choisira le gars au fond de son garage ? ». Il pense en outre que Swift est une réponse partielle à l’attraction grandissante que représentent les outils de développement de Microsoft et l’augmentation progressive de la part de marché de Windows Phone.

 

Lui-même trouve quoi qu’il en soit le langage « très intéressant ». Il « ne se pressera pas » pour son utilisation mais continuera d’observer les avancées qui seront faites.

Applidium : Swift ne va changer les habitudes que pour une minorité du code

Applidium est une entreprise française comptant une trentaine d’employés. La société est spécialisée dans la création d’applications mobiles, avec une orientation particulière : il n’est pas question de développeurs multiplateforme, ceux-ci préférant créer du code natif et aussi optimisé que possible pour chaque plateforme. Nous nous sommes entretenus avec Romain Goyet, co-fondateur de l’entreprise et lui-même contributeur de VLC. Son avis est particulièrement marqué : « Contrairement à d’autres, nous sommes très, très contents de l’annonce de Swift ». Un optimisme qui n’est pas nécessairement étonnant puisque Applidium utilise intensivement l’Objective-C dans ses projets.

 

Il expose cependant son point de vue en notant une série de points forts. « Déjà, Swift n’est pas imposé, en tout cas pour l’instant » indique-t-il ainsi. « Objective-C sera de toute façon soit maintenu encore des années, soit laissé en l’état, mais il ne sera pas retiré ». Comme Felix Paul Kuehne de VideoLAN, il note d’ailleurs la possibilité de brasser Swift avec l’Objective-C et le C. Conséquence : « Tout ce qu’on connait actuellement ne devient pas d’un coup obsolète ».

 

Il tient ensuite à expliquer un point important : « Quand les gens pensent Objective-C, il faut savoir que ce n’est que la partie émergée de l’iceberg. Vis-à-vis des frameworks et des API, on peut dire qu’il ne représente que 10 % de l’apprentissage nécessaire ». Du coup, Swift ne fait que remplacer ces 10 %, car « le reste ne change pas et est partagé entre tous les langages ».

 

itele applidium

L'application iTélé, réalisée par Applidium

 

Comme Stéphane Sibué, il trouve en outre que Swift est « très intéressant », notamment parce qu’il est « plus facile ». D’ici un ou deux mois, il pense que les développeurs seront prêts à l’utiliser et « l’investissement sera rentabilisé », avec plusieurs bénéfices : « Un code plus court, donc moins de bugs, surtout avec un compilateur plus intelligent ». Applidium compte d’ailleurs utiliser Swift, « soit pour des nouveaux projets, soit à travers l’ajout de fonctionnalités dans des produits existants ». Les utilisateurs ne devraient cependant pas s’attendre à voir réellement des différences : « Dans la pratique, on ne peut pas dire si une application a été codée en Objective-C ou en Swift une fois qu’elle a été compilée ».

 

Romain Goyet pointe également dans une autre direction : la véritable rentabilité de l’apprentissage de Swift. Ainsi, même si le nouveau langage peut faire gagner du temps aux développeurs Objective-C, « il reste fermé car destiné uniquement à l’environnement Apple ». Un point important alors que le nombre d’outils de développement multiplateforme augmente. Le fondateur renchérit : « Si Swift devenait open source, les acquis pourraient être réutilisés sur d’autres plateformes ». Et pourquoi pas sur Android avec les API de Google par exemple ? « Peut-être ! Théoriquement, c’est possible ».

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Pourquoi un nouveau langage et pas un langage existant ?

Avant tout, un code plus sûr 

Éléments d’autres langages et compilation dynamique

EVERYDAYiPLAY : le besoin de solutions multi-plateformes

VideoLAN : une syntaxe étrange, mais des avantages notables

Stéphane Sibué : Objective-C n'est pas mort

Applidium : Swift ne va changer les habitudes que pour une minorité du code

Fermer

Commentaires (50)


Très bon article ! espérons que PlayCanvas/HTML5 nous simplifie tout ça. Mais l y aura de toutes façons toujours des applis en code “Natif”


Etant un petit dev indépendant, je me demande si ils vont enfin permettre de développer facilement sous d’autres systèmes d’exploitation. (je sais je rêve :p)


Enfin un article clair sur ce nouveau truc <img data-src=" /><img data-src=" /><img data-src=" /><img data-src=" />


Ca a l’air intéressant, mais moi qui n’y connais absolument rien en code, ben j’ai du mal à comprendre et à me rendre compte du véritable intérêt.

Dépassé je suis.


Pour l’instant le côté non-multiplateforme reste quand même un gros écueil, c’est du perdu pour toutes les boîtes qui font autre chose que de l’interface. Chez nous (startup eye tracking) tout l’algo est en c++ pour sa rapidité et sa compatibilité multiplateforme, Swift ne répond certainement pas à ce besoin là. Je comprends qu’ils fassent un truc sur mesure pour leurs besoins, mais la multiplication des langages est pénible, d’autant que Swift ne risque pas d’être très répandu en dehors des Apps iOS.

Il faut être un peu critique avec les annonces d’Apple : non, Swift ne remplacera certainement pas Python, et non Swift ne sera pas un raz de marée chez les devs, trop de défauts (aucun écosystème existant, pas aussi rapide que du c++, seulement utilisable chez Apple pour l’instant donc l’utilisation sur serveur est hors du spectre). Ceci n’est pas une révolution..








brokensoul a écrit :



. Ceci n’est pas une révolution..







Et personne n’a dit le contraire.









Ohmydog a écrit :



Ca a l’air intéressant, mais moi qui n’y connais absolument rien en code, ben j’ai du mal à comprendre et à me rendre compte du véritable intérêt.

Dépassé je suis.





en caricaturant ça permettra d’avoir une appli/jeux qui plantent moins et qui peuvent être développés en moins de temps qu’avec le langage actuel.



le rêve aurait été qu’il passe en Java <img data-src=" />



Apple n’avait pas encore de langage safe c’est une bonne chose <img data-src=" />

On voit une nouvelle génération de langages comme GO ou M# qui sont safe mais n’utilisent pas de compilation JIT.

Par contre je suis étonné du peu de réactions sur les performances. Apple a quand même annoncé à la conférence qu’il était plus rapide que C <img data-src=" />

Vu toutes les réactions sur les performances depuis 5 ans où je parle de bartok ,de M# et des langages safe, j’imaginais ce genre de débats débarquait <img data-src=" />








charon.G a écrit :



Par contre je suis étonné du peu de réactions sur les performances. Apple a quand même annoncé à la conférence qu’il était plus rapide que C <img data-src=" />







En même temps apple et les mensonges sur les performances ca date d’il y a longtemps.









XMalek a écrit :



En même temps apple et les mensonges sur les performances ca date d’il y a longtemps.







+1 eux et Samsung sont des champions dans ce domaine …









XMalek a écrit :



Etant un petit dev indépendant, je me demande si ils vont enfin permettre de développer facilement sous d’autres systèmes d’exploitation. (je sais je rêve :p)







Je pense que c’est leur très gros point faible. Certains diront que Microsoft a le même, mais les parts de marché sont largement différentes et ils ont Mono (qui semble repartir, enfin).



Actuellement, seul Delphi permet de compiler des applications iOS/MacOS directement sur un PC, mais il est toujours dépendant d’un MAC pour récupérer les SDK et tester/déployer.



bon moi après lecture de l’actu je retourne à mon COBOL <img data-src=" />





l’Objective-C est très largement basé sur le C et en garde donc une bonne partie des problèmes. C’est en particulier le cas des pointeurs



C’est faux !



Les pointeurs en C, ce n’est pas un problème. Cela vient simplement des personnes programmant en C n’ayant pas le niveau de compétence requis.








christophe_gossa a écrit :



C’est faux !



Les pointeurs en C, ce n’est pas un problème. Cela vient simplement des personnes programmant en C n’ayant pas le niveau de compétence requis.





Ce qu’il ne faut pas lire… C’est vrai qu’il n’y a aucune faille dans google chrome /ie/firefox ou dans windows /apple/linux



Est-ce que les tuples peuvent être imbriqués ? par exemple :

var mon_tuple = (arg : 502, tab : (sub : 12))








charon.G a écrit :



Ce qu’il ne faut pas lire… C’est vrai qu’il n’y a aucune faille dans google chrome /ie/firefox ou dans windows /apple/linux





Quel est le rapport ?









Edtech a écrit :



Actuellement, seul Delphi permet de compiler des applications iOS/MacOS directement sur un PC, mais il est toujours dépendant d’un MAC pour récupérer les SDK et tester/déployer.





Haaa .. Delphi … dire que j’ai programmé avec ce langage depuis sa venue après le Turbo Pascal 7.0 (en fait, depuis Delphi 2), jusqu’à sa version XE. Avec ce que je considère comme son apothéose avant les versions .NET: Delphi 7 :-) Ensuite, une bonne version a été Delphi 2007 (pour du pur Win32).

Mais bon, Delphi is not dead !









Vanilys a écrit :



Haaa .. Delphi … dire que j’ai programmé avec ce langage depuis sa venue après le Turbo Pascal 7.0 (en fait, depuis Delphi 2), jusqu’à sa version XE. Avec ce que je considère comme son apothéose avant les versions .NET: Delphi 7 :-) Ensuite, une bonne version a été Delphi 2007 (pour du pur Win32).

Mais bon, Delphi is not dead !







C’est XE6 maintenant, ça avance (qui doit être la version 16) ! <img data-src=" />



Mais au taff, je suis toujours sur le… 6 !





Pourquoi un nouveau langage et pas un langage existant ?



Devant le succès rencontré par la plateforme mobile d’Apple, on peut se demander pourquoi introduire un nouveau langage alors que les développeurs iOS sont nombreux. Il faut savoir en fait que l’Objective-C est très largement basé sur le C et en garde donc une bonne partie des problèmes. C’est en particulier le cas des pointeurs, qui sont tout simplement les adresses mémoire du premier octet d’un objet. Plus la taille d’une application augmente, plus leur nombre croît en proportion. Lorsqu’une erreur survient avec un pointeur, il y a essentiellement deux conséquences : un crash de l’application ou l’ouverture d’une faille de sécurité.





En gros, un developpeur qui ne vaut rien va faire de la merde des qu’il sort de java.



Pour les autres ils peuvent faire des apply bien plus performante qui ne crash pas.








christophe_gossa a écrit :



Quel est le rapport ?





Les langage type safe et memory safe n’utilisent pas de pointeurs. Les limites de tableaux sont vérifiés avant l’exécution ou à la compilation du programme.

Si tu dépasses d’un tableau avec un langage safe, il va jeter une exception et l’état mémoire du programme n’est pas compromis. En C/C++ ça donne lieu à un buffer overflow.

Tu en trouves à foison dans les produits cités au dessus.

Seul un robot ou un homme parfait serait capable d’éviter ce genre de bugs dans un gros projet.









Edtech a écrit :



C’est XE6 maintenant, ça avance (qui doit être la version 16) ! <img data-src=" />



Mais au taff, je suis toujours sur le… 6 !





Ouaip, mais je suis plus devéloppeur Delphi .. :)

Elle est bien la version XE6 ?









Vincent_H a écrit :



Et personne n’a dit le contraire.





Pas une critique sur ton article Vincent, c’était pour remettre les pendules à l’heure (AMHA) par rapport aux annonces d’Apple et à leur couverture par les médias grand public…









spidy a écrit :



en caricaturant ça permettra d’avoir une appli/jeux qui plantent moins et qui peuvent être développés en moins de temps qu’avec le langage actuel.



le rêve cauchemar aurait été qu’il passe en Java <img data-src=" />





<img data-src=" />

<img data-src=" />









Edtech a écrit :



Actuellement, seul Delphi permet de compiler des applications iOS/MacOS directement sur un PC, mais il est toujours dépendant d’un MAC pour récupérer les SDK et tester/déployer.







Je crois que Qt 5 le fait (j’ai pas essayé)

Il possible avec Qt de faire des programmes qui tournent sous Windows, Mac, Linux, Ios, Android) directement sur un PC









escaflowne a écrit :



Je crois que Qt 5 le fais (j’ai pas essayer)

Il possible avec Qt de faire des programme qui tourne sous Windows, Mac, Linux, Ios, Android) directement sur un PC







Attention, certains logiciels font de l’encapsulation web dans un binaire tout prêt. Delphi compile nativement. Pour Qt5, je ne sais pas ce qu’il fait <img data-src=" />









Vanilys a écrit :



Ouaip, mais je suis plus devéloppeur Delphi .. :)

Elle est bien la version XE6 ?







Pas utilisé la version XE6, un peu la XE5. Ça reste dans la ligné des versions depuis XE je dirai. Avec toujours une interface assez horrible (surtout quand tu veux faire du Binding !) et les mêmes plantages qui traînent depuis la v5 au moins <img data-src=" />



Mais sinon, le langage a bien évolué, et c’est sympa à utiliser. Mais je préfère C# et WinRT <img data-src=" />





la véritable rentabilité de l’apprentissage de Swift. Ainsi, même si le nouveau langage peut faire gagner du temps aux développeurs Objective-C, « il reste fermé car destiné uniquement à l’environnement Apple ».





Tout est là: qui va vouloir faire l’effort de s’adapter à un écosystème de développement qui cible 10-20% du marché des smartphones, et ne peut être réutilisé ailleurs ?



Comme dit dans l’article,



la question du multiplateforme se pose en permanence.





Il reste quoi ?



Quelques concepteurs de framework multi-plateforme (et encore, ceux qui voudront lâcher C/Objective-C), quelques irréductibles qui ne désirent adresser que le marché Pommé.



En dehors de ça, point de salut. Dans ce contexte, je ne pense pas que le langage a vocation à se répandre comme une trainée de poudre.








charon.G a écrit :



Les langage type safe et memory safe n’utilisent pas de pointeurs. Les limites de tableaux sont vérifiés avant l’exécution ou à la compilation du programme.

Si tu dépasses d’un tableau avec un langage safe, il va jeter une exception et l’état mémoire du programme n’est pas compromis.







rofl, c’est beau cette croyance que les languages safe le sont à 100% des jolis buffers overflow, des corruptions de page mémoires, des exceptions non piégées j’en ai eu des tonnes en c# ou java dès que tu commences à charger des données, à traiter des buffers de données, des images, etc, bref dès que tu fais autre chose qu’une appli de base.



Un exemple par exemple en c# 32 bits (framework 3.0 je ne sais pas si le bug existe toujours):




  • Tu crée un tableau A de caractères vide (avec [])

  • Tu crée un tableau B de caractères juste après

  • Tu alloues une chaîne d’1 Mo pile (oui c’est fait exprès et il y a pas mal de bugs connus dessus :p)

  • Tu crées une nouvelle variable C qui pointe sur la première variable

  • Tu redimensionnes ton tableau à une taille inférieur à 4 caractères en utilisant la variable C

  • Tu ré alloues une autre chaine à A

  • Constater que B est corrompue









XMalek a écrit :



rofl, c’est beau cette croyance que les languages safe le sont à 100% des jolis buffers overflow, des corruptions de page mémoires, des exceptions non piégées j’en ai eu des tonnes en c# ou java dès que tu commences à charger des données, à traiter des buffers de données, des images, etc, bref dès que tu fais autre chose qu’une appli de base.



Un exemple par exemple en c# 32 bits (framework 3.0 je ne sais pas si le bug existe toujours):




  • Tu crée un tableau A de caractères vide (avec [])

  • Tu crée un tableau B de caractères juste après

  • Tu alloues une chaîne d’1 Mo pile (oui c’est fait exprès et il y a pas mal de bugs connus dessus :p)

  • Tu crées une nouvelle variable C qui pointe sur la première variable

  • Tu redimensionnes ton tableau à une taille inférieur à 4 caractères en utilisant la variable C

  • Tu ré alloues une autre chaine à A

  • Constater que B est corrompue







    Corrompue, mais aucun plantage, pas de violation d’accès ou de débordement de pile. Ça n’empêche pas de faire de la merde, ça évite qu’elle se répande et ouvre des failles de sécurité.



    Et puis, .NET 3 est obsolète depuis longtemps, on en est à la 4.5.1 !









Edtech a écrit :



Corrompue, mais aucun plantage, pas de violation d’accès ou de débordement de pile. Ça n’empêche pas de faire de la merde, ça évite qu’elle se répande et ouvre des failles de sécurité.



Et puis, .NET 3 est obsolète depuis longtemps, on en est à la 4.5.1 !







Maintenant imagine qu’au lieu d’une variable B je fasse appel à une fonction système qui va allouer des buffers critiques en bas niveau.



Ouaip, ultra, safe. <img data-src=" />



Mais oui je suis d’accord que 3.0 c’est pas récent (mais c’est un exemple qui me revient facilement en tête), Après je sais qu’il a fallu attendre la 4.0 pour les correctifs de String (les impacts de performance sur l’allocation de chaines et l’infame bug du += des chaines (il était plus rapide de faire a = a + b que de faire a += b))









XMalek a écrit :



rofl, c’est beau cette croyance que les languages safe le sont à 100% des jolis buffers overflow, des corruptions de page mémoires, des exceptions non piégées j’en ai eu des tonnes en c# ou java dès que tu commences à charger des données, à traiter des buffers de données, des images, etc, bref dès que tu fais autre chose qu’une appli de base.



Un exemple par exemple en c# 32 bits (framework 3.0 je ne sais pas si le bug existe toujours):




  • Tu crée un tableau A de caractères vide (avec [])

  • Tu crée un tableau B de caractères juste après

  • Tu alloues une chaîne d’1 Mo pile (oui c’est fait exprès et il y a pas mal de bugs connus dessus :p)

  • Tu crées une nouvelle variable C qui pointe sur la première variable

  • Tu redimensionnes ton tableau à une taille inférieur à 4 caractères en utilisant la variable C

  • Tu ré alloues une autre chaine à A

  • Constater que B est corrompue





    Le runtime .NET n’est pas non plus exempt de tout bugs.Et comme l’explique edtech ça n’amène pas à des buffer overflow.

    Perso j’ai du avoir un crash du runtime depuis que je code en .NET.









christophe_gossa a écrit :



C’est faux !



Les pointeurs en C, ce n’est pas un problème. Cela vient simplement des personnes programmant en C n’ayant pas le niveau de compétence requis.





Même un développeur chevronné peut faire des erreurs. Plus ton langage te simplifie la tâche, moins tu as de chances d’en faire, que tu sois débutant ou confirmé. Du temps gagné, c’est super précieux.

Si en plus ça ne se fait pas au détriment des performances, c’est parfait.









ErGo_404 a écrit :



Même un développeur chevronné peut faire des erreurs. Plus ton langage te simplifie la tâche, moins tu as de chances d’en faire, que tu sois débutant ou confirmé. Du temps gagné, c’est super précieux.

Si en plus ça ne se fait pas au détriment des performances, c’est parfait.





il y a forcément un impact sur les performances, pas de miracle.. Mais c’est quand même un compromis qui peut être intéressant, je suis d’accord. Et celui qui dit ne jamais faire d’erreurs n’a jamais codé <img data-src=" />









brokensoul a écrit :



il y a forcément un impact sur les performances, pas de miracle.. Mais c’est quand même un compromis qui peut être intéressant, je suis d’accord. Et celui qui dit ne jamais faire d’erreurs n’a jamais codé <img data-src=" />







Ce qui reste effectivement le meilleur moyen <img data-src=" />









charon.G a écrit :



Apple n’avait pas encore de langage safe c’est une bonne chose <img data-src=" />

On voit une nouvelle génération de langages comme GO ou M# qui sont safe mais n’utilisent pas de compilation JIT.

Par contre je suis étonné du peu de réactions sur les performances. Apple a quand même annoncé à la conférence qu’il était plus rapide que C <img data-src=" />

Vu toutes les réactions sur les performances depuis 5 ans où je parle de bartok ,de M# et des langages safe, j’imaginais ce genre de débats débarquait <img data-src=" />





T’es sur qu’ils ont dit de meilleur perf par rapport au C ?

Leur slide parle que de l’objective-C et du python … Et encore c’est a relativiser









arno53 a écrit :



T’es sur qu’ils ont dit de meilleur perf par rapport au C ?

Leur slide parle que de l’objective-C et du python … Et encore c’est a relativiser





De mémoire ils en ont parlé à un moment donné. Sur ton lien un commentaire semble le mentionner.









Vincent_H a écrit :



le C et l’Objective-C. […] le second est orienté objet et surtout fonctionnel : le développement se fait par l’intermédiaire de fonctions emboitées les unes dans les autres.







Ce n’est pas un langage que je connais, mais je n’ai jamais entendu dire que l’Objective-C était un langage fonctionnel <img data-src=" />



Et à vrai dire personne ne semble avoir le même avis que toi <img data-src=" />



Existe t il des devs courageux (dans le sens qui se levent tot, pas le genre fou) qui développent sous bbry pour avoir un avis comparatif ? Perso je ne connais que l assembleur saturn <img data-src=" />








coolraoul a écrit :



En gros, un developpeur qui ne vaut rien va faire de la merde des qu’il sort de java.



Pour les autres ils peuvent faire des apply bien plus performante qui ne crash pas.





Toi, tu pues le pur <img data-src=" />









Presteus a écrit :



Toi, tu pues le pur <img data-src=" />







On est vendredi mais non.



Le garbage collector est mauvais en java.



Bref y a rien de mal a dire que la java n’est pas un bon langage pour la gestion mémoire ( il a d’autre point fort tout de même ) et qu’il est adapté a des developpeurs peu consciencieux.



Là ou le C peut être catastrophique comme merveilleux selon qui s’en sert. Mais le C a de nombreux points faible aussi.



Mais le fait de présenter l’absence de pointeur dans l’article comme un “avantage” de ce nouveau langage ça me dérange un peu. Surtout pour les raisons évoqué.



Mais oui j’avoue le troll a java était pas nécessaire ^^



Je dis pas que je fais mieux que les autres en C, je fais souvent de la m* aussi mais je mettrai pas la faute sur le langage :p



bon, ayé… j’ai craqué, abonné ^^ le commentaire constructif peut être plus tard après lecture de l’article <img data-src=" />



tiens, tant que j’y suis, quelqu’un aurait il un feedback sur dot42 ? légèrement hors sujet mais le bidule m’a l’air très intéressant et personne n’en parle ou presque








coolraoul a écrit :



On est vendredi mais non.



Le garbage collector est mauvais en java.



Bref y a rien de mal a dire que la java n’est pas un bon langage pour la gestion mémoire ( il a d’autre point fort tout de même ) et qu’il est adapté a des developpeurs peu consciencieux.



Là ou le C peut être catastrophique comme merveilleux selon qui s’en sert. Mais le C a de nombreux points faible aussi.



Mais le fait de présenter l’absence de pointeur dans l’article comme un “avantage” de ce nouveau langage ça me dérange un peu. Surtout pour les raisons évoqué.



Mais oui j’avoue le troll a java était pas nécessaire ^^



Je dis pas que je fais mieux que les autres en C, je fais souvent de la m* aussi mais je mettrai pas la faute sur le langage :p







Sur quoi tu te bases pour dire que Java n’est pas bon pour la gestion de la mémoire ?









qosdevelopment a écrit :



bon, ayé… j’ai craqué, abonné ^^ le commentaire constructif peut être plus tard après lecture de l’article <img data-src=" />



tiens, tant que j’y suis, quelqu’un aurait il un feedback sur dot42 ? légèrement hors sujet mais le bidule m’a l’air très intéressant et personne n’en parle ou presque





Je ne connais pas mais si j’avais à porter des applications en C# sur android je lui préfererai xamarin. Il fait parti de la fondation .NET. Et microsoft devrait leur apporter un soutien important surtout avec la nouvelle orientation de nadella.









charon.G a écrit :



Je ne connais pas mais si j’avais à porter des applications en C# sur android je lui préfererai xamarin. Il fait parti de la fondation .NET. Et microsoft devrait leur apporter un soutien important surtout avec la nouvelle orientation de nadella.







Le problème est que Xamarin est hors de prix pour moi, d’où la recherche d’alternatives développant déjà pour des applis pro en C#/SqlServer et en perso sur Unity/C#. J’ai fait l’effort pour l’objective C et sans regret, au début c’est étrange mais ensuite c’est du bonheur…. mais franchement le Java là j’ai pas envie <img data-src=" /> Je ne trouve pas de communauté Française sur le sujet dot42 alors je viens à la pêche ici ;)









qosdevelopment a écrit :



Le problème est que Xamarin est hors de prix pour moi, d’où la recherche d’alternatives développant déjà pour des applis pro en C#/SqlServer et en perso sur Unity/C#. J’ai fait l’effort pour l’objective C et sans regret, au début c’est étrange mais ensuite c’est du bonheur…. mais franchement le Java là j’ai pas envie <img data-src=" /> Je ne trouve pas de communauté Française sur le sujet dot42 alors je viens à la pêche ici ;)





En effet c’est une bonne raison. désolé de ne pas pouvoir t’aider la dessus.









charon.G a écrit :



Les langage type safe et memory safe n’utilisent pas de pointeurs. Les limites de tableaux sont vérifiés avant l’exécution ou à la compilation du programme.

Si tu dépasses d’un tableau avec un langage safe, il va jeter une exception et l’état mémoire du programme n’est pas compromis. En C/C++ ça donne lieu à un buffer overflow.

Tu en trouves à foison dans les produits cités au dessus.

Seul un robot ou un homme parfait serait capable d’éviter ce genre de bugs dans un gros projet.









ErGo_404 a écrit :



Même un développeur chevronné peut faire des erreurs. Plus ton langage te simplifie la tâche, moins tu as de chances d’en faire, que tu sois débutant ou confirmé. Du temps gagné, c’est super précieux.

Si en plus ça ne se fait pas au détriment des performances, c’est parfait.







Que je sache, personne n’est obligé de programmer en C.

Si le C ne convient pas pour certains car il serait une source de bugs, rien ne les empêche d’utiliser un autre langage.



Alors pourquoi s’obstiner à faire du C puisqu’il serait source de bugs ?









christophe_gossa a écrit :



Que je sache, personne n’est obligé de programmer en C.

Si le C ne convient pas pour certains car il serait une source de bugs, rien ne les empêche d’utiliser un autre langage.



Alors pourquoi s’obstiner à faire du C puisqu’il serait source de bugs ?





Le C a ses avantages et ses défauts. Le C reste plus performant que les languages safe actuel(c#,java). Il est multiplateforme(bien que c’est en train de bouger sur ce point pour C#, java déjà le cas). Dans mon cas perso le C est aussi plus adapté à la programmation système.



Perso je ne m’obstine pas à utiliser du C, j’utilise les deux langages. C/C++ pour la programmation cliente et C# pour mes services cloud. il ne me viendrait jamais à l’idée pour la sécurité de coder en C++ coté serveur par exemple.



Pour le moment il n’existe pas de langage parfait donc on en utilise plusieurs selon les besoins.



Erreur à supprimer








coolraoul a écrit :



Le garbage collector est mauvais.







<img data-src=" />



Voila j’ai corrigé <img data-src=" />



C’est d’ailleurs marrant dans toutes les démos de perf des languages safe y a jamais un appel au garbage collector (ou l’appel automatique est désactivé) on se demande pourquoi <img data-src=" />









XMalek a écrit :



<img data-src=" />



Voila j’ai corrigé <img data-src=" />



C’est d’ailleurs marrant dans toutes les démos de perf des langages safe y a jamais un appel au garbage collector (ou l’appel automatique est désactivé) on se demande pourquoi <img data-src=" />







Pas faux, après je sais pas si c’est pareil sur tous les langages mais me semble qu’en java il est particulièrement mauvais, génère de beaux freeze au démarrage, incapable ( ça a peut être changé ? ) de désalloué deux objets qui se pointent mutuellement etc …



Non franchement rien ne vaut une libération manuelle, après aux développeurs d’utiliser les outils a leurs dispositions pour vérifier que tout ce qui a été alloué a bien été désalloué ( y en a beaucoup en C ).



Pour eviter les problèmes de dépassement mémoire lié aux pointeurs, il suffit de choisir la bonne structure de donnée selon ce qu’on veut faire. Oui on ne peut pas faire n’importe quoi en C … C’est pas du tout le langage facile qu’on présente sur le net pour apprendre quand on est débutant. On peut faire n’importe quoi tout compile, mais au final c’est un langage difficile.



Perso après 2-3 ans de développement que en java, c# php je peux pas nier que développer sur ces langages c’est très agréable. Le retour sur C et reprendre les bonnes habitudes niveau mémoire est toujours difficile.



Mais donc pour en revenir au sujet, Swift va faciliter le développement, mais ces avantages ne sont que en terme de facilité de développement pour moi ( et donc de vitesse de developpement, de cout, de maintenance, c’est pas du tout négligeable hein ), en aucun cas sur la qualité et les performances du programme final. Un developpeur senior qui a bouffé du C toute sa vie il sera surement aussi efficace et fera pas n’importe quoi avec sa mémoire. On ne peut pas écrire dans un article que les pointeurs sont un “désavantage” du langage C. Pour moi c’est une force, qui permet de contrôler parfaitement ce qu’on fait, mais çà peut être a double tranchant.