Google, Facebook et Uber envisagent l'utilisation de Swift

Mickaël Bazoge |

Google pourrait bien adopter Swift comme un des langages pour Android, en plus de Java, le langage de prédilection pour le système d’exploitation mobile du moteur de recherche. La structure ouverte de Swift, qui est open-source, et les bisbilles judiciaires avec Oracle sont de nature à faire pencher la balance vers le langage orienté objets d’Apple.

Google aura évidemment du pain sur la planche pour s’appuyer sur Swift : le langage devra être pris en charge par les API et le SDK d’Android, sans oublier de mettre à niveau toutes les bibliothèques de l’OS compatibles Swift. Des interfaces de programmation bas niveau sont en C++, pour lequel il n’existe aucune passerelle avec Swift. Mais le travail est déjà en cours, indépendamment d’Apple et de Google (lire : Swift en route vers Android, avec la bénédiction d’Apple).

Et Google n’est pas seul à s’intéresser de près à Swift. Lors d’une rencontre à Londres, des représentants du moteur de recherche, de Facebook et d’Uber ont discuté de l’opportunité d’intégrer le langage d’Apple à leurs produits, rapporte The Next Web. Chez Facebook, le travail d’intégration aurait déjà commencé, d’après les sources du site, même si pour le moment c’est encore assez discret. Uber a de son côté un exemple tout prêt où puiser l’inspiration : celui de Lyft, passé avec armes et bagages à Swift (lire : Lyft raconte le voyage en Swift de son app iOS).

Swift est un des langages qui intéresse le plus les développeurs actuellement, depuis son passage en open-source. D’après les stats de GitHub, le bébé d’Apple est le 11e langage le plus populaire ; il est aussi utilisé par IBM pour propulser son cloud. Il faudra du temps et beaucoup de ressources chez Google, Facebook, Uber et les autres pour intégrer Swift dans leurs process. Pour le moment, c’est Google qui doit porter l’effort, les autres éditeurs s’appuyant ensuite sur ce travail pour adapter leurs apps et services au langage (en particulier pour tout ce qui concerne la gestion serveur). C’est pourquoi aucune annonce officielle ne devrait émerger avant un petit moment.

avatar robrob | 

Le plus gros probleme pour Android c'est la gestion memoire qui est differente du modele de Swift.
Sinon c'est vrai que ca semble etre un tres bon langage qui resout enormement de problemes habituels de C avec le meme niveau de controle bas niveau.

avatar C1rc3@0rc | 

Je vois pas trop le problème, la gestion de la mémoire se fait peu au niveau du langage (déclaration weak dans la construction des classes "chainées") mais c'est surtout le compilateur qui gère ça et le "moteur d'exécution".

Dans le détail, ARC est plus pertinent sur mobile que le GC d'Android qui lui a besoin de 2 a 3 fois plus de mémoire en moyenne, ce qui explique aussi pourquoi les smartphones Android ont plus de RAM.

Apres il est vrai que le RC demande de penser un peu mieux son code et d'anticiper sa gestion de la mémoire, mais cela n'intervient que dans des cas "critiques", le compilateur prenant en charge les situations les plus courantes.

Le passage de Java a Swift dans Android n'est pas un problème pour Google, Swift étant capable de travailler avec les librairie C natives et la traduction des librairies Java en Swift peut de se faire de manière automatisée.

Le plus gros problème va être de motiver les developpeurs Android a se convertir a Swift, mais vu le potentiel du langage et sa courbe d'apprentissage courte ça devrait pas être difficile. D'autant qu'Oracle est depuis trop longtemps une menace et qu'avec leurs comportement stupide ils sont en train de réussir a saborder Java.

Apple a vraiment bien joué sur ce coup et même si Swift n'est pas une innovation en soi, comme ont pu l'etre Clascal ou DyLan, c'est une réalisation importante et bienvenue.

avatar BeePotato | 

@ C1rc3@0rc : « Je vois pas trop le problème, la gestion de la mémoire ne se fait pas au niveau du langage mais c'est le compilateur qui gère ça et le "moteur d’exécution". »

Une partie se fait aussi, bien évidemment, au niveau du langage. On ne va pas écrire exactement le même code pour de l’ARC que pour un garbage collector (notamment pour la gestion des cycles), et le langage intègre ce qu’il faut pour le modèle de gestion de mémoire pour lequel il est pensé.

