Ma petite entreprise

Pour ceux qui ne connaissent pas (encore) Factor, il s'agit d'un langage "a pile" (dans la tradition de Forth) écrit par Slava Pestov (connu pour jEdit et une des stars de Reddit). Je viens juste de lire un petit billet d'une personne qui "essaie" Factor depuis quelques temps, et voici une citation qui a attiré mon attention:

Factor on the other hand scales horribly both with respect to lines of code per word (function) and the amount of local state (number of variables). This is because local state is manipulated on a stack which you have to keep track of in your head. Anything exceeding 3 variables and a single line of code and the cognitive load starts to ramp up exponentually. Four variables and the mind is constantly distracted trying to keep track of the stack order. Five and you’re spinning wheels, going nowhere fast.

Partant de ce constat, l'auteur conclue:

So instead you’re constantly having to come up with neat composable abstractions to fold up the state. This is the sort of thing that makes code elegant, loosely coupled and small in any language.

Il est donc assez intéressant de remarquer qu'un des effets de Factor, en tant que langage, serait de pousser les développeurs à créer des abstractions qui sont compactes de manière à diminuer la charge cognitive qui résulterait de l'absence de ces abstractions. Si je prend mon expérience en Python, j'ai remarqué plusieurs fois que la "fluidité" du langage (le fait qu'il soit tellement facile de s'exprimer avec) me faisait parfois négliger l'architecture de mes applications (et je me retrouvais une fois l'application un peu plus grosse a faire du refactoring important) - donc il est tout à fait possible que l'inverse se produise.

On dit souvent que c'est de la contrainte que naissent les choses les plus élégantes, et c'est peut-être ce qui se passe avec Factor. Pour le moment, je ne l'ai pas essayé, et je ne suis pas vraiment convaincu par ce que j'ai vu -- mais je pense que je vais jouer avec pendant les vacances de Noël

En tout cas, je me demande bien ce qui se passerait si on prenait un caractéristique opposée : plutôt que de contraindre, on pourrait montrer des choses que l'on ne voit pas d'habitude. En particulier, nous sommes relativement incapables de voir l'architecture d'un programme, de par l'absence d'outils de visualisation (a moins de faire de l'UML2/MDA)... si nous avions une manière de voir l'architecture, est-ce que cela nous inciterait à mieux concevoir l'architecture de nos programmes ?

Addendum: D'après certains commentaires sur Reddit, Factor appartientdrait à la catégorie de BondageAndDisciplineLanguage... en tout cas l'appelation a m'a fait sourire

Un petit billet pour vous dire qu'il y a maintenant un tutoriel pour COLA, qui consiste en l'implantation du fameux Brainfuck. L'intérêt est un peu limité (j'aurais préféré quelque chose du genre BASIC), mais on voit un peu comment utiliser COLA, qui manque cruellement de documentation accessible.

LLVM a aussi d'ailleurs un tutoriel plutôt développé. Personnellement, je suis assez excité par l'abondance récente de librairies permettant de faire des langages, avec des performances plutôt bonnes. Il reste cependant un enjeu de taille : aboutir à une base de librairies qui permette de facilement passer d'une runtime a l'autre, afin de minimiser le ré-apprentissage lorsque l'on passe d'une plateforme à une autre.

Si tous ces noms vous semblent relativement obscurs, ou si vous ne comprenez pas du tout de quoi je parle, allez jeter un coup d'oeil sur la page de Ian Piumarta consacrée à son projet. Voici une réponse qu'il a donnée récemment à quelqu'un qui se posait la même question que nous tous : c'est quoi tous ces noms ?

Pepsi and Coke are the problem names. The first is the object-message system. The second is the function system, currently called Jolt. They are slowly being combined into a single entity, which was going to be called 'Coke' but could equally be called a 'cola'. (The name 'cola' is not, as far as I know, problematic. The acronym is meaningful too.) I'm not sure how useful it will be to explicitly name the object-like and function-like parts of the final cola, but that doesn't mean we can't have fun inventing some names.

Et puis, juste pour le fun, voici une petite citation relative à ces projets, toujours par l'auteur:

I could paraphrase like this: we've genetically engineered 1/3rd of a franken-chicken that is missing lots of body parts but that we hope can be coerced into laying eggs that hatch into increasingly more complete franken-chickens, and eventually eggs for any species you like -- feathered or not. What you are seeing today is missing the (far) more interesting 2/3rds that hide the non crippled-chicken possibilties.

Ce qui semble bien résumer l'approche Voilà, donc tout ça, c'était pour vous faire patienter en attendant mon billet "OOPSLA: Day two" !