Apple développerait-elle un nouveau langage ?

dazz [06/07/2010 18:37] (effacer) (editer)

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

Yohmi [06/07/2010 18:37] (effacer) (editer)

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

eliotus [06/07/2010 18:41] (effacer) (editer)

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

Hok [06/07/2010 18:42] (effacer) (editer) via MacG Mobile

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

mezos [06/07/2010 18:46] (effacer) (editer)

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.

FloMo [06/07/2010 18:49] (effacer) (editer)

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 ?

Anabys [06/07/2010 18:51] (effacer) (editer)

AppleScript 2 :D

SuMyDi [06/07/2010 18:52] (effacer) (editer)

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

phoenix73 [06/07/2010 18:53] (effacer) (editer) via MacG Mobile

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 ?

iBorg [06/07/2010 18:58] (effacer) (editer)

Java : trop limité, trop multi-plateformes.

mezos [06/07/2010 19:04] (effacer) (editer)


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

NicolasO [06/07/2010 19:19] (effacer) (editer)

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.

Ikari [06/07/2010 19:20] (effacer) (editer)

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

kubernan [06/07/2010 19:25] (effacer) (editer)

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

Artanis [06/07/2010 19:25] (effacer) (editer)

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

kissscoool [06/07/2010 19:26] (effacer) (editer)

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

6ix [06/07/2010 19:27] (effacer) (editer)

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

shenmue [06/07/2010 19:30] (effacer) (editer)

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

Artanis [06/07/2010 19:34] (effacer) (editer)

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

Hindifarai [06/07/2010 19:43] (effacer) (editer)

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

makidoko [06/07/2010 19:45] (effacer) (editer)


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.

Artanis [06/07/2010 19:46] (effacer) (editer)

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

NicolasO [06/07/2010 19:53] (effacer) (editer)

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

pvmstg [06/07/2010 20:12] (effacer) (editer)

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

Eurylaime [06/07/2010 20:12] (effacer) (editer)

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

Lonesome Boy [06/07/2010 20:14] (effacer) (editer)

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.

Macleone [06/07/2010 20:21] (effacer) (editer)

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…

Artanis [06/07/2010 20:27] (effacer) (editer)

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

Macleone [06/07/2010 20:27] (effacer) (editer)

@ Lonesome Boy:

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…

R1x_Fr1x [06/07/2010 20:29] (effacer) (editer)

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

oomu [06/07/2010 20:35] (effacer) (editer)

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.

6ix [06/07/2010 20:46] (effacer) (editer)



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

Lonesome Boy [06/07/2010 20:49] (effacer) (editer)

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…

Lonesome Boy [06/07/2010 20:53] (effacer) (editer)

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

gazobu [06/07/2010 21:04] (effacer) (editer)

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 !

gazobu [06/07/2010 21:33] (effacer) (editer)

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

marc_os [06/07/2010 21:57] (effacer) (editer)

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 retain et release. 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 retain que telle portion de code utilise tel objet, puis via les release 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.

mdiam [06/07/2010 22:05] (effacer) (editer)

Voir [http://www.macruby.org]
et b] [http://macruby.labs.oreilly.com]

Apple est déjà en train de développer un langage (MacRuby) :
- qui permette au moins ce que permet Objective C,
- basé sur un langage existant et moderne (et avec un fort potentiel) : Ruby,
- basé sur LLVM

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

Thibaut-J [06/07/2010 22:13] (effacer) (editer)

@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

mdiam [06/07/2010 22:28] (effacer) (editer)

Ah, j'oubliais les transparents d'Olivier Gutknecht sur Macruby :

http://www.slideshare.net/olg/introduction-macruby

--Maurice

gazobu [06/07/2010 22:57] (effacer) (editer)

@mdiam
"une version dégradé de xcode qui soit multiplateforme !!"

pile poil contraire à la politique actuelle de Apple.

mac*gyver [06/07/2010 23:13] (effacer) (editer)

bah ils utilisent aussi la langue de bois sur certains problemes materiels

Artanis [06/07/2010 23:20] (effacer) (editer)

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.

Xalio [06/07/2010 23:44] (effacer) (editer)

Il n'y a pas de Garbage Collector en cocoa Touch....

BeePotato [07/07/2010 01:48] (effacer) (editer)

@ Lonesome Boy : « Je suis bien d'accord pour le init, je pensais plutôt à une sorte de "fusion" de l'alloc et de l’init… »

Attention à ne pas relancer la très vieille discussion sur le new ! :)

