Nicolas Roard a écrit 1135 commentaires

- Objective-C met l'accent sur les décisions au temps de l'execution, alors qu'ooc essaie d'attraper les erreurs au temps de la compilation.


Ben uniquement si tu le veux, sinon le compilo t'engueule hein...


- Objective-C n'est pas traduit en C mais compilé directement. Parmi les inconvénients, cela veut dire qu'il faut porter le compilateur sous toutes les plateformes visées. Dans le cas d'ooc, on peut utiliser le compilateur ooc pour traduire .ooc -> .c/.h, puis utiliser gcc pour cross-compiler sur un des 50+ architectures qu'il supporte.


En meme temps vu que le compilo objc le plus utilise c'est gcc, on est a peu pres tranquille concernant la problematique du multi-plateforme ;-)

Plus serieusement, il y a pas mal de trucs interessants fait en ce moment autour de LLVM, et David Chisnall a implemente un frontend Objective-C.


Enfin, ooc est inspiré en partie de Java, lui-meme inspire (entre autres) d'Objective-C, lui-meme inspire de Smalltalk. Concrètement, Objective-C est un langage mature qui apparamment ne changera plus beaucoup. Cela permet une grande stabilité, mais le langage est condamné a rester dans ses habitudes: il est trop tard pour tirer les leçons du passé (par exemple, gcc semble ne pas supporter totalement ObjC 2.0). Par contraste, ooc est un jeune galopin qui essaie d'apprendre de ses grands-parents. Il est largement encore temps de s'impliquer et d'influer sur le design.


J'allait justement souligner ObjC 2.0 -- pour un langage qui ne changera plus beaucoup, c'est un changement assez recent... (bon par contre, c'est en gros Apple qui pousse :-/)

Pour ce qui est du support ObjC 2.0 dans gcc, pas sur a 100% mais il me semble que gcc supporte tout ce qu'il faut... mais libobjc non. ObjC est dynamique et utilise un runtime, i.e. libobjc sous linux, et le runtime NeXT sur OSX, qui lui supporte ce qu'il faut.

Pas tout a fait les memes mesures, mais je m'etait amuse a faire joujou avec les perfs ObjC y'a quelques temps...

http://camaelon.blogspot.com/2007/01/fun-with-objective-c.ht(...)

Note qu'en pratique, la seule fois ou j'ai fait du IMP-caching c'etait sur un algo de rendu volumetrique qui devait aller aussi vite que possible (pour avoir du rendu interactif reparti), et encore c'etait loin d'avoir ete LE facteur determinant au niveau rapidite...

Pour un logiciel 'normal' y'a franchement peu d'interet de nos jours je trouve. Maintenant bon, ce qu'il y a de bien c'est qu'on peut toujours le faire si vraiment on veut ;-)

En plus de Smalltalk, le fait de pouvoir utiliser les biblotheques d'Etoile font la difference -- tout particulierement EtoileThread. Jetez un oeil aux source de Melodie, ecrit en Smalltalk, multithreade tres facilement grace a EtoileThread (qui implemente un modele concurrent base sur les futures).

Le gros "probleme" de squeak c'est son interface graphique, qui fait fuir enormement de gens. J'avoue que la premiere fois qu'un copain m'a montre squeak il y a 7 ou 8 ans, j'ai trouve ca sympa, morphix (le toolkit graphique) assez puissant (avec la demo du texte contenu dans une bulle/chemin) mais completement "gadget" et j'ai passe mon chemin. Belle erreur !

Smalltalk est un langage/environnement vraiment fabuleux, qui permet de developper a une vitesse folle, et avec une souplesse inimaginable. Pour un programmeur, c'est un pur regal (oui, je suis un fan, ca se voit?)

Ca t'amene aussi a changer assez radicalement la facon dont tu abordes la programmation, et puis, ca permet de comprendre vraiment ce que c'est la POO :)

Maintenant, morphix, je peux pas piffrer comme toolkit, y'a de bonnes idees a la base mais le resultat actuel est un salmigondi de code... cocoa/gnustep est a cent coudees au dessus je trouve.