« même si Swift n'est pas une innovation en soi, comme ont pu l'etre Clascal ou DyLan, c'est une réalisation importante et bienvenue. »

Tout à fait.

avatar C1rc3@0rc | 

aujourd'hui il est pensé pour ARC, mais demain vers quoi va-t-il evoluer.

Le cadre actuel permet dans Swift de penser la gestion de la mémoire de manière abstraite et logique: le weak est une indication logique, ce n'est pas une instruction d'allocation.
Peut être qu'il aurait ete plus logique de considérer l'inverse ( un strong plutôt pour sécuriser les contingences dans les structures de données).
Par contre lancer le cycle GC de manière manuelle, ça peut être adapté, mais il s'agit de bas niveau et dans ce cas on est plus dans la logique de conception mais dans le programmation de l'exécution, a ce moment on est alors proche du niveau système et autant avoir des outils de ce niveau.

Si on fait de la programmation applicative (des applications...) il faut optimiser la logique du soft, penser fonction et interface (pas que visuelle ;) ) et essayer de rester le plus indépendant du matériel.

L'OS et le compilateur sont la pour gerer l'attribution des ressources alors que l'applicatif lui doit se focaliser sur la logique et l'aspect fonctionnel et le developpeur applicatif n'a pas a compenser les manques et erreurs de l'OS.

On peut d'ailleurs critiquer cet aspect qui manque dans Swift au niveau du parallélisme: il n'y a pas de modele logique dans le langage, il faut passer par des librairies proches de l'OS, et ça c'est une grosse faille pour de la programmation de haut niveau.

En programmation de haut niveau l'adage est : " il ne faut jamais confier la gestion de la mémoire au programmeur, c'est bien trop dangereux et inefficace."
En programmation système l'adage c'est " il ne faut jamais confier la gestion de la mémoire au logiciel, c'est bien trop dangereux et inefficace"

Les deux sont vrais!

avatar madmak | 

Il semble bien qu'Apple soit encore un moteur d'innovation finalement.

avatar nova313 | 

Je ne dirai pas qu'Apple est un moteur d'innovation pour les langages de programmation, mais ils ont su le rendre open-source. Vu qu'Apple compte sur les développeurs pour vendre ses iDevices (s'ils n'y avaient pas d'apps, les devices ne se vendraient pas), il est normal que les développeurs s’intéressent au nouveau langage d'Apple.

Cela aurait un gros avantage, celui de n'avoir qu'un langage de programmation à apprendre. Personnellement, je comprend 12 langages de programmations, cela fait beaucoup, mais cela demande aussi ENORMEMENT d'apprentissage. Je dois avouer que Swift 2 m'a séduit (mais pas Swift 1), et j'apprécie sa syntaxe (sauf l’absence de points virgules).

avatar iGeek07 | 

@nova313 :
Swift 1 était plutôt Swift 0.5… c'est d'ailleurs une des raisons pour laquelle ils ne l'ont pas mis Open Source dès la première WWDC : prendre un an pour finir les bases du langage (une vraie version 1… qui se trouve etre Swift 2 ^^)

avatar C1rc3@0rc | 

Et encore tu es bien généreux en disant 0.5...
Swift 2 a encore des "scories" comm la boucle for du C qui est en cours d'évacuation.
Ceci dit, l'approche d'Apple est plutôt pragmatique car même les langages fortement conçus et contrôles ont toujours du être amendés pour satisfaire des cas reportés par les développeur. Je vais prendre 2 exemples de bons langages: Ada et Python.

Ada a été conçu pour le secteur militaire et industriel, avec un cahiers des charge et un comité de normalisation stricte, et avec un objectif de sécurité et d'efficacité. Pourtant, et malgré une réalisation très soignée et novatrice il a connu plusieurs révision, dont la dernière avec la version 2012 qui lui a apporté des outils majeurs absents a l'origine ou des corrections réellement nécessaire.

Python lui même qui est vraiment conçu pour la sécurité et l'efficacité et du faire une gros changement entre la version 2 et la version 3, ou des bizarreries ont été élimine et a permis de le rendre encore plus cohérente. Reste encore des choses étranges comme l'absence de constantes, peut être pour la version 4.

A l'opposé on voit des horreurs initialement cuisinées a la va-vite qui progressivement sous la pression des développeurs s'améliorent considérablement. Javascript est d'ailleurs un cas d'école a ce niveau et sa toute dernière version démontre une rationalisation pragmatique. Y a encore du boulot, notamment avec les ";" qui sont un facteur de bug.