« Franchement, qui a déjà eu à faire un alloc sans faire un init juste après? »

En fait, c’est plutôt l’inverse : on fait assez régulièrement appel à un init sans avoir fait un alloc juste avant.

ispeed [07/07/2010 06:10] (effacer) (editer)

Je viens de terminer le fameux livre programmation Cocoa sous MacOsx de Aaron Hillegass 3ème édition à conseiller au débutant comme moi :)))

phoenix73 [07/07/2010 08:58] (effacer) (editer) via MacG Mobile

L'idée serait moins dans seulement Java mais bien un couplage VM et LLVM.

Après ça ouvrirait la porte à Java, mais aussi Scala, Groovy ou JRuby.

Cocoa est une API, elle peut donc être mappée en Java ou autre.

Une des raisons du succès d'Android est qu'il utilise un langage qui est très largement utilisé dans l'industrie. Et qu'il a donc un immense réservoir de développeur.

Autre succès, le multiplateforme. On peut développer de l'Android sur Mac, Linux ou Windows.

Le modèle Apple de production logicielle est fermé sur lui même et c'est un frein quoi qu'on en dise, certaines personnes ou entreprises ne peuvent ou veulent investir dans des postes de développement sous OS/X.

On a rarement raison tout seul et plus une plate-forme est ouverte plus riche sont les offres et outils.

XCode 4 sera certainement excellent mais quand on fait du dev sous Eclipse/Netbeans/IntelliJ toute la journée, rebasculer sur un IDE entièrement différent le soir, c'est juste trop couteux.

C'est pour ça qu'Apple doit se poser des maintenant la question sur ses outils de production de code pour ses plateformes iOS et OS/X.

Sinon ce sera Android, pour tel et tablette, qui prendra la place de périphérique léger orienté web, de la maison à l'entreprise.

setnan [07/07/2010 10:35] (effacer) (editer)

