Quel langage choisir ?

[yduc]

Je suis quelque peu perdu face à Xcode et me demande si Apple n'a pas commis une énorme bourde en choisissant Objective-C, langage quasiment inconnu, comme langage natif pour son système. Pourquoi pas le C++ ??? Enfin passons. Quant à Xcode lui-même, quand on a tâté du lumineux C++Builder (aaah, Borland...), on se dit que ce qui est innovant un jour ne l'est pas forcément pour l'éternité !

J'ai lu l'excellent document de Pierre Chatelier, De C++ à Objective-C (dispo sur www.projectomega.org), mais ça me confirme surtout qu'il y a des semaines voire des mois d'apprentissage avant d'être à l'aise et efficace sur ce langage.
Pour info, j'ai réalisé quelques modestes programmes dans le temps avec Symantec C++.

Donc, voilà : je m'interroge. Quel langage choisir pour me lancer ? Objective-C et Interface Builder ? Carbon ? Java ? CodeWarrior ? Autre ?
Objective-C est le langage natif du système, donc a priori le plus pérenne, mais le coût de démarrage est décourageant. Et, dans le cadre d'un projet un peu plus ambitieux que j'ai, qu'en est-il des performances générales de Cocoa ? Pour du calcul intensif, le couple Objective-C/Cocoa tient-il le choc face à C++/Carbon ?
Carbon : quelle pérénnité ? Et comment gère-t-on les ressources sans ResEdit ? (avec Interface Builder ?) Java : langage moderne et répandu, intéressant à acquérir mais sur Mac OS X et avec Xcode, permet-il de faire une application généraliste complète ? CodeWarrior : ça existe encore ? CW est-il exclusivement C/C++/Carbon ?

Merci par avance à ceux que mes questions auront inspirés et bonne journée.

Yves

PS : je proscris la ligne de commande.

 

[ntx]

Quel langage choisir pour me lancer ? Objective-C et Interface Builder ? Carbon ? Java ? CodeWarrior ? Autre ?

Code Warrior, oublie, il n'est plus développé. Tu veux faire quoi exactement : des applications uniquement Mac OSX, dans ce cas Objective-C/Cocoa. Tu veux faire du multi-plateforme, C++ ou Java.

Objective-C est le langage natif du système, donc a priori le plus pérenne, mais le coût de démarrage est décourageant. Et, dans le cadre d'un projet un peu plus ambitieux que j'ai, qu'en est-il des performances générales de Cocoa ? Pour du calcul intensif, le couple Objective-C/Cocoa tient-il le choc face à C++/Carbon ?

Les performances sont très bonnes, et même si c'est fastidieux à apprendre, Cocoa est un framework très complet et très puissant. Tu ne seras pas déçu d'avoir passé du temps à l'apprendre.

Et comment gère-t-on les ressources sans ResEdit ? (avec Interface Builder ?)

Oui, avec interface builder, tu crées ou modifies les fichier .lproj.

Java : langage moderne et répandu, intéressant à acquérir mais sur Mac OS X et avec Xcode, permet-il de faire une application généraliste complète ?

Oui, mais Eclipse (ou IntelliJ si tu as les moyens) sont plus performants pour faire du Java que XCode.

CodeWarrior : ça existe encore ? CW est-il exclusivement C/C++/Carbon ?

Il est sur sa fin, notamment sur les Mac/x86 , et il me semble qu'il ne permet de faire que du Carbon.

 

[tatouille]

n, langage quasiment inconnu

heu chez toi dans ton microcosme
http://en.wikipedia.org/wiki/Objective-C

 

[yduc]

Merci pour ces éléments.

Tu veux faire quoi exactement : des applications uniquement Mac OSX, dans ce cas Objective-C/Cocoa. Tu veux faire du multi-plateforme, C++ ou Java.

Mac OS X uniquement, mais j'aurais aimé si possible m'appuyer sur des... connaissances multi-plateformes ! Or je connais bien le C++, que je pratique couramment (sur PC).