Soit un langage est comme Lisp construit de manière mathématique et minimaliste pour être extensible et réflexif des le départ, soit est construit pour être structurant et normalisé comme Ada, mais dans tous les cas s'il est pertinent il va évoluer. L'approche d'Apple est donc pragmatique et semble attirer beaucoup de monde.

avatar alderaan | 

@nova313 :
Ben, si sortir un langage complet et avoir une courbe d'adoption pareille ne qualifie pas de "moteur d'innovation", je me demande bien ce qui rentre dans tes critères...

avatar k43l | 

Courbe d'adoption entre guillemet. Envisager n'est pas faire. Mise à part IBM, d'on le partenariat avec Apple selon moi n'est pas étranger à cette adoption plus ou moins massive, rien n'est fait.

Surtout pour Google ça signifierai revoir de manière profonde Android. C'est possible après tout, mais si tôt je ne le pense pas.

avatar BeePotato | 

@ k43l : « Courbe d'adoption entre guillemet. Envisager n'est pas faire. Mise à part IBM, d'on le partenariat avec Apple selon moi n'est pas étranger à cette adoption plus ou moins massive, rien n'est fait. »

Je pense qu’il parlait de l’adoption dans la communauté des développeurs (dont un gros paquets de petits développeurs, donc), et non d’une adoption par les grosses boîtes.

« Surtout pour Google ça signifierai revoir de manière profonde Android. C'est possible après tout, mais si tôt je ne le pense pas. »

Ah ben c’est sûr que ce ne serait pas un projet qui sera réalisable du jour au lendemain en deux coups de cuiller à pot. Et d’ailleurs, il serait idiot pour Google de s’y mettre avec Swift 2 alors que la version 3 amènera encore des changements significatifs de syntaxe.

avatar C1rc3@0rc | 

«Surtout pour Google ça signifierai revoir de manière profonde Android. C'est possible après tout, mais si tôt je ne le pense pas.»

Je vois pas pourquoi. En théorie un OS est indépendant d'un langage de programmation. Si ce n'est pas le cas c'est que soit il y a une erreur de conception a la base, soit qu'il y a une volonté de contrôle du propriétaire, ce qui alors implique que l'OS est propriétaire.

Java n'est qu'un langage parmi les autres, conceptuelement et syntaxiquement discutable malgré son succès, et il est de plus construit sur une machine virtuelle. Dans les fait on peut donc remplacer Java par n'importe quoi d'autre qui se base sur la VM et qui reste compatible avec le code "compilé" pour la VM. C'est le cas par exemple de Jython, une version de Python qui tourne sur la VM de Java.

Au pire Google peut donc commencer la transition très vite en gardant la VM et en implementant Swift dessus.

avatar Armaniac | 

@alderaan :
Je suis assez d'accord... La courbe d'adoption du Swift, notamment sur les plateformes mobiles d'Apple, est quand même pas degueu. Je ne sais pas ce que ça donne sur Mac, en revanche.

avatar Hertzfield (non vérifié) | 

@nova313 :
Tu peux mettre des ; si tu le désires.
Ce n'est pas obligatoire mais tu peux.
C'est bien le Swift, j'aime le Swift.

avatar Darcel | 

C'est bon ça !

avatar bompi | 

Pourquoi Google n'utiliserait pas Go ? Langage sympathique et produit par Google... Avec de bonnes idées, une bonne polyvalence, il est assez facile à appréhender par tout développeur ayant écrit quelque chose dans un langage cousin (même éloigné) du C.

avatar C1rc3@0rc | 

Parce que c'est un langage qui n'est pas conçu pour de l'application mais de la programmation système. Il demande trop d'attention et un vraie formation d'ingénieur. L'absence volontaire de gestion des exceptions et des assertions est en soit une approche qui se défend, tout comme le choix de ne pas intégrer l'approche objet classique, ou d'intégrer un parallélisme assez particulier, mais ça implique une méthodologie et une discipline de développement qui ne colle pas avec la population qui produit des applications pour smartphone.

Le problème de Go c'est qu'il s'adresse donc a des ingénieurs systèmes, qui vont eux être formés a Ada, Eiffel et des méthodologies de développement pour contrôler le C.
Le developpeur d'application lui a besoin d'un langage qui paraisse abordable, pas trop contraignant (beaucoup viennent du Javascript ou pire du PHP) mais qui dans les fait dispose de forts et nombreux mécanismes de contrôle d'erreur. A ce niveau Swift est une vraie réussite. Et Swift est d'abord un langage applicatif, même s'il a un potentiel pour la programmation système.