Par contre la machine virtuelle qu'est-ce que c'est lent !

Heu... non, du tout ! la VM squeak en tant que telle est plutot veloce ! Par contre, l'interface graphique des dernieres VM rame bien plus que du temps de la 3.6/3.7 ... j'avoue ne pas avoir trop suivi le pourquoi du comment, et puis bon, les fois ou j'utilise squeak je reste cantonne au browser de classe + transcript + workspace :D donc ca va...

Sans vouloir paraître vexant, est-ce que c'est vraiment "utilisable" ?

Ca depends pour quoi. Pour du prototypage, c'est proche de l'ideal. Pour faire une appli cliente, eventuellement pourquoi pas, mais tu peux oublier une integration avec le reste des applis de ton ordi (quoi que, il me semble qu'il y avait un bridge wxWidgets, donc je dit ptet des betise).

Reste le web -- si tu ne connais pas, essaie http://www.seaside.st , c'est le meilleur serveur d'application web que je connaisse, c'est absolument monstrueux :) -- tu as tous les avantages de smalltalk (expressivite du code, concis, le debugger, refactoring browser, etc.) associe avec une framework de dev hyper bien foutu. C'est phenomenal, particulierement quand on compare avec le reste des "offres" dispos pour developper des applis web. C'est bien simple, Seaside permet de developper une appli web aussi simplement -- voire plus simplement, ca depends de quelle plateforme on parle ;-) -- qu'une appli desktop. Et tout les problemes que peux avoir Squeak du point de vue UI passent evidemment a l'As vu qu'on fait du HTML+CSS...

Associe a Magritte (un framework permettant de decrire tes objets et qui du coup peut generer automatiquement un tas de trucs pour toi, ce qui est une bonne chose vu qu'on est paresseux) c'est assez genial..

Un exemple d'application seaside: http://www.dabbledb.com (qui en soit est aussi tres, tres interessant, d'ailleurs ;-)

Super initiative !

Franchement, la bouffe gratuite c'est un avantage en nature tres sympa: il y a une multitude de cafeteria sur le campus avec un tas de menus differents, sans parler des micro-kitchens un peu partout. Mais en plus, les cafet servent vraiment de la bonne bouffe ! :)

Un autre aspect tres interessant, c'est le nombre de conferences qui sont organises sur le campus -- on peut litteralement passer sa journee a assister a des confs, sur un tas de sujets differents, par des intervenants exterieurs ou des gens de chez google. Quand j'y suis passe il y'a 3 mois, j'ai pas arrete de croiser guido van rossum dans un tas de confs par exemple :-P

vu que tu me dis que lisaac genere un fichier c, deja ca devrait etre trivial de linker ca avec gnustep. Apres il te reste a faire le binding lui meme, mais bon... pas forcement bien difficile -- probablement en utilisant les fonctions C du runtime objective-c. Par contre, le coup de ne pas autoriser des envois de messages non definis, ca peut poser problemes.

En même temps, tu sait jamais quand un langage "exotique" te sera utile -- au cours d'un entretien d'embauche j'ai eu une boite qui m'a demandé si j'avais déja programmé en ... PostScript (!!) -- la raison étant qu'ils avaient un langage maison implémentant de la logique métier, assez proche de PS (stack-based quoi).

De façon moins anecdotique, je trouve qu'avoir programmé en lisp ou smalltalk (ou autre langage dynamique) change assez radicalement la façon dont on programme par la suite, même si on se retrouve à faire du C/C++/Java. Et en règle générale je suis persuadé qu'on s'enrichit beaucoup au contact de langages "exotiques" -- ça permet d'avoir une autre approche à son arc...

et... ubuntu n'est pas basé sur debian ?

la raison de partir d'une base ubuntu plutôt que d'utiliser debian-live c'est tout simplement qu'il y avait moins à faire :-) -- ubuntu fait tout le boulot pour son live cd, il m'a paru plus simple de partir de là et de virer /modifier ce qui nous intéressait pas plutôt que de partir quasi à zéro de debian-live -- surtout vu qu'ubuntu continue à améliorer son live cd, reconnaissance du hardware, etc. À la base hein, ce qui nous intéresse, c'est montrer étoilé/gnustep, pas la conception d'un live cd en soi ;-)

