On static vs. dynamic type systems in programming languages

I'm a "static typed languages" guy. Whose who know me see what I mean :)

The Rail's boys would say it's because I'm frightened by the field of possibilities, the freedom of dynamic languages [1]. I believe that it's more certainly because I came to software development through OCaml, a really good static typed language, and not like a vast majority of developer through languages from the C family (Java the worst among them [2]), which really missed the point of most of the advantages of static typing (yes, one days I will write about how enlightening was my experience with the Coq Proof assistant, and why things like FPH are beautiful)

So, because I'm dealing with Javascript, Pearl, Ruby and Python fan boys quite often (Lisper and Smaltalker are somewhat rarer ;), I would highlight this really good article about static and dynamic type systems, and the fallacies that most programmers believe about statically typed language : http://www.pphsg.org/cdsmith/types.html.

Synopsis:

Fallacies About Static and Dynamic Types

Many programmers approach the question of whether they prefer static or dynamic types by comparing some languages they know that use both techniques. This is a reasonable approach to most questions of preference. The problem, in this case, is that most programmers have limited experience, and haven't tried a lot of languages. For context, here, six or seven doesn't count as "a lot." On top of that, it requires more than a cursory glance to really see the benefit of these two very different styles of programming. Two interesting consequences of this are:

• Many programmers have used very poor statically typed languages.
• Many programmers have used dynamically typed languages very poorly.

This section, then, brings up some of the consequences of this limited experience: things many people assume about static or dynamic typing that just ain't so.

And as I clearly fit in the category of "programmers [who] have used dynamically typed languages very poorly", I have to find the same article about fallacies on dynamic type language.
I would really enjoy stuff about run-time optimization, contract on dynamic language, meta-programing [3] and such things.

[1] actually, when I see something like Jquery, I understand that Javascript is somewhat amazing. I will have to look harder on it.
[2] when you reach something like that to get a real static type check for something like an heterogeneous list, then you know that something goes wrong.
[3] it's something that is possible in static typed language,as for example with OCamlP4, but I believe meta-programing in Lisp (for example) is more powerful, and the concept of meta-programing is more spread in dynamic typed language. It may be one of the fallacies ;)

Metting Tapestry father - Howard Lewis Ship in Paris

Thuesday the 7 october, I met Howard Lewis Ship, the father of Tapestry 5 Java web framework in Paris.
He was here for a 3 weeks trip in Europe, far from its home, Portland, USA.

There were Howard, his wife Suzan, and almost all my developers team, so 5 people from Linagora, all of them T5 addicts.

Evening part I : bar and T5

Imminent release of 5.0 final....

The evening began with a beer (or two...) in a bar near Linagora, and the discussion almost immediately started on Tapestry 5. Howard wanted to know how we came to T5, so I explained that I'm following its development since 5.0.1 and that I didn't chose at all by luck T5. Now, every developer in my team use T5, and quite like it.

We chatted about the iminent release of T5.0 final (YES !), the beauty of the framework thanks to the IoC framework, its scalabity, not only in performance, but in all thinkable meaning of the term : scalabitly in component from technical ones to business ones, scalabilty of the T5 user target from the business oriented people to the the technical nerd, etc.

We also discussed the missing points, around the documentation and some little things (what bring me to a ml post on the subject).

... and Tapestry 5.1 project...

The discussion followed on the 5.1 release, it's short, time-based and not functionnality-based release cycle, every 3 to max 5 month.