avatar BeePotato | 

Aïe.

Pourquoi aïe ? Parce qu’avec Google, on peut craindre un scénario à la WebKit → Blink, avec la sortie dans quelques années d’un fork de Swift (un « Swiftle » ou un « Gwift », bien que ce dernier nom sonne un peu trop gnomesque) contrôlé par Google et adopté massivement par les développeurs à cause du poids d’Android.
(Et comme le feront probablement remarquer certains : oui, c’est aussi le même genre de scénario que KHTML → WebKit, mais à l’époque je n’ai pas dit « aïe » parce que ce n’était pas sur mes arpions qu’on marchait.)

avatar robrob | 

@BeePotato
Il y a des raisons au fork de Google pour Webkit et ca facilite aussi le travail sur Webkit. Si a un moment il y a des raisons de faire un fork sur Swift je vois pas en quoi ce serait un probleme. Mais honnetement les forks de langage c'est plus rare et souvent moins justifie techniquement.

avatar iGeek07 | 

@robrob :
+1
Pour un langage je ne vois pas pourquoi ils voudraient forker. Ce n'est pas similaire à WebKit sur ce point là.

avatar Un Type Vrai | 

C'est vrai qu'ECMAScript n'a qu'une seule implémentation.
C'est vrai qu'Oracle n'a pas pu faire de procès à Google ou Microsoft sur l'interprétation du langage ...

En fait des fork de langage existent bien, mais ça ne s'appelle pas des forks.

Hacks VS php, Objective-C vs Objective-C 2.0 etc.

Et même sur des langage peu connus :
Eiffel n'est pas (n'etait pas ?) identique à 100% pour le compilateur SmartEiffel et EiffelStudio.

Bref,

Après Applesera tentée de mettre dans Swift des choses propre à Apple... Ce qui pourrait desservir Google qui pourait faire un fork.
N'est pas toujours coupable le plus évident.

avatar C1rc3@0rc | 

Lorsque j'ai commencé mes cours d'informatique, le prof avait mis une "pancarte" ou était écrit en gros "Lisp est plus évolué que ses successeurs et descendants"...

Il y a une notion de conservatisme syntaxique qui fait qu'inévitablement le developpeur veut réaliser des concepts nouveaux avec une syntaxe existante.

Soit le langage est comme Lisp, mathematique, et permet d'integrer les concepts et de s'étendre selon le principe mathématique grâce a une base simple et cohérente

Soit on defini un nouveau langage qui intègre de la manière la plus cohérente un modele conceptuel, comme pour Swift.

Soit il faut greffer des structures grammaticales et syntaxiques construites de toutes pieces dans un langage existant. Le pire exemple de cela c'est le C qui a fini par intégrer (ou au moins tenté) des formes de programmations sécurisés d'Ada et orientées objets qui sont a l'opposé absolu du concept initial du langage (un assembleur de "haut niveau"), ce qui a conduit a des monstres comme le C++.

Tout dépendra de la façon dont Apple voudra normaliser et étendre le langage.

Cela pourra s'apparenter a ECMAScript ou Ada, ou cela pourra aboutir a des incohérences comme l'a vécu le Pascal ou chacun y allait de sa version.

L'approche opensource permet les deux, le comité de normalisation garantit la cohérence s'il sait rester dans lee concepts.

Un des points problématique de Swift c'est la gestion des exceptions qui n'est vraiment pas élégante et tres loin du modele d'Eiffel, alors que tout le permettait.
A ce sujet SmartEiffel n'existe plus. LibertyEiffel bouge encore un peu, mais...

Y a aussi une bizarrerie avec le "Labeled Statements": ça n'a pas plus de justification que le goto et c'est aussi dangereux!
Un autre très gros problème de Swift c'est la programmation parallèle et asynchrone.
Et finalement autre problème c'est qu'il se repose trop sur Cocoa.
Et la il risque d'y avoir des raison fork.

avatar BeePotato | 

@ C1rc3@0rc : « Y a aussi une bizarrerie avec le "Labeled Statements": ça n'a pas plus de justification que le goto et c'est aussi dangereux! »

