Damien a écrit 158 commentaires

Pas tant que ça, Stéphane Ducasse, l'un des auteurs de Skweek le jeu, est contributeur de Squeak le Smalltalk libre : http://stephane.ducasse.free.fr/skweek2.htm

Les volontaires pour une mise à jour du jeu seraient très bienvenus, contactez les auteurs !

Apple est un des gros contributeurs à LLVM.

oui franchement les screenshots sont pas mal... par contre une question que je me pose, les caractéristiques de vol des avions sont crédibles ? par exemple je vois qu'il y a quelques planeurs, est-ce que le nez part bien à droite si on met le manche à gauche sans assister au palonnier ?

J'utilise pdfLaTeX par défaut et j'ai jamais vu ce problème… donc un argument de plus pour abandonner le DVI. À mon avis, sauf besoin vraiment particulier, DVI est obsolète, les développements se font plus sur pdflatex maintenant, et avec microtype il sort des résultats plus jolis.

trop gros :-)


Sinon comme boite il y a Heeg en Allemagne, aussi. Voir les sponsors de ESUG: http://www.esug.org/

Le truc c'est que la plupart des développements sont pour des grosses boites, qui demandent des développements perso et qui n'en font pas la pub puisque c'est des outils internes. Soops par exemple leur truc gère les négociations et échanges d'électricité entre les producteurs européens. Je crois qu'AMD au une usine où les robots de production sont gérés en Smalltalk.

Bref c'est un peu comme Erlang, il y a des millions de lignes de code dans le monde, mais planquées dans des gros systèmes.

JP Morgan, UBS je crois bien, et sinon SOOPS à Amsterdam. Je cherche pas de taf dans l'industrie, donc c'est celles que je connais par des contacts académiques.

ou alors le "modèle de conception" est une implémentation à part entière de la solution

Oui, par exemple une implémentation dans un langage de haut niveau, expressif, flexible… Y'en a même des comme ça qui compilent avec des perfs décentes :-]

En même temps, les bugs de compilateurs ça se fait remarquer assez vite d'habitude…

Il n'y a pas de sérialisation, l'image est juste un snapshot de la mémoire après un full GC. Si tu ajoutes une variable d'instance, tous les objets concernés sont mis à jour (évidemment pour les objets qui se font mettre à jour, la nouvelle variable d'instance est vide donc ça peut poser problème is on ne fait rien).

Dans ce cas, non (le compilo Smalltalk lit des chaines et produit du bytecode, tout pareil). C'est le "métier" d'un compilo de transformer du code d'une représentation à une autre.

Ah sisi on les utilise, je connais des spécimens de Smalltalk Sapiens Industrialis. C'est rare comme bestiole, certes, mais c'est intéressant à côtoyer :-)

Oui bien sûr, mais tant que le "comment faire" est rangé dans les bonnes couches d'abstraction c'est pas trop grave.
Je voulais surtout faire remarquer que le code, idéalement, c'est lisible. Ce n'est pas une sorte de produit "sale" pour donner aux machines, comme le binaire :-)

Pourquoi ça le serait ? Les objets individuels ne prennent pas plus de place que dans les autres langages.

Si tu veux un ordre d'idées, une image Squeak de base prend une vingtaine de Mo. Et là dedans il y a le code de tout l'environnement, compilateur, débogueur, interface graphique, gestionnaire de versions, etc soit un peu plus de 2000 classes, 45000 méthodes, et 670000 objets en tout). Qui est chiche de lancer eclipse et compter ? :-)

humm… presque ;-)

Modèle métier = les données et ce qu'on en fait, au niveau d'abstraction idéal (un dessin)

Syntaxe = la représentation, l'encodage de ces données sous un format précis, adapté au stockage/transport ou autre mais pas au manipulations "métier" (une suite d'octets en PNG)

Et si, le code est fait pour représenter ce qu'on veut faire. Le tout est d'avoir un langage de prog qui te force pas à explique comment à tout bout de champ. Même en Smalltalk:


"comment"
1 to: collection size do: [ :i | (collection at: i) faisCeciCela ]

"quoi"
collection do: [ :each | each faisCeciCela ]

Je bosse en Smalltalk depuis deux ans. En Smalltalk, l'un des grands trucs c'est que tous les objets sont persistants par défaut. Donc en général on ne sérialise ni on ne parse jamais rien, et on n'utilise que très rarement des fichiers.
Si tu veux garder des des données il suffit de mettre les objets en question dans une variable, soit globale, soit d'instance de classe (par exemple l'équivalent du database.yml de ruby on rails, c'est un objet "connexionSpec" avec database/host/port/user/password en variables d'instances).

Donc si on a besoin d'accéder à des données, suffit de taper dans l'API des objets en question. Si l'API convient pas ou que pour raisons algorithmiques il faut vraiment réorganiser les données, pas besoin de parser, pas besoin de générer du code, il y a juste à créer la nouvelle structure de données à partir de l'originale.

Avec l'habitude on en vient à trouver ça pénible quand il faut manipuler des fichiers, parce que un fichier c'est comme une chaine, c'est plat, amorphe et ça sait rien faire d'intéressant (alors que mon connectionSpec je peux lui demander de devenir actif et il va me répondre d'autres objets qui représentent les tables etc)

En assembleur aussi

Exactement :-)
http://en.wikipedia.org/wiki/Sapir-Whorf_hypothesis