Ceci dit, le live cd gnustep de gürkan (http://www.linuks.mine.nu/gnustep/) utilise debian-live. Mais comme pour le live-cd étoilé tout est recompilé à la main via le svn, franchement,... n'importe quel base de live cd suffirait. Donc autant prendre le live cd qui a le plus de chance d'être à jour sur les dernières technos... et puis y'a quand même un minimum de doc pour modifier un live cd ubuntu.

Disons que j'avais juste envoyé un mail sur gnustep-dev et etoile-dev, mais vu que jesse a rajouté le paragraphe sur etoile-project.org... un peu normal du coup que la news filtre plus que ce que je pensais !! :-)

La pub pose pas tellement de problème, c'était juste que la release finale sera bien mieux :)

Pour les paquets GNUstep, en général debian est à jour, pour le reste je ne sait pas trop... les ports FreeBSD devraient être ok également, il me semble. Ceci dit concernant debian, les paquets n'ont pas encore été updaté avec la nouvelle version, mais les mainteneurs sont en train des les préparer.

Ceci dit, c'est pas non plus bien difficile à compiler à la main... si les dépendances sont installées.. Un post d'il y a deux jours de Yen-ju : http://www.etoile-project.org/etoile/blog/2006/08/short-guid(...) explique tout ça.

Comme programme, ça dépends de ce que tu veux... GWorkspace comme file manager par exemple; si tu installes étoilé, EtoileMenuServer, etc.

Concernant WindowMaker, non, il ne s'adaptera pas aux thèmes gnustep; pour étoilé on a notre propre window manager, Azalea.

J'ai vraiment envie de l'installer, pour le découvrir, pour faire des programmes utilisant GNUStep ... mais lorsque je vais sur le site, je ne vois rien de tout ça, et le site insiste pour dire que c'est juste un frameword. Enfin, derrière il y a quand même un bureau comme on peut le voir sur bon nombre de sceenshoots.

C'est tout le problème... ce n'est qu'un framework, oui; mais d'un autre côté, il fournit tout ce qu'il faut (presque) pour avoir un bureau (cad que le framework fournit aussi quasiment tout les services nécessaires à un bureau -- notifications, préférences, notion de workspace commun, etc), de telle sorte que simplement utiliser une appli comme gworkspace (pour avoir un gestionnaire de fichier) et d'autres applis utilisant gnustep suffit pour avoir un bureau bien intégré (cf le livecd). D'ou l'ambivalence de GNUstep. Si tu veux, c'est au même niveau que les KDE libs -- elles ne sont pas le bureau KDE, mais elles fournissent tout ce qu'il faut pour créer des applis qui ensemblent forment un bureau.
Sauf qu'en plus, GNUstep fournit des applis pour le développement (Gorm, project center, etc) et même des applis qui sont carrèment fait pour un bureau comme gworkspace.

Mais GNUstep en tant que projet n'a pas eu comme objectif (et rétrospectivement c'est certainement une erreur) de créer un bureau. Il aurait fallu avoir cet objectif depuis longtemps, ou au moins un projet frère chargé d'en créer un...

Pour le moment, étoilé progresse bien, et régulièrement; mais on n'a pas encore un truc tout prêt à utiliser offrant un bureau nickel. Étoilé reste pour le moment une série de librairies, d'outils et d'applications (aaargh on dirait gnustep !!!). Mais bon on espère très fort avancer vite fait vers un bureau réellement utilisable :-D et en particulier, un filemanager + desktop + gestionnaire de session qui tienne la route (gworkspace ne nous plait pas pour diverses raisons).