Oui, mais après tout, il ne s’agit que d’une extension du break et du continue, qui présentent déjà les dangers du goto (dont ils sont plus ou moins une variante). De ce point de vue, ce n’est pas tellement pire qu’une exception, je trouve.

« Un autre très gros problème de Swift c'est la programmation parallèle et asynchrone. »

Pour ma part, j’apprécie l’usage de GCD pour cette tâche, mais je comprends qu’on puisse préférer quelque chose d’un peu plus discret syntaxiquement parlant. :-)

« Et finalement autre problème c'est qu'il se repose trop sur Cocoa. Et la il risque d'y avoir des raison fork. »

Oui, c’est bien ce qui peut mener à des velléités de fork.
En revanche, du point de vue du développer visant les plateformes Apple, cette proximité avec Cocoa est plus vue comme une force que comme un problème. ;-)

avatar C1rc3@0rc | 

Le probleme de GCD c'est qu'il s'agit d'une librairie propre a l'OS.
Ce n'est pas une construction du langage.

Si on fait de la programmation système, ça va, mais si on fait de la programmation applicative ( donc qui doit être portable et surtout se situe au niveau logique supérieur) c'est une aberration.

On est d'accord que pour developper pour iOS un minimum c'est de connaitre et d'exploiter les ressources de l'OS mais la on parle pas de développement sur iOS ou MacOS, mais du langage Swift et de plus de son portage sur des OS différents comme langage de programmation universel.
Demain on va voir arriver des architectures matérielles multi processeurs, des asymétriques, mêlant du vectoriel, etc... S'il faut considérer qu'a chaque fois que l'on veut faire un calcul matricielle de sélectionner une librairie spécifique par OS, alors Swift ne sera jamais un langage répandu: on va rester aux dérivés du C.

Le break et le continue ne sont pas comparable au goto. Ils sont certes la pour rendre réalisable des malfaçon dans la conception de haut niveau, comme les points de sortie multiple d'une fonction, mais il ne s'agit pas d'un saut arbitraire aussi puissant et dangereux que le goto. Ils restent des altérations pratiques et limités a la boucle en cour, donc même problème que les points de sortie multiples de la fonction.

L'exception, certes est mal comprise et souvent mal utilisé, mais ce n'est pas une instruction de branchement, c'est une gestion de la violation de la logique. Lorsque l'exception se declenche c'est une preuve qu'il y a une erreur de conception dans le logiciel et cela permet de minimiser les degat. C'est ultra puissant associé a la programmation par contrat.

Le labeled statement lui est un branchement du même type que le Goto, ni plus ni moins. Il n'a pas sa place ailleurs qu'en assembleur.

Et les boucles imbriquées devraient être impossibles car elles relèvent d'une erreur de conception ou de réalisation.

avatar BeePotato | 

@ C1rc3@0rc : « Le probleme de GCD c'est qu'il s'agit d'une librairie propre a l’OS. Ce n'est pas une construction du langage. »

