C'est bien dit, de nombreux langages sont bien meilleurs que le C ou l'objective-C, mais les milliards de lignes de code déjà écrites ne peuvent être remplacées sans un coût gargantuesque en temps et en argent (+ le pb d'ingénieurs à recycler) : donc on continue à travailler avec un langage digne de l'homme de Cro-Magnon (j'en fait parti, je vous rassure)...

Cro-magnon ? L'assembleur, c'est du langage australopithèque, alors ? :-)

Machine virtuelle ? Faudrait préciser car la ça fait penser a virtual box.

Le C, où le code le plus fiable au monde.

Microsoft Visual Basic, un langage de chimpanzé. ;)

un mec qui ne sait pas gérer le mémoire est un mec qui ne sait pas coder. point.

y a bien des langages DIFFERENTS du C mais dire qu'ils sont "meilleurs'", c'est ouvrir la boîte de pandore de débats sans fin et je pourrais vous tenir 1 mois d'argument (si on me paye la bière) avec rien que le C. alors sur objective-C.. encore plus. - oui, il est réaliste d'imaginer que le runtime de objective-c évolue pour avoir plus de fonctionnalités dynamiques. Cependant, tout le monde semble oublier LLVM. je n'ai pas trop envie d'expliquer ici l'intérêt à terme de LLVM. En gros, LLVM permet de la compilation vers du pseudocode, pseudocode qui ensuite est compilé et optimisée pour l'architecture finale (intel x86, emt64, arm, etc) Il est réaliste de se contenter du "pseudocode" , cela devient donc du code portable pour une éventuelle machine virtuelle, être managé à la .NET ou portable à la java. LLVM ouvre cette voie là à C et objective C et offre un pseudocode standardisé sur lequel construire d'autres choses. Apple a donc déjà prévu depuis quelques années, en investissant dans LLVM/Clang, une route pour faire évoluer objective-C _ ecoutez, les geeks adorent _démolir_ pour réécrire le monde. Cele est excitant. On part d'une page blanche et on créé, youhou mais c'est un jeux de geeks. Pratiquement tous les outils que vous utilisez sont construits sur des langages et recherches qui ont + de 20 ou 30 ans. OS X repose sur MACH qui date de 1984., Objective C et Smalltalk sont de la même période. Ne parlons pas de SQL, html, etc. Cocoa est le descendent de Nextstep/openstep de 1989 (à peu près). Cela ne signifie pas "windows sclerosé et monolithique à vie!" : on parle ici de technologies fondamentales (de bas niveau) sur lequel bâtir. Ces technologies ont été sans cesse améliorées, remises en questions. Il n'y a pas de raison de _détruire_ sous prétexte qu'on veut une "énième syntaxe rigolote pour émerveiller les geeks". Méfiez vous des souhaits des geeks/hackers. Ils pensent souvent plus à leur passion qu'au résultat pour les utilisateurs.