En attendant.. ben je dirait que la combinaison gworkspace + window maker reste le plus sûr, plus project manager pour le développement ( http://pmanager.sf.net ) et gorm évidemment..

Que veux tu dire ? Je me souviens pas avoir présenté les choses comme ça, mais bon, possible, je suis un incorrigible optimiste combiné à un sale procrastinateur :-)

Si tu parles du support des thèmes sous gnustep, ça fait très longtemps qu'on peut les utiliser... La seule chose c'est que le dit support n'est pas inclu par défaut, faut utiliser Camaelon, mais c'est pas la mort à utiliser hein... J'ai une branche sur le repository gnustep pour intégrer certaines parties de camaelon, mais j'avance pas très vite (j'ai plein d'autres trucs sur le feu, et une thèse à finir). L'intégration serait un _plus_ pour diverses raisons, mais n'est pas nécessaire -- la preuve, on utilise Camaelon avec étoilé, et on utilise bien le thème Nesedah par défaut...

Accessoirement, le look en question, ça peut difficilement faire 2-3 ans -- au pire ça fait dans les un peu plus d'un an, vu que c'est dans ces environs qu'il a été créé par jesse ross si je dit pas n'importe quoi.

'fin bon c'est comme tout hein, si y'a des contributeurs tout ça avance plus rapidement, bizarrement :-)

Oui, les tutoriels de Nicola sont bien pour démarrer. Jette un oeil sur http://www.roard.com/docs/ , je link pas mal de docs/tutoriels (quoique ça fait un bail que je l'ai pas mis à jour). Sinon la plupart des tutoriels pour Cocoa et/ou les docs d'Apple sont utilisables tels quels.

Comme ide, y'a aussi ProjectManager (http://home.gna.org/pmanager/) qui est plutôt sympa.

Comme bouquin, je conseille celui d'Aaron Hillegass, excellent (plutôt l'édition anglaise que française, dont j'ai trouvé la traduc très moyenne, mais bon..). Y'a aussi celui de Garfinkel qui est paraît il très bien. Ils sont orientés Cocoa (même si Aaron parle de GNUstep, m'enfin il parle d'une vieille version...), mais sont focalisés sur le framework, donc appliquables plus ou moins tel quel à GNUstep. Concernant Objective-C uniquement, il y a le très complet petit guide d'O'Reilly sur Objective-C.

Oui et non -- le thème est déja utilisé par étoilé ( http://www.etoile-project.org et http://www.etoile-project.org/etoile/blog/ , voir les screnshots) .. mais au final pour étoilé on a par défaut un menu horizontal à la mac os, et on veut un "dock" avec des tabs plutôt que le dock montré sur le concept 01.

oui bon... utiliser un thème peut être ? http://www.etoile-project.org/etoile/blog/

D'un autre côté, on dispose de DistributedObject (DO) sous GNUstep :-P donc faire de la prog inter-processus c'est facile :D -- les objets distants se comportent comme étant locaux (2 lignes à changer en déclarant son objet..). Et les distributed notifications aussi... ;-)

Je connais pas dans le détail les translators de BeOS, mais c'est probablement une archi similaire -- ce que je voulais dire c'est que faire ça en ObjC c'est trivial ("de base" avec le langage quoi) alors qu'avec C++ c'est évidemment possible (c'est bêtement un plugin -- une librairie partagée hein !) aussi. Mais bon avec un langage dynamique, ce genre d'archi logicielle "ouverte" est évidemment plus simple, alors qu'avec un langage plus statique, ben... c'est moins souple et faut se taper le boulot à la main...

Ce sont bien des librairies; mais effectivement c'est entre autre parce qu'Objective-C utilise un runtime pour le passage de message (cad, le code est bien compilé -- ça reste du C -- mais les messages eux sont dynamiques).

Ceci dit, ce que je dit marche(rait) aussi avec des "plugins" normaux -- c'est juste qu'objective-c est dynamique et baigne dans le polymorphisme... donc ce genre de chose est faisable bien plus facilement.

L'intérêt ? bah ... effectivement, il n'est ni normalisé ni répandu -- la seule plateforme capable de lire du rtfd en dehors de GNUstep est Mac OS X (et NeXTSTEP/OPENSTEP évidemment).

