Federighi : « Swift sera entièrement développé au grand jour sur GitHub »
Swift s'ouvre, Craig Federighi aussi. Le Senior Vice President en charge de l'ingénierie logicielle a répondu aux questions d'Ars Technica et The Next Web sur le passage en open source du nouveau langage de programmation d'Apple.
Pourquoi rendre Swift open source ?
Si l'entreprise californienne a décidé de placer sa création sous licence Apache 2.0 (la même que celle utilisée par Microsoft pour une large partie de son framework .NET), c'est parce qu'elle croit dur comme fer qu'il s'agit du langage de programmation majeur pour les 20 prochaines années.
Selon Craig Federighi, il y avait une forte demande des développeurs, y compris de ceux de grosses compagnies comme IBM, pour réaliser toutes sortes d'applications en Swift. « Nous avons pensé que le meilleur moyen de rendre cela possible était au bout du compte le passage en open source. »
Le dirigeant justifie également cette ouverture peu commune chez Apple par la volonté de faire de Swift un langage largement enseigné :
Nous travaillons avec beaucoup de professeurs qui sont très intéressés par Swift parce que c'est un langage expressif qui permet d'introduire toutes sortes de concepts de programmation. Le rendre open source permet à ces professeurs de vraiment l'intégrer dans le cœur de leur programme scolaire.
Craig Federighi présente aussi cette ouverture comme une suite logique du développement de Swift 2. Il explique que bon nombre de changements apportés par cette mise à jour sortie en juin dernier ont été guidés par les retours des développeurs. Libérer Swift va permettre « d'approfondir considérablement cette interaction » avec les développeurs, estime-t-il.
Comment sera géré le projet ?
Et pour montrer que ce ne sont pas des paroles en l'air, il souligne que « l'équipe Swift va entièrement faire évoluer le langage au grand jour sur GitHub. Les modifications vont apparaître quotidiennement, y compris pour Swift 3.0. »
Plutôt qu'avoir à digérer une grosse mise à jour à la prochaine WWDC comme ce fut le cas avec Swift 2, les développeurs peuvent d'ores et déjà suivre les évolutions en temps réel sur GitHub.
L'une des nouveautés introduites aujourd'hui est le Swift Package Manager, un dépôt pour les modules Swift qui va progresser avec l'aide de la communauté. En plus de GitHub qui héberge le code, Apple a mis en place le site Swift.org qui sert de plateforme.
De nouveaux horizons
Apple a libéré dès le départ le compilateur pour Linux, qui permet donc d'écrire des applications en Swift pour Linux (seulement Ubuntu pour le moment). Et Windows ? Le responsable de l'ingénierie logicielle déclare que le système d'exploitation de Microsoft n'était pas une priorité pour le lancement, mais qu'il est très ouvert à l'idée d'une compatibilité avec celui-ci dans le futur. « Je pense qu'il est prévisible que quelqu'un dans la communauté, qu'il soit mené par Microsoft ou par d'autres, fasse ce portage. »
Il s'attend aussi à ce que la communauté pousse rapidement Swift dans les serveurs et l'utilise pour des applications de big data ou de machine learning, entre autres (lire : Perfect : du Swift « côté serveur »).
À plus court terme, Craig Federighi assure être conscient des lacunes de ce jeune langage, en particulier le problème de compatibilité ; la version actuelle de Xcode peut se retrouver dans l'incapacité de compiler du code Swift 1.x créé il y a moins d'un an. « Nous allons fournir des outils pour aider les développeurs à faire avancer leur code source », promet-il. L'un des objectifs de Swift 3.0 sera de faciliter ce cheminement de « vieux » code à travers le temps en évitant autant que possible la réécriture.
« Objective-C ne va pas disparaître »
Pour conclure, le dirigeant se veut rassurant sur Objective-C, qui « ne va pas disparaître », du moins pas tout de suite.
Nous aimons toujours le langage Objective-C. Nous sommes toujours très dépendants d'Objective-C et faisons encore une énorme part de notre travail avec lui ici à Apple. Nous allons continuer de le faire évoluer autant que nécessaire pour l'adapter à un monde en constante évolution.
Néanmoins, c'est bien Swift qui représente l'avenir. Craig Federighi « recommande » aux nouveaux développeurs et à ceux commençant de nouveaux projets d'adopter Swift. « Nous pensons que Swift est vraiment le bon point de départ. »
Trop sympas, les mecs!
C'est le Apple qu'on préfère. Modernes et assez ouverts pour faire évoluer les choses dans le bon sens.
Est-ce que Swift sans Metal est aussi puissant? Je sais qu'un est un langage et l'autre un API mais ne sont-ils pas liés?
@bonnepoire :
Pas grand chose à voir. Métal est là pour fournir un accès plus bas niveau afin d'accélérer les tâches graphiques. Swift est comme tu le dis un langage de programmation, il existe complètement indépendamment de Métal et l'inverse est également vraie.
Ce n'est pas le sens de ma question. Je reformule: est-ce que swift exploite ou optimise Metal d'une façon ou d'une autre? Je sais que Metal est bas niveau
@bonnepoire :
Non.
Pour une fois ils ne font pas les choses à moitié!
On voit qu'ils veulent vraiment donner toutes ses chances à Swift pour être un langage majeur.
Et un des développeurs du "packages manager" a été embauché par Apple parce qu'il travaillait sur Homebrew : de bonnes choses en perspectives! :)
Je ne savais pas que Swift faisait du Métal, je croyais qu'elle faisait de la soupe-pop-music qui saoûle.
--> []
Un non-développeur peut-il s'essayer à Swift (plus par curiosité que pour en faire son métier), ou bien est-ce dans tous les cas complexe à appréhender ? Des ressources à conseiller ?
Merci
@instantcook :
Si tu n'as vraiment aucune connaissance en prog Swift n'est finalement pas un mauvais point de départ. La doc est bien faite et le eBook d'Apple t'en apprendra beaucoup.
Après attend toi à devoir intégrer beaucoup de notions parfois complexes, quelque soit le langage tu n'y couperas pas !
En tout cas Swift est vraiment super agréable à utiliser.
@instantcook :
Un développeur a été un non-développeur à un moment hein :)
Tu peux trouver des cours sur internet et il y a des ressources et un tutoriel sur le site d'Apple. Sur macg ils ont aussi parlé de plusieurs tuto. Swift me semble assez facile à aborder pour quelqu'un qui n'a jamais touché au code donc ça devrait aller. Après tu auras des bases que tu pourras retrouver dans pas mal d'autres langages si tu veux :)
Si tu cherches un livre : iOS 9 Programming Fundamentals with Swift, de Matt Neuberg.
Bonne recommandation.
Matt Neuburg est un excellent pédagogue (et par ailleurs un chic type, super-sympa).
Mais à part TidBits, hard-core du Mac et de iOS depuis des lustres, si on regarde du côté des éditeurs comme O'Reilly, Packtpub, Manning, NoStarchPress etc., on se rend compte que le marché des livres sur Swift vient d'exploser ces derniers mois, et de façon exponentielle ces dernières semaines. Il y en a pour tous les niveaux, et pour toutes les approches (ou presque).
On sent monter la vague de fond Swift; ça ne fait que commencer.
@instantcook
oui. Et en particulier parce que Xcode intègre "playground"
Playground permet de taper du code swift et voir son résultat en temps réel.
Ce n'est pas fait pour écrire une app mais pour apprendre et comprendre ce que le code fait. Bon outil pour appréhender la programmation.
http://rshankar.com/xcode-6-and-playground/
https://developer.apple.com/xcode/
Franchement, Apple fait du bon boulot avec Swift. J'espère qu'ils vont tenir leurs promesses et que la communauté va suivre, notamment du côté universitaire. Swift me parait, toute proportion gardée, un concurrent crédible dans le milieu scientifique au redoutable Python.
Swift, concurrent de Python ?
Franchement, ça, j'y crois moins.
Les deux langages sont plutôt complémentaires.
Swift servira à écrire des apps, à programmer le système.
Python est plutôt un langage de script que de développement stand-alone.
Analyses dans PostgreSQL, dans PostGIS, dans MongoDB ? Python.
Script d'interface entre MySQL et R ? Python.
Langage pour une nouvelle app chez Affinity ? Swift. (Enfin, je parie.)
Client iOS ? Swift. Etc.
Et n'oublions pas qu'une bonne partie des programmes scientifiques en Python sont désormais exécutés dans un carnet de browser, comme c'est le cas pour Jupyter (cf. jupyter.org). À ce niveau, une bonne partie des capacités de Swift seraient gâchées, alors que pour Python, c'est idéal.
Entièrement d'accord ! Ils sont plus complémentaires que concurrents directs, c'est vrai, et au vue de la syntaxe de Swift, que je trouve jusqu'à présent assez similaire à celle de Python, cela peut s'avérer une complémentarité gagnante. Cela étant, toute proportion gardée, dans le monde de l'édition et de l'enseignement académique, Swift peut se transformer en un langage idéal pour apprendre l'informatique aux étudiants. Il me parait beaucoup plus simple que C et Objective-C à maitriser, et beaucoup moins indigeste — ce qui n'est pas peu dire, concernant Objective-C, que j'ai toujours trouvé très lourd, raison pour laquelle j'ai renoncé. Au niveau des usages, bien sûr chaque langage répond à des besoins particuliers (quoique je pourrais très bien traiter mes données avec C++). Il n'empêche que Swift est beaucoup plus rapide que Python, c'est une évidence, pas besoin de s'appeler Apple pour le dire : Python est un interpreted language, il est de fait plus lent que Swift. Pour un programmeur amateur dans mon genre qui ne maitrise que Python et R, Swift peut devenir une petite révolution. Je lis la doc Apple, et je constate à mon grand bonheur qu'il n'y a pas « tant » de différences que ça entre Python et Swift, du moins au niveau de la syntax, ce qui permettrait à des amateurs dans mon genre de « level up » sans trop de résistance, et de développer des applications standalone qui pourraient répondre à des besoins plus spécifiques et plus ambitieux. Je considère de plus en plus que tous les étudiants universitaires, peu importe leur cursus, devraient apprendre à coder et en ce sens Swift peut être un concurrent sérieux à Python au moins sur le plan pédagogique.
Ah ils les sentent bien partir les développeurs hein, fallait bien une carotte paour les motiver à rester…
Va falloir retirer le bras après le doigt, et ensuite on verra pour les épaules et le bassin…
Gros pari pour la pomme, maintenant, il ne reste plus qu'à attendre le patch qui va corriger El Capitroll, parce que Swift ou pas, si le support est une bouse sans nom… bref.
Ils se bougent enfin le fondement et je ne vais pas cracher dans la soupe, mais il va vraiment en falloir plus pour remonter la pente, on est loin de la technique, maintenant c'est une image qu'Apple doit se reconstruire… muarff !
@MaamuT :
En moins vulgaire cela donne quoi ?
Rien à voir. Aucune pertinence et aucune intelligence. Tu es le trou noir de l'intellect.
Oui jeune Padawan, c’est ce que me disent les lecteurs de MacG depuis 15 ans, mais je te parle de choses que les moins de 6 mois ne peuvent pas connaître…
Je me fous que ce soit du Swift ou du C++, ce que je vois c’est que le monde du dev Apple grogne depuis quelque temps, et que ce passage est un peu comme qui dirait un aveu d’impuissance, là où ils sont, ils ont besoin d’aide pour aller plus loin.
Que fera tu avec une application Swift fulll codded si le résolveur DNS de ton ordi n’est pas foutu de trouver le serveur sur lequel se trouve son contenu ?
Pourquoi de grands éditeurs fuient le sandbox ?
Depuis Lion, Apple engrange les effets de bords et utiliser un Mac en dehors des clous Apple est aujourd’hui une galère sans nom, et les devs ont des machines qui sont très loin des clous Apple.
Vous voyez les choses en imaginant les superbes résultats que l’on obtiendra bientôt grâce à ce super langage open source… et moi aussi j’imagine des choses magnifiques aussi, mais après, j’essaye aussi de les imaginer fonctionner sur les Macs d’aujourd’hui… et ça, c’est une toute autre affaire, entre la théorie est la pratique, le chemin est spécial avec Apple.
Grâce à Swift, je vais mettre seulement une semaine à développer un truc, là où je mettais deux semaines avec C++, cool, c’est une semaine de moins sur les 2 mois et demi que prend de toute manière la validation par le Store…
Avoir un environnement propice à la productivité et mettre au bout de la chaîne un goulot d’étranglement monstrueux.
En réponse, ils améliorent encore l’environnement, et toujours rien pour le goulot, triste.
Ce passage à l’open source est pour moi une très bonne chose c’est un fait, mais il va falloir surveiller tout ça, ce n’est pas la première fois qu’un tel projet est annoncé, pour être remis en questions quelques semaines plus tard.
En tout cas, cela peut aussi ramener Apple aux bonnes vieilles pratiques qu’elle connaît très bien pour en avoir abusé au bon temps.
Je n'ai rien compris. Le peu que j'ai réussi à suivre mélange langage, client pour serveur de nom, qualité d'un OS, procédure de distribution de logiciel.
C'est très confus.
Ou très con. Le fus est inutile.
Tu as l'air de sous-entendre que développer en Swift impose de devoir publier sur le Mac App Store, alors que ce qu'Apple annonce c'est (entre autre) qu'on pourra écrire en Swift sur Linux pour développer des logiciels pour Linux (et d'autres).
Il y a une grosse différence entre quelques éditeurs qui sortent du Mac App Store et la volonté de développer pour OS X.
Ça serait sympa de ne pas tout mélanger.
Tu as l'air de sous-entendre que développer en Swift impose de devoir publier sur le Mac App Store, alors que ce qu'Apple annonce c'est (entre autre) qu'on pourra écrire en Swift sur Linux pour développer des logiciels pour Linux (et d'autres).
Justement. C'est pour ça que son intervention est inutile et creuse. Limite aberrante.
Tu soulève LE point, Swift devrait être l'ouverture…
Ce sera la bonne réponse à bien des problèmes rencontrés par le dev Apple depuis un bon moment, et c'est une très bonne chose.
En temps que dev, j'en suis le premier ravis, mais, pourquoi continuer à dev sur la plate-forme Apple, puisqu'ils vont s'ouvrir aux autres ?
N'oublions pas que dans tout ça, les plus gros soucis relevés par les devs et concernant le monde du Mac, ne sont toujours pas au menu de la pomme.
Je suis mitigé, ravis d'avoir un bon outil à dispo, mais dégoûté de voir que le Mac est décidément loin des préoccupations d'Apple.
Oui Apple s'ouvre, et oui le Mac meure petit à petit et cette ouverture n'annonce rien quant à la direction prise par Apple…
Bref…
Les grandes phrases ne font pas avancer les choses.
C'est quoi pour toi "les problèmes rencontrés par les dev Apple" ?
"mais, pourquoi continuer à dev sur la plate-forme Apple, puisqu'ils vont s'ouvrir aux autres ?"
Si tu te pose cette question c'est qu'en effet, tu devrais envisager de faire autre chose...
Si je me pose ces questions, c’est que j’utilise l’environnement de dev d’Apple depuis de nombreuses années sur mes Macs, et qu’avec le temps, c’est de plus en plus compliqué.
Encore une fois, je parle du Mac, aujourd’hui, développer pour Mac est effectivement une question que beaucoup de dev se posent, tant la pertinence du sujet est devenue de moins en moins flagrante.
Demande à Twitter pourquoi l’entreprise a basculé l’ensemble de ses outils de devs sur du Linux ?
Mais avant, demande à Tim Cook, parfaitement informé du petit bug du DiscoverID, pourquoi il a mis deux ans pour ne rien faire, pour finalement remettre DnsResponder, juste après le départ de Twitter.
Pour vous c’est du détail, pour un dev c'est juste une hérésie.
Je bosse la moitié du temps sur le terminal en ssh sur mes serveurs, et l’autre sur du code html/php, et pour le moment, mon Mac répond encore, mais pour combien de temps ?
Le bug du resolver DNS m’a juste cassé les cahuêtes pendant des années, à grand coup de patchs dans le Bind pour qu’il recomprenne ce qu’il comprenait jusque là parfaitement… tout en renvoyant les requêtes incomprises à Google… :o
Aujourd’hui, grâce aux outils Apple et Swift, je vais pouvoir très facilement faire du dev vers presque toutes les autres plates-formes, par contre, pour OS X ou IOS, c’est toujours la même horreur et rien n’est annoncé en ce sens, qui saurait améliorer les choses.
Tu va concenter ton dev sur des trucs que tu pourras vendre, et avec le Mac, tu ne sais pas si ton produit va pouvoir vraiment utiliser toutes ses fonctions ou s’il ne sera pas refusé sans raison, sauf en contournant les protections (sandbox) ou en ne passant pas par l’App Store.
D’un côté, il est de plus en plus facile d’exporter vers la concurrence, de l’autre, de plus en plus compliqué de bosser sur les produits de la maison…
Donc oui, pourquoi continuer à faire du dev pour Apple, à part pour le plaisir d’avoir un Mac comme machine hôte ?
@ MaamuT : « demande à Tim Cook, parfaitement informé du petit bug du DiscoverID, pourquoi il a mis deux ans pour ne rien faire, pour finalement remettre DnsResponder »
Tu parles bien de discoveryd (et non « DiscoverID »), le truc qui est apparu dans la version 10.10.0 de Mac OS et en a été retiré avec la version 10.10.4 quelques mois plus tard ?
‘tain, le temps passe de plus en plus vite ! De nos jours, « deux ans » ne durent plus que huit mois ! :-P
« Donc oui, pourquoi continuer à faire du dev pour Apple, à part pour le plaisir d’avoir un Mac comme machine hôte ? »
Pour certains (dont moi), ce serait déjà une raison suffisante.
Mais pour ce qui est de développer pour d’autres OS, rappelons que ce n’est que Swift qu’Apple a rendu open-source. Pas Cocoa.
Du coup, dès qu’on se retrouve à faire du développement visant l’interface graphique, on se rappelle vite pourquoi on préfère continuer à cibler Mac OS (voire iOS). ;-)
@BeePotato :
Il a traîné dans Mavericks il me semble.
Et un an avant encore sur iPhone OS
@ Link1993 : « Il a traîné dans Mavericks il me semble. Et un an avant encore sur iPhone OS »
Non, il n’était pas utilisé dans Mavericks. Et si je ne m’abuse, côté iOS, il n’a été présent que dans iOS 8 (en parallèle de Yosemite, donc).
Ce projet open-source a autant d'avenir que Darwin, autrement dit, aucun.
C’est malheureusement à cela que je pensais aussi…
Ou pas…
Sur le papier, le truc est quand même déposé sur GitHub, ils se mettent en position de « forkable »… donc, le projet pourrait éventuellement continuer sans Apple.
Avec Darwin, il y’avait eu l’annonce, puis la grande déception en voyant le dépôt réel, ici, ce sera un .git
Je ne sais pas, je reste mitigé quand même, en tout cas, toujours rien de bien concret en faveur du Mac, ça c’est sûr, et inquiétant je trouve, aussi.
@MaamuT :
Sauf erreur de ma part, pour Darwin, ils travaillent de leur côté, et une fois que l'OS est livré, ils publient leur travail de l'année passée sur le dépôt ouvert… bref, il faut voir sur le long terme, mais là l'approche ne m'a pas l'air d'être du tout la même.
La participation d’Apple sur Darwin se limite au noyau Mach, basta.
Tout le reste vient de la communauté qu’Apple n’a jamais promue.
Au final, ça reste un joujou à base de BSD.
Swift a des ambitions bien plus grandes, un potentiel bien plus ouvert et sera déposé sur GitHub…
Deux approches effectivement différentes, pour deux produits très différents aussi, le deuxième pouvant parfaitement produire le premier ;)
Espérons juste qu’Apple gère les choses différemment pour cette fois.
En fait tu mélanges tout. Tes arguments ne défendent en rien tes positions. Tu gesticules pour pas grand chose au final.
Je t’en prie, c’est toujours un plaisir, mais même si je sais rester humble devant la flatterie, celle-ci ne te mènera à rien…
@Eurylaime :
Merci d'avoir consulté ta boule de cristal pour nous.
... développé au grand jour, il n'y a t'il pas un risque de voile ?
J'aime programmer pour programmer par pour que l'on me mâche le plaisir..
le bas niveau reste toujours plus motivant intellectuellement.
çà c'est perso...
Malin, comme ça Apple réduit ses coût de développement en peaufinant son image.
Ensuite une fois bien optimisé, ils sortiront leur version made in Apple qui elle sera entièrement fermée pour cause de sécurité.
Je ne suis pas sur que ce soit une bonne chose.
Swift est déjà très peu utiliser dans son propre écosystèmes, je ne suis pas sur que son ouverture améliorera son adoption.
Le seul moyen à mon sens dans un premier temps, sera de ne plus accepter d'application en Objective C sur ses stores. Mais bon pas dans l'immédiat car Swift n'a pas encore les capacités à remplacer Objective C.
Ensuite c'est quand même d'introduire un compilateur Windows... Bien que ce ne soit pas la plateforme de prédilections pour des applications, c'est quand même possible d'atteindre un très grand nombre de gens. Surtout quand le compilateur linux se limite à Ubuntu.
@ k43l : Swift est déjà, je trouve, étonnamment utilisé vu son âge.
Quant au but de cette ouverture, c’est bien d’augmenter son adoption, mais par forcément comme langage de développement d’applications à interface graphique (d’où, sans doute, l’absence de ciblage de Windows pour l’instant). Il semble plutôt que l’idée, en le rendant disponible sur Linux, soit de pousser le développement d’un paquet de bibliothèques diverses et variées, utilisées dans des logiciels serveurs mais aussi d’autres logiciels en ligne de commande (très fréquents dans le monde de la recherche scientifique), et dont certaines (voire beaucoup) pourront ensuite être réutilisées dans des applications pour Mac OS et iOS.
Évidemment, si le succès est au rendez-vous, on peut imaginer que certains s’empareront de ce langage pour le développement d’applications grand public, sans doute en y adaptant un framework multi-plateformes dédié aux interfaces graphiques. Et ça, ça peut finir par représenter un risque pour le développement en Cocoa, mais pour l’instant on en est loin et Apple semble préférer ce risque à celui de voir son langage rester peu connu, dans son petit coin.
Pour ce qui est d’interdire les applications développées en Objective C… ce serait contre-productif, mais surtout peu logique quand on voit que sont acceptées des applications développées avec un tas d’autres langages et frameworks.
Un truc qui est intéressant et agréablement surprenant, c’est qu’en plus du compilateur et de la bibliothèque standard de Swift, Apple fournit également une version open-source de Foundation.
C’est bien pratique.
Et dommage pour les divers projets « Pure Swift » qu’on a pu voir fleurir ces derniers mois et qui mettaient en avant le fait de ne pas dépendre de Foundation… :-)
Avec les Playgounds Swift cité par @oomu :
on pourrait vouloir retrouver pour Swift un terrain de jeux étendu sans «Playground Limitations :
cannot be used for performance testing.
Does not support User Interaction.
Does not support On-device execution.
Cannot use your app or framework code.
Does not support custom entitlements.»
En comparaison de Python dans Jupyter Notebook comme le précise @occam :
on a déjà tout ce qu'il faut pensé pour des démarches scientifiques épaulées par Python
Ceci dit dans les deux cas, rien n'empêchera d'essayer de bien comprendre les capacités qu'a un langage de permettre de bien formuler un problème … donc dans Swift, une bonne par devrait intégrer la capacité d'être un bon "langage auteur" (en référence aux logiciels auteurs … Director, Flash notamment ) m'est avis
Hahaha.
Croire qu'Apple fait un cadeau est aussi naïf que de penser qu'ils versent dans le philanthropisme...
L'open sourcing n'a qu'un seul but : profiter du savoir de centaines de developpeurs sans avoir à les payer et pernicieusement pousser leur technologie sur le devant de la scène tout en conservant les clefs de la barraque.
La véritable avancée aurait été de mettre ce code sous GPL ou MIT.
Mais la tendance est de suivre le troupeau et de dire du bien sans réfléchir.
@dway :
S'ils ne l'avaient pas rendu open-source, tu serais là à nous expliquer pourquoi Apple c'est le mal et pourquoi il ne faut pas utiliser une technologie propriétaire. Un troll reste un troll.
Ca pique hein ?
C'est un troll pour ceux qui n'admettent pas de voir cette réalité...
Et désolé, mais si Apple ne se pavanait pas et avait gardé le langage non open source, j'aurais rien dit. Là c'est du green washing appliqué au code.
@dway :
Ah... et le fait qu'Apple garde les clés de la baraque, ça s'appelle le "stewarding". Tous les langages open-source font de même pour éviter l'anarchie et que le projet parte dans tous les sens.
Ah pardon, je croyais que ca s'appelait le "ferme les yeux et souris, ça fait pas mal".
J'ai dû rater le train du bétail.
C'est fou comme le fait de soutenir des projets avilissants est à la mode. On croirait à une lobotomisation collective parce que "c'est trop pas hipster" de nager à contre courant.
Bref. De toutes facons quand on est pas raccord avec l'avis dominant de ces commentaires on se fait taxer de troll... Tellement petit.
@dway :
Intéressant. Alors, selon toi, qui devrait avoir le droit d'approuver les pull requests si pas Apple ? Quel autre projet open-source, de Linux à Python en passant par les petites merdes de 3 lignes de code trouvées sur Github a donné les droits de modifications du projet à d'autres que ses auteurs et les gens choisis par les auteurs ? Et pour finir, si à ton sens, il aurait mieux valu qu'Apple garde le langage fermé sans rien publier, pourquoi et qu'est-ce que cela aurait apporté de mieux ?
Réponds à ces 3 questions (j'en doute) et tu te rendras compte de l'énormité des bêtises que tu racontes.
Pages