Ce n’est pas une construction du langage, mais ce n’est pas non plus une bibliothèque (et non « librairie ») propre à l’OS. Elle fait partie du jeu de bibliothèques appelé « core libraries » sur swift.org (https://swift.org/core-libraries/), qu’il est prévu de fournir avec Swift sur toutes les plateformes où il sera développé.
Le développeur Swift utilisant des fonctions de Foundation et de GCD ne se retrouvera donc pas dépendant d’un OS.

Il n’y a donc qu’une différence syntaxique avec l’approche consistant à ajouter au langage des bouts de syntaxe dédiés à la gestion deu parallélisme.

« si on fait de la programmation applicative ( donc qui doit être portable et surtout se situe au niveau logique supérieur) »

Non, la programmation applicative n’a pas pour vocation première d’être portable — au contraire. Certes, on a souvent la tentation de faire le maximum de code indépendant de la plateforme pour se faciliter la vie si on sort la même application sur plusieurs plateformes, mais ça ne doit pas être un des objectifs principaux lors du développement. Même pour les parties non directement visibles par l’utilisateur (le modèle, quoi), on peut gagner à utiliser des outils fournis par la plateforme sur laquelle on développe, plutôt qu’à essayer à tout prix de rester générique et portable.

avatar BeePotato | 

@ robrob : « Il y a des raisons au fork de Google pour Webkit et ca facilite aussi le travail sur Webkit. »

En effet. Je prenais ce fork comme exemple de déroulement des événements (participation au projet le temps d’avoir un gros succès, puis fork une fois le succès acquis), plutôt que comme exemple d’impact négatif.

« Si a un moment il y a des raisons de faire un fork sur Swift je vois pas en quoi ce serait un probleme. Mais honnetement les forks de langage c'est plus rare et souvent moins justifie techniquement. »

Un désaccord sur la direction d’évolution de la bibliothèque standard, ça arrive facilement (surtout quand il s’agit d’adopter un langage comme langage de développement principal d’un OS déjà existant).
Ou un désaccord sur d’autres aspects plus fondamentaux du langage — il n’y a qu’à voir certaines des propositions sur Swift-evolution, avec des gars qui proposent des modifications qui transformeraient Swift en une sorte de clone de C++.

Et si un fork se produit pour une de ces deux raisons après qu’une grosse partie des développeurs Android seront passés à Swift, ils suivront naturellement la version Google et on perdra alors l’avantage d’un langage unifié.

Ce qui, en soi, n’est pas dramatique, je l’admets : après tout, on a très bien survécu jusque là avec un Objective C utilisé exclusivement sur les plateformes Apple ; on devrait donc s’en sortir sans réel problème avec un Swift version Apple (mais avec juste un poil de frustration en plus quand on tombera sur un joli morceau de code partagé en Swift version Google et qu’il faudra le réécrire en partie pour pouvoir l’utiliser).

À la réflexion, finalement, je me dis que je crains peut-être plus l’absence de fork, dans l’hypothèse du poids d’Android amenant à intégrer au langage des évolutions que je n’aimerais pas. :-)

Bref, juste des réflexions très préliminaires basées sur le fait que l’adoption d’un langage par un acteur d’un tel poids peut avoir des effets non anodins.

avatar robrob | 

@BeePotato
J'avoue m'etre interesse au Swift que de loin pour l'instant mais j'aime beaucoup ce que j'ai vu.
J'espere que malgre le cote open source, le controle de la direction du langage est assure par Apple. Tout comme Linux est tres controle malgre son cote open source (on peut reprocher certaines decisions mais elles sont generalement coherentes avec une idee maitresse).

avatar BeePotato | 

@ robrob : « J'espere que malgre le cote open source, le controle de la direction du langage est assure par Apple. »

Oui, c’est le cas pour l’instant.
D’où, en cas de future divergence de point de vue de Google au sujet de l’évolution du langage, une probabilité de fork qui me semble plus élevée que la probabilité d’arriver à imposer son point de vue.

avatar Khleo | 

Faudrait que l'on puisse developper des App Windows 10 en Swift et ça serait la fête

avatar patrick86 | 

"Faudrait que l'on puisse developper des App Windows 10 en Swift et ça serait la fête"

Oui, et on invitera Taylor pour chanter !

avatar Mike Mac | 

Taylor pour chanter ?

Et pourquoi pas David et Jonathan ?

avatar Armaniac | 

En ce qui me concerne, je m'étais intéressé à l'Objective C, juste par curiosité, il y a quelques années. J'avais fait joujou, suivi quelques tutos, mais je m'étais arrêté la. Je trouvais la syntaxe pas très sexy. Notamment l'usage à outrance des crochets me gonflait, sachant que sur un clavier Mac, il faut appuyer sur pas moins de trois touches en même temps pour l'obtenir...

J'ai vraiment découvert Swift il y a trois ou quatre mois. Et personnellement, sans être un développeur professionnel, je le trouve 100 fois plus lisible, et beaucoup plus facile à appréhender que l'Objective C. Quelques notions sont encore floues pour moi (les optionnels avec les ? Et !, notamment), mais j'ai réussi à coder une application complète et relativement complexe en deux mois sur Xcode, chose que je n'arrivais pas à faire avec l'Objective C. Cela dit c'est peut être aussi dû au fait que j'ai mûri certains concepts et méthodes de codage entre temps. Et niveau documentation, celle d'Apple est déjà pas mal foutue (ça manque quand même cruellement d'exemples concrets pour chaque fonction ; Microsoft a fait ca pour le VBA par exemple, c'est vraiment très pratique), et Internet fourmille de forums et tutos pour le Swift. Signe que le langage est en pleine expansion.

Si en plus il devient vraiment multi-plateforme, il va gagner énormément en attractivité. C'est toujours chiant de devoir switcher entre les langages dans une même appli.

avatar C1rc3@0rc | 

