Ma petite entreprise

Comme je l'ai annoncé hier, aujourd'hui était mon premier jour de OOPSLA, la conférence mythique sur le thème de la programmation orientée-objet, les langages, et d'autres réjouissances pour informaticien hardcore.

Cette première journée était en fait dédiée à de multiples séminaires et conférences hébergées, parmi lesquelles il fallait évidemment choisir -- comme vous vous en doutez, celle à laquelle je suis allé est le Dynamic Languages Symposium, où l'on parle (évidemment) beaucoup de langages de programmation (on n'en parle jamais assez !).

Je vous préviens tout de suite, c'est un article plutôt long, mais j'ai déjà du largement réduire mes notes... ceux qui n'ont pas eu la chance d'y assister auront au moins un peu l'impression d'y être !

Lire la suite

UNe fois n'est pas coutume : je vais écrire un billet qui est en fait une annonce... je m'en vais demain au palais des congrès de Montréal assister à deux jours de OOPSLA !

Au programme des réjouissances :

• Dynamic Languages Symposium où je vais pouvoir rencontrer Ian Piumarta qui nous présentera OMeta
• Celebrating 40 years of language evolution avec (entre autres) James Gosling, Bertrand Meyer et Guy L. Steele Jr.

Avec bien sûr un tas de posters, petites conférences et démos en tout genre. Le problème principal, ça va être de choisir quoi voir, tellement les choses disponibles sont alléchantes... une chose est sûre, je ne vais pas m'ennuyer !

Je ne sais pas si vous lisez Reddit, mais on y voit souvent des choses relatives a Erlang, qui démontrent un certain intérêt pour ce langage.

Mon premier contact avec Erlang été une conférence du MSLUG, où Yariv (ErlyWeb,Vimagi) nous a présenté son expérience avec Erlang dans le contexte du développement d'applications Web. Il disait qu'essentiellement il était curieux d'expérimenter Erlang, qui lui semblait avoir les bon traits pour ce qu'il voulait faire (distribution, concurrence, réseau). J'en suis ressorti avec la conviction que je devrais vraiment faire un petit programme avec Erlang.

Il y a quelques mois, j'ai décidé de passer à l'acte et j'ai passé mon dimanche a jouer avec Erlang, ce qui a donné quelques notes pas vraiment complètes mais néanmoins utiles.

Aujourd'hui, j'ai vu que Bob Ippoloto (bien connu dans le monde Python) était interviewé à propos de l'utilisation qu'il fait d'Erlang dans ces projets. Une des premières choses surprenantes, c'est ça:

When I did some benchmarks on it an Erlang prototype, it worked so much better?than the Python equivalent that I thought it might actually be broken;?it wasn’t, so Erlang very quickly became my production platform of?choice.

Mes essais n'étant jamais vraiment allés très loin, je m'en tenais à ce que Bob lui-même disait de la performance d'Erlang (en gros 2 fois plus lent que Python). Cela dit, à y regarder de plus près les deux langages semblent tout à fait complémentaires.

Un autre aspect intéressant, est cette citation a propos des nouveaux employés qui apprennent Erlang:

I suppose it was a bit risky, but nobody has had any?problems getting into it, and they the new employees seem to prefer Erlang to anything?else when starting new projects.

