Apple développerait-elle un nouveau langage ?

Anthony Nelzin-Santos |
Jesper de Waffle en est sûr : Apple prépare un nouveau langage de programmation, conçu pour dépasser Objective-C. « Après avoir vu les vidéos […] de la WWDC 2010 […] je crois qu'Apple travaille à un nouveau langage pour dépasser Objective-C », écrit-il.

Objective-C a été constamment amélioré ces dernières années, mais il doit porter l'héritage du code produit au fil du temps, et du fait qu'il est une extension du C. Si Apple veut donc aller plus loin, elle se doit de redéfinir un langage.

Elle possède l'expérience de technologies pointues lui permettant de créer un langage moderne, notamment LLVM/Clang. Elle pourrait développer un langage suffisamment bas-niveau pour être aussi performant que l'Objective-C ou le C, tout en en profitant pour définir une nouvelle syntaxe.

Voilà qui permettrait aussi de forcer les développeurs à prendre de nouvelles habitudes, notamment en termes de gestion de la mémoire, où deux écoles s'affrontent, entre ceux qui préfèrent gérer la mémoire manuellement, et ceux qui se reposent entièrement sur le garbage collector. Le passage progressif au parallélisme comble le principal défaut du garbage collector, son impact sur les performances, mais l'utilisation de ce dernier pose toujours des questions sur un OS comme iOS, où le garbage collector ne fait pas assez dans le détail.

Apple pourrait bien forcer la main aux développeurs sur ce point précis, mais d'ailleurs sur l'adoption de ce nouveau langage aussi : si l'Objective-C pourrait rester dans les parages pendant un temps, il suffit de faire de ce nouveau langage le langage par défaut d'iOS pour que près de 50.000 développeurs y passent, pour ne pas descendre du TGV App Store.