@ bompi : Rien à voir, lorsque l'on doit programmer des fonctions hyper-optimisées il arrive que l'on passe sur de l'assembleur. On l'utilise aussi sur une multitude de micro-contrôleurs : il n'y a pas de langage plus bas niveau (sauf en passant pas l'hexa, mais là il faut une sérieuse dose de...). Par contre le langage C existe depuis les années 70 (1972 je crois) soit près de 40 ans; il a certes évolué mais il est très très loin des langages de dernière génération. Quand on voit le temps qu'il faut pour programmer, le risque d'erreur lors du codage, les astuces and co pour contrer les limites du langage...il faut revenir sur terre. Pour info je développe en assembleur microchip et Intel, C, pascal et Delphi, c++, visual C, visual basic et dernièrement en objective-C pour mon mbp et je confirme que tous les langages ne se valent pas (temps de développement, risque d'erreur, taille de code...)

@Hok [16/07/2010 13:00] via MacG Mobile >Machine virtuelle ? Faudrait préciser car la ça fait penser a virtual box. la "virtualisation" est un principe que vous pouvez appliquer à tous les étages de l'informatique : le système d'exploitation, mais pourquoi pas le logiciel lui même, le processeur, ou le stockage, etc. Ici, je suppose que l'auteur pense à "manager" les logiciels objective C du futur. comme avec .NET/C# ou Java les faire s'exécuter par dessus une machine virtuelle (virtual box fait exécuter TOUT le système d'exploitation par dessus une machine virtuelle qui simule un "pc", ici on se "contente" de simuler une machine idéale pour l'application elle même, au sein du système d'exploitation) Cela apporte une très grande flexibilité (tout est dynamique, la machine virtuelle gérant tout) et plus de sécurité (la machine virtuelle bride ou non le programme, si bien sur vous avez confiance en la fiabilité de la machine virtuelle hein... ) Le tout au prix d'une perte gigantesque de performance (aux ingénieurs d'être ultra malin pour minimiser le coût.) Qu'on parle de .net ou d'applicatifs web en javascript au sein d'un navigateur web, on en est pas loin : l'application vit dans un espace virtuel qui l'isole du système d'exploitation. Or, je le répète, Apple travaille depuis des années à remplacer GCC (le compilateur C GNU) par LLVM, qui apporte justement la brique pour évoluer vers une telle solution, en plus Apple conserverait le choix de l'un et l'autre : idéal. LLVM est aussi pensé pour faciliter la compilation de code natif sur plusieurs architectures, ce qui rend LLVM stratégique pour l'iphone / ipad. En ayant imposé Cocoa sur iphone/ipad et en faisant passer à LLVM avec ios 4, apple s'ouvre à la possibilité de basculer facilement vers éventuellement une autre architecture (intel, etc) à l'avenir, à la place de arm Mon point est donc : Pourquoi faire des plans sur la comète alors qu'apple a déjà une base pour le futur : LLVM.

@ canola : Pas du tout, il a très fortement évolué ces dernières années. D'autre part, c'est devenu un langage compilé (et non plus interprété) d'où une plus grande qualité des applications écrites en visual basic.

LLVM leur permet d'inclure dans objective-C et C de nouvelles syntaxe et fonctionnalités (les blocs , par exemple) LLVM leur ouvre d'autre modes d'utilisation du code (pseudocompilé, managés,etc). Xcode 4 actuellement en beta pousse vers ça. Ios 4 préconise son usage. Pour l'heure Apple semble satisfait de faire évoluer obj-c via LLVM. LLVM est utilisé dans snow leopard pour divers sous-systèmes (pour opengl/core animation par exemple). Il est certain qu'à l'avenir apple va introduire des ajouts radicaux à obj-c, cela peut se faire comme pour les "blocs" : sans détruire tout l'acquis. Si on veut savoir ce que va faire Apple dans le futur, il faut surveiller les développements autour de LLVM. http://fr.wikipedia.org/wiki/LLVM http://llvm.org/ http://clang.llvm.org/ http://seminaire.lrde.epita.fr/slides/2009-05-27/geoffray.pdf LLVM, Clang, VMkit. Ce qui est possible avec llvm http://blog.bigzaphod.org/2010/05/21/birth-of-a-platform/ La section 3.3.1 du contrat développeur iphone n'est que la mise en place de futures profondes modifications de Obj-c/Cocoa rendues possibles par LLVM. http://brockerhoff.net/blog/tag/llvm/ blogueur débattant sur LLVM et ce qu'il apporte ou non.

Je ne comprend pas le besoin de faire évoluer l'objective-c. C'est pour ne plus avoir à se soucier de la mémoire ? uniquement ?

Il y a encore un paquet de chemin à parcourir pour arriver à l'objective-z, ne serai-ce que passer au b serait déjà un plus… enfin je dis ça, je dis rien. Ok, ok je ->[]

Tiens, une news intéressante ! :D

[quote=primalmotion]un mec qui ne sait pas gérer le mémoire est un mec qui ne sait pas coder. point.[/quote] +1

@azgard [16/07/2010 13:46] >Je ne comprend pas le besoin de faire évoluer l'objective-c. c'est excitant quand on casse tout. vous avez jamais joué à Godzilla vs la ville en lego? :) >C'est pour ne plus avoir à se soucier de la mémoire ? uniquement ? ça, et autre chose et surtout la MODE. (aujourd'hui hmm... scala! demain... python !) Mais plus sérieusement : on peut toujours faire mieux. On peut améliorer les choses, on peut fournir plus de puissance et conforts de créations de logiciels plus les ordinateurs deviennent puissants plus ont peut s'affranchir de leur gestion interne. On "virtualise". Bien des langages reflètent cela mais j'estime qu'on a pas besoin du fantasme "on va créer une nouvelle syntaxe youhouuu" pour faire évoluer Cocoa/Obj-C vers toujours plus de flexibilité et dynamisme. Il suffit de suivre les travaux sur LLVM.

[quote]primalmotion [16/07/2010 13:14] un mec qui ne sait pas gérer le mémoire est un mec qui ne sait pas coder. point.[/quote] Un mec qui perd du temps à gérer la mémoire alors qu'un système peut le faire automatique est un pigeon. Point.

[quote]Un mec qui perd du temps à gérer la mémoire alors qu'un système peut le faire automatique est un pigeon. Point.[/quote] Un développeur Realbasic, sans doute ......

ErGo_404 -> entre un pigeon et un charlot, je pense que mon choix est fait te concernant.

Back to basics. Il vaux mieux apprendre à conduire avec une boite de vitesse manuelle. La boite automatique c'est bien et tout et tout, mais quand même il vaut mieux maitriser les bases avant. Qui a appris à conduire avec des boites de vitesse automatique uniquement?

Evitons les erreurs de code ou de bon gout de type 404.

90 millions d'américains au bas mot. Dont des pilotes professionnels qui ne sont spécialement pas pires que les nôtres… L'analogie est peut-être pas la meilleure ;D

Plusieurs remarques: 1. Les VMs plus lentes que du natif, c'est plus tellement vrai. Java est le deuxeime langage le plus rapide derriere le C, meme dans des micro-benchmarks. A terme, beaucoup de recherche est dans le monde des VMs. (LLVM entre autre) Et avoir un code en bytecode, permet de transformer le code avant de le compiler sur LA machine ou il doit etre execute et pour la facon dont il est execute, et de l'optimiser pour celle-ci. Contrairement a un compilo natif qui optimise pour une moyenne. Les machines sont de plus en plus heterogenes et dur a prevoir, donc cette approche va gagner a terme. Java est deja plus rapide que beaucoup de langages qui compilent en natif. 2. Les GCs sont de plus en plus rapides. Une allocation avec GC est PLUS rapide, de beaucoup qu'un malloc. Et incroyablement plus rapide qu'un compteur de reference a la Objective-C (en plus d'etre correct sur les boucles en memoire) Evidemment, il est difficile de faire un bon GC pour un langage comme C ou les pointeurs peuvent etre partout. (On est oblige d'etre conservatif, de faire comme si tout etait un pointeur) 3. C, c'est bien pour etre proche de la machine. L'allocation/desallocation a la main, c'est bien quand on doit controller de tres pres ce qui se passe. 99% des programmes (hors jeu) n'ont JAMAIS besoin de cela. C'est sur qu'un programmeur qui ne sait pas manager sa memoire est pas tres tres fort. Mais c'est pas grave parce qu'il sera toujours plus performant que quelqu'un qui sait manager sa memoire et qui ne se rend pas compte qu'il n'en a pas besoin. Le bon dev sait qu'il ne doit pas se mettre des batons dans les roues pour le plaisir. La phrase de tout a l'heure me fait penser a: "Un bon codeur doit savoir coder d'une main, dansle noire avec un bandeau sur les yeux et assis a l'envers sur sa chaise" Oui, peut-etre, mais a mon avis, il ne le fera pas.

[quote]Un mec qui perd du temps à gérer la mémoire alors qu'un système peut le faire automatique est un pigeon. Point.[/quote] -- non mon gars t'as rien compris à la vie C'est un mec qui sait développer. Et pas un mec qui comprend rien à la programmation et attend que le système fasse tout à sa place. Tu peux pisser des centaines de lignes de code. Mais si tu comprends pas ce qui est fait derrière, ben tu vas vite coder des bugs que tu ne vas jamais comprendre, et jamais pouvoir corriger. Avant de coder en Objective-C, lit le manuel. Ca a l'air tout con, mais savoir le béa-ba de la gestion de la mémoire en Objective-C c'est partir du bon pied pour faire du bon code. Du code robuste. Pas un truc qui marchotte et plante de temps en temps Et c'est d'autant plus vrai sur des systèmes avec une petite RAM tels que les iPhones. Si tu alloues plein d'objets dans se soucier de leur durée de vie, tu vas vite te retrouver avec la mémoire pleine, et l'OS qui va devoir passer son temps à faire le ménage là où t'aurais du le faire toi même si t'avais été moins c... Bref, tu bouffes de la RAM, du proc, de la batterie pour palier le fait que t'es trop nul ou faignant. Bref, le garbage collector a été ajouté à Objective-C parce que ça allait être une nécessité pour satisfaire les gens qui allaient venir du monde java pour coder sur l'eldorado iPhone. Mais pas parce que c'était le truc qui manquait cruellement à Objective-C pour en faire un vrai langage.

@tijej: +1

@tijej Android et WebOS ont fait le choix d'une VM. Il marche ni mieux ni moins bien qu'un iphone. Le management memoire d'Objective-C est une horreur: devoir changer un compteur dans un objet qu'on lit est une heresie. Cela veut dire que si tu ne dois pas modifier un objet, tu dois neanmoins faire deux ecritures dedans (une pour acquerir, l'autre pour relacher). Ces ecritures sont des CAS (compare and swap), qui necessitent une communication entre les cores, pour verifier que personne d'autre n'y a touche. Sur les machines d'aujourd'hui, c'est bien pire qu'un bon GC.

[quote=Liocec] C'est bien dit, de nombreux langages sont bien meilleurs que le C ou l'objective-C, mais les milliards de lignes de code déjà écrites ne peuvent être remplacées sans un coût gargantuesque en temps et en argent (+ le pb d'ingénieurs à recycler) : donc on continue à travailler avec un langage digne de l'homme de Cro-Magnon (j'en fait parti, je vous rassure)... [/quote] Au niveau machine virtuelle, la seule référence est Java. Apple a déjà testé sur ces serveurs : c'est une catastrophe de lenteur et de plantages. LLVM (machine virtuelle bas niveau) est de toutes façons la solution retenue pour le futur de XCode, au moins pour compiler le C et l'Objective-C. Ca donne plus de souplesse et de meilleurs performances. Mais pour autant, c'est au développeur de gérer la mémoire.

C'est marrant quand même que ça dure ces histoires... Ces concepts sont vieux comme le monde (bon, ok, vieux comme Java). On peut savoir coder sans aimer se farcir l'allocation/initialisation/finalisation/déallocation à la main; ça s'appelle juste de la programmation de haut niveau (donc pas pour tout ce qui touche aux fondations du système). Et ça n'a /absolument/ rien à voir avec le fait d'utiliser une VM, à part la perte potentielle de performances. Pour la VM (qui est le sujet là, quand même), ça se justifie dans une certaine mesure pour les applications, notamment pour les raisons de sécurité évoquées dans l'article, ou dans certains domaines spécifiques, genre OpenCL/OpenGL ou le même code doit pouvoir tourner sur différents processeurs. Et c'est pas nouveau, c'est le principe de base de LLVM (comme l'a souligné oomu un certain nombre de fois), et dans une certaine mesure de la JVM avant ça. C'est évident que ça apporte quelque chose pour une certaine classe de programmes, c'est aussi évident que c'est un boulet pour d'autres. Malgré ce que racontent les devs Java (je le sais, je l'ai été), les micro-benchmarks ne sont absolument pas significatifs, ils montrent juste qu'une machine virtuelle a été optimisée pour certaines opérations. Et n'importe quel code en Fortran écrit un peu sérieusement explose tout le Java qu'on veut. Et juste histoire de répéter, on peut tout à fait avoir des ramasse-miettes dans des langages non virtualisés. Aucun modèle ne peut marcher pour toutes les utilisations possibles. On aura encore un bout de temps des langages de bas niveau pour la programmation système (C...), des langages de haut niveau, de plus en plus virtualisés pour la programmation applicative (ObjC, C#, Java...), et des langages spécifiques pour la programmation haute performance (OpenCL...). Et le "langage-pour-écrire-des-petits-scripts-vite-fait" ou pour faire des prototypes (Perl, Ruby, Python...). Tout simplement des niches écologiques différentes.

@ oomu: [quote]mais dire qu'ils sont "meilleurs'", c'est ouvrir la boîte de pandore de débats sans fin et je pourrais vous tenir 1 mois d'argument (si on me paye la bière) avec rien que le C. alors sur objective-C.. encore plus.[/quote] Quand tu veux ;)

Le malloc vaincra!

@titej : Je croyais que le système de comptage de référence d'Objective C était réservé aux applications Mac, je me trompe ? A ma connaissance il n'était pas utilisable sur iPod/iPhone/iPad. @NicolasO: Gros +1. Autant je suis parfaitement d'accord avec ceux qui affirment que savoir gérer soi-même est un gros plus pour un développeur (toujours bon de savoir comment ça fonctionne sous le capot), autant une fois qu'on a compris le principe, ça ne présente que peu d'intérêt pour la plus grande partie des applications. Pour les jeux, les traitements lourds (compresseurs/décompresseurs, filtres graphiques, etc), tout ce qui touche au système ainsi que les applications critiques (systèmes embarqués dans l'aéronautique par exemple), maîtriser le plus possible son code est essentiel. Pour le reste, ce n'est que perte de temps. On le voit assez sur (semi-troll, désolé) pas mal de projets d'applications Linux, où les développeurs préfèrent passer 20 piges à optimiser au poil de cul plutôt que d'utiliser ce temps à améliorer l'expérience utilisateur. Résultat, personne ne voit la moindre différence, et certaines applis ont une ergonomie toujours aussi mauvaise. (oserais-je un second troll pour contrebalancer en parlant de Snow Leopard et de son Finder, quitte à me faire lyncher sur la place publique ? =p) Gérer sa mémoire manuellement quand on développe une to-do list ou un client RSS, c'est clairement une perte de temps. C'est aussi ça l'avantage de disposer d'un choix de langages variés ; celui de sélectionner le plus adapté à son application et à ses contraintes. Comme toujours, il y a un juste milieu, il est aussi idiot à mon sens de prôner le tout bas niveau que le tout haut niveau.

Dites les gars qui savent coder (et donc gérer la mémoire) vous mettriez des liens sur vos réalisations si elles sont publiques que nous voyions les maitres à l'œuvre ? Parce que c'est bien beau de savoir coder mais j'aimerais voir ce que vous en faites. Et apprendre de vos lumières moi qui ne code qu'en RealBasic.

@ Zed-K: [quote]Je croyais que le système de comptage de référence d'Objective C était réservé aux applications Mac, je me trompe ?[/quote] Si je me plante pas, c'est le garbage collector qui n'est pas présent sur iOS. Après, l'utilisation des autoreleasePool pose toujours le problème de l'occupation mémoire dans un environement contraint (puisque les objets ne sont pas désalloués immédiatement). (en fait, après vérification, Apple décourage l'utilisation des autorelease pools, et favorise la gestion à la main, ce qui est somme toute logique pour un environnement embarqué).

Les premières version de Mac OS étaient écrites en Pascal ;-)

un mec qui ne sait pas que "mémoire", c'est un nom féminin, on ne l'embauche pas comme développeur. ^^

bonjour en tant que developpeur independant, cest lhorreur, a present cest a nouveau : une marque = un os = un langage de programmation cest insuportable ! Didier,

Hum, on continue a gloser de trucs abscons qui concernent, un part croissante c'est vrai, mais tout de meme marginale d'utilisateurs des systemes Apple (oui aussi GnuStep...) L'uilisateur ignore, et heureusement, avec quels outils ont été conçu l'outil (l'ordinateur) sur lequel tournent ses outils favoris (texteur, tableur, mail, photoshop...)! Ceci dit, pour ajouter mon grain de sel dans le débat, si on pouvait expurger l'informatique des reliques issues du C ca serait une bonne chose. Un specialiste en sécurité me disait récemment qu'utiliser C(et ses incarnations) assurait l'existence de failles de sécurités majeures et donc le travail pour les hackers et les experts en sécurité. Comme dit B.Meyer (cf Eiffel), C est un assembleur portable, pas un langage de développement... Et selon le vieux débat: La gestion de la memoire? (tenants des langages statiques ) ben c'est trop important pour laisser la machine s'en occuper ! (cf tenants des langages dynamiques ) ben c'est trop important pour laisser l'humain s'en occuper ;) Le vrai pb aujourd'hui c'est qu'aucun langage courant sait gérer le multiprocesseur multicore. Pendant des lustres on a voulu (INTEL) faire croire que le salut venait de la course au MHz, jusqu'a ce que la limite soit atteinte il y a quelques années. Maintenant on vient enfin sur le parralellisme (bientot massif) et la on sait pas le programmer. Y a bien des langages pour programmer le parallélisme vectoriel et des parallélismes spécifiques, mais pas des machines multi proc, multicore, faisant tourner des softs heterogenes... Y avait dans le temps des tentatives de creer des machines dédiées à LISP, Simula ou Smaltalk (les plus vieux et les plus puissants langages...) multitaches, mais c'etait une impasse me semble-t il. ...

... Intel et cie a tenté de faire traiter la complexité de l'ordonancement au niveau du proc, et c'est un échec apparemment. On a aussi tenté d'optimiser le compilateur, mais la aussi ça bloque. On tente maintenant de faire gérer l'incapacité du langage par des ordonanceurs style GrandCentral. Mais bon ça resoud rien. Et comme l'avenir c'est des machines massivement paralelle, c'est l'impasse! Pour l'instant c'est l'expectative, mais faut trouver une solution. La gestion de la memoire dans un contexte multitache est un monstre probleme mathematique. Bidouiller un peu le proc, ou l'OS ne suffira pas. Apple est en train d'adapter Mac OS dans cette perspective, mais il faudra de toute facon mettre en place une solution globale: faut reprenser la facon de programmer et donc revoir l'OS, le langage et les compilateurs... Une chose est certaine les "C" sont déja inadaptés aux programmes moyens et sont totalement largés par les multicores. Pour les langages de scripts (ruby ou python) c'est différents, sur quoi ils tournent n'a pas d'importance, c'est pas leur role. Mais pour développer des softs optimisés qui tirent parti de la puissance de la machine, c'est une tout autre histoire... Objective-C et C vont pas disparaître de sitot, mais l'avenir est ailleurs...

Heureusement qu'il y a monotouch pour rattraper le niveau :)

J'ai longtemps hésité à réagir vu que la dernière fois que je suis intervenu sur ce sujet, je me suis fais basher (avec raison, j'avais pas assez potassé mon sujet avant de ramener ma fraise :). Mais bon, ça me gêne dans un coin alors voila : l'article associe VM avec GC comme si un environnement de dev qui s'appuie sur une VM implique forcément que la gestion de la mémoire est confié à un GC, alors que ça n'a rien d'une obligation. Mais vraiment rien.

@ Liocec : « Pour info je développe en assembleur microchip et Intel, C, pascal et Delphi, c++, visual C, visual basic et dernièrement en objective-C » Ce qui me surprend, c’est que dans cette liste c’est Objective C qui est à la fois le plus efficace et le plus agréable à utiliser. Du coup, je ne vois vraiment pas pourquoi tu le traites de langage de Cro Magnon. ;) Je pensais initialement que cette appréciation venait d’une comparaison avec d’autres langages bien différents, mais là ce n’est même pas le cas. Bizarre, bizarre…