Euh si tu veux programmer prends un clavier qwerty sinon tu trouveras aucun langage "sexy" ;)
Et pour les crochets d'OJC, mets toi a Lisp avant, je te jure que ça va t'aider avec les crochets ;)

Mais bon si tu veux vraiment te mettre a la programmation commence avec Python et attaque avec le site Openclassroom et lis au moins un bouquin d'algorithmique de base

https://openclassrooms.com/courses/algorithmique-pour-l-apprenti-programmeur/qu-est-ce-qu-un-algorithme
N'hesite pas a explorer ce site et a en suivre les cours ils sont bons et abordables.

Surtout il y a des bouquins de références chez McGraw Hill dont au moins ces 3 la:

Data Structures and algorithms - concepts, techniques and applications de G.A.V. Pai

Schaum's Outline of Theory and Problems of Data Structures

Schaum's Outline of Essential Computer Mathematics

Apres y a des bouquins comme Analyse de données en Python de WMcKinney chez Eyrolles, mais c'est pour un niveau plus avancé.

avatar BeePotato | 

@ C1rc3@0rc : « Euh si tu veux programmer prends un clavier qwerty sinon tu trouveras aucun langage "sexy" ;) »

C’est une remarque que j’ai souvent lue, mais avec laquelle je n’ai jamais été d’accord (bien qu’utilisant tous les jours des claviers qwerty et azerty).

Oui, le clavier qwerty US donne un accès plus rapide aux crochets, aux accolades et au point.
Mais en échange, on se retrouve avec un accès plus lent qu’en azerty pour les parenthèses, les guillemets, le point d’exclamation, les deux points, ainsi que pour les @, &, ^ et $.

Il ne s’agit donc en rien d’une solution miraculeuse ou encore obligatoire pour développer. J’ai l’impression que cette réputation lui vient d’une comparaison avec la disposition azerty PC, effectivement bien peu agréable à utiliser (et pas juste pour programmer). Mais la disposition azerty Mac, notamment avec son regroupement logique des parenthèses, accolades et crochets sur les mêmes touches, est pour moi un plaisir à utiliser pour la programmation.

Évitons donc de présenter cette idée du « clavier qwerty pour la programmation sinon rien » comme s’il s’agissait d’une véritée absolue et indiscutable.

avatar Lio70 | 

@Armaniac
Quand on veut coder a l'aise et de manière professionnelle, on se munit du materiel adéquat, c'est a dire d'un clavier Qwerty. Aucun problème a taper des crochets avec un Qwerty. L'Objective-C abonde de crochets, ce qui le rend justement plus lisible. Swift est fait pour les debutants, de la meme manière qu'on a invente Windev pour des developpeurs franchouillards que ca emmerdait de devoir apprendre l'anglais. Argument de Swift, en resume: on peut taper comme on veut. Bref, un langage pour les amateurs qui ne parviennent pas a coder dans un environnement des que celui-ci exige d'eux de l'ordre et de la structure. Sans compter l'immaturité du langage et les nombreux bugs d'analyseur et compilateur.

Ca va être chouette, les applications en Swift. Bonjour le partage de code, les reprises de code fait par quelqu'un d'autre en milieu professionnel, etc... Parce qu'évidemment, meme dans des milieux prétendument hautement professionnels, on finira par adopter Swift parce qu'un code multi-plateforme revient moins cher. Quelque soit le domaine, quand plusieurs choses du meme acabit sont en competition, c'est la moins bonne qui triomphe car elle est en general aussi la moins couteuse.

Ce qu'Apple aurait du faire pour continuer d'être une plateforme de qualité, c'est a dire qui ne se soumet pas a la loi du grand nombre: obliger l'utilisation d'Xcode avec C, C++ et Obj-C point final, rejeter Swift, rejeter iAd, interdire la publicité dans les apps tournant sur OSX et iOS, interdire Java depuis toujours, ne pas permettre la gratuite des applications, obliger les developpeurs a être ages de 21 ans révolus pour s'enregistrer et distribuer leurs apps. Le monde des apps OSX/iOS se serait dégraissé de lui-meme pour privilégier le meilleur.

avatar alderaan | 

@Lio70 :
A la lecture de ce commentaire, mon bullshitomètre est monté dans le rouge, y est resté trop longtemps et a explosé.

avatar C1rc3@0rc | 

@Lio70

C'est du second degré?