Les performances sont très bonnes, et

Depuis Mac OS X, les applications ont pris un tel embonpoint (environ x 20 sur disque, en RAM et en mémoire virtuelle) que je ne peux imaginer que ça ne grève pas les performances à un moment ou à un autre. Pour l'anecdote, la totalité de mes applications OS 9, si je les ouvre simultanément, occupent moins de RAM que la plus petite des applications OS X ! (je n'ai jamais réussi à remplir les 64 Mo de RAM physique que j'avais du temps d'OS 9, et par comparaison une toute petite application comme Calculette sous OS X occupe 90 Mo de mémoire virtuelle)

même si c'est fastidieux à apprendre, Cocoa est un framework très complet et très puissant. Tu ne seras pas déçu d'avoir passé du temps à l'apprendre.

As-tu, sans trop rentrer dans les détails, quelques arguments montrant la puissance et l'intérêt de Cocoa ? (par rapport à d'autres frameworks) Pour revenir à Objectif-C, cela a pu être révolutionnaire à l'époque de NeXT mais aujourd'hui ce langage semble vieillot, limité (pas de constructeur digne de ce nom, pas de surcharge des opérateurs...), ressemble peu au C dans sa forme (le C++ est bien mieux intégré) et semble calamiteux dans sa gestion de la mémoire (autorelease...). Vraiment (et pardon de me répéter), on se demande bien pourquoi Apple a fait ce choix.

Eclipse (ou IntelliJ si tu as les moyens) sont plus performants pour faire du Java que XCode.

Eclipse est-il un environnement complet incluant (ou s'interfaçant avec) un éditeur de ressources de type Interface Builder ?

heu chez toi dans ton microcosme
http://en.wikipedia.org/wiki/Objective-C

Wikipedia me donne a priori raison : il dit que l'Objective-C est utilisé principalement sur NeXT (mort à ce jour) et Mac OS X. Bref, quasiment un langage propriétaire...

Merci à nouveau.

Yves

 

[ntx]

As-tu, sans trop rentrer dans les détails, quelques arguments montrant la puissance et l'intérêt de Cocoa ? (par rapport à d'autres frameworks) Pour revenir à Objectif-C, cela a pu être révolutionnaire à l'époque de NeXT mais aujourd'hui ce langage semble vieillot, limité (pas de constructeur digne de ce nom, pas de surcharge des opérateurs...), ressemble peu au C dans sa forme (le C++ est bien mieux intégré) et semble calamiteux dans sa gestion de la mémoire (autorelease...). Vraiment (et pardon de me répéter), on se demande bien pourquoi Apple a fait ce choix.

Va sur le site développeur d'Apple ou ailleurs et renseigne toi par exemple sur les bindings ou Core Data. Ca te donnera une idée de la "puissance" de Cocoa. Sinon tu peux aussi trouver sur le web un exemple d'éditeur de texte écrit sans taper une seule ligne de code. Et si tu es intéressé par le traitement d'image, Quartz Composer est aussi une belle "bête".