Mais le RTF est le format par défaut sous NeXT/GNUstep/ OS X pour le texte enrichi; et GNUstep savait donc déja lire/sauver du RTFD. Étendre le parseur pour du RTFD était trivial. le RTFD est une simple application du concept de bundle (en gros, considérer un répertoire comme un document) à un document RTF : c'est tout bêtement un répertoire contenant un ou plusieurs fichiers RTF accompagnés éventuellement d'images ou fichiers liés.

Bref 1) c'était simple à ajouter 2) ça existait sous NeXT et OS X 3) surtout, c'est un moyen simple de sauver facilement n'importe quel contenu enrichi à partir de n'importe quel textview, même contenant des images. Du coup par exemple, TextEdit peut être utilisé comme mini traitement de texte, il suffit de drag'n dropper des images dans la vue texte.

Accessoirement, le code pour lire/sauver du RTF(D) est gêré par un bundle (~plugin) sous GNUstep -- on peut tout à fait avoir le même genre de bundle pour d'autres formats (je voudrais d'ailleurs ajouter HTML en sauvegarde par exemple). Et la beauté de la chose du tout objet c'est là encore que toutes les vues textes disposeront de cette capacité automatiquement... (sans même recompiler)

Ben... les API ne sont pas propriétaires, d'une part... et de deux, l'intérêt n'est selon moi pas (que) d'être compatible avec Apple. L'intérêt c'est de pouvoir disposer de ces api et des outils comme Gorm pour programmer, tout simplement car ce sont des outils assez géniaux !

Pour faire simple: si Apple n'avait pas racheté NeXT et transformé NeXTSTEP en Mac OS X, et même imaginons que NeXT ait coulé complètement... Et bien il y aurait toujours des gens développant GNUstep. L'api et des outils comme Gorm sont, par eux-mêmes, intéressants. Ca reste l'environnement de développement le plus génial et bien foutu que je connaisse (si on excepte Smalltalk -- mais si Smalltalk est un environnement/langage assez fabuleux, l'api est une bouse à bien des égards comparé à OpenStep).

Le fait qu'Apple utilise Cocoa n'est que la cerise sur le gateau pour ceux que ça intéresse; on n'est pas du tout dans le cas de Wine par exemple, ou je doute que les développeurs bossent sur Win32 car ils trouvent l'api agréable à programmer.

Vu qu'office mac utilise Carbon et pas Cocoa, ça semble déja mal barré ;-)

juste à préciser, quand même: les templates de code consistent simplement à créer pour toi les fichiers des classes éventuellement définies dans Gorm/IB (cad, juste le header et les déclarations des méthodes). Ce n'est pas du tout du code généré pour créer/gêrer l'interface -- ce qui est la grande différence entre l'approche Gorm/IB et le reste des constructeurs d'interface -- vu que l'interface et tout le reste sont déja des objets; un "nib" est simplement la sérialisation dans un fichier de l'ensemble des objets composants l'interface.

