En même temps, vu qu'IB est ce qu'on fait de mieux, c'est pas un désavantage de l'avoir copié ;-)
Sinon oui, Gorm est un clone au niveau UI de IB. Il a ceci dit des trucs en plus que IB n'a pas, comme un export/import facile des chaînes de caractères contenu dans un fichier gorm (== pour la traduc).
Donc oui, Gorm n'est pas particulièrement innovant par rapport à IB; mais il l'est par rapport aux restes des constructeurs d'interface :-)
Et puis surtout, il est libre. Et à mon avis c'est là son principal intérêt, car du coup on peut vraiment imaginer tout un tas de "custom palettes" contenant des objets, pour batir facilement un programme (je rappelle que les objets ne sont pas nécessairement des widgets!).
Alors qu'IB se cantonne à un créateur d'UI finalement, sans aller au dela (vers un "assembleur de composants logiciels"); c'est plus dû à des raisons sociologiques (pas hyper intéressant pour des boites de proposer des palettes IB, et manque de documentation) que technologiques, mais ce qui ne marche pas tant que ça dans un modèle commercial (ventes/mise à dispo de composants) a bien plus de chance de marcher dans un modèle libre (ou on a justement _intérêt_ à partager les composants logiciels).
Ben ouaip hein, c'est tout bêtement car ça reste window maker !
Ce que "contrôle" un toolkit (Gtk, Qt, GNUstep, etc.) sous X11, c'est "l'intérieur" des fenêtres, pas les fenêtres/titres de fenêtres -- ça, c'est du ressort du windows manager, en l'occurrence WindowMaker.
Donc bon, c'est normal que ça reste le "même design" pour les fenêtres, vu que le programme est le même...
Heu.. ben oui mais bon la barre des fenêtres, les bordures, toussa, c'est gêré par le Windows Manager hein, ici WindowMaker, pas par GNUstep... (bon en fait GNUstep peut aussi gêrer ses fenêtres lui même, mais c'est pas très pratique si tu as d'autres applis non-GNUstep ;-)
Reste les menus oui, mais ils sont thémables également...
Sinon GNUstep est thémable hein.. Il ne l'est pas par défaut (ceci dit ça va pas tarder), il faut utiliser Camaelon (dispo sur le cvs d'étoilé), mais ça marche sans problème.
Bah oui, mais une vidéo est plus intéressante je trouve... sinon, des captures d'écran et un peu de texte explicatif, on trouve hein: http://www.roard.com/docs/(...)
pour l'interface, l'auteur du thème est Jesse Ross -- enfin, j'ai créé un thème camaelon à partir de son mockup pour le moment, donc c'est pas parfait, mais il bosse en ce moment lui même sur un thème camaelon..
Plus sérieusement, ça a l'air amusant à faire, mais est ce que sur une application un peu conséquente, on a pas tendances à se perdre dans l'interface ?
Ben pour une appli plus conséquente, aucune idée :) -- ma palette steptalk étant toute neuve... Ceci dit, c'est forcèment beaucoup plus lent que des objets Objective-C; je pense pas que coder un algo de traitement d'image par exemple soit idéal :-)
Par contre, pour faire du prototypage, ou l'utiliser en même temps que des objets ObjC, je pense que ça peut être bien pratique.
Pour ce qui est de se perdre dans l'interface, ça devrait quand même aller je pense :-) -- ça ne différe pas vraiment de l'usage normal avec des objets ObjC...
Et pour la prochaine version je ferait probablement un browser de classe (style smalltalk) donc ça devrait même être plus facile de naviguer.
J'ai l'impression que c'est très bien pour les trucs pour lesquels c'est fait, mais si t'as des trucs compliqués à faire c'est la merde.
Pour ce que j'en ai vu, je suis d'accord avec toi -- rails est très bien pour des applis CRUD, mais pour un truc complexe, c'est plus chiant. Mais bon, on fait souvent des trucs simples, et dans ce cas, rails est bien pratique.
Pour des trucs plus complexe, je recommande Seaside, c'est vraiment excellent et bien fichu.
Oui, le développeur (Stefan Kleine Stegemann) avait décidé de stopper vu que l'intégration d'ObjC++ était prévue pour gcc 4.0, ce qui lui simplifierait (beaucoup) le boulot. Bon, ObjC++ est maintenant prévu pour gcc 4.1, mais cette fois ci c'est en bonne voie..
À propos de la release du WebKit avec cvs et tout, voilà le mail qu'il a envoyé hier sur la mailing list:
On s'en souvient, mais bon ... c'était assez évident qu'ils avaient une build interne d'OSX/x86 -- OPENSTEP tournant sur x86 (et Sparc, 68k, etc.) et Rhapsody également, ça aurait été étonnant de ne pas maintenir une version qui tourne à peu près sur x86, en cas de problèmes avec l'approvisionnement en PowerPC...
Non par contre ils avaient eu un projet pour porter le MacOS original sur x86 aux alentours de 87 jusqu'au débuts des années 90 je crois, nommé "Star Trek" : là ou aucun mac n'était encore jamais allé :D
Une équipe avait fait une démo technique, ça marchait (mais bon, d'une démo à un produit finit, y'a un monde..), donc ils avaient mis des gens dessus, mais au final ça a capoté (à priori) pour deux raisons (autre que l'enlisement propre à la paperasse..) :
- ça risquait d'affaiblir la vente de matos mac..
- microsoft avait déja son fameux contrat demandant d'être payé une licence windows par machine, que la machine soit livrée avec windows ou non, et les constructeurs étaient du coup pas prêt à mettre beaucoup d'argent sur une licence macos..
On peut rapprocher l'étape actuelle du mouvement des clones Apple, qui ont failli couler la boite (rendez vous compte, ils avaient l'outrecuidance de faire mieux pour moins cher :-P ), que Steve Jobs a coulé rapidos une fois revenu au commande... la différence, c'est que depuis que iPapy est revenu, Apple a fortement modifié ses sources de revenus -- le software est maintenant dans les 50% !! Etant beaucoup plus centré sur le soft, ça permet évidemment plus de latitude pour laisser tomber le hard (.. enfin.. prendre des risques quoi..), surtout que dans les 50% de hard il y a l'ipod..
Bref, Apple peut maintenant se permettre de prendre des risques au niveau hard. Evidemment, leurs premier Mac/x86 seront plus ou moins vérouillés pour éviter qu'OSX tourne sur n'importe quel clone PC (et de toute façon OSX ne sera évidemment supporté que sur leur propre matos) -- mais bof, Darwin étant OpenSource, franchement je vois pas trop comment ils pourraient avoir un truc infaillible pour éviter qu'OSX tourne sur des PC autre que ceux fournis par Apple..
Mais si quelques bidouilleurs font tourner OSX sur leurs PC, c'est pas vraiment gênant pour Apple -- le matos restera non supporté officiellement, donc ceux qui auront tâté de l'OSX par cette voie là pourraient vouloir acheter un "mac" (qui aura l'avantage de pouvoir faire tourner OSX, linux... et à priori Windows... triplé gagnant ?) -- au pire ces bidouilleurs contribueront à Darwin (drivers..), ou au minimum au bouche à oreille -- ce qui arrangera Apple ! Et ce piratage d'OSX ne sera pas trop pénalisant -- nombre de personnes préfèreront acheter chez apple pour être tranquille (si Apple n'est pas outrageusement cher, mais au vu du MacMini, on peut espérer), et du côté des pros, je les vois mal recompiler Darwin et appliquer des patchs pour avoir un PC bancal semi-supporté, alors que le mac/x86 ne devrait pas être, en toute logique, beaucoup plus cher qu'un PC (Apple va devoir réduire ses marges, je vois pas trop comment ils pourraient faire d'autre !). À moins d'avoir quelque chose de vraiment particulier sur leur Mac/x86 (un composant spécial absolument "vital" ^_^), mais à priori ils ne seront même pas forcé d'utiliser OpenBIOS (cf la doc sur le port x86 dispo chez apple), alors hein...
Bref moi je les vois bien, une fois avoir réussi leur transition, dans quelques années, récupérer de bons contrats OEM (Dell? :D ) ... OSX étant honnêtement bien en avance sur tout le monde, et Tiger a amené de nouvelles API particulièrement alléchantes (CoreImage, CoreData..)
Eventuellement, nous resortir la YellowBox (updatée) sous Windows pour attirer/fidéliser les devs, tout en conservant les iApps sur les Mac/x86 pour se différencier de la concurrence...
... Bref évidemment, tout ça c'est un pari risqué, est-ce que les devs suivront ? et les utilisateurs ? C'est vrai que la première réaction ça a été.. hmm.. dur à avaler pour certains (ouaip moi aussi chui deg:-) mais en y pensant un peu, c'est une stratégie intéressante -- ils sont certains ainsi de ne plus risquer d'être vraiment à la ramasse côté puissance -- mais.. ils ont pas intérêt à se louper !
Ca devrait être intéressant à voir...
allez hop retour sur gnustep parce que bon linux aussi a sa carte à jouer :-D
Apple a trainé les pieds pour fournir les patchs ( propres ) d'Objective-C++ pour gcc
Oui et non.. c'est plutot que le dev en charge (laski) est pas très.. heu... diplomate. Les patchs, il les as fournis hein, mais les responsables C++ voulaient faire les choses différemment et n'étaient pas d'accord sur ces patchs, donc bon... mais ça ce n'est que l'histoire "récente" (~ un an), et d'ailleurs ça a l'air de se régler maintenant. Auparavant (pre 4.0) le problème était que le frontend c++ était en train d'être refondu et les devs gcc ne voulaient pas des patchs apple avant que ce soit finit (ce qui est compréhensible..). Je pense pas qu'apple ait plus que ça trainé les pieds, mais bon...
Oui, pour le moment le gcc d'apple ne permet pas de compiler GNUstep (ou autre projet utilisant le runtime GNU). Pour compiler GNUstep sous MacOSX ou Darwin, il faut recompiler un gcc FSF ...
Mais ce n'est pas une question de patcher gcc *exprès* pour que le runtime ne marche pas, c'est juste qu'ils en avaient pas grand chose à fiche à l'époque (on peut les comprendre, améliorer/optimiser gcc et le runtime NeXT était largement plus prioritaire pour eux comme boulot !). Ceci dit, Andrew Pinski et Zem Laski ont (si je ne me trompe pas) commité ce qu'il fallait pour que ça passe, donc bon, avec un peu de chance (je ne sais pas quelle version de gcc est livré avec XCode2) ça marche directement maintenant; sinon, ça sera probablement pour la version suivante, mais on est loin d'un complot contre le runtime GNU hein :-P
Côté gcc FSF, on aura probablement ObjC++ pour la prochaine release mineure...
Pour rappel ce qu'on pouvait lire à propos de la release 4.0 sur le wiki de gcc:
In addition, the GCC Steering Committee has promised Apple (Zem Laski) that we will get Objective-C++ into GCC 4.0. Therefore, GCC 4.0 will not be released without Objective-C++, unless something seems to have gone horribly awry. (Update) Things went horribly awry, so Objective-C++ has not made it into GCC 4.0.
:-)
Mais bon, Mike Stump a l'air de pousser les choses un peu plus que Laski (et je trouve que c'est sympa à lui d'avoir envoyé un mail sur discuss-gnustep pour dire ce qu'il faisait).
Pas autant "normal" que ça, pour la simple raison qu'Objective-C nécessite un runtime; et Apple utilise un runtime (le runtime de NeXT) qui est différent du runtime utilisé par GNUstep (il s'agit du runtime GNU). Ca fait longtemps qu'Apple a mis à disposition ses patchs concernant Objective-C++, mais si ce n'est toujours pas officiellement intégré à gcc, c'est que ça nécessitait une tripotée de changements:
- dans les frontends C/C++/ObjC
- dans le runtime
Comme en plus ça a "coincidé" avec le gros nettoyage C++ chez gcc... c'est resté en plan. Un nouveau mainteneur vient d'être récemment nommé (Mike Stump, voir http://gcc.gnu.org/ml/gcc/2005-04/msg01178.html)(...) et il a posté un message indiquant qu'il passait ObjC++ sur la mainline mardi soir (plus une série d'améliorations, dont certaines assez intéressantes ;-)
Bref, les choses bougent enfin, donc cool.
Oui, j'ai été un peu surpris en lisant cette "promesse", surtout après avoir eu la flameware, mais c'est justement ce qui a peut être poussé apple à bouger..
De toute façon, indépendamment de cette promesse, en l'état actuel ObjC++ fera très probablement parti de gcc 4.0 d'après ce qu'alex malmberg et andrew pinsky m'ont dit. Par contre ils étaient un peu dubitatif quand à l'utilisabilité de la chose.. c'est pour ça qu'il vaut mieux cibler 4.1, mais bon, j'espère que la 4.0 sera suffisament utilisable pour démarrer quelques portages, au moins.. on verra bien, la 4.0 est pour dans environ 3 mois..
Justement puisque tu en parles, toujours en train d'essayer de porter mes applis Mac OS X vers GNUstep, je n'arrives pas à faire ce que tu viens de dire. Je ne trouve pas dans Gorm où on peut faire ça. Ce qui s'en rapproche le plus semble être dans le menu Classes l'item Load Classes mais il est tout le temps grisé chez moi :-(.
Oui, c'est bien l'item Load Classes -- mais il me semble que greg a pas mal amélioré ça (il a réécrit le parser, etc.), et si je ne me trompe pas, il te faut probablement la dernière release publique (ou le cvs) pour en tirer partie. Enfin, ChezMoiCaMarche, mais hein, mais bon j'utilise le cvs, pas les release publiques..
Ou en est ton Dock que tu nous avais présenté dans l'un de tes journaux ? Il avait l'air très prometteur !
Ben pour le moment, il va le rester, prometteur ;-)
Nan, sans dec, j'aimerais beaucoup bosser dessus (enfin.. entre autre ;-), mais j'ai pas trop des masses de temps libre, et quitte à bosser sur gnustep, autant le faire sur des trucs qui ont plus d'impact comme camaelon... accessoirement les sources sont sûr le disque dur d'une sparc5 (éteinte) dans un placard, à ~1400 km de là... difficile pour moi de les récupérer pour le moment ;-)
Sinon, que conseillerais tu a ceux qui veulent débuter dans la programmation Objective-C (Gnustep/Cocoa) ?
Le bouquin que j'ai préféré, c'est "Cocoa Programming for MacOSX" de Aaron Hillegass -- vraiment top. Aaron bossait à la formation des devs chez NeXT, et ça se sent. Il y a une traduction française, mais par contre j'ai été franchement déçu (même pas capables de traduire l'analogie à K2000/Robocop !! pourtant utilisée à très bon escient ^_^ ). Et en plus Aaron explique plus le côté "framework" que le côté "utilisation de Xcode", et c'est donc beaucoup plus intéressant pour nous autres :-) (dans la nouvelle édition, il a un chapitre sur GNUstep d'ailleurs, mais pas très à jour à priori -- lire http://gnustep.org/resources/BookClarifications.html(...) )
Il me semble que Simson L. Garfinkel a sorti un bouquin sur Cocoa aussi, son bouquin sur la prog NeXT était une référence, j'imagine que celui sur Cocoa est cool aussi, mais je l'ai pas lu. Ce malade a mis le feu à un cube y'a longtemps ;-) http://www.simson.net/photos/hacks/cubefire.html(...)
Sinon effectivement, y'a les docs en ligne sur gnustep.org, ou sur developer.apple.com, et y'a les mailing lists, l'irc (#gnustep sur freenode)...
Non il y a aussi le fait que le fait de favoriser la génération automatique des controllers pose des problèmes d'indépendance comme je viens de l'expliquer.
Ce que permet Gorm n'est pas simplement la "génération automatique des controllers". Lis mon message plus haut. Si c'était ça, ce serait franchement stupide comme approche.
Moi j'ai trouvé pas mal d'inconvénients :
- MVC c'est pas top.
Tu peux étayer ?
- générer des controllers dépendant d'un framework graphique c'est pas top du tout.
Si c'est que faisait Gorm, oui. Comme ce n'est absolument pas le cas, je vois pas trop ce que tu veux dire par là...
- C'est gentil mais ca s'intègre nul part sauf sous Mac, et le modèle MVC fortement intégré ne permet pas d'envisager sereinement une indépendance de la couche graphique sans avoir à réécrire tous les controllers.
J'ai l'impression que tu n'as pas compris le design pattern MVC ni ce que fait Gorm... parce que c'est carrèment à l'opposé de ce que tu décrit.
- la réutilisation du code basé sur le copié-collé c'est nul.
Là, tu est de mauvaise foi :-)
Je vois pas en quoi Objective-C empêche une réutilisation du code "standard" basée sur l'héritage, etc. Simplement je remarquais que l'on pouvait aisèment reprendre du code *existant*, ce qui est pas mal pratique.
- la réutilisation de code C++ est limité au monde Mac.
Faut savoir, la réutilisation du code c'est nul ou pas nul ? :-)
Mais bon, ne pas avoir ObjC++ est effectivement dommage. On attends tous la prochaine version de gcc pour ça ... (4.0, au pire, 4.1)
C'est la pire solution de réutilisation que je connaisse : la maintenance sera affreusement répartie, pouf productivité en chute libre.
J'ai pas dit que c'était une méthode idéale; mais avoir cette possibilité tout à fait pragmatique est bien utile, cf mon exemple.
lequel est même déporté sur une autre machine, merci les DistributedObjects.
Mais dis donc c'est révolutionnaire tout ça à notr époque :)
Le principe d'avoir des objets répartis, ce n'est pas révolutionnaire. Par contre, j'ai pas vu plus simple qu'avec GNUstep (même RMI est plus lourdingue, même si java 1.5 va justement alléger ça) -- tu n'as besoin que de changer l'initialisation de ton objet, une ligne, et hop ensuite le reste fonctionne exactement comme si ton objet distant était local. Ceci dit, le fait que java permette des choses (style bean builder) très très proche d'ObjC/OpenStep n'est pas exactement une suprise -- java a été fortement inspiré par ObjC ! cf un mail fameux de Patrick Naughton (http://virtualschool.edu/objectivec/influenceOnJava.html(...)), un des architectes principaux de Java. D'ailleurs ce qu'on peut reprocher à java est en partie qu'ils n'aient pas été plus inspirés au niveau du framework !
Le seul truc que j'aime bien et qui sort du lot par rapport à la concurrence, c'est effectivement le fait de créer automatiquement un controller. Celà peut être sympa pour faire du RAD, mais dans le cadre d'une vraie application où le controller est INDEPENDANT de l'interface, ben c'est foutu : là tu es limité à utiliser les widgets de GNUStep, pour une autre interface ben faudra recoder ton controller : résultat question gain de temps ben c'est retour à la case départ, voir tu recules encore plus.
Ouaip là t'est un peu à côté de la plaque. Le truc, c'est pas juste "créer automatiquement un controller". Tu peux créer *n'importe* quelle classe et l'instancier, on est franchement pas limité aux contrôleurs; de la même façon tu peux simplement importer un source code existant, avoir la classe disponible, et instancier un objet de cette classe dans ton gorm !
Je vois pas ce que tu veux dire avec ton "faudra recoder ton contrôleur". Par *définition* un contrôleur est dépendant de ton interface graphique... c'est le modèle MVC -- modèle-vue-contrôleur. Ce qui est indépendant de ton UI, c'est ton modèle. La vue, c'est ton UI. Le contrôleur est là pour lier ta vue et ton modèle.
Ici, l'exemple de la vidéo est tellement simple (franchement, multiplier deux nombres..) que je n'ai pas pris la peine de créer une classe "contrôleur" séparée, et que je n'ai finalement qu'un objet "modèle" directement lié aux éléments de mon UI. Dans un vrai programme, j'aurait une classe "modèle" qui contiendrait ma logique métier, une vue (ici simplement créée avec Gorm), et une classe contrôleur liant le modèle et la vue. Je suis étonné de réexpliquer les principes du design pattern modèle-vue-contrôleur...
Moi je peux te faire une démo en Java ou VB identique qui te prends également 2 lignes de codes à écrire :)
Clair -- une calculette en VB sera encore plus courte à coder ! par contre, ton code sera liée à ton UI, ie, complètement pas scalable comme approche.
Enfin à part cette featurette (création automatique d'un controller) dont je t'ai montré les limites, je ne vois rien qui innove par rapport à la concurrence actuelle.
Comme je viens de l'expliquer plus haut, tu ne m'as en rien montré les limites de ce que tu appelle une "featurette" -- la possibilité de manipuler tes objets en live...
Et là je ne suis pas du tout convaincu que TrucStep puisse se vanter d'améliorer notre productivité.
Ben, tant pi.
On croirait entendre les développeurs VB qui disent qu'il vont coder la partie métier en C++ derrière :) Et là tout à coup la productivité chutte lamentablement parcque justement faut utiliser autre chose...
Oula, non, tu as mal compris ce que je voulais mettre en avant. Personnellement, je suis très productif avec Objective-C, merci bien. Par contre, quelque chose qui est *pratique*, c'est qu'il est relativement simple d'encapsuler du code existant (C, C++ -- enfin pour celui là, uniquement sur mac en attendant gcc 4.x ..) dans un objet Objective-C.
Les caractèristiques d'Objective-C aident beaucoup pour travailler à ce niveau de "composant" (dynamisme, introspection, envoi de messages, forwarding, protocoles, catégories, etc.). Tiens un exemple: récemment, j'avait besoin d'un objet pour faire du rendu volumétrique. Ben j'ai pris un code C que j'avais par ailleurs, qui faisait ça très bien, et je l'ai encapsulé dans un objet. Du coup, j'ai pu créer une UI très rapidement avec Gorm, qui communique avec cet objet, lequel est même déporté sur une autre machine, merci les DistributedObjects. D'un coup, une grosse souplesse et une sacré puissance sur un code qui existait déjà, pour quelques lignes ajoutés. On parle souvent de réutilisabilité, c'est le gateau à la crème de la programmation orientée objet. Avec ObjC c'est une réalité.
je suis moins convaincu de sa supériorité par rapport à d'autres solutions
Lesquelles ?
GNUstep/Cocoa n'est pas la réponse ultime -- mais au moins pour créer une interface graphique, je te garantit que ça booste. Regarde la vidéo cité en lien -- ça ressemble presque à n'importe quel gui builder ... mis à part quelques points "légèrement" plus intéressants: l'instantiation directe d'un objet *dans* l'interface (MyController), la séparation nette MVC, la souplesse du framework (le coup des nextKeyView)..
Pas de code généré, on travaille directement avec des objets... Et Gorm n'est pas limité à des widgets graphiques (là preuve, MyController) -- tu peux également te créer tes propres palettes d'objets. C'est pour ça que c'est bien plus qu'un GUI builder, c'est réellement un constructeur de relations inter-objets.. si tu penses que ça ne fait pas gagner du temps, ben hein...
Je rajoute également, si je suis si enthousiaste avec GNUstep, ce n'est pas seulement parce que je trouve que ça facilite pas mal le développement d'applications (et qu'accessoirement, le "modèle" de desktop NeXT qu'on peut avoir me semble plus intéressant et original que windows..), c'est aussi par les possibilitées que l'on entrevoit -- Apple avec Cocoa est resté assez timoré de ce point de vue, mais il y a vraiment des choses extrèmement intéressantes à bâtir à partir d'OpenStep/ObjC comme base.. Gorm est un exemple typique: c'est bien plus qu'un bête constructeur d'interface graphique, c'est réellement un modeleur d'interactions entre objets...
GNUstep a mis un sacré temps à être utilisable, faute de développeurs, mais maintenant que les briques sont là, on peut jouer avec :-)
Bah, je me suis permis de citer ce chiffre parce que bon, ça donne une idée, et c'est effectivement tiré d'une étude réelle faite par Booz Allen en 92:
- took 100+ senior programmers and trained them on NeXTstep, then asked them to write the same app on both NeXT and their previous system.
- First application written was written 2 - 5 times faster.
- Savings were 90%
- 83% less lines of code in the NEXTstep version
- 82% said NeXTstep was better in ALL categories
- It isn't faster to code on NeXTstep; you just have to write less of it. The revolution is "getting rid of software".
Bien évidemment, comme toute étude, c'est à prendre avec des pincettes. Maintenant, je n'imagine pas que, simplement parce que je cite ce chiffre, tout le monde va juste le croire simplement sur ma bonne poire :-)
Si je le cite, c'est parce que ça reste intéressant, et surtout parce qu'empiriquement, cela confirme mon expérience personnelle : j'ai la certitude que je développe beaucoup plus vite avec GNUstep que ce que je faisait avec Qt par exemple (que j'avais déja trouvé épatant pourtant). Et je ne pense pas que cela soit complètement anecdotique: tous les gens que je connaisse qui ont touché au dev sous Cocoa/GNUstep apprécient beaucoup le framework et trouvent qu'ils vont plus vite.
Certes, il y a d'autres facteurs qui jouent, mais un point reste valide -- "it isn't faster to code on NeXTstep; you just have to write less of it". À mon avis, ça s'explique d'une part grâce à la qualité de l'api, vraiment bien fichue et qui évite trois tonnes de code, et d'autres part aux outils de dev (en particulier Gorm) qui évitent pas mal de code aussi, pour se concentrer sur le code réellement utile.
Bon par contre je viens de voir que j'avait fait une gaffe de taille :-) -- l'étude parle de 2 à 5 fois plus vite alors que j'ai mis de 5 à 10 fois (ah là là, ce que c'est que l'enthousiasme ^_^). Ceci dit, l'étude porte sur les API NeXTSTEP, et l'api OpenStep est encore meilleure (et couvre de plus la partie non-graphique), et j'ai effectivement vu quelques fois ce chiffre de 5 à 10 fois. Mais bon, j'avoue, j'ai honte, mea culpa :-)
Maintenant, quand tu dis que le dev informatique a évolué, oui, et non. Le dev sous OSX est tout à fait similaire au dev sous gnustep et tout à fait similaire au dev sous NeXTSTEP en 90 (tiens, regarde la vidéo mis en lien dans la dépêche, et refait la même chose sous OSX -- c'est vraiment pareil). Et que je sache les gens restent impressionné par InterfaceBuilder et par Cocoa. Donc on a peut être évolué, mais pas tant que ça ... ;-) (la récente vidéo de Steve Jobs faisant une démo de NeXTSTEP 3.0 est assez rigolote/triste de ce point de vue, on croirait voire une démo de OSX http://www.openstep.se/jobs/(...) -- finalement on a pas tant que ça progressé...)
Ceci dit, il y a nombre de choses que j'aimerait avoir sous GNUstep et qui amélioreraient les choses -- style des outils de refactoring automatique intégrés dans l'IDE -- mais il reste qu'en l'état actuel, c'est déja très, très confortable... et quand tu parles d'amélioration de l'informatique depuis les années 90, et que je regarde les environnements de développements Smalltalk des années 80/90, ben, y'a encore du chemin à faire, hein.. mais bon.
La force d'Objective-C et d'OpenStep, c'est d'être exceptionnellement bien adaptés à "l'agrégation" de composants et à la production d'interfaces graphiques. Mon avis, c'est qu'il faut essayer d'utiliser le bon outil pour un travail donné. Pour faire un moteur 3D qui tue, C++ est certainement bien meilleur qu'Objective-C. Pour faire une interface graphique, OpenStep est largement mieux, y'a pas photo. Pour batir un logiciel avec des "briques", Objective-C est idéal pour créer les dites briques, car on profite de toute la souplesse du langage. Par contre, pour implémenter le "contenu" de la brique, un autre langage peut être plus adapté, comme C++ par exemple.. enfin, c'est mon avis.
Bref. Tout ça est très simple à vérifier après tout: y'a plein de docs en lignes, tout est en free software, allez-y !
Ben, oui, il y a eu une flameware récemment, les gens se sont un peu emportés (alors qu'en fait le problème a été résolu très rapidement par alex malmberg) ...
Concernant ObjC++, http://gcc.gnu.org/wiki/What%20will%20be%20in%204.0(...) indique qu'ils ont promis à Apple de sortir gcc 4 avec ObjC++ (par contre.. à priori c'est zem lasky qui s'en occupe, et vu ses prodigieux talents diplomatiques... espérons que ça ne déraille pas..). Bref, on espère, mais y'a de bonnes chances.
En étant raisonnable, on peut se dire que ObjC++ sera probablement là pour gcc 4.0, mais probablement (aussi) un peu buggé... bref... gcc 4.1 est l'hypothèse la plus raisonnable pour un ObjC++ stable. Maintenant, on espère que ObjC++ sur gcc 4.0 soit 1) effectivement là 2) pas trop mal fichu pour qu'on puisse commencer à l'utiliser. Qui vivra verra...
mais bon, gcc.gnu.org est plus ou moins mort en ce moment:
"machine went down for fsck on Thursday and found a HD died and then found out the RAID was corrupted"
[^] # Re: à l'exception, évidemment...
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Gorm 1.0 est disponible. Évalué à 3.
Sinon oui, Gorm est un clone au niveau UI de IB. Il a ceci dit des trucs en plus que IB n'a pas, comme un export/import facile des chaînes de caractères contenu dans un fichier gorm (== pour la traduc).
Donc oui, Gorm n'est pas particulièrement innovant par rapport à IB; mais il l'est par rapport aux restes des constructeurs d'interface :-)
Et puis surtout, il est libre. Et à mon avis c'est là son principal intérêt, car du coup on peut vraiment imaginer tout un tas de "custom palettes" contenant des objets, pour batir facilement un programme (je rappelle que les objets ne sont pas nécessairement des widgets!).
Alors qu'IB se cantonne à un créateur d'UI finalement, sans aller au dela (vers un "assembleur de composants logiciels"); c'est plus dû à des raisons sociologiques (pas hyper intéressant pour des boites de proposer des palettes IB, et manque de documentation) que technologiques, mais ce qui ne marche pas tant que ça dans un modèle commercial (ventes/mise à dispo de composants) a bien plus de chance de marcher dans un modèle libre (ou on a justement _intérêt_ à partager les composants logiciels).
[^] # Re: C'est moche
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Gorm 1.0 est disponible. Évalué à 5.
Ce que "contrôle" un toolkit (Gtk, Qt, GNUstep, etc.) sous X11, c'est "l'intérieur" des fenêtres, pas les fenêtres/titres de fenêtres -- ça, c'est du ressort du windows manager, en l'occurrence WindowMaker.
Donc bon, c'est normal que ça reste le "même design" pour les fenêtres, vu que le programme est le même...
[^] # Re: C'est moche
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Gorm 1.0 est disponible. Évalué à 7.
Reste les menus oui, mais ils sont thémables également...
'fin bon..
[^] # Re: C'est moche
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Gorm 1.0 est disponible. Évalué à 9.
Sinon GNUstep est thémable hein.. Il ne l'est pas par défaut (ceci dit ça va pas tarder), il faut utiliser Camaelon (dispo sur le cvs d'étoilé), mais ça marche sans problème.
[^] # Re: GNUstep
Posté par Nicolas Roard (site web personnel) . En réponse au journal programmation GNUstep avec StepTalk palette. Évalué à 3.
http://www.roard.com/docs/(...)
et sur le site d'Eric Levenez, on a la création de calculette qui m'a (pas mal) inspiré:
http://www.levenez.com/NeXTSTEP/IB_ex2.html(...)
(bon c'est une démo en Objective-C, utilisant les API NeXTSTEP, pas OpenStep, mais pour des raisons évidentes les deux API sont très proches)
[^] # Re: Stevolas Roabs
Posté par Nicolas Roard (site web personnel) . En réponse au journal programmation GNUstep avec StepTalk palette. Évalué à 3.
pour l'interface, l'auteur du thème est Jesse Ross -- enfin, j'ai créé un thème camaelon à partir de son mockup pour le moment, donc c'est pas parfait, mais il bosse en ce moment lui même sur un thème camaelon..
[^] # Re: Yeah !
Posté par Nicolas Roard (site web personnel) . En réponse au journal programmation GNUstep avec StepTalk palette. Évalué à 3.
on ne rit pas :)
Plus sérieusement, ça a l'air amusant à faire, mais est ce que sur une application un peu conséquente, on a pas tendances à se perdre dans l'interface ?
Ben pour une appli plus conséquente, aucune idée :) -- ma palette steptalk étant toute neuve... Ceci dit, c'est forcèment beaucoup plus lent que des objets Objective-C; je pense pas que coder un algo de traitement d'image par exemple soit idéal :-)
Par contre, pour faire du prototypage, ou l'utiliser en même temps que des objets ObjC, je pense que ça peut être bien pratique.
Pour ce qui est de se perdre dans l'interface, ça devrait quand même aller je pense :-) -- ça ne différe pas vraiment de l'usage normal avec des objets ObjC...
Et pour la prochaine version je ferait probablement un browser de classe (style smalltalk) donc ça devrait même être plus facile de naviguer.
[^] # Re: ...
Posté par Nicolas Roard (site web personnel) . En réponse au journal programmation GNUstep avec StepTalk palette. Évalué à 4.
[^] # Re: Après avoir testé rails...
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Support d'Ajax dans Ruby on Rails. Évalué à 4.
J'ai l'impression que c'est très bien pour les trucs pour lesquels c'est fait, mais si t'as des trucs compliqués à faire c'est la merde.
Pour ce que j'en ai vu, je suis d'accord avec toi -- rails est très bien pour des applis CRUD, mais pour un truc complexe, c'est plus chiant. Mais bon, on fait souvent des trucs simples, et dans ce cas, rails est bien pratique.
Pour des trucs plus complexe, je recommande Seaside, c'est vraiment excellent et bien fichu.
http://www.seaside.st(...)
[^] # Re: Apple, communication et marketing...
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Apple abandonne IBM pour Intel. Évalué à 1.
Et c'est justement pour ça (et du fait que Rhapsody était également multiplateforme) qu'une build interne x86 d'OSX était plus que probable..
[^] # Re: A noter pour ceux qui comme aurait l'idée en tête
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Apple ouvre le CVS de WebCore. Évalué à 8.
Oui, le développeur (Stefan Kleine Stegemann) avait décidé de stopper vu que l'intégration d'ObjC++ était prévue pour gcc 4.0, ce qui lui simplifierait (beaucoup) le boulot. Bon, ObjC++ est maintenant prévu pour gcc 4.1, mais cette fois ci c'est en bonne voie..
À propos de la release du WebKit avec cvs et tout, voilà le mail qu'il a envoyé hier sur la mailing list:
http://lists.gnu.org/archive/html/discuss-gnustep/2005-06/msg00016.(...)
[^] # Re: Apple, communication et marketing...
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Apple abandonne IBM pour Intel. Évalué à 8.
Non par contre ils avaient eu un projet pour porter le MacOS original sur x86 aux alentours de 87 jusqu'au débuts des années 90 je crois, nommé "Star Trek" : là ou aucun mac n'était encore jamais allé :D
Une équipe avait fait une démo technique, ça marchait (mais bon, d'une démo à un produit finit, y'a un monde..), donc ils avaient mis des gens dessus, mais au final ça a capoté (à priori) pour deux raisons (autre que l'enlisement propre à la paperasse..) :
- ça risquait d'affaiblir la vente de matos mac..
- microsoft avait déja son fameux contrat demandant d'être payé une licence windows par machine, que la machine soit livrée avec windows ou non, et les constructeurs étaient du coup pas prêt à mettre beaucoup d'argent sur une licence macos..
On peut rapprocher l'étape actuelle du mouvement des clones Apple, qui ont failli couler la boite (rendez vous compte, ils avaient l'outrecuidance de faire mieux pour moins cher :-P ), que Steve Jobs a coulé rapidos une fois revenu au commande... la différence, c'est que depuis que iPapy est revenu, Apple a fortement modifié ses sources de revenus -- le software est maintenant dans les 50% !! Etant beaucoup plus centré sur le soft, ça permet évidemment plus de latitude pour laisser tomber le hard (.. enfin.. prendre des risques quoi..), surtout que dans les 50% de hard il y a l'ipod..
Bref, Apple peut maintenant se permettre de prendre des risques au niveau hard. Evidemment, leurs premier Mac/x86 seront plus ou moins vérouillés pour éviter qu'OSX tourne sur n'importe quel clone PC (et de toute façon OSX ne sera évidemment supporté que sur leur propre matos) -- mais bof, Darwin étant OpenSource, franchement je vois pas trop comment ils pourraient avoir un truc infaillible pour éviter qu'OSX tourne sur des PC autre que ceux fournis par Apple..
Mais si quelques bidouilleurs font tourner OSX sur leurs PC, c'est pas vraiment gênant pour Apple -- le matos restera non supporté officiellement, donc ceux qui auront tâté de l'OSX par cette voie là pourraient vouloir acheter un "mac" (qui aura l'avantage de pouvoir faire tourner OSX, linux... et à priori Windows... triplé gagnant ?) -- au pire ces bidouilleurs contribueront à Darwin (drivers..), ou au minimum au bouche à oreille -- ce qui arrangera Apple ! Et ce piratage d'OSX ne sera pas trop pénalisant -- nombre de personnes préfèreront acheter chez apple pour être tranquille (si Apple n'est pas outrageusement cher, mais au vu du MacMini, on peut espérer), et du côté des pros, je les vois mal recompiler Darwin et appliquer des patchs pour avoir un PC bancal semi-supporté, alors que le mac/x86 ne devrait pas être, en toute logique, beaucoup plus cher qu'un PC (Apple va devoir réduire ses marges, je vois pas trop comment ils pourraient faire d'autre !). À moins d'avoir quelque chose de vraiment particulier sur leur Mac/x86 (un composant spécial absolument "vital" ^_^), mais à priori ils ne seront même pas forcé d'utiliser OpenBIOS (cf la doc sur le port x86 dispo chez apple), alors hein...
Bref moi je les vois bien, une fois avoir réussi leur transition, dans quelques années, récupérer de bons contrats OEM (Dell? :D ) ... OSX étant honnêtement bien en avance sur tout le monde, et Tiger a amené de nouvelles API particulièrement alléchantes (CoreImage, CoreData..)
Eventuellement, nous resortir la YellowBox (updatée) sous Windows pour attirer/fidéliser les devs, tout en conservant les iApps sur les Mac/x86 pour se différencier de la concurrence...
... Bref évidemment, tout ça c'est un pari risqué, est-ce que les devs suivront ? et les utilisateurs ? C'est vrai que la première réaction ça a été.. hmm.. dur à avaler pour certains (ouaip moi aussi chui deg:-) mais en y pensant un peu, c'est une stratégie intéressante -- ils sont certains ainsi de ne plus risquer d'être vraiment à la ramasse côté puissance -- mais.. ils ont pas intérêt à se louper !
Ca devrait être intéressant à voir...
allez hop retour sur gnustep parce que bon linux aussi a sa carte à jouer :-D
[^] # Re: en passant, WebKit est vraiment opensource maintenant
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Apple abandonne IBM pour Intel. Évalué à 3.
Oui et non.. c'est plutot que le dev en charge (laski) est pas très.. heu... diplomate. Les patchs, il les as fournis hein, mais les responsables C++ voulaient faire les choses différemment et n'étaient pas d'accord sur ces patchs, donc bon... mais ça ce n'est que l'histoire "récente" (~ un an), et d'ailleurs ça a l'air de se régler maintenant. Auparavant (pre 4.0) le problème était que le frontend c++ était en train d'être refondu et les devs gcc ne voulaient pas des patchs apple avant que ce soit finit (ce qui est compréhensible..). Je pense pas qu'apple ait plus que ça trainé les pieds, mais bon...
[^] # Re: Alors...
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche David Hyatt fait passer le test Acid2 à Safari et contribue à Konqueror. Évalué à 6.
Oui, pour le moment le gcc d'apple ne permet pas de compiler GNUstep (ou autre projet utilisant le runtime GNU). Pour compiler GNUstep sous MacOSX ou Darwin, il faut recompiler un gcc FSF ...
Mais ce n'est pas une question de patcher gcc *exprès* pour que le runtime ne marche pas, c'est juste qu'ils en avaient pas grand chose à fiche à l'époque (on peut les comprendre, améliorer/optimiser gcc et le runtime NeXT était largement plus prioritaire pour eux comme boulot !). Ceci dit, Andrew Pinski et Zem Laski ont (si je ne me trompe pas) commité ce qu'il fallait pour que ça passe, donc bon, avec un peu de chance (je ne sais pas quelle version de gcc est livré avec XCode2) ça marche directement maintenant; sinon, ça sera probablement pour la version suivante, mais on est loin d'un complot contre le runtime GNU hein :-P
Côté gcc FSF, on aura probablement ObjC++ pour la prochaine release mineure...
Pour rappel ce qu'on pouvait lire à propos de la release 4.0 sur le wiki de gcc:
In addition, the GCC Steering Committee has promised Apple (Zem Laski) that we will get Objective-C++ into GCC 4.0. Therefore, GCC 4.0 will not be released without Objective-C++, unless something seems to have gone horribly awry. (Update) Things went horribly awry, so Objective-C++ has not made it into GCC 4.0.
:-)
Mais bon, Mike Stump a l'air de pousser les choses un peu plus que Laski (et je trouve que c'est sympa à lui d'avoir envoyé un mail sur discuss-gnustep pour dire ce qu'il faisait).
[^] # Re: Alors...
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche David Hyatt fait passer le test Acid2 à Safari et contribue à Konqueror. Évalué à 4.
- dans les frontends C/C++/ObjC
- dans le runtime
Comme en plus ça a "coincidé" avec le gros nettoyage C++ chez gcc... c'est resté en plan. Un nouveau mainteneur vient d'être récemment nommé (Mike Stump, voir http://gcc.gnu.org/ml/gcc/2005-04/msg01178.html)(...) et il a posté un message indiquant qu'il passait ObjC++ sur la mainline mardi soir (plus une série d'améliorations, dont certaines assez intéressantes ;-)
Bref, les choses bougent enfin, donc cool.
[^] # Re: ???
Posté par Nicolas Roard (site web personnel) . En réponse au journal Le grand satan avance.. Évalué à 3.
[^] # Re: Objective-C++?
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Sortie de la distribution GNUSTEP 0.9.4, GNUstep news, et vidéo. Évalué à 2.
De toute façon, indépendamment de cette promesse, en l'état actuel ObjC++ fera très probablement parti de gcc 4.0 d'après ce qu'alex malmberg et andrew pinsky m'ont dit. Par contre ils étaient un peu dubitatif quand à l'utilisabilité de la chose.. c'est pour ça qu'il vaut mieux cibler 4.1, mais bon, j'espère que la 4.0 sera suffisament utilisable pour démarrer quelques portages, au moins.. on verra bien, la 4.0 est pour dans environ 3 mois..
[^] # Re: trop génial
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Sortie de la distribution GNUSTEP 0.9.4, GNUstep news, et vidéo. Évalué à 3.
Oui, c'est bien l'item Load Classes -- mais il me semble que greg a pas mal amélioré ça (il a réécrit le parser, etc.), et si je ne me trompe pas, il te faut probablement la dernière release publique (ou le cvs) pour en tirer partie. Enfin, ChezMoiCaMarche, mais hein, mais bon j'utilise le cvs, pas les release publiques..
[^] # Re: bonne nouvelle
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Sortie de la distribution GNUSTEP 0.9.4, GNUstep news, et vidéo. Évalué à 3.
Ben pour le moment, il va le rester, prometteur ;-)
Nan, sans dec, j'aimerais beaucoup bosser dessus (enfin.. entre autre ;-), mais j'ai pas trop des masses de temps libre, et quitte à bosser sur gnustep, autant le faire sur des trucs qui ont plus d'impact comme camaelon... accessoirement les sources sont sûr le disque dur d'une sparc5 (éteinte) dans un placard, à ~1400 km de là... difficile pour moi de les récupérer pour le moment ;-)
Sinon, que conseillerais tu a ceux qui veulent débuter dans la programmation Objective-C (Gnustep/Cocoa) ?
Le bouquin que j'ai préféré, c'est "Cocoa Programming for MacOSX" de Aaron Hillegass -- vraiment top. Aaron bossait à la formation des devs chez NeXT, et ça se sent. Il y a une traduction française, mais par contre j'ai été franchement déçu (même pas capables de traduire l'analogie à K2000/Robocop !! pourtant utilisée à très bon escient ^_^ ). Et en plus Aaron explique plus le côté "framework" que le côté "utilisation de Xcode", et c'est donc beaucoup plus intéressant pour nous autres :-) (dans la nouvelle édition, il a un chapitre sur GNUstep d'ailleurs, mais pas très à jour à priori -- lire http://gnustep.org/resources/BookClarifications.html(...) )
Il me semble que Simson L. Garfinkel a sorti un bouquin sur Cocoa aussi, son bouquin sur la prog NeXT était une référence, j'imagine que celui sur Cocoa est cool aussi, mais je l'ai pas lu. Ce malade a mis le feu à un cube y'a longtemps ;-)
http://www.simson.net/photos/hacks/cubefire.html(...)
Sinon effectivement, y'a les docs en ligne sur gnustep.org, ou sur developer.apple.com, et y'a les mailing lists, l'irc (#gnustep sur freenode)...
Y'a aussi ma page (pas mis à jour depuis longtemps) qui référence des articles: http://www.roard.com/docs/(...)
[^] # Re: trop génial
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Sortie de la distribution GNUSTEP 0.9.4, GNUstep news, et vidéo. Évalué à 6.
Ce que permet Gorm n'est pas simplement la "génération automatique des controllers". Lis mon message plus haut. Si c'était ça, ce serait franchement stupide comme approche.
Moi j'ai trouvé pas mal d'inconvénients :
- MVC c'est pas top.
Tu peux étayer ?
- générer des controllers dépendant d'un framework graphique c'est pas top du tout.
Si c'est que faisait Gorm, oui. Comme ce n'est absolument pas le cas, je vois pas trop ce que tu veux dire par là...
- C'est gentil mais ca s'intègre nul part sauf sous Mac, et le modèle MVC fortement intégré ne permet pas d'envisager sereinement une indépendance de la couche graphique sans avoir à réécrire tous les controllers.
J'ai l'impression que tu n'as pas compris le design pattern MVC ni ce que fait Gorm... parce que c'est carrèment à l'opposé de ce que tu décrit.
- la réutilisation du code basé sur le copié-collé c'est nul.
Là, tu est de mauvaise foi :-)
Je vois pas en quoi Objective-C empêche une réutilisation du code "standard" basée sur l'héritage, etc. Simplement je remarquais que l'on pouvait aisèment reprendre du code *existant*, ce qui est pas mal pratique.
- la réutilisation de code C++ est limité au monde Mac.
Faut savoir, la réutilisation du code c'est nul ou pas nul ? :-)
Mais bon, ne pas avoir ObjC++ est effectivement dommage. On attends tous la prochaine version de gcc pour ça ... (4.0, au pire, 4.1)
[^] # Re: trop génial
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Sortie de la distribution GNUSTEP 0.9.4, GNUstep news, et vidéo. Évalué à 4.
Ouaaaip bon je m'emporte ;-)
C'est la pire solution de réutilisation que je connaisse : la maintenance sera affreusement répartie, pouf productivité en chute libre.
J'ai pas dit que c'était une méthode idéale; mais avoir cette possibilité tout à fait pragmatique est bien utile, cf mon exemple.
lequel est même déporté sur une autre machine, merci les DistributedObjects.
Mais dis donc c'est révolutionnaire tout ça à notr époque :)
Le principe d'avoir des objets répartis, ce n'est pas révolutionnaire. Par contre, j'ai pas vu plus simple qu'avec GNUstep (même RMI est plus lourdingue, même si java 1.5 va justement alléger ça) -- tu n'as besoin que de changer l'initialisation de ton objet, une ligne, et hop ensuite le reste fonctionne exactement comme si ton objet distant était local. Ceci dit, le fait que java permette des choses (style bean builder) très très proche d'ObjC/OpenStep n'est pas exactement une suprise -- java a été fortement inspiré par ObjC ! cf un mail fameux de Patrick Naughton (http://virtualschool.edu/objectivec/influenceOnJava.html(...)), un des architectes principaux de Java. D'ailleurs ce qu'on peut reprocher à java est en partie qu'ils n'aient pas été plus inspirés au niveau du framework !
Le seul truc que j'aime bien et qui sort du lot par rapport à la concurrence, c'est effectivement le fait de créer automatiquement un controller. Celà peut être sympa pour faire du RAD, mais dans le cadre d'une vraie application où le controller est INDEPENDANT de l'interface, ben c'est foutu : là tu es limité à utiliser les widgets de GNUStep, pour une autre interface ben faudra recoder ton controller : résultat question gain de temps ben c'est retour à la case départ, voir tu recules encore plus.
Ouaip là t'est un peu à côté de la plaque. Le truc, c'est pas juste "créer automatiquement un controller". Tu peux créer *n'importe* quelle classe et l'instancier, on est franchement pas limité aux contrôleurs; de la même façon tu peux simplement importer un source code existant, avoir la classe disponible, et instancier un objet de cette classe dans ton gorm !
Je vois pas ce que tu veux dire avec ton "faudra recoder ton contrôleur". Par *définition* un contrôleur est dépendant de ton interface graphique... c'est le modèle MVC -- modèle-vue-contrôleur. Ce qui est indépendant de ton UI, c'est ton modèle. La vue, c'est ton UI. Le contrôleur est là pour lier ta vue et ton modèle.
Ici, l'exemple de la vidéo est tellement simple (franchement, multiplier deux nombres..) que je n'ai pas pris la peine de créer une classe "contrôleur" séparée, et que je n'ai finalement qu'un objet "modèle" directement lié aux éléments de mon UI. Dans un vrai programme, j'aurait une classe "modèle" qui contiendrait ma logique métier, une vue (ici simplement créée avec Gorm), et une classe contrôleur liant le modèle et la vue. Je suis étonné de réexpliquer les principes du design pattern modèle-vue-contrôleur...
Moi je peux te faire une démo en Java ou VB identique qui te prends également 2 lignes de codes à écrire :)
Clair -- une calculette en VB sera encore plus courte à coder ! par contre, ton code sera liée à ton UI, ie, complètement pas scalable comme approche.
Enfin à part cette featurette (création automatique d'un controller) dont je t'ai montré les limites, je ne vois rien qui innove par rapport à la concurrence actuelle.
Comme je viens de l'expliquer plus haut, tu ne m'as en rien montré les limites de ce que tu appelle une "featurette" -- la possibilité de manipuler tes objets en live...
[^] # Re: trop génial
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Sortie de la distribution GNUSTEP 0.9.4, GNUstep news, et vidéo. Évalué à 5.
Ben, tant pi.
On croirait entendre les développeurs VB qui disent qu'il vont coder la partie métier en C++ derrière :) Et là tout à coup la productivité chutte lamentablement parcque justement faut utiliser autre chose...
Oula, non, tu as mal compris ce que je voulais mettre en avant. Personnellement, je suis très productif avec Objective-C, merci bien. Par contre, quelque chose qui est *pratique*, c'est qu'il est relativement simple d'encapsuler du code existant (C, C++ -- enfin pour celui là, uniquement sur mac en attendant gcc 4.x ..) dans un objet Objective-C.
Brad Cox (le créateur d'Objective-C) considérait d'ailleurs son langage comme étant idéal pour ça -- aggréger des composants de haut niveau (http://www.virtualschool.edu/cox/pub/TaskMaster/CoxUserPgmblSystems(...))
Les caractèristiques d'Objective-C aident beaucoup pour travailler à ce niveau de "composant" (dynamisme, introspection, envoi de messages, forwarding, protocoles, catégories, etc.). Tiens un exemple: récemment, j'avait besoin d'un objet pour faire du rendu volumétrique. Ben j'ai pris un code C que j'avais par ailleurs, qui faisait ça très bien, et je l'ai encapsulé dans un objet. Du coup, j'ai pu créer une UI très rapidement avec Gorm, qui communique avec cet objet, lequel est même déporté sur une autre machine, merci les DistributedObjects. D'un coup, une grosse souplesse et une sacré puissance sur un code qui existait déjà, pour quelques lignes ajoutés. On parle souvent de réutilisabilité, c'est le gateau à la crème de la programmation orientée objet. Avec ObjC c'est une réalité.
je suis moins convaincu de sa supériorité par rapport à d'autres solutions
Lesquelles ?
GNUstep/Cocoa n'est pas la réponse ultime -- mais au moins pour créer une interface graphique, je te garantit que ça booste. Regarde la vidéo cité en lien -- ça ressemble presque à n'importe quel gui builder ... mis à part quelques points "légèrement" plus intéressants: l'instantiation directe d'un objet *dans* l'interface (MyController), la séparation nette MVC, la souplesse du framework (le coup des nextKeyView)..
Pas de code généré, on travaille directement avec des objets... Et Gorm n'est pas limité à des widgets graphiques (là preuve, MyController) -- tu peux également te créer tes propres palettes d'objets. C'est pour ça que c'est bien plus qu'un GUI builder, c'est réellement un constructeur de relations inter-objets.. si tu penses que ça ne fait pas gagner du temps, ben hein...
[^] # Re: trop génial
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Sortie de la distribution GNUSTEP 0.9.4, GNUstep news, et vidéo. Évalué à 6.
GNUstep a mis un sacré temps à être utilisable, faute de développeurs, mais maintenant que les briques sont là, on peut jouer avec :-)
[^] # Re: trop génial
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Sortie de la distribution GNUSTEP 0.9.4, GNUstep news, et vidéo. Évalué à 10.
- took 100+ senior programmers and trained them on NeXTstep, then asked them to write the same app on both NeXT and their previous system.
- First application written was written 2 - 5 times faster.
- Savings were 90%
- 83% less lines of code in the NEXTstep version
- 82% said NeXTstep was better in ALL categories
- It isn't faster to code on NeXTstep; you just have to write less of it. The revolution is "getting rid of software".
Bien évidemment, comme toute étude, c'est à prendre avec des pincettes. Maintenant, je n'imagine pas que, simplement parce que je cite ce chiffre, tout le monde va juste le croire simplement sur ma bonne poire :-)
Si je le cite, c'est parce que ça reste intéressant, et surtout parce qu'empiriquement, cela confirme mon expérience personnelle : j'ai la certitude que je développe beaucoup plus vite avec GNUstep que ce que je faisait avec Qt par exemple (que j'avais déja trouvé épatant pourtant). Et je ne pense pas que cela soit complètement anecdotique: tous les gens que je connaisse qui ont touché au dev sous Cocoa/GNUstep apprécient beaucoup le framework et trouvent qu'ils vont plus vite.
Certes, il y a d'autres facteurs qui jouent, mais un point reste valide -- "it isn't faster to code on NeXTstep; you just have to write less of it". À mon avis, ça s'explique d'une part grâce à la qualité de l'api, vraiment bien fichue et qui évite trois tonnes de code, et d'autres part aux outils de dev (en particulier Gorm) qui évitent pas mal de code aussi, pour se concentrer sur le code réellement utile.
Bon par contre je viens de voir que j'avait fait une gaffe de taille :-) -- l'étude parle de 2 à 5 fois plus vite alors que j'ai mis de 5 à 10 fois (ah là là, ce que c'est que l'enthousiasme ^_^). Ceci dit, l'étude porte sur les API NeXTSTEP, et l'api OpenStep est encore meilleure (et couvre de plus la partie non-graphique), et j'ai effectivement vu quelques fois ce chiffre de 5 à 10 fois. Mais bon, j'avoue, j'ai honte, mea culpa :-)
Maintenant, quand tu dis que le dev informatique a évolué, oui, et non. Le dev sous OSX est tout à fait similaire au dev sous gnustep et tout à fait similaire au dev sous NeXTSTEP en 90 (tiens, regarde la vidéo mis en lien dans la dépêche, et refait la même chose sous OSX -- c'est vraiment pareil). Et que je sache les gens restent impressionné par InterfaceBuilder et par Cocoa. Donc on a peut être évolué, mais pas tant que ça ... ;-) (la récente vidéo de Steve Jobs faisant une démo de NeXTSTEP 3.0 est assez rigolote/triste de ce point de vue, on croirait voire une démo de OSX http://www.openstep.se/jobs/(...) -- finalement on a pas tant que ça progressé...)
Ceci dit, il y a nombre de choses que j'aimerait avoir sous GNUstep et qui amélioreraient les choses -- style des outils de refactoring automatique intégrés dans l'IDE -- mais il reste qu'en l'état actuel, c'est déja très, très confortable... et quand tu parles d'amélioration de l'informatique depuis les années 90, et que je regarde les environnements de développements Smalltalk des années 80/90, ben, y'a encore du chemin à faire, hein.. mais bon.
La force d'Objective-C et d'OpenStep, c'est d'être exceptionnellement bien adaptés à "l'agrégation" de composants et à la production d'interfaces graphiques. Mon avis, c'est qu'il faut essayer d'utiliser le bon outil pour un travail donné. Pour faire un moteur 3D qui tue, C++ est certainement bien meilleur qu'Objective-C. Pour faire une interface graphique, OpenStep est largement mieux, y'a pas photo. Pour batir un logiciel avec des "briques", Objective-C est idéal pour créer les dites briques, car on profite de toute la souplesse du langage. Par contre, pour implémenter le "contenu" de la brique, un autre langage peut être plus adapté, comme C++ par exemple.. enfin, c'est mon avis.
Bref. Tout ça est très simple à vérifier après tout: y'a plein de docs en lignes, tout est en free software, allez-y !
[^] # Re: Objective-C++?
Posté par Nicolas Roard (site web personnel) . En réponse à la dépêche Sortie de la distribution GNUSTEP 0.9.4, GNUstep news, et vidéo. Évalué à 2.
Concernant ObjC++, http://gcc.gnu.org/wiki/What%20will%20be%20in%204.0(...) indique qu'ils ont promis à Apple de sortir gcc 4 avec ObjC++ (par contre.. à priori c'est zem lasky qui s'en occupe, et vu ses prodigieux talents diplomatiques... espérons que ça ne déraille pas..). Bref, on espère, mais y'a de bonnes chances.
En étant raisonnable, on peut se dire que ObjC++ sera probablement là pour gcc 4.0, mais probablement (aussi) un peu buggé... bref... gcc 4.1 est l'hypothèse la plus raisonnable pour un ObjC++ stable. Maintenant, on espère que ObjC++ sur gcc 4.0 soit 1) effectivement là 2) pas trop mal fichu pour qu'on puisse commencer à l'utiliser. Qui vivra verra...
mais bon, gcc.gnu.org est plus ou moins mort en ce moment:
"machine went down for fsck on Thursday and found a HD died and then found out the RAID was corrupted"