Eclipse est-il un environnement complet incluant (ou s'interfaçant avec) un éditeur de ressources de type Interface Builder ?

Pour Eclipse, je ne pense pas, mais je n'ai jamais fait d'application Java avec une interface. Par contre, il y a aussi NetBeans qui lui a un outil de développement d'interfaces graphiques.

Bref, quasiment un langage propriétaire...

Disons très peu utilisé, mais il existe aussi des implémentation sous Unix ou Windows avec GNUstep qui est la version libre de NextStep, l'ancien nom de Cocoa sous Next.

 

[Céroce]

Pour revenir à Objectif-C, cela a pu être révolutionnaire à l'époque de NeXT mais aujourd'hui ce langage semble vieillot, limité (pas de constructeur digne de ce nom, pas de surcharge des opérateurs...), ressemble peu au C dans sa forme (le C++ est bien mieux intégré) et semble calamiteux dans sa gestion de la mémoire (autorelease...). Vraiment (et pardon de me répéter), on se demande bien pourquoi Apple a fait ce choix.

J'ai fait pas mal de C++ sous MacOS 7, et il n'y a pas un jour où je regrette ce langage. Objective-C est bien plus élégant. Objectif-C est un langage qui ajoute au C les concepts objets de façon directe, alors que pour le C++, on a l'impression que 300 experts ont mis leur grain de sel dedans pour incorporer tous les concepts imaginables.

Tu parles par exemple de la surcharge d'opérateur. Ben moi, je trouve que ce concept, c'est bien en principe (trop cool pour additionner deux matrices!), mais en pratique, c'est de la merde, on ne sait jamais quelle méthode est effectivement appelée. Surtout quand on voit comment c'est utilisé dans la bibliothèque standard:
cout << "Devine quelle méthode est appelée";

Mais le C++ a plein d'autres défauts, le principal étant de pousser le développeur à TOUT sous-classer, à cause de sa rigidité.


Par contre, je suis totalement d'accord avec toi pour dire qu'Objective-C est propriétaire.

 

[tatouille]

Wikipedia me donne a priori raison : il dit que l'Objective-C est utilisé principalement sur NeXT (mort à ce jour) et Mac OS X. Bref, quasiment un langage propriétaire...

Merci à nouveau.

Yves

je vois que tu t'es interressé a la question ........
note que je connais bien les achitectures generiques x86 que tu appeles pc
je pratique le cpp dessus mais je n'ai jamais eu windows .............
y'a vraiment qu'en France que j'entend ce genre de discours (douteux) ....

bon bref l'obj-c n'est pas language inconnu c'est un language sortie des universités et il n'est pas
propriétaire dailleurs des labo de recherche travaillent toujours dessus pour le faire évolué à l'instar du cpp

je suis d'accord avec ceroce le cpp c'est rigide et a un arriere gout de mal fini ou pas fini
avec des bonnes idée et des beaucoup moins bonnes ....

enfin c'est resté en chantier ... tu sais depuis combien de temps gcc supporte l'obj-c ?

Obj-c was originally written by Brad Cox and StepStone

http://www.virtualschool.edu/cox/

 

[Luc G]

Un regard très extérieur :

J'ai commencé à regarder cocoa/objective C pour voir si je peux faire avec un truc pas trop compliqué. Pour moi à qui C donne toujours des boutons les concepts d'objective C me semblent plus intéressants que ceux de C++ (C++, mais je le répète, c'est vu de l'extérieur, je n'ai pas de réelle pratique, c'est un peu : "vous aurez tout et le reste par-dessus le marché, par contre, c'est pas livré avec les meubles de rangement). Même le typage faible d'Objective C (chose qui par atavisme personnel me hérisse plutôt le poil) semble cohérent avec la logique du langage.

Par contre, déjà que la gestion de mémoire des langages "classiques" est un peu pénible, c'est vrai qu'objective C, ça a l'air vraiment foutoir. La fréquentation des langages où c'est transparent fait parfois douter des progrés informatiques. Et par ailleurs, même s'il n'est pas officiellement propriétaire, il l'est largement pour l'heure en pratique. De toutes façons, sous OSX, ce qui est intéressant, ce n'est pas objective C, c'est le couple Cocoa/Objective C et là, il y a vraiment de la puissance.



Incidemment, je ne peux m'empêcher de regretter que le développement des langages les plus utilisés aujourd'hui ait plus son origine dans les bidouillages pratiques que dans les avancées théoriques : on y perdrait sans doute (et encore) un peu en performances pures mais à côté de ça, on verrait un peu mieux ce qu'on fait.

Pour les notions de polymorphisme et de surcharge d'opérateurs, les langages comme OCaml ont quand même des approches plus propres, il me semble mais c'est vrai qu'ils n'ont pas forcément la souplesse de la nombreuse et turbulente famille C.

 

[tatouille]

oui comme l'Objective-Caml
ou le D mais bon c'est inconnu tout ça holala

 

[Luc G]

oui comme l'Objective-Caml
ou le D mais bon c'est inconnu tout ça holala

Ben oui, OCaml, c'est ce que je disais Polymoprhisme tout en ayant un typage fort et automatique, c'est quand même assez puissant.

Pour D, j'ai entendu le nom mais aucune idée de ce que c'est

 

[tatouille]

Ben oui, OCaml, c'est ce que je disais Polymoprhisme tout en ayant un typage fort et automatique, c'est quand même assez puissant.

Pour D, j'ai entendu le nom mais aucune idée de ce que c'est

bah luc c'est une base 5 pour tester ton niveau de connaissance

par exemple si sur ta copie tu n'as rien rempli
ou alors mis que des bétises tu obtients un D

 

[Luc G]

bah luc c'est une base 5 pour tester ton niveau de connaissance

par exemple si sur ta copie tu n'as rien rempli
ou alors mis que des bétises tu obtients un D

Tu crois pas si bien dire : je donne quelques cours d'algorithmique (peu d'heures et niveau démarrage ) mais j'utilise OCaml pour la chose et j'ai corrigé les copies hier soir.
(Pour les notes, j'en suis encore aux chiffres pas aux lettres )

 

[yduc]

renseigne-toi par exemple sur les bindings ou Core Data.

En effet ça semble très intéressant, voire magique. A approfondir...
Cela dit je me demande parfois si le coût d'apprentissage de ces frameworks, extrêmement complets et sophistiqués, n'atteint ou ne dépasse pas le coût du "faire soi-même" ?...

pour le C++, on a l'impression que 300 experts ont mis leur grain de sel dedans pour incorporer tous les concepts imaginables.

Tu reproches à C++ sa richesse mais la richesse n'est pas obligatoire ! Pour prendre un exemple, si la gestion de la visibilité ne t'intéresse pas, tu mets tous tes membres en public et basta (c'est vrai que dans ce cas il faut penser à écrire "public:", car par défaut tout est private).

la surcharge d'opérateur [...] en pratique, [...] on ne sait jamais quelle méthode est effectivement appelée.

A vrai dire je ne m'aventure pas dans les cas compliqués type class1 += class2 + class3, mais l'opérateur =, quand même...

pousser le développeur à TOUT sous-classer

C'est vrai que les catégories d'Objective-C apportent une souplesse importante. A contrario, ce qui me choque c'est la dispersion de la classe (de sa définition !) dans une multitude possible de fichiers sources.

y'a vraiment qu'en France que j'entend ce genre de discours (douteux)

Si douteux fait référence au caractère propriétaire de l'Objective-C (je ne suis pas sûr d'avoir compris), il y a débat entre vous, semble-t-il ! Au sens strict, il ne l'est pas bien sûr. Mais le moins que l'on puisse dire est qu'il n'est pas couramment employé. Personnellement, j'ai découvert son existence avec Mac OS X !!

C++ est connu par des milliers de gens dans le monde : les points forts d'Obj-C sont-ils si précieux qu'ils méritent de délaisser ce langage ultra connu ? Cocoa (ou NeXTStep) sont-ils irrémédiablement liés à l'Obj-C et ne pouvaient-ils pas être réécrits en C++ ? Après tout, ce sont les fonctionnalités de la librairie qui importent, plus que le langage d'implémentation. Réécrire Cocoa en C++ n'aurait-il pas été un grand service à rendre à la communauté des développeurs Apple et finalement à la plate-forme elle-même ?

ou le D mais bon c'est inconnu tout ça holala

Ou le E, allons-y... (vieux langage sur Amiga, assez génial d'ailleurs !)


Bon, avec tout ça j'hésite encore...
Amusant : Apple termine son tutoriel Java... en invitant le lecteur à adopter l'Objective-C !

Yves

 

[tatouille]

Réécrire Cocoa en C++ n'aurait-il pas été un grand service à rendre à la communauté des développeurs Apple et finalement à la plate-forme elle-même ?

il existe un binding Obj-c++
et réécrire un truc qui marche ... ils ont deja mis des années et non

la puissance de cocoa c'est que c'est une grosse lib d'objets de pré-objets
pour un éditeur de logiciel ca peut-etre un choix crucial (sans parlé du coreaudio et du coreimage
une année de dev pour une beta contre quelques mois pour une release )
)
(de plus quartz etant 3d pour l'instant on n'en voit que les 20% , le marché n'est pas prèt)

je vois vois pas

il existait deja une grosse communauté obj-c avant cocoa

 

[Céroce]

Tu reproches à C++ sa richesse mais la richesse n'est pas obligatoire ! Pour prendre un exemple, si la gestion de la visibilité ne t'intéresse pas, tu mets tous tes membres en public et basta (c'est vrai que dans ce cas il faut penser à écrire "public:", car par défaut tout est private).

Sauf qu'on ne programme jamais tout seul dans son coin... on relit aussi le code des autres.

C++ est connu par des milliers de gens dans le monde : les points forts d'Obj-C sont-ils si précieux qu'ils méritent de délaisser ce langage ultra connu ? Cocoa (ou NeXTStep) sont-ils irrémédiablement liés à l'Obj-C et ne pouvaient-ils pas être réécrits en C++ ? Après tout, ce sont les fonctionnalités de la librairie qui importent, plus que le langage d'implémentation. Réécrire Cocoa en C++ n'aurait-il pas été un grand service à rendre à la communauté des développeurs Apple et finalement à la plate-forme elle-même ?

En fait, je ne suis pas sûr que ce soient tant les qualités d'ObjC qui justifient qu'on le conserve, plutôt que les défauts de C++.
C++ me semble bien trop rigide (en particulier, bien trop typé) pour lui adapter Cocoa.

La difficulté n'est pas d'apprendre le langage ObjC lui même: quand on maîtrise le C, une demi-journée suffit (si, si), mais bien d'apprendre à utiliser Cocoa, qui est une grosse Framework avec beaucoup de classes.
Sachant que l'on peut mélanger ObjC et C++, on peut tout à fait écrire les couches basses en C++, et l'interface graphique en ObjC, dans le cadre d'un développement multi-plateformes.

 

[yduc]

C++ me semble bien trop rigide (en particulier, bien trop typé) pour lui adapter Cocoa.

Dieu merci, quelques tout petits frameworks en C++ existent de part le monde et qui marchotent avec ce typage fort...

Si je comprends bien, c'est le fait de pouvoir envoyer un message quelconque à l'objet id que le C++ ne sait pas faire, et tout l'édifice Cocoa repose sur cette possibilité ?

Et pourtant, ceci est possible en C++ : on déclare toutes les méthodes virtuelles et on fait dériver toutes les classes d'une classe mère (NSObject, donc) où l'on met toutes les méhodes du framework. Et alors on reproduit le fonctionnement d'Obj-C ! Mais, et c'est là où l'habitué du C++ que je suis perd pied, c'est qu'on n'a rien fait d'autre qu'ajouter la possibilité d'appeler des méthodes vides...
J'imagine que, même en Obj-C, la plupart du temps lorsqu'on envoie un message, on a un pointeur typé, non ?

Yves

 

[tatouille]

oui l'obj-c a un collecteur poubelle un id est évidemment un NSObject ou l'un de ses dérivés

mais heureusement que ça ne se limite pas à ça

si tu veux un exemple c++/cocoa regarde les sources d'abiword
à la racine des src

abi/src/wp/ap/cocoa/
abi/src/af/xap/cocoa/

 

[mpergand]

Si je comprends bien, c'est le fait de pouvoir envoyer un message quelconque à l'objet id que le C++ ne sait pas faire, et tout l'édifice Cocoa repose sur cette possibilité ?

J'imagine que, même en Obj-C, la plupart du temps lorsqu'on envoie un message, on a un pointeur typé, non ?

Tout passe par des @selector
http://developer.apple.com/document...le_ref/occ/intfm/NSObject/respondsToSelector:

La résolution des méthodes se fait au runtime, càd que si tu appelles une méthode qui n'existe pas, ex: [monObj vazyCoco] ça compile quand même et t'as pas le temps de voir le ch'ti warning que déjà ton appli a plantée

Tout le concept d'objet délégué repose sur ce dynamisme de résolution des méthodes. En C++ tu ne peux rien faire sans dériver, en ObjC tu ne peux rien faire sans créer des objets délégués.
Revers de la médaille, cette résolution au runtime est très couteuse, donc pas l'algo massivement récursif en ObjC !

 

[ntx]

Pour prendre un exemple, si la gestion de la visibilité ne t'intéresse pas, tu mets tous tes membres en public et basta (c'est vrai que dans ce cas il faut penser à écrire "public:", car par défaut tout est private).

Oui mais ça c'est pas de la programmation objet propre, c'est du bricolage Tu passes un analyseur de code la-dessus, tu te fais allumer à chaque ligne J'espère que tu ne fais pas ce genre de truc dans un cadre professionnel ? :zen:

En fait il manque un framework global au C++. On a la STL qui comble une partie des manques, mais il aurait fallu partir de plus haut et créer toute une arborescence à partir d'une classe "Objet" qui aurait servi de base à toutes les autres et là on aurait enfin un vrai langage objet avec les bons côtés du Java et de l'Objective-C et la puissance du C++ (surcharge d'opérateurs, héritage multiple, une liberté totale ... au risque de faire n'importe quoi )

 

[yduc]

Tout passe par des @selector

Normal : le langage permettant que n'importe quel message puisse être envoyé à n'importe quel objet, il fournit les moyens de savoir si un objet donné sait traiter un message donné. (En C++ ces questions ne se posent pas : erreur à la compilation.)

La résolution des méthodes se fait au runtime

En C++ aussi ! (les méthodes virtuelles)

Revers de la médaille, cette résolution au runtime est très couteuse, donc pas d'algo massivement récursif en ObjC !

D'ailleurs je serais curieux de savoir comment fonctionne cette résolution, afin de connaître le coût de l'algorithme, mais je ne connais pas encore assez le langage pour l'imaginer. Je crains que ça ne fonctionne par recherche dans une table, soit recherche dichotomique soit par clé de hachage (O(log n)). Dans les deux cas ça consomme du CPU mais pas de pile (on peut être massivement récursif ; la pile ne débordera pas).
Si effectivement les envois de message sont coûteux en CPU, il faut simplement les éviter à l'intérieur de la boucle cruciale pour les performances et écrire le bout de code... en C !

Le C++ est assez efficace : en gros, c'est une indirection par pointeur (O(1)).

J'espère que tu ne fais pas ce genre de truc dans un cadre professionnel ?

Oh, j'en fais de bien pires !

En fait il manque un framework global au C++. [...] on aurait enfin un vrai langage objet avec les bons côtés du Java et de l'Objective-C et la puissance du C++

Tu mélanges framework et langage, là, non ? Le framework universel (intégré à la librairie standard du langage) n'est pas pour demain, surtout s'il doit aussi gérer l'interface utilisateur. De plus ce serait un monde triste. Quant au langage universel, je m'en méfie et préfère faire avec ce qui existe, malgré ses défauts, que réinventer sans arrêt l'eau tiède (et malgré la tentation ). Mieux vaut parler anglais avec le monde entier que l'esperanto tout seul !

Yves