La version 0.9.4 apporte de nombreuses nouvelles applications et bien évidemment une mise à jour des bibliothèques et des applications déjà présentes. GNUstep est une implémentation par la Free Software Foundation (FSF) des API OpenStep, qui comportent une partie graphique (AppKit, fournissant un ensemble de widgets graphiques réutilisables) et une partie non-graphique (Foundation, en charge des chaînes de caractères unicodes, tableaux, threads, etc.). GNUstep étant de plus multi-plateforme, il est facile d'obtenir des programmes portables (d'autant plus que sur MacOSX, Cocoa est également une implémentation d'OpenStep).
En plus de ces bibliothèques, le projet GNUstep fournit des applications d'aide au développement, comme ProjectCenter (un IDE) ou Gorm (un modeleur d'interface graphique.. mais pas uniquement) qui accélèrent grandement le développement d'applications.
GNUstep utilise Objective-C pour le développement, une extension au C ANSI permettant de faire très simplement de la programmation objet (fortement inspiré de Smalltalk), mais des bindings pour d'autres langages existent (Java, ruby, etc.). Objective-C++, un bridge permettant de mixer dans le même code source du C++ et de l'Objective-C devrait être inclu dans la prochaine version de GCC (4.0) (et ainsi utiliser le meilleur des deux mondes).
L'intérêt de GNUstep, en plus de fournir une implémentation libre d'une API de grande qualité, est la présence des outils de développements (en particulier, Gorm), accélérant de beaucoup le développement d'application (une étude publiée dans les années 90 concernant le développement sur NeXTSTEP indiquaient un facteur de 5 à 10 fois plus rapide -- ce qui s'explique en partie par la qualité des API, mais également car on a besoin de beaucoup moins de lignes de code : et qui dit moins de lignes, dit moins de bugs).
Une démo montrant le développement d'une application graphique en utilisant ces outils est disponible (voir les liens de la dépêche) -- jetez y un coup d'oeil !
Aller plus loin
- GNUSTEP 0.9.4 (19 clics)
- Le projet GNUstep (9 clics)
- Demo Flash (12 clics)
- Demo MPEG (6 clics)
- GNUstep au Fosdem 2005 (3 clics)
- Backbone (2 clics)
# bonne nouvelle
Posté par CrEv (site web personnel) . Évalué à 4.
J'étais interessé depuis un moment, et j'attendais justement un live cd pour tester avant de me lancer dedans (le download est en cours...)
La demo m'avais déjà bien interessé / intrigué.
En fait j'aime bien le principe (en tout cas ce que j'ai pu en comprendre et voir) et je trouve ce projet très interessant, malgré l'impression "d'austérité" qu'on peut avoir au premier abord... (en gros je trouve les concepts bien, mais ça manque un peu de "couleurs", mais bon, je vais peut-être changé d'avis sur ce point quand je l'aurai testé ;-) )
Bonne continuation
++
[^] # Re: bonne nouvelle
Posté par Nicolas Roard (site web personnel) . Évalué à 7.
une préversion de Camaelon 2 est sur http://www.roard.com/gnustep/,(...) mais 1) il faut le cvs gnustep (un bug dans le clipping a été corrigé hier) 2) le code est un peu bordélique 3) libérer la mémoire du cache graphique ? késako ? :-)
Donc me reste à finir ça, nettoyer le code et releaser le tout. Espérons pour la semaine prochaine, au pire avant le fosdem de toute façon.
Mais bon vala, ça bouge quoi, maintenant que j'ai pris un peu le temps de bosser dessus..
[^] # Re: bonne nouvelle
Posté par Anonyme . Évalué à 6.
Félicitations, ca à l'air d'être du super boulot !
J'espère que un bon aspect graphique va donner un bon coup de fouet à l'intéret porté à gnustep. Ce projet mérite toutes les attentions, et manque cruellement d'une plus large communauté.
[^] # Re: bonne nouvelle
Posté par g_remy . Évalué à 3.
Ou en est ton Dock que tu nous avais présenté dans l'un de tes journaux ? Il avait l'air très prometteur !
Sinon, que conseillerais tu a ceux qui veulent débuter dans la programmation Objective-C (Gnustep/Cocoa) ?
[^] # Re: bonne nouvelle
Posté par - - . Évalué à 6.
les premiers chapitres couvrent la syntaxe objective C et les fondements de cocoa qui sont les mêmes que openstep/gnustep
bon, ensuite ca part droit dans la maîtrise de apple Xcode et des évolutions de cocoa, et là, gnustep est largué.
sinon, gnustep.org a toutes les docs en liens.
Objective C a une syntaxe "c" mais est aux antipodes de C++, et utilise des concepts véritablement objets et basé messages, avec un runtime (mémoire managé ,garbage collector), l'introspection, le dynamisme etc. cela n'est pas inconnu (ironiquement, parce que objective C les précède) pour un développeur java ou c#
j'insiste véritablement sur le fait que Gnome et KDE ont pris leur essort parce que malheureusement GNUstep était méconnu et trop ambitieux pour être utilisable à l'époque, mais c'est une vrai tragédie.
Oui Gnome a pour moi atteint une grande qualité et c'est mon environnement de travail, et KDE est des plus complets et actifs, mais GNUstep aurait pu être le meilleur des environnements :
- un incroyable framework de développement, très mature, cohérent , complet, normalisé et documenté (openstep)
- des concepts d'interfaces tels les services ou la dock (ceux qui utilisent windowmaker savent que la dock est pas un gadget vain) vraiment en avance sur leurs temps
- un langage de développement moderne, objet et managé (mais pas interprété)
- un langage de scripting des applications
- des guides pour concevoir des interfaces d'applications CLAIRES (ca veut dire "lisible" pas forcément "blanc") et cohérentes hérités des travaux de Next/apple
bref, c'était une fondation solide et mature pour construire encore mieux
rendez vous raté, la communauté a tout réinventé dans gnome et kde, et peut être est il trop tard.
j'encourage vivement les gens à s'intéresser à gnustep ou cocoa d'apple (osx)
[^] # Re: bonne nouvelle
Posté par Nicolas Roard (site web personnel) . É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: bonne nouvelle
Posté par ... a little wood elfe . Évalué à 0.
Sinon pour la partie Cocoa que je connais mieux, j'ai utilisé au départ les tutoriels de http://www.projectomega.org/main.php(...) mais c'est trés orienté Mac OS X. Sinon pour des questions plus sur les frameworks ou le langage je conseille les forums de http://www.objective-cocoa.org(...) en français ou le wiki http://www.cocoadev.com/(...) en anglais.
[^] # Re: bonne nouvelle
Posté par - - . Évalué à 4.
vivement que Cameleon 2 soit une part normale de gnustep que les gens arrêtent de me brouter avec le troll "c gris"
:)
"Grey can be beautiful, baby"
[^] # Félicitations!
Posté par Brice Favre (site web personnel) . Évalué à 1.
[^] # Re: bonne nouvelle
Posté par Nicolas Roard (site web personnel) . Évalué à 3.
http://www.nongnu.org/backbone/images/screenshots/preferences-4.png(...)
inclu sur le cd ...
[^] # Re: bonne nouvelle
Posté par CrEv (site web personnel) . Évalué à 3.
Mais bon, c'est pas si grave ;-)
Sinon, j'ai testé (rapidement) le livecd, et c'est bien pratique comme méthode pour se rendre vraiment compte de ce que c'est.
Pour le moment ça me plait pas mal, d'ailleur j'ai commencé à installer sur ma mdk mais je butte sur qq prob tout con je pense ;-)
m'enfin, sur le principe je trouve ça bien, reste à avoir une interface un poil plus accueillante et je trouverais ça parfait !
# Objective-C++?
Posté par Larry Cow . Évalué à 5.
Tu peux me (nous) éclairer un peu là-dessus, sitouplé? ;)
[^] # Re: Objective-C++?
Posté par Nicolas Roard (site web personnel) . É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"
[^] # Re: Objective-C++?
Posté par Larry Cow . Évalué à 4.
Oui hein. Pourtant, d'habitude les MLs GNUstep sont plutôt tranquille, côté trafic. Mais là, ça m'avait fait très très peur.
ils ont promis à Apple de sortir gcc 4 avec ObjC++
Ah, c'est pile-poil l'info qui me manquait, super. Effectivement, s'ils ont promis, on a de bonnes chances.
Seul truc qui me chipote encore un peu, c'est qu'il ressortait des discussions qu'ObjectiveC (sans le ++, donc) ne faisait pas partie des langages "importants pour les releases" (à la différence de C et de ++). Leur promesse à Apple serait donc une forme d'exception à cette non-importance d'ObjC, ou bien ils sont revenus sur leur décision? (la réponse était surement dans la fin de la flamewar, mais je t'avouerais que j'ai pas eu le courage de lire jusqu'au bout)
Autrement, effectivement, si on n'a un ObjC++ fonctionnel qu'à partir du 4.1, ça serait déjà un moindre mal, surtout après qu'on ait failli avoir un ObjC cassé entre 4.0 et 4.1 :)
[^] # Re: Objective-C++?
Posté par Nicolas Roard (site web personnel) . É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: Objective-C++?
Posté par Croconux . Évalué à 1.
Il y a un détail qui me chifonne (comme dirait Colombo). Si ça gène tant Apple, pourquoi ne se bougent-ils pas pour l'implémenter ? Rien en les empêche de contribuer au lieu se contenter de profiter de la bonne volonté de développeurs bénévoles. Ils sont quand même les premiers bénéficiaires pour ObjC++.
[^] # Re: Objective-C++?
Posté par Larry Cow . Évalué à 1.
Le seul problème, c'est que ça casse manifestement plein de trucs. En effet, gcc a continué à avancer, depuis l'époque où Apple l'a "forké" pour créer sa version. Et aujourd'hui, on est en passe de se retrouver avec deux branches très éloignées: l'une gérant bien l'objective-C(++), l'autre fournissant des optimisations sympa pour C/C++.
On comprend donc mieux qu'Apple pousse pour l'intégration de leurs modifications dans mainline, faute de quoi ils se retrouveraient dans l'incapacité de:
1) fournir un jour un gcc standard par défaut (bon ok, je doute qu'ils souhaitent réellement faire ça, mais on se sait jamais)
2) récupérer des modifications futures de la branche principale dans leur version.
[^] # Re: Objective-C++?
Posté par oops (site web personnel) . Évalué à 0.
>passe de se retrouver avec deux branches très éloignées:
Il me semble d'ailleur qu'ils ont le même problème avec WebKit qui
est un fork du backend de konqueror
# trop génial
Posté par TImaniac (site web personnel) . Évalué à 6.
Pourquoi faut-il toujours un argument à la con comme celui-là ?
Ca me rappelle une blague : "Quelle est la différence entre un canard ?"
De plus le chiffre paraît complètment farfelu, même en imaginant qu'on puisse le comparer à quelque chose d'actuel.
Bref, j'en viens à me dire qu'ils ont une bonne dose de prétention exaspérente chez GNUStep, faudrait que quelqu'un leur explique que même si le projet initial semblait novateur et permettait effectivement un certain gain de temps, l'informatique a évolué, les langages et outils également.
[^] # Re: trop génial
Posté par Nicolas Roard (site web personnel) . É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: trop génial
Posté par Nicolas Roard (site web personnel) . É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 TImaniac (site web personnel) . Évalué à 3.
mais plus vite que quoi ??
Y'a toujours pas d'élément de comparaison !
Maintenant, quand tu dis que le dev informatique a évolué, oui, et non.
Je parles surtout des "alternatives", commes les langages/framework tel Python, Java, .NET, etc, mais aussi les outils comme Eclipse, Visual Studio, etc.
Et là je ne suis pas du tout convaincu que TrucStep puisse se vanter d'améliorer notre productivité.
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.
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...
Enfin tout ca pour dire que GNUStep et autre MachinStep ont été réellement innovant mais il est temps à mon avis d'essayer de faire prévalloir d'autres arguments pour le "vendre", l'argument de la productivité ne tenant plus beaucoup debout (je dis pas que que GNUStep est contre-productif, je dis juste que je suis moins convaincu de sa supériorité par rapport à d'autres solutions).
[^] # C'est pas si compliqué pourtant...
Posté par kwikwi . Évalué à 6.
La phrase précédente nous apprend que les développeurs ont fait le même programme sous NeXTstep et leur "système" précédent.
Le ton général de ces quelques lignes est à la gloire de NeXTstep, dont le nom est cité (au moins sous la forme de "NeXT") 4 fois en 6 lignes. 3 fois sur 4 pour dire que "c'est mieux avec NeXT".
Alors, sans doute, pour respecter vraiment la forme, aurait-il mieux valu écrire explicitement l'élément de comparaison, ajouter une cinquième fois NeXT(step), puis refaire mention du "système précédent" qui est l'élément auquel on le compare.
Mais franchement, à part les gens tâtillons ou de mauvaise foi, qui irait blâmer l'auteur de l'enquête (que Nicolas Roard ne fait que citer, a priori) de ne pas avoir alourdi son "bilan" de la sorte?
Ensuite, je passe une bonne partie de mon temps depuis quelques mois à pondre (sans prétention) des applications avec interface graphique en Java (Swing mon amour, je sais, sapusaipalibre mais ce n'est pas moi qui choisis) sous emacs et Eclipse, et j'ai regardé la petite vidéo de démo de NeXTstep.
Je trouve sympa la rapidité avec laquelle on peut développer une application graphique comme c'est montré. Il faut voir à l'usage comment ça rend pour des applications plus complexes, avec un vrai MVC derrière (i.e. avec un vrai modèle...).
Il faut également comparer ça aux outils de développement du même type (si j'ai bien compris le fonctionnement de cette partie de Gorm) qui existent comme Bean Builder pour Java.
Or les Beans sont très "à la mode", parce que ça permet de développer plus vite. (Plus vite que quoi? Je te laisse deviner, mais ça parle de réinventer la roue et de taper encore une fois les mêmes bouts de code que d'habitude...)
Nier le fait que le développement d'applications à base de composants fait gagner du temps, c'est un sacré défi.
Alors oui, par rapport à Eclipse + Bean Builder (ou l'environnement de développement Delphi qui permet il me semble ce genre de choses), on ne gagne peut-être pas de temps.
Mais ça reste un gain de temps par rapport à la programmation "à l'ancienne" qui est encore la majorité des cas.
Montrer aux gens qu'ils peuvent développer rapidement et facilement avec NeXTstep, comme ils pourraient le faire avec d'autres logiciels pour d'autres langages et avec d'autres contraintes (notamment de liberté, cf. le Java de Sun avec Swing) ce n'est pas inutile.
Y a-t-il un équivalent vraiment libre à ce que propose NeXTstep?
(C'est une vraie question ouverte, tous éléments de réponse bienvenus...)
En tout cas, NeXTstep a le mérite d'exister sur ce créneau, et c'est tant mieux.
(Pour la peine, j'y donnerai peut-être un galop d'essai un de ces quatre.)
[^] # Re: C'est pas si compliqué pourtant...
Posté par Croconux . Évalué à 4.
Mais justement c'est quoi leur système précédent ? Cobol + Vi ? C++ avec Emacs ? C'est bien là le problème : On dit pas avec quoi on a comparé. L'étude date de 92, 13 ans, une éternité à l'échelle de l'informatique. Java date de 94 donc il n'y avait pas de Java parmi les "anciens systèmes", pas plus que de python, .Net, etc. Bref il faudrait comparer ce qui existe aujourd'hui. Les résultats d'une étude aussi vieille ne sont plus d'actualité. En cherchant bien on doit pouvoir trouver une étude aboutissant à la conclusion que les gens sont plus productifs avec Cobol qu'avec leur "ancien système". Evidemment il ne faut pas regarder la date de l'étude ni le fait que l'ancien système c'est peut être l'assembleur ou l'hexa.
[^] # Re: C'est pas si compliqué pourtant...
Posté par oops (site web personnel) . Évalué à 3.
de NeXT pour le fun, mais qui n'est pas approprié de nos jours ( et qui reste un "argument" marketing :)
Cependant, il me semble que IB ( Gorm pour GNUstep ) que reste
très au dessus de ce que j'ai pu essayé en Java ( JBuilder ), à Glade
ou à QTDesigner.
En terme d'utilisabilité, de fonctionnalités, le fait que cela ne gère pas
du code pourris ( mais une forme sérialisé ) etc ...
[^] # Re: trop génial
Posté par Nicolas Roard (site web personnel) . É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 TImaniac (site web personnel) . Évalué à -2.
Objective-C n'est pas le seul à proposer cette superbe fonctionnalité. Ce que je voulais dire c'est que c'est surtout compliqué d'utiliser plusieurs langages en parallèle, celà multiplie les coûts de maintenance, sans parler du déploiement... (la preuve celà marche que sur Mac)
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é.
Stop on dirait un spot publicitaire :)
Alors question réutilisabilité, je veux : utiliser mes composants EJB, tout en interagissant avec des objets COM distribués.
Tu vois ce que je veux dire ?
La réutilisation c'est gentil mais il ne faut pas que ce soit un "copié-collé" d'un morceau de code C/C++ (ce qui limite tout de usite les possibilités d'ailleur) pour l'intégrer dans un composant Objective-C. C'est la pire solution de réutilisation que je connaisse : la maintenance sera affreusement répartie, pouf productivité en chute libre.
lequel est même déporté sur une autre machine, merci les DistributedObjects.
Mais dis donc c'est révolutionnaire tout ça à notr époque :)
GNUstep/Cocoa n'est pas la réponse ultime -- mais au moins pour créer une interface graphique, je te garantit que ça booste.
Mais comme d'hab je suis convaincu que GNUStep permet de gros gain de productivité si l'on compare à la programmation traditionnelle en C, mais si l'on compare avec des solutions plus modernes (JBuilder, Eclipse, Visual Studio), j'ai des gros doutes.
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.
Moi je peux te faire une démo en Java ou VB identique qui te prends également 2 lignes de codes à écrire :)
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.
Alors oui GNUStep est une bonne solution, qui propose de nombreux avantages (notamment en terme de productivité par rapport aux autres solutions), mais je vois toujours pas l'intérêt de phrase du genre :
"vous allez développez 2 fois plus vite"
Non seulement celà ne veut rien dire, mais en plus si la phrase n'est pas finie, c'est volontaire : vous savez très bien que la comparaison date d'il y a 10 ans et ne tiens plus la route.
[^] # Re: trop génial
Posté par CrEv (site web personnel) . Évalué à 4.
Peut-être que ça ne marche que sous MacOs et GNUstep parce que se sont les seuls à implémenter les spec Nexstep, non ?
Si c'est juste une phrase qui te gène tant que ça, ingore là et passe ton chemin, non ? puisqu'en plus tu admet que c'est une bonne solution...
Personne n'a dit que c'était (ou en tout cas moi je ne l'ai pas compris comme ça) le meilleur environnement qu'il puisse exister et que tout le monde devrait s'y mettre sans réfléchir...
Evidemment que d'autres systèmes sont désormais d'une puissance presque aussi égalable, bien que j'en sois pas convaincu...
Si on regarde un peu les environnements actuels et qu'on regarde nextstep en même temps, ce qui me sidère c'est de voir que tous les autres on mis une dizaine d'année pour être presque aussi bien...
Je sais pas vous mais moi je trouve ça plutôt domage...
[^] # Re: trop génial
Posté par TImaniac (site web personnel) . Évalué à -1.
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. Mais bon d'après ce que jugent les gens de mon dernier post mes propos ne sont pas intéressant donc je ne m'étendrais pas plus longtemps sur le sujet.
Si on regarde un peu les environnements actuels et qu'on regarde nextstep en même temps, ce qui me sidère c'est de voir que tous les autres on mis une dizaine d'année pour être presque aussi bien...
En même temps pour faire du RAD, le VB existe depuis 91... le Java depuis maintenant plus de 10 ans...
Alors donc je le demande encore une fois : qu'apporte NeXTStep de plus que la concurrence, aujourd'hui ? (afin de justifier son adoption)
Moi j'ai trouvé pas mal d'inconvénients :
- MVC c'est pas top.
- générer des controllers dépendant d'un framework graphique c'est pas top du tout.
- 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.
- la réutilisation du code basé sur le copié-collé c'est nul.
- la réutilisation de code C++ est limité au monde Mac.
Maintenant je veux les avantages et surtout atouts par rapport aux autres solutions.
[^] # Re: trop génial
Posté par Volnai . Évalué à 3.
Java c'est mignon mais ca ne marche que si tu as une JVM.
Ce que tu dis n'est pas forcement faux (a vrai dire je sui loin d'être assez qualifié pour en juger), mais ce qui ressort quand on te lis c'est que tu n'as jamais essayé. Et du coup, c'est normal que tu ne sois pas convaincu...
[^] # Re: trop génial
Posté par Nicolas Roard (site web personnel) . É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 bleh . Évalué à 3.
C'est amusant parce que c'est justement le pattern qui a motivé la création des JSP, des Servlets et des EJB ... Ce vieux pattern datant du smalltalk est bien pratique pour séparer les couches justement. Je suis comme Nicolas j'aimerai bien que tu étayes ...
[^] # Re: trop génial
Posté par Frédéric Lopez . Évalué à 2.
http://www.object-arts.com/EducationCentre/Overviews/MVC.htm(...)
Pour une meilleure solution, voir le MVP :
http://www.object-arts.com/EducationCentre/Overviews/ModelViewPrese(...)
[^] # Re: trop génial
Posté par Nicolas Roard (site web personnel) . É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 ... a little wood elfe . Évalué à 1.
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 :-(.
J'ai plein d'autres questions mais vu que je viens d'enfin réussir à m'inscrire sur la ml je vais les leur réserver (a priori l'interface web d'inscription aux mls ne marche pas).
PS : comme exemple de réutilisation aisée de code je citerais le cas du framework QuickLite qui encapsule dans de l'Objective-C le code de SQLite de manière fort simple et élégante (appréciation subjective basée sur mon peu d'expérience de ces choses là) et que j'utilise actuellement dans un nouveau projet.
Je pourrais aussi citer la manière dont Apple a réalisé le framework WebKit en encapsulant le code c++ de khtml. Je ne sais pas combien de temps cela prend à Apple de maintenir ce framework ou combien cela leur a pris de le réaliser mais d'un point de vue développeur l'accès aux fonctionnalités de khtml est tout de même beaucoup plus simple via WebKit.
[^] # Re: trop génial
Posté par Nicolas Roard (site web personnel) . É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: trop génial
Posté par ... a little wood elfe . Évalué à 0.
J'ai déjà essayé l'installation à partir des sources des releases officielles ou du CVS mais je finis toujours par me heurter à une erreur de compilation qui d'après le message retourné par gcc serait une erreur de gcc ???
Du coup je suis donc obligé d'utiliser les paquets debian.
[^] # Re: trop génial
Posté par Croconux . Évalué à 4.
D'autant qu'au début des années 90 tout celà n'existait pas. Le langage de référence c'était C++. Je veux bien croire qu'Objective C soit plus simple et moins prise de tête mais ça n'est pas très compliqué d'y arriver : A peu près tout est plus simple que le C++.
# Torrent ?
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.