Ma petite entreprise

A friend of mine is working on a project where his Python app has to work on Jython (Python on the JVM). As he had the bad surprise of seeing a noticable performance decrease, I wanted to check this for myself.

I know the JVM is not very good for dynamic languages (yet), but I wanted to test this with a real application. So I took a collection of Pamela files from a real project I finished a couple of months ago, and made Pamela parse the whole files 100 times (Pamela is a markup to HTML processor, similar to HAML).

The numbers are not very suprising, and a bit disappointing for the JVM as a runtime for dynamic languages:

• On CPython, Pamela processed 60 KB/s, and the test run for 30.27s
• On Jython 2.5r0, Pamela processed 30.25 kb/s, and the test run for 63.03s

The tests do not take into account the VM startup, and all the data is pre-loaded to memory. If you compare this very simple benchmark to results of Ruby vs JRuby it seems like having a 50% performance hit is not so bad when switching from native to JVM runtime.

I did another comparison, which is to start a simple Retro web service and run Apache Benchmark (ab -n1000) on it. The result are not really better:

• On CPython, Retro serves 426.52 req/s
• On Jython, Retro serves 53.79 req/s (and if you set concurrency to -C100 you'll likely get a connection reset by peer...)

My bet is that if you use the JDK library (java.util.collections, java.io, etc) you'll likely get better performance -- but the utility of Jython seems to be either running existing Python libraries on the JVM or using Python as a "glueing language" for your native JVM objects. In this latter case, you might as well look into other scripting languages available for the JVM like JavaScript or Lisp !

Anyway, things are likely to change when dynamic method dispatch gets implemented in Java 7 !

In the quest for finding the proper "market positionning for Sugar", I just found a new candidate : "javascript meta-language frameworks".

It's actually from a presentation (starting at slide 51 here) that is featured in todays John Resig's blog post.

After the last presentation of Sugar (as you'll have understood, one I'm not really proud of), I realized I had to decouple Sugar and LambdaFactory, and position Sugar as a meta-language targetting JavaScript and LambdaFactory as a generic meta-programming framework. Meta-programming is still a hairy topic that few people are able to understand, and some of the deeper design decisions in LambdaFactory cannot be well communicated with only one example of front-end language -- I think I've been too excited by the possibilities offered by LambdaFactory and neglected presenting Sugar as a viable language, and focusing on it from a feature perspective.

My goal is to finish the PEG-based parsing library, so that I can ship Sugar without depending on C-based dparser, and then increase my guerilla-marketing efforts to promote Sugar as a better-JavaScript. Then maybe, if Sugar becomes more widely used, we'll see people starting to be interested in the underlying meta-programming framework and start writing and sharing transformation passes (like the dead-code removal pass I presented at YULHackers).

Lately I've been doing some back and forth between JavaScript and Sugar source code. In some places I rewrote the JavaScript in Sugar as I was expanding the code, and found myself removing syntactic elements -- the result is quite interesing. Here is the original JavaScript code

$(".do-save").click(function(){var l=;$("li").each(function(){l.push($(this).text())});save(l)})

And then the Sugar version

$ ".do-save" click { var l= ; $ "li" each {l push ($(target) text ())} ; save (l) }

The exercise of removing unnecessary syntax (like function()) and replacing parens by spaces was quite satisfying, and I think the result speaks for itself.

However, there is still some room for syntax simplification to be done on this part of the expression

$ "li" each {l push ($(target) text ())}

where I would like to see something along the lines of

$ "li" each {l push ( $ `target text ! )}

The additions made to the syntax would be

• a single argument invocation with a variable is denoted by functor 'argument
• a zero-argument invocation is denoted by functor !

Although these two syntactic forms are not common, the backquote is used in Lisp to escape interpretation, and the exclamation denotes a command (an invocation).

I guess some people will say that we can't simplify something by adding new elements, but for lack of a better word this is still how I would discribe my goal in evolving Sugar's syntax. Being a visual person, I try to use a "visual" approach to designing Sugar's syntax, and make use of whitespace and simple punctuation elements to add more rhythm to reading the code. I often think of programming languages as textual interfaces, and in this respect, syntax deserves as much design as user interfaces do nowadays.

Then again, there are the questions of style (some people like indentation, some people like braces) and references (some people know Java, some people know Smalltalk). For me, what's important despite the contextual elements is consistency -- the first users of vi may have not liked its style or its references, but making the small effort of using it for some time, even if it looks and feel weird is sufficient to give you a feel that there is an underlying consistency build by careful design.

So I'm just back from the FreeHackers' Montréal YULhackers unconference where I presented Sugar in front of a dozen of people (including some fellow Pythonistas from The Navarra Group).

I decided to use a three sections presentation of Sugar:

1. The origins of Sugar, coming from my experience with common programming languages
2. A practical overview of Sugar, from its design to its actual syntax
3. Why Sugar is a good replacement to JavaScript for front-end web development

Overall, the feedback I got seemed to be a little bit mixed: some people were asking about the practical interest of using Sugar (which makes me think I did not make my point clearly), and there was little reaction to my demonstration of the meta-programming features of Sugar (which seem to me as the most interesting part).

I must say I expected a little bit more enthusiasm from the people there, but I then realized that I wasn't presenting to the LtU crowd, so it's kind of normal that I did not get too much feedback on such a hairy topic as meta-programming languages

Interestingly, Riadh suggested to put more efforts into "marketing Sugar" so that its benefits would be more easily understandable by everybody. So far, my personal attitude towards "marketing my projects" was something along the lines of "it's working for me, I've open-sourced it so people can see if they can make us of it" -- which for some projects like Sugar does not really help their visibility.

More recently, I've started to publish projects like Sugar on github.com and to post announcements on programming.reddit, which is a great way to generate some buzz (it worked quite well for the trendy K7 project), so maybe I'll use this blog to post more "marketing material" for Sugar.

Anyway, the experience was interesting and it gave me a chance to create a presentation that will probably interest some of the regular readers here

UPDATE: The presentation got promoted on SlideShare and is now visible on site front page (for a limited period of time I guess) !

So it's confirmed, I will be presenting Sugar this Saturday at Montréal Free Hacker's Union (see the announce here).

I'm still hesitating on the approach I will use for the presentation: so far I've advertised Sugar as a replacement to JavaScript for front-end web development (which is where it's most useful), but its actual goal is a bit different (Sugar is meant to be a practical meta-programming language). As a result, the presentation draft focuses as much on the conceptual background of Sugar as on its syntax and usage.

My intuition is that it's more interesting to do a presentation on things that people won't find in the Sugar source code, like its inception and design. The presentation being followed by a workshop, I have plenty of time to present Sugar in practice.

However, I know we're in North America here and that people would normally expect a "hands-on tutorial" rather than a theoretical overview followed by practical examples (which is more a French/European way of presenting). So this will be an experiment... I'll let you know how this went

The news just got out today: the PyPy (Python in Python) project has gained some funding to strengthen its code base. This is a really good news, as PyPy has been showing steady progress since its inception 5 years ago.

While vast and a bit daunting, PyPy is a very modern, radical approach to dynamic languages (and Python in particular) : the goal is not only to write a Python interpreter in pure Python, but to make the whole language manipulable in Python directly, from the syntax to the object model. Among others, the PyPy project involves Christian Tismer, the author of the very interesting Stackless Python fork, which incorporates extensions to make Python support millions of lightweight threads.

In the end, PyPy is more a dynamic language creation platform than a Python interpreter, as you have the opportunity to intercept and replace any mechanism involved in the language. PyPy can also output C, JavaScript or CLI code, which makes it a nice framework for code generation. I personnally expect good things from LLVM back-end, especially from a performance perspective.

Anyway, I'm excited to see that PyPy is gaining even more recognition and I can't wait for the next release !

The wide adoption of the object-oriented paradigm lead to great side-effects for software : many programs became more accessible, more flexible and more reusable. Why ? because OOP encourages the use of abstraction to "untangle" code and provide more opportunities for changing or extracting parts of the program.

Most OO-designed programs tend to be easy to tear apart, change or update mainly because the OO paradigm encourages this "component-based" approach to software architecture. However, when you take a closer look at the 'tools' used to write these programs namely compilers (or interpreters) and parsers, you'll realize that they are often more like monolithic black boxes than a flexible set of loosely-coupled components.

There are few examples of "addons" or experimental languages that try to 'expose the inner working' of their toolchain to let developers write their own extension (Meta-Lua or OMeta would be good examples), but it definitely hasn't reach the mainstream. Looking back at the C pre-processor or the Lisp macro system, we can see that this need for flexibility existed long ago, and the solution chosen was more changing the outside than changing the inside.

Maybe the growth of the open-source movement shifted our expectations, but I personnaly don't appreciate "black box software" too much, but I almost expect to have ways to put my hands in the "guts" of the system.

With growing interest for the notion of DSL (Domain-Specific Languages), and the culture of flexibility that dynamic languages have encouraged, we can better understand the practical benefits of being able to adapt the toolchain that we use for creating software.

In the domain of programming languages, many debates are focused on the syntax -- mainly because for most languages the syntax is cast in stone, forming a monolithic block with the operational semantics and core library ; but in essence, syntax, semantics and core library are three different things, that could be separated.

We have a good example of this with JavaScript : it implements semantics which are very close to many dynamic (and non-dynamic) languages, and its traits (mostly prototype-based inheritance and closures/anonymous functions) make it so versatile that it's quite easy to mimic more complex semantics (class-based inheritance, multiple-dispatch, run-time type checking, etc).

However, JavaScript syntax relates more to Frankenstein than to Pascal, if I may say. To circomvent this, people have written Ruby to JS or Python to JS translators, which allow to use JavaScript libraries with the syntax and semantics of Python/Ruby.

Anyway, the method is not changing too much : we're merely wrapping stuff instead of replacing or upgrading parts of a system. The task may be easier now with the plethora of parsing libraries and the cool string and list manipulation primitives offered by most dynamic languages, but this still keeps these projects in the domain of "cool hacks".

The OMeta paper shows us that it is possible to open a parser so that users/developers can easily add rules and modify an existing grammar dynamically -- meaning that you can re-program parsers written using OMeta very easily.

So what would it take to open our compilers, and software-engineering tools ? Looking at projects such as LLVM, the DLR you can already see that some things are opening: we're starting to get access to (object-oriented) representations of programs -- not limited to syntactic elements like AST, but to more in-depth representations. Even better, with the DLR or with LLVM you can write your programming "programmatically" by assembling objects that represent (or maybe just 'are') your program.

This takes syntax out of the equation, thus allowing you to think about plugging any syntax you want, providing you implement a parser that can create this object model. This simple realisation that syntax, semantics and library can be separated is, in itself, a paradigm shift that people will experiment as more tools offer them this ability.

We've seen many new programming languages emerge in the last 10 years, and often with only superficial differences -- open compilers and open development tools will very likely help more mutual consolidation and cooperation between language designers. With now 3 major VMs capable of running a wide range of languages (JVM, .NET, Tamarin) and a growing understanding of the domain of programming languages, we can definitely expect a lot of exciting projects to come !

The last few weeks have been an occasion for me to take a step back and think about some stuff (more to come soon -- in this introspective process, I've tried to find an article about Io I wrote four years ago for an on-line magazine. It vanished off the net, but thanks to Wayback machine I managed to retrieve the full content !

It's still an interesting read (thought I would definitely be more precise on the language traits now), and I even found some stuff I didn't recall (like Io was originally design to be part of a visual environment, a la Self !). Here is the full copy...

Lire la suite

People who know me personally know how much I love Io's design and how its applied philosophy of minimalism inspired me. Io is (to some extent) inspired from Lua, which is also a very lightweight embedded language. Lua is well-known for being used as an embedded scripting language in C++ application, one of them notoriously being WoW. Lua also happens to be reasonably fast, to have a nice Pascal-inspired syntax and has some very interesting projects such as Meta-Lua.

So having all those advantages (including closures and corountines), how come Lua is not as widespread as say, Python ? I'd say the answer is this: there is no real standard library, and as opposed to Python, Lua doesn't come with batteries included.

Now, things can change: we all know that Java is one of the language with the most libraries, which has an OK VM. There is already Python, Ruby and a handful of other dynamic languages... but now Lua is also available in the form of Kahlua. True to the original Lua, Kahlua is very small (source is <50K) and fully compatible with the original Lua.

I see this as a great opportunity to use Lua a little bit more in practice, and take advantage of the richness of the JVM and the lightweightness of Lua. This also leads to another question: do you really use a language for its syntax, for its library or for its implementation ?

Il semblerait que je persévère dans la continuité émergente de ce blog : moins d'article sur les interfaces, et plus sur les langages -- ce qui curieusement, ne reflète absolument pas ce que je fais au quotidien. Cela dit, je pense qu'il y a ici l'occasion de jeter un pont entre ces deux domaines, grâce au design...

Je profite de l'ébullition qui se produit actuellement autour de Arc, et notamment de la réponse de Paul Graham "Take the Arc challenge" pour vous faire part de mes impressions... non pas sur le langage lui-même, mais sur le fait d'être la personne qui conçoit le langage : le "designer".

Si je parle de "design" ici, plutôt que de conception, c'est pour mettre l'accent sur le fait que Arc a réellement été conçu avec des valeurs fortes, par opposition à quelque chose qui a été pensé ou plutôt "intuitionné" et ensuite qui a évolué de manière organique. En regardant plus en détail le (vaste) ensemble des langages existants, on se rend compte assez rapidement qu'une bonne partie manque de principes de conception clairs -- ce qui témoigne de l'absence d'une volonté de design.

Bref, ce n'est manifestement pas le cas de Arc, et Paul Graham a même pris l'occasion d'exprimer plus en détail sa vision dans son dernier article. Petits extraits:

(...) I worked on things that would make programs shorter. Why would I do that? Because making programs short is what high level languages are for. It may not be 100% accurate to say the power of a programming language is in inverse proportion to the length of programs written in it, but it's damned close. Imagine how preposterous it would sound if someone said "The program is 10 lines of code in your language and 50 in my language, but my language is more powerful." You'd be thinking: what does he mean by power, then ?

et plus loin

This is not to say none of the stuff I did was hard. Some of it seemed hard to me. But in language design, solving problems, whether hard or easy, is not the goal. Making a good language is. The real test of Arc—and any other general-purpose high level language—is not whether it contains feature x or solves problem y, but how long programs are in it.

Ce qui résume relativement bien un aspect qui est souvent peu considéré : un langage n'est pas essentiellement quelque chose de technique, mais bel et bien un mode d'expression (et j'ajouterais : un mode d'expression qui structure la pensée en retour). Comme le rappelle Paul Graham en début de son article : chacun semble avoir son opinion à propos de Arc, et la plupart des premières réactions on été primaires et plutôt négatives... une des raisons étant qu'il faut du temps pour apprendre le langage et le pratiquer ; ce n'est donc que plus tard que des remarques "plus constructives" pourront émerger.

Ceci m'amène finalement à ce que je voulais vraiment dire dans cet article (hormis de sensibiliser mon lectorat - qui n'en a sûrement pas besoin - au concept de design de langage) : lorsque l'on fait (vraiment) du design, on essentiellement fait des choix qui ne sont pas des conséquences de contraintes techniques, mais des choix qui vont donner le coeur et la chair de ce que nous allons créer.

Bien souvent, ce coeur et cette chair ne s'expriment pas directement, et la forme l'emporte sur le fond dans l'esprit des gens : chacun a toujours quelque chose à dire sur la forme (et croyez moi, vous le voyez tous les jours quand vous bossez dans l'interface graphique mais très peu de gens sont capables de comprendre qu'il y a un fond... et dans ce cas restent en général très prudents en s'exprimant par rapport à lui.

Bref, être un designer n'est pas quelque chose de facile, parce que l'on met beaucoup de nous même dedans. Nous mettons beaucoup de choses qui ne sont pas le fruit d'une démarche problème -> solution, nous essayons plutôt de créer un esprit, de "donner une âme" aux choses si je puis dire.

Lorsque j'ai fait ma license de design, j'étais ingénieur en logiciel depuis deux ans... et j'ai vraiment compris que pratiquer l'ingénierie avait quelque chose de réconfortant : c'est un peu comme une série de puzzles logiques, où il y a certes beaucoup de solutions, mais où la part de créativité que l'on peut investir fait justement partie de ce fond invisible qui ne préoccupe pas tant les gens. Au final beaucoup de satisfaction (les puzzles assemblés) et peu de frustration (personne pour manifester son désaccord sur la forme).

Pour le design, c'est vraiment différent : on se retrouve littéralement à nu devant les autres, et il faut avoir le coeur bien accroché pour ne pas se laisser démonter par des critiques qui tiennent (bien souvent) plus du réflexe que d'une tentative de compréhension. Nos profs nous ont heureusement entraîné tout le long en nous confrontant à ce genre de situation, mais il reste que c'est quelque chose de vraiment éprouvant, car il n'y a pas d'abri possible : quelque chose que l'on a designé vient du fond de nous, et ne pas la comprendre, ou la remettre en question nous affecte directement en conséquence.

Bref, Paul Graham est quelque part victime de son succès : c'est quelqu'un de connu, et il a visiblement beaucoup investi de lui-même dans Arc... et peut-être n'était-il pas encore complètement prêt à entendre tant de critiques abruptes.

En tout cas, pour vous remercier d'avoir lu cet article jusqu'au bout, je vous invite à regarder ce fil de discussion où vous trouverez des versions dans beaucoup de langages d'un même programme... c'est très très intéressant de regarder les exemples de code en se demandant "quel est l'esprit de ce mode d'expression" ?

Ce n'est pas très fréquent que je me fasse le relais des nouvelles fraîches du jour, mais là, ça me fait un peu l'effet d'un nuage de vapeur qui se condense (si vous voyez ce que je veux dire) : Arc est sorti (chérubins et trompettes !).

Au menu, c'est en effet un dialecte de Lisp plutôt séduisant, dans le sens où des primitives s'inspirent des bonnes choses que l'on trouve dans d'autres langages (each, for, case, etc). A priori il y a là un bon espace pour des gens (comme moi) qui sont trop accoutumés aux bonnes choses (merci Python), mais qui aiment la souplesse et l'élégance des "grands anciens" (Lisp et Smalltalk, par exemple :).

Petite deception, Arc ne tourne pas sur une VM sexy ou ne se compile pas en bytecode quelconque... mais utilise MzScheme... enfin, pourquoi pas. De mon côté, je n'ai pas attendu Arc, et j'ai notamment repéré des choses comme e7, Nu ou Clojure.

Alors c'est clair, Arc a Paul Graham derrière lui, et a un peu atteint un stade de mythe... mais peut-être que l'on va voir la communauté programming.reddit.com s'enflammer et nous pondre plein de projets et de librairies Web 3.0 qui vont permettre de concurrence Erlang (si je puis dire )

Je sais que certains lisent mon flux Delicious mais peut être que ce commentaire (Reddit) n'aura pas retenu leur attention, et ce serait bien dommage de passer à côté de ça

En gros, c'est un article qui présente quatres caractéristiques/dimensions pour définir un système de types:

• statique (les expressions ont des types) vs dynamique (les valeurs ont des types)
• fort (un cast est nécessaire pour une coercition de valeurs) vs faible (la coercition, faite à l'exécution, ne nécessite pas de déclaration)
• latent (pas de déclarations de type) vs manifeste (on déclare les types) (personnellement, je dirais plutôt implicite vs explicite)
• nominal (la relation de sous-typage est explicite, comme l'héritage) vs structurel (c'est la structure/l'interface qui définit le type)

Je trouve que c'est un très bon boulot de schématisation, puisqu'il me semble que cela couvre tous les langages que je connais... reste la question subsidiaire : mais qu'est-ce qu'un type ?

Allez, je suis sûr que vous avez chacun votre petite idée sur la question

On peut lire assez souvent des gens s'exprimer de manière générale sur des langages de programmation, et la plupart des avis concernent la syntaxe (y'a trop de parenthèses, c'est quoi ces point-virgules, pourquoi il faut indenter... etc !), et s'arrêtant généralement à des premières impressions.

Parfois, ou plutôt rarement, on peu voir des gens s'exprimer sur des points précis d'un langage, en citant leur expérience dans une industrie particulière. C'est typiquement le genre de feedback rêvé pour un concepteur de langage : avoir des informations précises sur les conditions d'utilisation du langage, assorties d'exemples choisis et annotés... si en plus on bénéficie de proposition d'amélioration, on nage en plein rêve !

Eh bien la présentation écrite par Tim Sweeney (Epic Games, Gears of War) est de cette trempe : simple, claire, marrante juste comme il faut, elle analyse sous l'angle de Gears of War et de Unreal les caractéristiques des ces logiciels et les limitations engendrées par le langage.

On y trouve notamment des statistiques très intéressantes vis à vis du moteur Unreal:

• 50% des bugs sont liés à des erreurs que le compilateur pourrait trouver tout seul
• 90% des variables de type int sont faites pour indexer des tableaux
• 40% des boucles "for" sont des "comprehensions" fonctionnelles
• 50% de ces boucles sont des "folds" fonctionnels

On détecte ici que Tim a une bonne expérience des langages fonctionnels comme OCaml ou Haskell (qu'il cite a plusieurs reprises). Le thème de la concurrence est également fréquemment abordé dans sa présentation (on y parle des STM - "Software Transactional Memory").

Le meilleur de la présentation est pour la fin : nous avons droit à quelques reflexions sur le langage idéal pour Tim.... je vous laisse le plaisir de découvrir ce qu'il propose.

En tout cas, je considère que les programmeurs de jeu vidéo sont ceux qui sont le plus sur la ligne de front, car ils ont (dorénavant) à gérer un très large éventail de problèmes (parallélisme, performance, distribution) avec des technologies avant-gardistes (Cell/PS3)... et c'est donc à mon avis des gens à écouter très sérieusement

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.