Posté par Damien (page perso, ) le 02/09/2008 à 15:59. (lien). Évalué à 0.

…dois-je préciser que ladite traduction n'aurait probablement pas été aussi rapide avec la clause ND ?

[ Répondre ]

Posté par Damien (page perso, ) le 01/09/2008 à 08:44. (lien). Évalué à 0.

…tout est dans le titre, sauf http://squeakbyexample.org/.

On vend le bouquin en conférence ou en ligne en impression à la demande, et le PDF est disponible gratuitement. La première version est sortile il y a un an, en on a déjà une traduction française faite par des membres de la communauté :)

[ Répondre ]

Posté par Damien (page perso, ) le 15/03/2008 à 19:15. (lien). Évalué à 1.

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 !

[ Répondre ]

Posté par Damien (page perso, ) le 18/02/2008 à 20:17. (lien). Évalué à 2.

Apple est un des gros contributeurs à LLVM.

[ Répondre ]

Posté par Damien (page perso, ) le 26/12/2007 à 03:41. (lien). Évalué à 3.

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 ?

[ Répondre ]

Posté par Damien (page perso, ) le 29/11/2007 à 16:29. (lien). Évalué à 3.

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.

[ Répondre ]

Posté par Damien (page perso, ) le 29/11/2007 à 09:52. (lien). Évalué à 1.

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.

[ Répondre ]

Posté par Damien (page perso, ) le 27/11/2007 à 12:53. (lien). Évalué à 2.

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.

[ Répondre ]

Posté par Damien (page perso, ) le 26/11/2007 à 20:41. (lien). Évalué à 4.

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 :-]

[ Répondre ]

Posté par Damien (page perso, ) le 26/11/2007 à 20:36. (lien). Évalué à 2.

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

[ Répondre ]

Posté par Damien (page perso, ) le 26/11/2007 à 14:24. (lien). Évalué à 1.

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).

[ Répondre ]

Posté par Damien (page perso, ) le 26/11/2007 à 01:06. (lien). Évalué à 1.

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.

[ Répondre ]

Posté par Damien (page perso, ) le 26/11/2007 à 00:51. (lien). Évalué à 2.

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 :-)

[ Répondre ]

Posté par Damien (page perso, ) le 26/11/2007 à 00:34. (lien). Évalué à 1.

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 :-)

[ Répondre ]

Posté par Damien (page perso, ) le 26/11/2007 à 00:21. (lien). Évalué à 1.

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 ? :-)

[ Répondre ]

Posté par Damien (page perso, ) le 25/11/2007 à 23:55. (lien). Évalué à 3.

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 ]

[ Répondre ]

Posté par Damien (page perso, ) le 25/11/2007 à 23:31. (lien). Évalué à 3.

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)

[ Répondre ]

Posté par Damien (page perso, ) le 25/11/2007 à 21:19. (lien). Évalué à 3.

En assembleur aussi

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

[ Répondre ]

Posté par Damien (page perso, ) le 25/11/2007 à 21:14. (lien). Évalué à 2.

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).

[ Répondre ]

Posté par Damien (page perso, ) le 25/11/2007 à 21:06. (lien). Évalué à 4.

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.

[ Répondre ]