Je me souviens très bien de Yariv qui nous disait que la plupart des gens qu'il connaît (lui y compris) et qui ont touché à Erlang n'ont (presque) plus envie de toucher à un autre langage (ce sont des choses qui semblent aussi arriver... avec Smalltalk

Maintenant, après avoir joué un peu plus avec Erlang, je trouve que la syntaxe est quand même souvent lourdingue, et que je faisais beaucoup d'erreur de syntaxe. J'irais même jusqu'a dire que Erlang, au niveau de syntaxe sent un peu trop les années 80, et aurait besoin d'une petite amélioration.

Ma perspective sur les langages de programmation est qu'ils s'agit avant tout d'un coeur fonctionnel (la base du langage) sur lequel on greffe une syntaxe. Mais pour Erlang, quel serait son coeur fonctionnel ? Et que pourrait on améliorer dans la syntaxe ?

Si l'on prend l'approche de Alessandro Warth et Ian Piumarta (que je partage tout a fait), on construirait une API dans un langage de base (C, JavaScript, Python, Pepsi/Coke/Cola ou même Smalltalk, pourquoi pas que l'on étendrait syntaxiquement avec des constructs expressifs.

Donc la question subsidiaire est: quelle API couvrirait le coeur fonctionnel de Erlang ? Je serais bien curieux de le savoir

Je suppose que vous l'avez remarqué (si vous ne lisez pas mon blog en RSS, en tout cas), mais je viens de refaire le design d'Ivy, et donc également du blog (c'est encore un peu en cours).

J'ai pris beaucoup de temps pour arriver à ce design là, en passant par beaucoup d'autres styles. C'est finalement celui qui est resté, parce qu'il représente bien (selon moi) l'approche d'aller à l'essentiel et de communiquer clairement,qui caractérise mon approche du design d'interface et du design logiciel.

J'ai particulièrement travaillé les hierarchies de lecture et la cohérence typographique de l'ensemble, en essayant dans un premier temps de limiter (voire supprimer) l'usage d'images, d'icônes ou de photos, dans ce souci d'aller à l'essentiel. Evidemment, ça ne veut pas dire que les images sont définitivement hors jeu, mais plutôt que je les intégrerais au fur et à mesure -- une image vaut souvent mille mots, en plus de rajouter un aspect chaleureux à l'ensemble.

D'une certaine manière, ce redesign d'Ivy est le point de départ de l'ouverture au public d'un certain nombre de projets vraiment intéressants sur lesquels je travaille depuis presque deux ans. Juste pour vous donner une petite liste de ce que j'ai dans les bacs, et qui va être annoncé et publié dans les mois qui viennent:

• Un nouveau langage de programmation (yay !)
• Une librairie pour faire des Webservices 2.0 extrêmement rapidement
• Des outils qui vont vous faire aimer le terminal encore plus

Alors patience, et si vous avez des commentaires au sujet du nouveau look, je suis toute ouïe !

La philosophie less is more (Mies van der Rohe) m'a été communiquée il y a quelques années indirectement par Steve Dekorte, au travers de son langage Io.

Lentement, mais sûrement, cette manière de voir s'est transformée en manière de faire, pour se répercuter dans ma manière de concevoir et d'implanter des programmes et des interfaces. Je suis de nature communicative (j'aime faire part de la manière dont je me sens, de mes idées), et j'ai du lutter (je lutte encore) contre ma tendance naturelle a en rajouter, ce qui a pour conséquence de parfois diluer le message.

En tout cas, cet article de chez Intel fait un intéressant parallèle entre une étude psychologique et les langages de programmation. L'étude est la suivante : dans un magasin d'alimentation, un ensemble de confitures sont exposées dans la vitrine. Pendant un certain temps, 24 pots de confitures différents étaient exposés, puis seulement 6 pots de confitures différents ont été exposés.

Le résultat est impressionnant:

• Pour 24 pots: 3% achètent un pot de confiture
• Pour 6 pots: 60% achètent un pot de confiture

Soit 20 fois plus de personnes. Pourquoi ? Simplement parce que les gens ressentent un "information overload" qui rend le choix difficile. Ils voient la confiture (mmmhhh, de la bonne confiture), mais sont directement confronté au choix anxiogène : mais laquelle choisir ?

Le parallèle avec les langages de programmation est simple : est-il mieux de fournir plusieurs manières de faire (le fameux "there's more than one way to do it" de Perl) ou une seule. Pour ma part, je me positionne clairement du "une seule, mais la bonne". C'est une des choses qui frappe avec du code Python (ou Java, maintenant), c'est qu'il y a beaucoup d'homogénéité. Python le fait via sa syntaxe, Java le fait via des conventions (et un investissement important d'éducation des programmeurs).

Dans mon soon-to-be-announced langage "Sugar", c'est précisément l'approche que j'ai essayé de développer : donner le plus de guide possible pour laisser la place au choix la ou c'est important, a savoir sur l'implantation plutôt que sur la syntaxe.

En tout cas, j'apprécie beaucoup les liens inter-domaines (psychologie et informatique), d'autant plus que je pense que le métier de "designer logiciel" est sous-exploité voire inconnu. Si les gens considéraient les langages de programmation et les API comme des interfaces à part entière (comme on le fait pour les interfaces graphiques), nous pourrions régler beaucoup de problèmes à leur source.