Sur le même sujet :
- En route vers Mac OS XI ?
Tags
avatar NicolasO | 
@marc_os: Cette histore de pointeur c'est pas un peu un argument contre Objective-C? Il faudrait pas sortir un peu du mode de pensee C? 99% des progammes n'ont pas besoin de pointeurs mais de leur equivalent surs : references et tableaux. Les pointeurs sont sources de bug et de programme dont on ne sait pas ce qu'ils font. En echange de (rares et petites) ameliorations de performances. ((int *) p ++) -- == p ?
avatar marc_os | 
Cette collègue m'a montré qu'elle pouvait très bien programmer en Obj-C sans maîtriser les pointeurs. Enfin, dans certaines limites. Mais je sais, C et Unix c'est dépassé.... Si un informaticien professionnel n'est pas capable de comprendre et maîtriser ce qu'est un pointeur, qu'il change de métier, car je doute fortement de la qualité des logiciels qu'il peut produire. Mais bon, c'est sûr, quand on "apprend" quasiment exclusivement en faisant des recherches sur Google...
avatar NicolasO | 
Il y a savoir comprendre et maitriser un pointeur et devoir s'en servir au quotidien. Il est vrai qu'Objective-C protege contre beaucoup d'entre eux. Je pense que le pointeur, au meme titre que l'assembleur, appartient aux choses qu'un bon dev doit comprendre pour savoir comment son code va s'executer et qu'il doit etre capable, si necessaire, de savoir les manipuler. Ca ne doit pas constituer son quotidien. Il doit s'en tenir le plus possible eloigner. En l'occurence, le C fait une erreur conceptuelle enorme: melanger pointeur et tableau n'est pas une bonne idee. (Ce n'est pas la meme idee, meme s'ils sont implantes pareils.) Et une autre moins pire: associer le fait de ne pas passer par copie avec le fait d'utiliser un pointeur. Meme les references en C++ sont mieux que cela.
avatar lol51 | 
NicolasO > Ce n'est pas une erreur conceptuelle, c'est la simple traduction du language assembleur. Le C permet d'accéder à la mémoire, or un tableau n'est rien d'autre qu'une zone de mémoire, je ne vois pas ce qu'il y a de choquant là dedans. Une fois que l'on a bien compris le mécanisme sous-jacent (qu'est-ce que va donner ma ligne de code en assembleur ?), la syntaxe est très claire sans aucune ambiguité. Il en faut pas voir ça comme une contrainte mais comme une liberté d'écriture, c'est d'ailleurs cette liberté d'écriture qui en fait un langage considéré comme "puissant". Pour avoir eu des cours avec un enseignent chercheur mordu du C (et du C++) en cours d'imagerie numérique, je peux t'assurer que la "confusion" (même si je ne vois pas ça comme ça) en vaut la chandelle, car quand on arrive à jouer sur ces points là, on peut s'affranchir d'une quantité de code inutile qui feront augmenter de manière significative la performance d'une application. Alors après, évidemment programmer un logiciel de stock de patate en C est complètement inutile...
avatar NicolasO | 
@lol51: Je parle d'erreur conceptuel dans le cas general, car on n'a pas de manipuler l'assembleur a la main. Le C ne te fait pas pousser les arguments sur la pile lors d'un appel de fonction... Je suis bien d'accord que pour quelques applications (jeu, graphisme, noyau OS...) c'est bien d'etre a ce niveau de detail. C'est bien pour le C, du coup. Mais Objective-C langage de haut niveau se traine le C comme boulet. D'autre langage autorise a ecrire du C ou de l'assembleur quand on veut mais n'oblige pas a penser en terme de pointeur.
avatar marc_os | 
@ NicolasO : Mais pourquoi donc considères-tu le C comme un boulet ? En Obj-C, tu n'est pas obligé de vraiment comprendre les pointeurs, si c'est ça qui te chagrine. Tu peux même ne jamais les utiliser directement, et ne considérer comme usage que les cas où une API que tu utilises prend un pointeur en paramètre. Comme le fait cette ex-collègue qui avant l'Obj-C ne connaissait que l'AS. Qu'y a-t-il de difficile conceptuellement à se cantonner à la règle simple : Si une API veut qu'on lui passe un pointeur, et bien on lui en passe un ? (Ce qui revient à la vision du "passage par référence" de VB ou php). C'est si difficile que ça ? Qui peut le plus, peut le moins. Le moins décrit ci-dessus, cela n'empêchera pas ceux qui les maîtrisent d'utiliser les pointeurs à bon escient.
avatar dazz | 
ouais ben ce serait une bonne nouvelle :) il reste que ca finalement a Apple pour finir de "révolutioner" l'informatique, un langage 100% Apple, compatible a rien, nouvelle styntaxe moins abscon plus lisible. Steve jobs pourra alors prendre sa retraite, Apple aura tout changé :)
avatar Yohmi | 
Ce serait un coup de poker risqué, car beaucoup de nouveaux venus ne seront peut-être pas nécessairement enclins à apprendre un nouveau langage alors qu’ils viennent à peine de se mettre à l’Objective-C. Et Google (+ Adobe) en profiterait probablement pour faire sa pub en mettant en avant le fait que sur Android (ou Flash), vous n’avez pas à sans-cesse réapprendre un langage… Mais je suppose que c’est bien que ça évolue, ces langages sont si vieux, il doit y avoir des routines que l’on peut éviter maintenant… enfin je dis ça, je n’y connais rien du tout en code ^^
avatar eliotus | 
Ah un moment en lisant le titre j'ai cru que c'était une allusion a la lettre au sujet de l'iPhone 4 sans queue ni tête mais non ;-) Je sais où est la sortie merci ;-)
avatar hok | 
Ouai espérons que apple travaille dessus, car objC a une syntaxe peut commune qui rebute beaucoup de gens. Il faudrait une syntaxe genre C++/java/C# ou même du python ruby. Mais il faudrait que ce soit totalement compatible et melangeable avec objC. Il faudrait que ce soit haut niveau, dynamique et fonctionnel, et garbage collecté.
avatar Anonyme (non vérifié) | 
Avec tout le support qui existe aujourd'hui pour l'objective C, la progression se fera sur du long terme (si nouveau langage il y a). Tel que je l'imagine, si il y a un changement la valeur ajoutée sera de taille pour que le changement se fasse auprès des développeurs.
avatar Florent Morin | 
Avec l'apparition récente des blocks dans ObjC et la grande part du parallélisme, on peut s'attendre à un ObjC 3.0. De là à voir apparaître un nouveau langage... Le C reste incontournable depuis plus de 30 ans et a été la clé du succès d'Apple : pourquoi changeraient-ils ?
avatar Anabys | 
AppleScript 2 :D
avatar SuMyDi | 
Il existe un langage objet qui étend le C : le langage D (non, non ça n'est pas une blague). Sa syntaxe est proche du C++, il en garde certains aspects comme les templates (mais avec une syntaxe différente plus simple et plus claire), en enlève d'autres (héritages multiples, ...). En fait il a été conçu pour palier aux différents défauts du C++. Plus d'infos ici : [url]http://fr.wikipedia.org/wiki/D_(langage)[/url]. Peut-être Apple va-t-elle utilisé ce langage ? (adaptation rapide pour ceux venant du C, C++ voire de l'Obj-C).
avatar phoenix73 | 
Il serait malin de proposer un Java utilisant llvm, soit en natif soit par une étape de pré-compil, comme peut le faire GNU-java. Objectif C est un frein pour pas mal de monde à commencer par les régiments de Javaistes. Pourquoi réinventer la roue ?
avatar iBorg | 
Java : trop limité, trop multi-plateformes.
avatar Anonyme (non vérifié) | 
[quote] Il serait malin de proposer un Java utilisant llvm, soit en natif soit par une étape de pré-compil, comme peut le faire GNU-java. [/quote] Cette idée me plais bien, mais je ne sais pas si les développeurs actuel adhéreront... Je suis curieux de savoir ce que vous en pensez d'ailleurs pour ceux qui passent ici :)
avatar NicolasO | 
Des langages mieux que Objectove-C, il y en a des dizaines. La force de la plate-forme d'Apple, c'est cocoa qui, par sa qualite, comble beaucoup du retard du langage. Mais ca ne suffira pas a terme. Quelqu'un indiquait que son temps de dev etait 4 * inferieur sur Android que sur iPhone... Et encore, d'autres langages sont autorises sur Android, autorisant plus de productivite. Le probleme est de changer de langage sans changer de librairie. Par ailleurs, developper un langage de zero, c'est long et difficile. Surtout quand les plateformes concurrentes (Java, Dadvik, .Net) sont deja tres mures... Donc une etape necessaire, sur laquelle la pomme est en retard sur ces concurrents (Google a Davdik pour java et travaille sur Go, qui ressemble beaucoup a ce que voudrait Apple, MS a .Net qui a atteint un niveau acceptable). LLVM peut aider, mais c'est une vm tres bas niveau. Il reste beaucoup a faire autour.
avatar Ikari | 
@phoenix73 Objective C n'est pas un très bon frein si on considère le succès de l'AppStore ^^ Je trouve l'Objective-C beaucoup plus esthétique et clair que le C++ et le Java. (C'est un avis totalement arbitraire, certes ^^)
avatar kubernan | 
Un truc capable de nativement s'intégrer pour le Web. Ni plus, ni moins.
avatar Artanis | 
La syntaxe de l'Objective-C est un de ses avantages, c'est quelque chose qu'on ne peut comprendre qu'en le manipulant. C'est vraiment un des meilleurs langages objets que j'ai vu pour l'instant. Et paradoxalement, il est assez proche de Java dans l'esprit (une fois qu'on veut bien regarder au-delà de la syntaxe de l'envoi de messages). Beaucoup plus que du C++ en tout cas. Et la courbe d'apprentissage n'a _rien à voir_ avec le C++. Ça m'embêterait pas mal qu'un langage replace l'ObjC dans la case "langage par défaut" pour MacOS X. C'est déjà possible de faire du Java compilé par LLVM, si je ne m'abuse, grâce à Dragonegg. Visiblement certaines personnes font ça, puisque GCJ est encore développé...
avatar kissscoool | 
Le Java c'est sympa et facile (très utilisé dans les écoles d'informatique comme premier langage orienté-objet) mais il faut parfois taper beaucoup de code pour pas grand chose, même si c'est facile. Le multi-plateforme est un avantage mais amène parfois quelques surprises… Il y a des avantages indéniables qu'a le Java (annotations, génériques ("templates")) mais est parfois plus limité que l'Objective-C dans ce qu'on peut faire, et manque de choses telles que les categories (vraiment pratique), les properties. Java a aussi cet inconvénient d'imposer le garbage collector et aussi d'être fortement typé. Mais ce n'est pas un langage qui fait un bon programme...
avatar 6ix | 
Plutôt que Java, quitte à changer de langage, le top serait alors de jeter un oeil à Scala ! Histoire d'avoir un langage récent, multi-paradigme (objet + fonctionnel), élégant, puissant, etc… Et comme il est d'ailleurs dit dans un commentaire de l'article de Jesper, Martin Odersky (l'homme à la base de Scala) ne serait apparemment pas contre le fait qu'Apple fasse en sorte que LLVM supporte Scala =)
avatar shenmue | 
@NicolasO:"Donc une etape necessaire, sur laquelle la pomme est en retard sur ces concurrents" Mais qu'est ce que tu racontes encore ? Tu connais xcode au moins ? Franchement j'en doute avec tes réflexions à la con. Avec toi, Apple ils sont toujours à la traine et quand ils sont devant, ça compte pas. C'est d'un lourd..
avatar Artanis | 
@ 6ix: LLVM est libre, hein? En plus les specs pour écrire un front-end sont disponibles et ont l'air relativement accessible. C'est pas le boulot d'Apple de faire en sorte que LLVM supporte langage. Ils le feront que s'ils y ont vraiment intérêt. Sinon Java c'est bien, ouais. C'est idéal pour certaines choses, ça l'est moins pour d'autres. Le fait que ObjC soit un sur-ensemble du C permet pas mal de choses, y compris une compatibilité quasi parfaite entre C, C++ et ObjC. L'autre point, c'est que l'ObjC sur Mac repose entièrement sur Cocoa. Il y a déjà d'autres langages qui permettent d'utiliser Cocoa (Python et Ruby au moins, de mémoire, en plus du défunt Cocoa-Java). Rien n'empêche un développeur (ou même Apple) d'écrire un bridge, là encore, c'est largement facilité par l'intéropérabilité avec C.
avatar Hindifarai | 
:) marrant ce fil de discussion. Associer le fort typage d'un langage à un défaut...première fois que je lis ça. Les deux survivants du GoF doivent en avoir les poils qui hérissent (pour avoir manger avec eux non ça les aurait fait exploser de rire en fait). Pour la personne qui a écrit que LLVM était une vm orientée bas niveau je la remercie c'était hilarant. Après chacun a ses features préférées dans tel ou tel langage, c'est une discussion sans fin. Un nouveau langage? Mouais pourquoi pas, reste à voir pour quelle cible et avec quels fondamentaux. Itératif? Fonctionnel? Objets? Composants? Aspects? Compilé? interpreté? bytecodé? Du moment que les absurdités telles que l'héritage multiple ne sont pas présents...
avatar makidoko | 
[quote]Elle pourrait développer un langage suffisamment bas-niveau pour être aussi performant que l'Objective-C ou le C, [b]tout en en profitant pour définir une nouvelle syntaxe.[/b][/quote] Non, ça suffit les conneries maintenant! Déjà à l'heure actuelle, l'Objective C a prétendu simplifier la syntaxe avec, pour le plus exaspérant, des encapsulations interminables et imbitables de crochets, qui comble pour un langage Cupertino-Cupertinien, sur un clavier Apple (tout du moins AZERTY) nécessitent pas moins de 3 doigts pour être produits. Donc malgré une intention louable au début (approcher le langage naturel), ce langage, en voulant se démarquer des autres tout en s'en inspirant et en sur-multipliant les signes cabalistiques, au final ne ressemble à rien.
avatar Artanis | 
J'ai du mal à voir /pourquoi/ Apple aurait intérêt/envie de se lancer là-dedans... Ce n'est pas parce que c'est possible que c'est intéressant. L'abstraction de la LLVM est déjà amplement justifiée par la portabilité x86/ARM... Je ne pense pas qu'Apple ait envie d'un langage de bas niveau. C'est contraire à quasiment tout ce qu'ils ont fait avec leurs outils de développement. Ça serait plutôt le contraire, ils poussent à utiliser l'infrastructure proposée par le système et les bibliothèques. D'autant que j'ai du mal à voir quel avantage on aurait à faire plus bas niveau que du C (qui est donc un sous-ensemble de l'ObjC). A mon avis ça manque aussi d'argument sur ce qu'Apple (et les développeurs) auraient à y gagner. L'ObjC 2.0 et les blocs arrivés avec GrandCentral Dispatch montrent que l'évolution est possible à l'intérieur du langage. J'aimerais avoir une liste claire de ce qu'on ne pourrait pas faire actuellement à cause du langage, et qui justifierait un changement complet, plutôt qu'une évolution de ce qui existe (quelque chose d'un peu plus consistant que l'abandon des @ dans les mots-clefs)...
avatar NicolasO | 
@hindifirai: C'est bien de rire, mais vm bas niveau, c'est comme le port salut, c'est ecrit dessus. Low Level Virtual Machine. Apres les premieres reactions, il me semblait important de rappeeler que cela n'etait pas comparable a la jvm ou a clr.
avatar pvmstg | 
Discussion un peu obscure. On parle du mérite ou pas de changer. Apple veut aller dans une direction qui vise à obliger le développement osX ou ios afin de garantir le maximum l'expérience mac et éviter les portages plus ou moins optimaux genre qt etc.. Donc en développant un langage propre... il aurait toute latitude. Avant impossible. Maintenant, avec la force du store et du mobile... il peut tenter d'en imposer
avatar Eurylaime | 
Le gars a du prendre un bon produit bien hallucinogène dès le matin oO
avatar Lonesome Boy | 
Bizarre cette mode de taper sur Objective-C… C'est un des (le?) langage les plus élégant et les plus puissant que je connaisse: sa "dynamicité", le mécanisme d'envoi de message (par opposition aux appels de méthodes), de forwarding, de délégation, les catégories, etc. sont hyper bien conçus. Le fait que ce soit un sur-ensemble du C est un avantage important, cela permet de réutiliser l'existant, notamment les fonctions et librairies optimisées dans tous les coins depuis des dizaines d'années. Après, c'est vrai que la syntaxe en elle-même peut-être déroutante, mais pour un "vrai" développeur cela a relativement peu d'importance, les concepts en ayant beaucoup plus. Au reste, je trouve la syntaxe élégante, hormis certaines lourdeurs pour certains types d'opérations. Mais il est vrai qu'il manque certaines choses à l'Obj-C. Par exemple, je pense qu'avec un langage moderne, le développeur ne devrait plus se soucier de la gestion de la mémoire. Le GC ne fait pas tout, d'autant qu'il n'est pas compatible avec toutes les versions d'OS X. Le fait de devoir faire des alloc/init est syntaxiquement lourd. La possibilité de surcharger les opérateurs serait un plus, au moins pour les chaînes de caractères. La gestion des assertions et la programmation par contrat directement intégrées au langage serait aussi un plus appréciable. Alors, un successeur à Objective-C, pourquoi pas, surtout avec l'expérience d'Apple en la matière. Mais il faudrait repartir d'une feuille blanche. Et la réécriture de tout le système, de tout Cocoa, serait un travail de titans. Cocoa est plus vieux qu'OS X, puisqu'il nous vient de NextStep, ne l'oublions pas.
avatar Macleone | 
Comment je suis mort de rire. Apple possède les outils nécessaire: clang… Sauf que clang est un compilateur orienté C/C++/Obj-C et qu'il ne sait faire que ça, et qu'il n'est absolument pas conçu pour compiler une autre langage. Quand à l'Obj-C, que quelqu'un donne un seul vrai argument expliquant pourquoi il faut le remplacer, et après on verra…
avatar Artanis | 
@ Lonesome Boy: de toute façon, la gestion automatique de la mémoire ne serait pas supportée sur les version pré-Leopard, tout simplement parce que ça dépend du runtime qui ne sera pas mis à jour. Le ramasse-miettes sera utilisé par défaut pour MacOS X progressivement. Cela dit, l'argument est valable pour iOS, mais je pense que le ramasse-miettes arrivera là aussi dans un avenir assez proche. Ça me semble infiniment plus probable que changer de langage par défaut. La surcharge d'opérateurs pourrait être un plus, si c'est fait correctement. Mais ça ne justifie toujours pas un nouveau langage. Ça ne nécessiterait même pas forcément de modification du runtime.
avatar Macleone | 
@ Lonesome Boy: [quote]Le fait de devoir faire des alloc/init est syntaxiquement lourd.[/quote] Oui, mais d'un autre côté, le fait de ne pas avoir de constructeur, mais une méthode -init apporte tellement de liberté que j'ai énormément de mal à m'en passer dans les autres langages. Sans cette souplesse, impossible de faire des class cluster, de faire un cache d'objet transparent (avec substitution de l'objet initialisé par un objet en cache dans init comme le fait NSNumber), etc…
avatar R1x_Fr1x | 
si Apple fournit un SDK assez puissant pour les developpeurs, je donne pas plus de 6 mois pour tous les convertir
avatar oomu | 
Apple changerait elle de langage 2 semaines après la conférence développeurs, à l'aube de la sortie de Xcode 4 première refonte majeure de interface builder (20 ans hein) et alors que LLVM/CLANG entièrement pensé pour révolutionner C et Objective C portent leur fruits , alors qu'Apple n'a jamais connu autant de développpeurs pour ses plateformes, que la WWDC a connu une affluence record et que tous les indicateurs sont au vert ? non.
avatar 6ix | 
[quote=Artanis]LLVM est libre, hein? En plus les specs pour écrire un front-end sont disponibles et ont l'air relativement accessible. C'est pas le boulot d'Apple de faire en sorte que LLVM supporte langage. Ils le feront que s'ils y ont vraiment intérêt.[/quote] On est bien d'accord; pour plus de précision, Odersky ne faisait que répondre à une question sur le rapprochement entre LLVM et Scala, disant que son équipe était trop petite pour se lancer dans un tel projet, mais que si Apple était motivé il ne serait pas contre. J'en suis venu à parler de Scala car à de parler de Java, autant aller directement vers ce langage qui à mon sens offre de très bonnes possibilités, d'où ensuite le rapprochement avec LLVM. Cela dit je suis d'accord avec ton point de vue, je ne vois pas trop l'intérêt pour Apple d'aller dans cette direction (concernant Java, ce serait même une sorte de retour en arrière étant donné qu'Apple le supportait pour Cocoa jusqu'à peu).
avatar Lonesome Boy | 
Oui, c'est clair qu'avec tout ce qui a été fait récemment (ou moins récemment) pour Obj-C et Cocoa, je vois mal Apple mettre tout ça à la poubelle à court ou moyen terme…
avatar Lonesome Boy | 
@ Macleone Je suis bien d'accord pour le init, je pensais plutôt à une sorte de "fusion" de l'alloc et de l'init… Franchement, qui a déjà eu à faire un alloc sans faire un init juste après?
avatar gazobu | 
cette news ne fait que retranscrire l'avis de Waffle, je pense que si Apple devait donner un grand coup de pied dans la termitière ce ne serait pas pour remettre en question objC, le chantier serait titanesque, et au final sans grand intérêt (pour Apple), ce qui intéresse la pomme aujourd'hui ce sont les devs pour l'Appstore, aussi je les vois bien concocter un "iPercard" qui permettrait à tout un chacun de bidouiller son programme qui par essence serait dans les clous, et il suffirait à l'Appstore de ne surveiller QUE le contenu pour le mettre en ligne. allez Andy, relèves tes manches !
avatar gazobu | 
ooooops, le lapsus ! c'est à Bill Atkinson de relever ses manches, Andy Hertzfeld il est chez … Google.
avatar marc_os | 
N'importe quoi. Mais c'est quoi cette histoire que le "garbage collector" d'Objective C ne serait pas performant ? Evidemment, il faut en tant que développeur bien lire la doc et comprendre l'intérêt des [i]retain[/i] et [i]release[/i]. Qui s'est donné la peine de faire un effort de comprendre, verra au contraire que la gestion de la mémoire sous Ojbective-C est au contraire très efficace, et bien moins pénible qu'en C++. Pour résumer, le développeur libère pas la mémoire occupée par les objets lui-même. Au lieu de ça, il indique par exemple via les [i]retain[/i] que telle portion de code utilise tel objet, puis via les [i]release[/i] qu'il n'en a plus besoin. Et en fait, derrière ça, Objective-C maintient un compteur d'utilisation pour chaque objet créé. Et quand le compteur passe à zéro, il libère la mémoire associée à l'objet (le "détruit"). C'est très efficace, et libère en même temps le développeur de la question de savoir à quels endroits dans son code il va devoir détruire manuellement les objets. Bref, je suis très dubitatif devant l'idée qu'Apple développerait un nouveau langage. Au contraire, les évolutions d'Objective-C, dont il y a quelques années déjà le support complet de C+, me feraient plutôt penser le contraire. Edit : Il va falloir que je me mette à jour.... Je ne connaissais pas le système de garbage collecror introduit avec Objective-C 2.0. Ce que j'ai décrit plus, c'est l'ancien système de gestion de la mémoire. Y aurait-il des problèmes de performances maintenant ? Pourtant d'après la doc que je viens de lire, il me semblerait que les développeurs de chez Apple ont justement bien fait attention à ce point. Par exemple, le garbage collector tourne dans un thread dédié, avec un priorité basse afin justement d'impacter le moins possible les performances. Bref, en fait ce serait pour moi au contraire un argument contre l'idée d'un nouveau langage - pour remplacer Ojbective-C.
avatar Anonyme (non vérifié) | 
Voir [b] [http://www.macruby.org] [/b] et b] [http://macruby.labs.oreilly.com] [/b] Apple est déjà en train de développer un langage (MacRuby) : - qui permette au moins ce que permet [b]Objective C[/b], - basé sur un langage existant et moderne (et avec un fort potentiel) : [b]Ruby[/b], - basé sur [b]LLVM[/b] Apple fait rarement des choix au hasard : vous devriez jeter un oeil sur Ruby que les unixiens connaissent (plus ou moins) bien ! Macruby fait ce que fait Ruby (donc multiplateforme) + permet de programmer des applications native (donc spécifique Mac). C'est au développeur de choisir son compromis portabilité versus "nativité" (amen !) Par ailleurs, (sauf erreur de ma part : quelqu'un confirme ?) l'environnement de développement utilisé pour générer le javascript pour mobilme est en Ruby (classique) et inspiré de Ruby on Rails. Apple possède donc une certaine expériece de ce langage. Et je verrais bien le nouvel environnement xcode (iCode ?) bâti au-dessus de Ruby, ce qui permettrait d'avoir une version dégradé de xcode qui soit multiplateforme !! -- Maurice
avatar Thibaut-J | 
@Lonesome Boy Fusion du alloc / init ? Ne serait-ce pas le principe du "new" ? Sinon, je suis contre une telle fusion (donc contre le "new"). Avec un alloc / init, on sait ce qu'il se passe derrière. Une allocation mémoire puis une initialisation des variables. Il ne faut pas oublier également qu'il y a différents "init". initWithFrame, initWithContentOfFile, initWithCoder, initWithNib… @end
avatar Anonyme (non vérifié) | 
Ah, j'oubliais les transparents d'Olivier Gutknecht sur Macruby : [b]http://www.slideshare.net/olg/introduction-macruby[/b] --Maurice
avatar gazobu | 
@mdiam [i]"une version dégradé de xcode qui soit multiplateforme !!"[/i] pile poil contraire à la politique actuelle de Apple.
avatar MacGyver | 
bah ils utilisent aussi la langue de bois sur certains problemes materiels
avatar Artanis | 
Voilà un lien vers un article de Siracusa, en gros sur ce sujet (dans lequel il explique le contraire de ce que je pense, mais qui vaut quand même le temps d'être lu): http://arstechnica.com/apple/news/2010/06/copland-2010-revisited.ars Fait plutôt inhabituel, les commentaires sont presque plus intéressants que l'article lui-même.
avatar Xalio | 
Il n'y a pas de Garbage Collector en cocoa Touch....

Pages

CONNEXION UTILISATEUR