I think this is a really good new, because it was one of the most recurrent criticism against Tapestry : its really really long release cycle, along with the compatibility issue between them. Even if Howard came back several times on the last point (it's even explained in the T5 home page, at the bottom), upgrades would be even smoother if there is less time between them. Moreover, from a customer point of view, it's always best to have his product based on a stable release. I mean, a release tagged stable, because T5 is already one of the most stable soft I used, but the "alpha" or "beta" status is something quite frightening for a customer...

Afterwards, Howard gives us the possibility to argue for our "most wanted feature".
This is our wish-list, along with what Howard expects :

• Portlets

That would be a great feature, because the component approach to the web really goes together with the portlet world. Howard thinks that it should be rather simple to make T5 portlet aware, because most of the needed abstractions are already here. And it's one of the things that should go in T5.1, so, we may be dreaming to cool webadmin interface with T5 in a portail in a near futur

• Webflow

That's another point that came back several time in the mailing list, and that is already in the T5.1 scope. Howard seems to be in discussion with Keith Donald to integrate Spring Web 2 and Tapestry 5 together.
Plus, this is a really good feature to ship, especially directed to the IT managers. It's the kind of tool that make them think they can actually develop using boxes and arrows. I'm not completely sure I want Spring web flow integration into T5, but I definitely want a conversation persistence scope, along with a clean way to manage "wizards". So, if it has to come with Spring Web Flow integration, so be it...

• skinning / themes

Howards was quite enthousiastic about the skinning and theming possibilities he envisions for 5.1. It would be a kind of sitemesh, for free, thanks to a T5 component.

• OSGi

We chatted a little about OSGi. Several people on the ml already tried to integrate T5 and OSGi together, with more or less success. For now, I'm not quite sure of OSGi, I think it lacks a lot of all the plumbery that T5 so nicely hide to developpers... Perhaps Spring Dynamic Modules is the way to go, but for now, I think its use cases should remain in the proof of concept level.

That was the main points, but we also talked about other framework as Terracotta, and ideas as ""CRUD should be free" (I would just add "as long as it is a side module, and not in the core". That's not really a problem with T5 and it's pluggable architecture, but for example, all the CRUD stuff is of no use in InterLDAP).

...in an evolving Java ecosystem

The last discussions in the bar where less focused on Tapestry, and more on the Java ecosystem. Java 7 came in the discussion, and I was happy to discover that Howard seems to share most of my view on the subject. He agree that the JVM need optimizations (faster, more plugable, more versatile, etc), but that Java the language should not evolve anymore...
We talked about Scala and Groovy, his preference going to the second one (obviously, mine is in the first :), but he really likes the lazy evaluation possibilities that Scala bring.

Here, there is something that I don't understand... For a functional developer, all Tapestry architecture is built around functional concept, I see map/fold and pattern matching every where in Tapestry :)

Jean-Louis, one of my co-worker, talked about his "easy ant" project - take the best of Ant and Maven dependency management thanks to Ivy. A to-be-followed project.

Evening part II : "La Casita" restaurant

For the end of the evening, we moved to "La Casita", a french restaurant near Les Champs Elysées. It's a typical France South-West cooking restaurant, with Champagne, Foie Gras, snails, duck, wine, cheese... And to my great pleasure, Suzan and Howard seemed to enjoy it !
So much for our French a priori and cliché about American taste :)

There, we talked less about Tapestry, and more on general subjects. We chatted about the difference on open source in USA (more pragmatic, due to cost efficiency) and in France (more philosophical and political).
We also had an input around the use of IRC, and the complementarity this communication channel can have with the traditionnal mailing list (folks, come in the Tapestry irc chan : #tapestry on freenode).

See you next time !

Along the night, I tested the Ballmer Peak applied to English spoken skills, and went at least as far in the curve as Millenium developpers...


For me, it was a really really great evening, Howard and Suzan are really nice people.
Moreover, Howard is one of the best architect I know in the Java world, it was a great pleasure to meet him. Suzy is realy nice, the next time I will have to invite my girlfriend too :)

So, thank you Howard and Suzy for this meeting, and see next time (in Portland ?)

Java Bar Camp Mardi 30 septembre

J'ai participé hiers soir à mon premier "Java Bar Camp" à Paris, dans les locaux de Octo Technologie.

Avant d'aller plus loin, je tiens à remercier les organisateurs, mis à part le retard sur l'arrivée des participants, tout le reste a été très bien géré, bravo !

Premières impressions : ce n'est pas du tout ce à quoi je m'attendais. Je m'attendais à un rassemblement de geek & développeurs barbus, alors que l'assemblée était beaucoup plus hétéroclite, avec une forte coloration consultant/chef de projet.
Les thèmes s'en sont fortement ressenti : méthodes de développement, build et tests étaient à l'honneur.

