@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 ^^)

Un truc capable de nativement s'intégrer pour le Web. Ni plus, ni moins.

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é...

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...

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 =)

@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..

@ 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.

:) 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...

[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.

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)...

@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.

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

Le gars a du prendre un bon produit bien hallucinogène dès le matin oO

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.

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…

@ 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.

@ 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…

si Apple fournit un SDK assez puissant pour les developpeurs, je donne pas plus de 6 mois pour tous les convertir

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.

[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).

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…

@ 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?

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 !

ooooops, le lapsus !
c'est à Bill Atkinson de relever ses manches,
Andy Hertzfeld il est chez … Google.

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.