Damien a écrit 158 commentaires

Pour le debugger : en pharo le gestionnaire d'exceptions global lance le debugger. Pas besoin d'exécuter un bout de code explicitement en mode debug.
C'est au point qu'on peut écrire un test qui appelle une méthode qui n'existe pas, créer la méthode depuis le debugger qui apparait quand on lance les tests, continuer l'exécution, et voir le test runner passer au vert.

Inspecteur mémoire : une fenêtre qui te montre l'état d'un objet (contenu des variables d'instances) et qui permet d'interagir avec directement, au niveau d'abstraction des objets (on s'embête jamais avec la représentation en bits/octets/hexa des choses).

Modèle sémantique = en gros l'arbre abstrait : le programme est constitué de classes, contenant des méthodes, les méthodes contiennent des expressions… les instances d'une classe donnée ont telle et telle variables… quand on compile une méthode et qu'une variable n'est pas définie le compilateur va lancer une exception, que l'éditeur peut choper pour proposer à quels endroits on peut définir ladite variable, ou si par hasard ça ne serait pas une typo, etc. Chercher les appelants d'une méthode ne va pas te donner de faux positifs dans les commentaires, comme grep ferait. On peut chercher les redéfinitions d'une méthode dans les sous-classes, pas simplement trouver toutes les occurrences de /ma_methode(.*)/ dans la base de code. Vim devrait connaître tout cela pour pouvoir interagir avec un programme sans se limiter à juste de la manipulation de texte.

Les outils dont je parle n'existent que dans les IDE vraiment finement liés au langage de programmation. Hors les Smalltalks, Emacs est probablement le plus similaire dans l'approche de manipulation en direct du programme.

Pas avec vim.

Si, c'est exactement pareil. Soit tu te cantonnes aux commandes vim de base, soit tu adoptes des plugins pour gérer tel langage ou tel outil annexe, et tu dois apprendre des commandes en plus. Si tu veux du réel support pour ton langage, tu verras qu'il faut quelque chose de complexe comme eclim : plein d'infrastructure comprenant entre autre un modèle sémantique du programme, un compilateur, une VM spécialisée pour les changements dynamiques de code, un debugger, un inspecteur mémoire, etc… Bref tu remplaces juste ctrl-espace clic-droit > menu > menu > menu > bordel c'est pas le bon > ah oui c'est là… par <esc>\;U&%&*%lkdjhfgs<enter>:!emacs

tous les langages de scripts avec un IDE potable

« langage de script » ça ne veut pas dire grand chose techniquement, à part sur l'usage généralement fait du langage en question… si c'est à bash et compagnie que tu penses, j'aimerais bien voir à quoi ressemble cet IDE potable :)

Smalltalk est un langage compilé et prédate QBasic de 7 ans. Beaucoup de choses ont d'abord été inventées en Lisp, de toute façon, donc la question n'est pas si telle ou telle fonctionnalité est originale, mais à quelle point elle est pratique dans sa réalisation, et intégrée dans les habitudes de développement.

Il y a Shampoo aussi.

Mais l'effort de développement pour retrouver une panoplie d'outils suffisemment complète hors de l'image est énorme. Shampoo est une réimplémentation complète du browser, en gros.

La RED est à peu près deux fois plus chère, mais je sais pas si c'est comparable niveau fonctionnalités.

Y'a-t-il un debugger pour Go? à quoi ressemble-t-il ?

Pinaillage: Dart est fortement typé, autant que Ruby ou Smalltalk. Un objet donné en mémoire signifie toujours la même chose. Il est juste dynamiquement fortement typé, avec déclaration et vérification statique rendues optionnelle.