Je vois mal un nouveau langage très diffèrent d'ObjC2 pariant plutot vers une v3. Pourquoi ? Ses possibilités de maitrise et de performance, les efforts, y compris récents, fait par Apple pour XCode 3.2.x et 4, etc.. Par exemple, les suivis des alloc d'objets dans Instrument y compris dans les sources, le "Build & analyse" (si vous vous dites "keskecé??" c'est bien dommage), les Class Models, ... Certes ils sont adaptables à d'autres langages mais..

L'ObjC2 est un langage vraiment intéressant, pour peu qu'on arrive à en saisir toutes les subtiliés (et à mon constat, c'est super rare :) ) Il y aura une évolution, obligé, mais pas pour tout de suite, et du moment qu'Apple ne reponde pas un AppleScript javanisant :)

BeePotato [07/07/2010 13:56] (effacer) (editer)

@ phoenix73 : « Objectif C est un frein pour pas mal de monde à commencer par les régiments de Javaistes. »
« XCode 4 sera certainement excellent mais quand on fait du dev sous Eclipse/Netbeans/IntelliJ toute la journée, rebasculer sur un IDE entièrement différent le soir, c'est juste trop couteux. »

Je trouve que ce frein est en fait un excellent filtre, permettant de ne conserver que les développeurs les plus motivés.

marc_os [07/07/2010 16:48] (effacer) (editer)

@ phoenix7 :
Un "nouveau" langage à apprendre n'est un frein que pour les amateurs / bricoleurs, pas pour les professionnels.
"De mon temps", dans les écoles d'ingénieur, un leitmotiv était qu'on nous apprenais à apprendre.
Ne serait-ce plus le cas ?
Si une personne dont le métier est le développement de logiciels pense qu'apprendre Objective-C est un frein pour elle, elle ferait bien de changer de métier.

kripton [08/07/2010 00:14] (effacer) (editer)

si seulement apple pouvait ressortir Dylan du placard...

xcode accepte plusieurs langages. rien n'empeche de laisser objective c et d'ajouter d'autres langages comme ruby ou dylan ma foi...

Yeux [08/07/2010 00:54] (effacer) (editer)

Je programme en RealBasic et en Visual Basic. J'ai acheté plusieurs livres pour apprendre à programmer l'iPhone/iPad, et je n'ai toujours rien compris...
Existe t'il "Objective C pour les nuls" en français ?
Merci.
*_*
@+

phoenix73 [08/07/2010 09:24] (effacer) (editer) via MacG Mobile

Je ne connais pas beaucoup de professionnel du developement qui excelle à la fois en Java et Objective C et qui jonglent avec brio entre les IDE Java majeurs et XCode.

Je serais plutôt enclin à penser que ceux qui croient ça facile, ne sont experts dans aucunes des 2 technos.

spiritmac [08/07/2010 11:34] (effacer) (editer)

Etant développeur en .NET C# et accessoirement en J2EE. Passer à l'objective-C c'est comme revenir 50 ans en arrière. On dirait vraiment un langage de dinosaure ...

Autant Apple est à la pointe niveau technologies et design. Autant le code est moche moche moche et vraiment chiant à utiliser.

marc_os [08/07/2010 11:54] (effacer) (editer)

@ Yeux : Mon avis : Apprends d'abord le C. Car dans Objective-C, il y a C. Ce n'est pas un jeu de mots à deux balles, c'est la réalité : Objective-C est basé sur le C. Et il y a un concept qu'il vaut mieux maîtriser, ce sont les pointeurs. Tiens, ça me rappelle un anecdote : J'ai été amené récemment à épauler une "petite jeune" qui faisait sa première application pour iPhone. Assez douée, elle avait englouti pas mal de bouquins sur le Objective-C et le dev pour iPhone en particulier. A un moment, elle m'a demandé : « C'est quoi ce signe & devant certaines variables ? ». Avant, le seul langage qu'elle connaissant était l'ActionScript de Flash.... Je lui ai parlé de manière succiinte des pointeurs, tout en lui conseillant de se prendre un bon bouquin pour apprendre le C, surtout ce qui concerne ces pointeurs... Tu développes en VB. Les passages de paramètres par référence en VB sont dans ce langage ce qui rappelle le plus les pointeurs de C. A toi de creuser. Avec VB, au moins tu as des notions de programmation orientée objet; tout du moins, tu as manipulé des objets. Mais as-tu écrit des classes toi-même ? Sinon, ... un sujet à creuser aussi.

@ phoenix73 : En école d'ingé (il y a longtemps), j'ai commencé par le Fortran et l'assembleur IBM. Si j'étais resté là, je serais à la rue aujourd'hui. Quand à maîtriser à fond deux environnement, ça n'est peut-être pas donné à tout le monde. Mais si tu as un bon bagage informatique, pourvoir changer d'environnement doit être faisable sans trop de difficultés. Au sujet de java / Obj-C, ce n'est pas comme si un dev java devait devenir un pro de Transac-SQL par exemple. Mais c'est sûr, il y a toutes les API spécifiques à apprendre, et pas mal de concepts dans Objective-C et Cocoa qui ne s'apprennent pas en une nuit; ni en se contentant de recherches d'exemples de code dans Google comme le font les jeunes aujourd'hui. C'est sûr, il faut savoir se poser cinq minutes une heure ou deux, et... lire. Lire sans copier/coller, zut alors.

NicolasO [08/07/2010 13:50] (effacer) (editer)

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

marc_os [08/07/2010 14:22] (effacer) (editer)

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

NicolasO [08/07/2010 15:50] (effacer) (editer)

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.

lol51 [08/07/2010 19:21] (effacer) (editer)

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

NicolasO [08/07/2010 20:31] (effacer) (editer)

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

marc_os [09/07/2010 10:39] (effacer) (editer)

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