Swift c'est pas Ada, on est d'accord mais c'est un langage jeune qui évolue et offre un cadre et des outils qui servent autant le développeur pro que l'étudiant ou l'amateur.
Le fait d'avoir des langage multiplateforme c'est pas une indication de nullité, au contraire, un langage spécifique a une plateforme c'est même inquiétant.

Le choix d'Objective-C semble du au besoin de disposer d'un langage orienté objet a typage dynamique permettant le latebinding nécéssaire a l'architecture du framework de NeXTStep qui s'inspirait fortement de l'environnement Smaltalk et qu'Interface Builder aujourd'hui intégré dans Xcode était développé en Lisp. Et comme le NeXT n'était pas un foudre de guerre fallait un langage compilé qui soit raisonnablement rapide et qui permette facilement de s'interfacer avec la base Unix: Objective C répondait a ces critères étant un preprocesseur C qui se calquait sur une bonne partie des concepts de Smalltalk. Et comme il ne rajoutait qu'un petit runtime au programme C il gardait une bonne vitesse d'exécution.

Et a cette époque il n'y avait pas non plus 36000 possibilités.

Quant a Java il tournait déjà sur NeXT Step et il a permis de rendre accessible le serveur WebObject de NeXT au marché des serveurs qui migrait lui massivement sur Java.
Et Java a l'époque présentait de vraies évolutions et était plus cohérent que l'usine a gas C++ ou l'antédiluvien C avec toutes ses bidouilles pour l'adapter a l'air du temps.

Il y avait bien d'autres langages qui auraient pu devenir pertinents pour prendre la révèle d'Objective C et faire du soft de qualité efficace (Eiffel, Ada 95, Object Pascal, BETA,...) mais soit c'était des langages non libres, soit pas encore assez développés.
De fait Apple a conservé Objective C pour réaliser Mac OS X.
Mais si ce langage a évolué, les concept de programmation aussi, les systèmes informatiques encore plus et l'approche OO et fonctionnelle sont nécéssaires…

avatar Rez2a | 

@Lio70 :
Je sais pas si tu es un dev Obj-C complètement fermé au fait d'utiliser un autre langage ou juste un mec qui n'y connaît rien, mais rien que la comparaison Swift/Windev me fait fortement espérer que tu n'es pas développeur de profession.

avatar Lio70 | 

@alderaan, C1rc3@0rc, Rez2a

Oui, professionnel depuis 20 ans. Et en ayant travaille sur Windows, OSX, Linux, HP-UX, Solaris et VAX/VMS, il y a pas mal d'outils de developpement qui me sont passes dans les mains, du simple langage de scripting au langage de programmation muscle. Je me suis meme fourvoye, a une epoque, dans Pascal/Delphi sous pretexte que c'etait bon et sympa, pour finir par realiser que je perdais mon temps et que l'on perd toujours son temps en sortant des fondamentaux. Idem pour des collegues qui se fourvoyaient avec Clipper.

Je ne suis pas ferme a l'innovation, mais a tout debat technique correspond un debat que je qualifierai de philosophique. Pourquoi inventer une technologie? Pourquoi innover? Quelles sont les considerations techniques, culturelles et commerciales qui orientent le choix d'adoption de telle ou telle technologie? Pourquoi adopter un truc nouveau qui fonctionne a moitie lorsqu'un truc ancien qui fonctionne tres bien est disponible? (je ne vise pas Swift ici, je parle en general, ca s'est vu souvent).

Pour argumenter serieusement, je devrais disserter pendant de nombreuses pages sur l'evolution des langages et, surtout, de ce qu'on en fait, pourquoi et comment. Les reactions aux News ne sont pas l'endroit ideal, et de toute maniere je n'ai pas le temps. Je ne repondrai donc pas davantage. Chacun est libre d'avoir son appreciation.

avatar BeePotato | 

@ Armaniac :
Concernant les crochets en Objective C, je suis d’accord avec Lio70 sur ce point : ils permettent une bonne lisibilité du code.
On a un peu perdu à ce niveau en passant à Swift et son usage des parenthèses qui viennent couper la lecture des noms de méthodes (on peut s’en rendre compte en voyant les discussions autour de l’étiquetage ou non du premier argument des méthodes en Swift). Dommage, ce langage ayant d’autres qualités par ailleurs.

avatar byte_order | 

c'est dommage que dans l'image d'illustration de cet article, le langage affiché n'est pas du Swift mais du CMake...
:-)

CONNEXION UTILISATEUR