Un langage non typé, ou faiblement typé, c'est un langage où une même représentation en mémoire peut avoir plusieurs sémantiques comment on s'en sert (donc par exemple l'assembleur, ou le C à cause des casts). NB les casts en C ne sont pas les mêmes qu'en Java, qui est fortement et statiquement typé.

Il y a du JS dans le bureau de Mac OS X ? où ?

Clairement. Un arbre abstrait avec seulement 15 sortes de noeuds différents qui sont bien othogonaux entre eux, c'est bien plus sympa que 200 avec des contraintes bizarres.

Sinon il y a latexmk comme remplacement plutôt bien foutu de rubber…

Je suis juste passé sur le site, voir les vidéos de démo… et j'ai juste une petite suggestion, peut-être que c'est déjà fait mais j'ai pas vu :
Plutôt que d'animer d'un point A vers un point B avec une fonction linéaire, une transition qui accélère et ralentit progressivement doit être super simple à faire et ça rendrait les transitions beaucoup moins mécaniques (donc les démos plus flashy :)

C++ est probablement encore trop simple, même avec boost… il lui manquait bien la réflexion…

Arc90 n'est de plus pas mentionnée dans la documentation ou les informations sur l'application.

Sisi : menu Help > Acknowledgments.

Et je rajouterais Moose http://www.moosetechnology.org/ ou plus précisément son DSL de visualisation Mondrian http://www.moosetechnology.org/tools/mondrian

Pas vraiment axé visu de graphes, plutôt scripting exploratoire pour visualiser des modèles ou des métriques.

Tu as lu le lien ?

Plutôt que de réinventer un langage de zéro, autant adopter Algol 68, qui est déjà spécifié proprement… il aurait suffit de remettre un compilo au gout du jour.

Enfin bon ce qui me frustre surtout c'est le manque d'inventivité. La plupart des langages qui sortent maintenant sont des resucées de ce qui existe déjà, un peu de ci, un peu de ça, et il n'y a que rarement une nouveauté réelle ou une approche intéressante d'un problème connu : les modules de Newspeak, les séquences en Clojure… éventuellement les goroutines, mais c'est pas bien différents de ce qu'il y a en Erlang…

Concernant Go, je pense que l'idée d'inventer un langage avec quelques principes forts pour voir ce que ça donne est intéressante. Par contre j'attendrai que ce langage apporte vraiment quelque choses de nouveau pour m'y intéresser réellement.

Oui mais bon, autant choisir des principes forts qui n'avaient pas déjà été essayés en 1968…
http://www.cowlark.com/2009-11-15-go/

Je suis avec toi sur les performances des GC modernes, mais pourquoi en prendre un conservatif alors que puisque tu conçois le langage, tu pouvais en faire un parfait (il sait exactement ce qui est un pointeur ou pas) ?

il n'y a quasiment aucun gaspillage mémoire

Si, parce que si tu as 100 méthodes dans une superclasse A, et une redéfinition dans sa sous-classe B, alors la table de lookup de B contient 101 entrées dont 100 redondantes.

Le lookup récursif marche très bien et s'optimise avec les polymorphic inline caches. Cherche les papiers sur le compilateur de Self (http://selflanguage.org ), ou http://www.lirmm.fr/prm/language.html .

Qui permet de coder avec un style fonctionnel assez facilement. Évidemment c'est pas Haskell, mais avec les blocs (qui sont des fonctions anonymes) on retrouve le même genre d'itérateurs que les fold, map etc.

Il faudrait peut-être des stats sur l'activité du SVN… ou peut-être juste compter le nb de frameworks et leur étendue, et comparer au nombre de développeurs actifs :)

En l'état c'est les API, le code, et comment on s'en sert qu'il faut montrer. Quoique, si ton collègue est designer, les screenshots peuvent avoir des retombées positives pour le projet ;p

Trollisti^WSérieusement, le look OpenStep est certes démodé mais propre. Pas comme ce qu'on peut voir dans pas mal de thèmes alternatifs des toolkits plus communs…

Le problème de ssh user@remotehost commande c'est que la commande s'exécute dans un shell de base, sans ton environnement perso. En passant par bash -lic on peut avoir un environnement complet qui a ta config de ~/.bashrc et/ou ~/.bash_profile.

Bon à connaître, ce soft :)

Ça marche pour toutes les fenêtres d'une application j'imagine, voire pour toutes les applications qui sont lancées dans le X distant ?

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

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