Mais revenons sur le déroulement de la soirée :
- 18h30 / 19h30 arrivée des participants (un peu de retard, Julien Dubois (M. Spring en France) absent (il est papa :), toutes mes félicitations )
- 19h30 :
* tour de salle : chacun décline nom/prénom, et 3 tags, des sujets qu'il souhaite évoquer - dans un bar camp, tout le monde est acteur ;
* après le tour de salle, chacun est libre d'aller inscrire sur un post-it le sujet dont il souhaite parler parmi les tags;
* 8 sujets sont choisis parmi les post-it, organisés en 2 sessions (donc réparti dans 4 salles)
- 19h45/20h35 : première session : TDD/Test ; Licenses OSS ; Spring vs JEE ; ? ;
- 20h40/21h30 : seconde session : usine logicielle (build, maven...) ; scrum en vrai ; ? ; ?
- ensuite, buffet et discussion libres.

J'ai choisi en première session JEE5 vs Spring (à regret), et en seconde session "Scrum en vrai".

Je ne vais pas m'éterniser sur la première session, orienté "débat", et il fut relativement stérile et consensuel. Rien n'émerge clairement, sauf que "certain client ne veulent que des normes, et JEE s'impose", "Sans Spring, Java en entreprise serait sûrement mort, bouffi par sa complexité". Bref, rien de nouveau. Le point de vu de Julien aurait sûrement mis un peu de couleurs.

La seconde session m'a beaucoup plus plû. J'y ai rencontré Eric Mignot de Pyxis, un "évangéliste Scrum", intégriste (dans le bon sens ), qui m'a permis de voir le chemin qu'il reste à parcourir dans sa mise en place dans les projets auxquels je participe, mais aussi de prendre consience du chemin déjà parcouru.

Après avoir revu les bases de scrum (organisation, objets), nous avons abordé les problèmes contractuel, la gestion de l'architecture, la gestion humaine des équipe.

Le mot qui revient le plus souvent est "engagement" : un projet Scrum ne peut pas fonctionner si toutes les personnes y prennant part son convaincu par la méthode, en particulier si le scrum master n'a pas un soutient indéfible de sa direction, et si le product owner n'a pas le pouvoir décisionnaire sur les paiement/le budjet et sur le périmètre fonctionnel.

La fin de la soirée étaient agréable, les groupes se formant et se séparant au gré des discussions, souvent pationnée.

En résumé : une expérience intéressante, un fin de soirée nettement plus intéressante que le début, et je reste sur ma fin en terme de développement pur - ce n'est pas dans ce genre de soirée que je parlerais de Scala ou de language fonctionnels :)

Project Euler - Scala

I discovered Project Euler, a website that purpose a lots of Mathematical problems that can be solved with programming. The website provides a check of you solution, and a forum to discuss it but only after you give the rigth answer.

Scala really shine in this kind of game. Well, I think that any functionnal language, and perhaps Ocaml even better that other (thanks to it's amazing vm), are really well fitted for this kind of small, algoritm instensive tasks.

The first problems are really simple, and brute force works well, but quickly it is not enonght, and the game become really interesting : it force myself to remind old memories of school, and I'm afraid at the size of the hole in them - I mean, I should have followed some advandced Maths courses in classe préparatoires, and it's almost if I have to discover again all the concept and properties and theorems... A good reason to do all the Project Euler problem till the last one !

Amazing Mythical Man Month

Fred Brooks was rigtht. Well, I know I will not have a Nobel for this fantastic discovery, but each time I refer to the TMMM, I'm really impressed by the insight of the man.

Ok, so, to be more specific : TMMM has 33 years. He is older than me. And Fred Brooks already depected most of the Agile programming method (history is constantly repeating itself).

But perhaps what impresse me the most is that he forecasted 33 years ago what is happening with Open Source software and the JVM ecosystem today : we will build better and cheaper programms only if common, higth-quality tools and library are broadly available.

It's (almost, but if we look from a hight level, it's not too bad) what is happeing in the JVM (do not read Java) world, and tools like IVY and Maven, Superpackages (ah, not yet) only make it happens quicker.

The future will be intersting, if Sun does not break everything (I hope it's too late for that now).