La surcharge n'est pas un concept orienté objet (*), c'est une émulation boiteuse du multiple dispatch de CLOS, quand on cherche à faire du static binding (* CQFD).

Toute cette machinerie de parsing, de templates et de manipulation d'AST illustre bien que tout ça fonctionne à un mauvais niveau de représentation des données : celui de la syntaxe au lieu du modèle métier. Quelle est l'avantage de CodeWorker par rapport aux parsers habituels (yacc, antlr, packrat…) ?

D'ailleurs il existe un outil de ce genre appelé Ometa, inspiré d'un autre qui date des années 70 : http://www.cs.ucla.edu/~awarth/ometa/
Voir aussi une implémentation de brainf*ck avec Ometa, pour illustrer le bidule : http://www.swa.hpi.uni-potsdam.de/tutorials/cola/index.html

Sinon pour la manipulation de programmes qui semble l'utilité première de CodeWorker, rien ne vaut un langage réflexif. En Smallltalk pour rajouter programmatiquement une variable d'instance à une classe on fait Foo addInstVarName: 'baz'. Pour ajouter une méthode à une classe :

String compile: 'pan ^ self = ''coin'' ifTrue: [''argh''] ifFalse: [''mm po mal'']'

Et baste, le code est visible dans l'IDE, compilé et committable. Si il y a besoin de faire des traitements plus compliqués l'arbre syntaxique abstrait est dispo, et c'est le même que les refactorings et le compilateur manipulent. En Lisp c'est pareil (voire plus puissant) mais je laisse les experts préciser.

Pour l'environnement "étrange" le seul truc c'est que le toolkit graphique de base marche dans sa fenêtre... il y a des plugins pour ouvrir plusieurs fenêtres de l'OS ou pour utiliser GTK ou Cocoa, simplement il n'y a pas beaucoup de main d'oeuvre pour maintenir tout ça donc c'est peu utilisé/connu.

Pour la lenteur il y a besoin d'un peu de nettoyage par endroit... les autres smalltalks sont dans le même bac que Java en performances, et bien plus rapide que python perl et ruby. Comme tout est objet, il y a également beaucoup moins de temps perdu à traduire des formats et convertir des structures de données etc.

D'autre part il y a un projet de compilateur optimisant pour Squeak qui devrait à terme donner des perfs équivalentes à C: Exupery
http://wiki.squeak.org/squeak/3842

Pour les applications, il y a Scratch et Plopp qui sont des jeux/programmes éducatifs, et évidemment Seaside, l'application la plus visible étant http://www.dabbledb.com

D'ailleurs il faudrait s'arranger pour mettre en commun les bug reports, et faire un errata pour la version anglaise.

BOWLS ?

Mon idée était surtout celle suivant laquelle ce genre de procédé fasse perdre du contrôle à l'utilisateur, avec un codage 100% visuel.

Euh, un outil de visualisation c'est pas fait pour coder, c'est fait pour visualiser, c.-à-d. présenter le logiciel suivant une perspective (intellectuelle, pas visuelle) différente, qui mette en évidence des structures ou des défauts dans celles-ci. Ça sert à comprendre le logiciel pour savoir où on en est et mieux le faire évoluer.

À fortiori je pense que c'est complétement inutile pour quelqu'un qui connaît bien son travail.

Parce que tu es un cowboy qui est prêt à passer des nuits blanches à

Le codage visuel, en sélectionnant des modules à la souris est très pratique pour enseigner ou apprendre l'informatique et les concepts qui la sous-tendent, mais je crois que c'est aussi un moyen de se rendre plus dépendant de son logiciel de visualisation.

Et alors ? Le codage textuel te rend dépendant d'une syntaxe, c'est la même chose.

Il existe pas mal d'outils de recherche de ce genre, en maintenance/évolution des logiciels.

Voir par exemple Moose :
http://moose.unibe.ch/seaside/go/moosepage/gallery

Il a l'avantage d'être indépendant du langage (il y a des parsers pour Java, C++, Smalltalk, et on pourrait en rajouter sans changer le reste de l'infrastructure), et dispose déjà de nombreux outils et visualisations pour comprendre et maintenir des logiciels. On l'a utilisé sans souci sur une image Squeak complète (2000 classes, 45000 méthodes).

Suite à ce post je suis retourné voir sur le site de SIL International (qui font Gentium et la licence OFL entre autres). Visiblement ils ont une nouvelle police en préparation : Andika (http://scripts.sil.org/andika ). C'est une sans-sérif toute simple, faite pour enseigner la lecture (les lettres sont bien distinctes les unes des autres).

Non car ce qui serait breveté c'est le protocole de Skype spécifiquement, pas l'idée de protocole de VOIP. On ne brevete pas une idée.

Justement, un logiciel ou un protocole c'est une idée (complexe certes).

En même temps pour les brevets matériels c'est pareil... on brevète l'idée de faire des stylos à bille plutot qu'à plume etc. Simplement, la réalisation de cette idée (le prototype de Bic) n'est pas copiable à l'identique comme de l'information. À la base le brevet est juste là pour laisser à l'inventeur le temps de profiter de son invention, acheter la ligne de production, établir sa marque, avoir les premiers bénéfices.