Il y a deux principaux avantages à cette approche: 1) ça fait largement moins de code à écrire ou maintenir 2) un nib n'est pas du tout limité aux objets "graphiques" (boutons et autres) mais on peut tout à fait inclure dans le nib n'importe quel objet (objet controlleur de l'interface, un objet métier, etc)

Du coup on peut aussi créer des palettes d'objets à soit et utiliser Gorm (ou IB) comme un outil de RAD très haut niveau, et créer un programme en deux-clics de souris sans une ligne de code ;-) -- bref cette approche permet de réutiliser très facilement des composants.

voir les vidéos de démo: http://xdev.org/gnustep/ (flash)

Squeak 1.1 a finalement été releasé sous APSL2 (http://www.gnu.org/philosophy/apsl.html) par Apple y'a environ deux mois... donc c'est libre :D (même si pour debian je pense qu'ils acceptent pas l'APSL2... uhuh)

Reste que Squeak 1.1 ça date; mais en même temps, tout ce qui a été ajouté depuis l'a été par des volontaires (afaik Alan Kay a confirmé que Disney n'avait pas les droits sur le code releasé quand l'équipe était chez Disney), donc ça devrait être possible de relicencier tout ça (bon c'est du boulot, mais y'en a qui bossent dessus justement...)

Et puis zut, même la licence précédente n'était pas si mauvaise que cela... Le drame de la licence de Squeak est que c'était probablement un des premiers projets "open source" d'apple je pense, et leurs avocats avaient fait un petit caca nerveux avec une licence trop restrictive :-) (interdiction d'exporter squeak dans les pays soumis à l'embargo américain, etc)

Si tu veux changer d'air ... essaie des langages dits "exotiques". Ma préférence va -- de très loin -- à Smalltalk, mais Lisp est particulièrement intéressant, sans parler d'erlang (ouaip vive le réparti!) et autres Haskell. Mais honnêtement... Smalltalk te fait changer complètement de point de vue sur la programmation et sur le genre d'architecture que tu peux créer. Jette un oeil à Squeak (une implémentation Smalltalk libre), à Seaside (un framework de construction d'appli web absolument incroyable, basé sur Smalltalk), etc. Déroutant au début, difficile de s'en passer après. Et chose marrante, on a tendance à coder ensuite de façon bien plus élégante même dans d'autres langages (ce que je viens de dire pour Smalltalk s'applique entièrement à lisp, mais perso je préfère Smalltalk ^_^).

Ruby est particulièrement inspiré de Smalltalk, mais reste moins puissant et moins rapide. Mais si tu aimes le genre de dynamisme que ruby permet, tu seras heureux avec Smalltalk :-) -- d'autant plus que tu te retrouves aussi avec une floppée d'outils facilitant le développement (refactoring tools, etc)

Sinon, dans le genre plus terre à terre, faut essayer Objective-C : c'est un mix de C et de Smalltalk, c'est utilisé pour la programmation OS X (Cocoa), et sous linux tu peux utiliser GNUstep. Dans les langages autre que Smalltalk c'est mon préféré -- on peut coder de la même façon en gros qu'en Smalltalk, de façon très dynamique/réflexive, et en même temps si on a besoin d'aller faire le gros sagouin avec des pointeurs pour gagner du temps, bah ça reste un sur-ensemble du C après tout, donc on peut s'y donner à coeur joie. Bref un très bon mix des deux.

Bref, y'a pas que C/C++/Java dans la vie, et heureusement il y a des langages plus intéressants...

Pour ce qui est de s'embêter à recoder toujours la même chose, après tout l'idée c'est quand même d'isoler ce genre de codes dans des librairies ou des frameworks :-) (note: un framework n'est pas une librairie: la différence tient au fait qu'avec une librairie, tu appelles du code pour effectuer telle ou telle action, alors qu'un framework est conçu pour te fournir un canevas générique ou tu n'as qu'à complêter les trous). Voire le concept de Domain Specific Languages aussi.

Un site intéressant sur les langages dynamiques, fonctionnels, etc. est lambda the ultimate : http://lambda-the-ultimate.org/

Un "truc" évident aussi, si tu ne sait pas quoi coder, c'est tout bêtement de réfléchir à un outil qui te manquerait, et de le créer...

Bon maintenant si vraiment l'info te sort pas les trous de nez, faut ptet penser à faire un break et/ou à penser à une reconversion; si vraiment tu tient à rester dans l'info, tu n'est pas non plus forcé de pisser du code, y'a d'autres évolutions possibles (archi logicielle, etc). Et puis il reste la possibilité de se lancer dans la recherche, en général tu peut faire des choses plus intéressantes que dans l'industrie, et tu est plus libre de bosser sur ce qui t'intéresse..

bon courage en tout cas ;-)

Oui, de la pesanteur des idées reçues... ;-)
J'ai pourtant précisé l'implication de sociétées privées dans le LL par ailleurs, mais pof, ça m'a échappé dans cette phrase.