@ BeePotato: nan c'est juste à la mode de dire qu'ObjC est dépassé

@ BeePotato : 1. Vu que 70 % de la planète utilise le C et dérivées, je suis aussi obligé de développer en C. 2. Ça ne veut pas dire que j'apprécie ce langage. 3. Pour l'objective-C c'est très récent pour moi, mais pour l'instant mon impression est presque identique que pour le C en dehors de certains procédés complémentaires assez bien vus.

@ NicolasO : Faut arrêter de croire que tu combat les idées reçues en disant "en vérité les langages managés sont + rapide car optimisés jit". Simplement car les processeurs modernes on leur cache L1 un ordre de grandeur plus rapide que le cache L2 qui eux le sont aussi par rapport a la ram. Et que par définition le GC opère dans la ram, et que le runtime est bcp plus gros il ne peut opérer dans le cache L1, le goulet d'étranglement se trouve dans les accès mémoires, de plus les pauses du GC imprévues rendent le programme moins réactif.

@ rimalmotion : « un mec qui ne sait pas gérer le mémoire est un mec qui ne sait pas coder. point. » Ça, c’est parfaitement vrai. Cela dit, « coder » n’est pas toujours le plus important pour le développement : il y a pas mal de situations où il vaut mieux avoir quelqu’un de très doué en algorithmique et ne connaissant strictement rien à la gestion de la mémoire, plutôt que l’inverse. @ ErGo_404 : « Un mec qui perd du temps à gérer la mémoire alors qu'un système peut le faire automatique est un pigeon. Point. » Ça, ce n’est pas vrai dans toutes les situations — mais on peut considérer que ça l’est dans le cadre du développement de la plupart des applications grand public actuelles, ce qui est sûrement ce aui intéresse la plupart des gens ici. Reste qu’il ne faut pas généraliser : l’informatique est un vaste domaine, avec des situations très variées demandant autant de solutions différentes.

@ tijej : Désolé de te contredire, un mec qui sait programmer n'a pas forcément besoin de savoir gérer la mémoire. Si revenir au bas niveau est pour toi un gage de qualité, alors il te faudra travailler avec Intel dans leur service Fondeur pour comprendre comment fonctionne le transistor... De nombreux outils, en commençant par les éditeurs de code, macro systèmes permettent aujourd'hui de ne pas se soucier des couches de bios, de l'OS, etc... Un bon développeur s'est celui qui sait parfaitement utiliser un langage de programmation ou plusieurs, même si celui-ci est du Logo avec des fonctions Cercle, Ligne...

Faire évoluer objective-c en tant que langage pourquoi pas. La surcharge des opérateurs en C++ me manque. L'héritage multiple aussi. Mettre une machine virtuelle je suis pas sure que ça fasse du bien aux applications iPhone. Vaut mieux du code compilé pour la plate-forme cible qu'un pseudo code compilé à la volé (via JIT) sur la machine cible. Le jour où l'iphone aura un quad-core, 6Go de ram et une batterie 10 fois supérieur à celle de maintenant on pourra s'amuser à faire comme avec Java et .NET. On aura le droit à une fenêtre avec un bouton "Hello World!" au milieu qui prendre 40 Mo de RAM et tous le monde sera heureux. En tout cas j'ai du mal à croire que l'approche d'Apple qui est plutôt de chercher la performance se mettent à pondre des usines à gaz juste parce que certains programmeurs ne savent pas gérer correctement la mémoire !

@ Liocec : « Vu que 70 % de la planète utilise le C et dérivées, je suis aussi obligé de développer en C. » Il n’y a pas que le C et ses dérivés qui m’interpellaient dans cette liste : Pascal, Delphi et Visual Basic, ça ne fait ni plus, ni moins digne de Cro Magnon que C et Objective C. « Pour l'objective-C c'est très récent pour moi » Oui, ça se devinait : pour avoir une telle appréciation de ce langage, il faut ne pas l’avoir pratiqué depuis bien longtemps, généralement.

@ tijej : « Bref, le garbage collector a été ajouté à Objective-C parce que ça allait être une nécessité pour satisfaire les gens qui allaient venir du monde java pour coder sur l'eldorado iPhone. Mais pas parce que c'était le truc qui manquait cruellement à Objective-C pour en faire un vrai langage. » Pas d’accord — la meilleure preuve étant que cet ajout ne concerne pas encore l’iPhone. À mon avis, le garbage collector a été ajouté par Apple principalement en raison de l’orientation de plus en plus poussée du développement vers le multithread. Or la gestion manuelle de la mémoire devient tout de suite bien plus compliquée en multithread. Une solution comme GCD aurait été beaucoup moins agréable sans garbage collector (pas impossible à utiliser, mais moins agréable).

A lire les commentaires je vois beaucoup de théories avec des gars qui en à plein la tronche. Je connaissais un ingénieur en électronique qui savait même pas souder un composant sur une platine. La pratique et l'expérience est préférable qu'à toute ces théories philosophiques. Montrez-nous ce que vous savez faire et là on pourra échanger.