Typage statique pour Ruby

Via cet article sur Segment7, voici le lien vers une publication sur le développement de DRuby (DiamondBack Ruby) [:en, :pdf] : un outil (codé en OCaml) visant à autoriser le typage statique en Ruby. Le code source de cette application devrait être publié dans les mois à venir.

J'ai un avis assez mitigé sur ce genre de projet : d'un côté, j'apprécie la possibilité de choisir (cf. article précédent sur le typage en Groovy), et je reconnais tout à fait beaucoup des avantages du typage statique. Parmi eux, une certaine fiabilité et la détection précoce d'erreurs de développement.
Mais en Ruby (Perl, Python, etc...) ? L'un des avantages de ces langages dynamiques n'est-il pas d'"éluder" au maximum les contraintes de type pour un développement plus rapide et libre ? En Ruby en tout cas, la "philosophie" veut que l'on s'intéresse davantage au comportement d'un objet (no primitive type here !) qu'à sa classe (principe du "Duck Typing"). On croise donc plus souvent des foo.respond_to? :a_method que des foo.is_a? A_Class.

Il est cependant intéressant de se poser la question suivante (et pas seulement en Ruby !) :

Comment et/ou avec quelles techniques, assurer la fiabilité d'un programme dans un langage dynamique ?

Je vais essayer de bientôt placer quelques petits exemples de code sur ce sujet.

Et maintenant, quel langage ?

Les habitués de forums de programmation pour débutants (SDZ ?) devraient avoir souri en lisant ce titre... (En effet, ce type de forum voit apparaître avec une fréquence de 2 à 10 par semaine des sujet portant un titre approché de ça : "Quel language choisire svp URGENT ?" le plus souvent).

Blague à part, la question n'est pas idiote. Loin de là.
Quel langage apprendre ?

Des langages !
Beaucoup !

Il y a beaucoup de langages. De plus en plus même (note : je vais parler ici des "vrais langages" de programmation, c'est à dire, à mon sens, ceux qui sont Turing-complet ; pas du HTML, LaTeX, XML ou autres...).

Lesquels sont généralistes ? La plupart.
Lesquels sont spécialisés ou orientés vers une utilisation précise ? La plupart aussi !
Je m'explique : Fortran permet de tout faire (à condition d'être courageux) mais n'a que peu d'intérêt en dehors du domaine scientifique. Ruby est généraliste, mais est surtout employé pour des applications web (Rails...). Python permet de faire de "vrais" programmes mais sera surtout utilisé (dans le monde pro) pour du scripting d'appoint. On cherche encore Ada ailleurs que dans de l'embarqué et le Javascript ailleurs que dans des applis web côté client... Et pourtant, dans l'absolu, tous permettent de faire la même chose.

Les généralistes et les familles

Cela dit, il existe quelques langages qui sont utilisés (utilisables ?) pour à peu près tout : le C++ et le Java. Pas de chance pour eux (ou pour moi !), je ne les apprécie pas outre mesure. Sans être allergique au C++ que j'ai déjà utilisé en milieu professionnel, je trouve qu'ils sont assez proches et assez lourds (j'ai déjà le Fortran à la maison, merci !) : je reconnais sans problème leurs qualités respectives, mais ils ne conviennent pas, à mon sens, pour un usage domestique/éducatif/récréatif. De plus il ne recèlent pas ou peu de concepts nouveaux pour moi (même si ça ne me ferait pas de mal de revoir la gestion des pointeurs et références en C++ et deux, trois petites choses...).

Dans le même ordre d'idée, je pourrais me mettre au Python. Mais comme il est très proche de Ruby, à quoi bon ? Me taper les différences de syntaxe et de convention pour faire les mêmes choses qu'en Ruby mais en Python ? Pas assez rentable à mon goût ! Je pense, ou plutôt espère, que connaître un langage dans une "catégorie" facilite et accélère l'apprentissage des langages proches, en cas de nécessité. Par exemple pour Ruby : Python, Perl, Groovy, Smalltalk...

Coder, pourquoi ?
Coder plus pour gagner plus...

Car si je code, ce n'est pas que pour le plaisir.

C'est vrai qu'après des débuts difficiles, je me suis mis à apprécier de plus en plus la programmation, pour pas mal de raisons. D'abord pour l'aspect mathématique assez fort que j'y retrouve. Ensuite pour le côté "Lego" : il y a un aspect "architectural" dans la construction d'un programme, des contraintes mais aussi une grande liberté devant son éditeur de texte (un peu comme face aux briques), et une fois terminé on peut "jouer avec" son programme. Enfin, c'est un monde riche en "concepts" liés à l'image que l'on (l'homme et/ou la machine) se fait d'un problème et de sa résolution.

Mais la programmation, c'est aussi une partie importante de mon métier (ingénieur modélisation - bon, ok, pas en ce moment, mais je vais trouver ^^). Et dans ce contexte, à mon niveau, il n'est pas question de choix. On travaille avec le(s) langage(s) qu'on nous donne. Et c'est là que ça se gatte... Dans le domaine de la simulation et analyse numérique, sont surtout utilisés le Fortran et le C++, que je maîtrise "relativement" bien. Les informations glanées sur le web, au cours d'entretiens, etc... ont mis en lumière d'autres "technologies" possibles : Matlab, VisualBasic, C et Ada principalement.

• Je pourrais me mettre au Matlab mais c'est pas gratuit, même s'il existe SciLab dans le genre...
• L'environnement VisualBasic, malgré tout le mal que j'en pense, a été installé sur ma bécane... moins d'une heure. Déjà, les IDE m'insupportent, alors quand on ajoute un helper autiste et des tutos qui commencent par "Comment insérer un copyright dans votre programme" (véridique : cherchez sur le web !) et enchaîne sur "Créer un menu dans une fenêtre", ça fait beaucoup. Sans rire, ce genre de truc est extrêmement dangereux pour le PC d'un gars comme moi... Dix minutes de plus et je transperçais l'écran à coup de tête. Dangereux je vous dis !
• C après C++, connaissant le Fortran ? Mouais...
• Ada serait sans doute le plus intéressant, mais il y a peu de chance qu'il me serve en milieu professionnel, vu qu'il est le plus souvent dédié au systèmes embarqués (domaine intéressant, mais un peu loin de ma branche).

L'utilisation éventuelle d'un langage en entreprise m'aide donc peu.

Concept ?
Aqui lo paradigme !

Il reste les "concepts".
Cela fait déjà un bon moment que le monde de la programmation fonctionnelle me fascine : attraction/répulsion.
Attraction car c'est une grande famille de langages, de LISP à Haskell en passant par Scheme et OCaml avec des méthodes intéressantes.
Répulsion car jusqu'ici, j'ai toujours été incapable de "décrypter" le moindre bout de code fonctionnel aperçu ici ou là : crispant.
Il y a aussi d'autres "concepts" (paradigmes en l'occurrence ici) : logique (PROLOG), concurrent (Ada, encore !), par contrainte...

Finalement...
Tout ça pour ça...

Finalement, c'est par hasard que je me suis mis... au Scheme.
Un article, chez RubyInside, décrivait un interpréteur pour Scheme, codé en Ruby, dans le bus. J'ai voulu tester. Du coup, il m'a fallu taper un peu de Scheme ; du coup, j'ai lu du Scheme ; du coup je me suis mis à comprendre un peu le Scheme ; du coup, j'apprends le Scheme.
Pour être tout à fait franc, ce langage faisait déjà parti de ceux qui me tentaient fortement, avec le LISP, l'OCaml, Io et Cobol (non, pour le Cobol, j'd3conne !).
Io a perdu car je voulais voir autre chose que de l'OO. Quite à se lancer dans le fonctionnel, autant prendre un langage "simple" : l'OCaml me semblait "trop riche" car multi-paradigme. Enfin, le LISP a eu un petit désavantage : cette citation de G. Chaitin sur la "pureté" d'un langage.
Scheme donc, avec l'interpréteur MzScheme (Bus-Scheme, celui en Ruby étant... peu utilisable ?).

Effectivement, Scheme est austère. Mais il semble reconnu pour son côté pédagogique et est (hormis pour les parenthèses) assez bref dans sa syntaxe : il y a une certaine élégance proche des maths je trouve. Il est vieux, mais a un certain charme... et j'avoue que je l'apprends avec un certain plaisir. Et pour ma bonne conscience professionnelle, Scheme est utilisé dans certains codes de calculs industriel, en appoint (bientôt un article sur "Quel(s) langage(s) dans tel programme ?").Que demander de plus ?

Références et Docs :

D'abord, deux textes pleins de sagesse (si si, il y a un rapport avec le reste...) :

• Succintness is Power
• Teach Yourself Programming in Ten Years

L'article sur Bus-Scheme, l'implémentation en Ruby :

• Ruby Inside : Bus Scheme
  

Commençons gentiment en Scheme (avec un interpréteur qui marche !) :

• Scheme
  
• Page d'acceuil MzScheme
• MzScheme : Learning
  
• Teach Yourself Scheme in Fixnum Days
  

Pour tout le reste vu dans cet article, Wikipédia saura répondre... sinon demandez toujours !

Typage statique ou dynamique : la "Groovy Alternative"

Notion de programmation plus complexe qu'il n'y paraît, le typage est souvent la source de trolls (statique vs dynamique). Pour un petit rappel, l'article Wikipedia, ou un excellent "tuto" (plutôt une présentation en fait) sur le SDZ.

Basiquement, l'opposition entre typage statique et dynamique reposent entre autre sur les arguments suivants :

• Le typage statique est lourd pour le programmeur, mais plus sûr.
• Le dynamique est beaucoup plus agréable, mais plus "glissant" et peut-être plus difficile à tester.

Je rentre pas dans le débat... Je me pose seulement la question de l'influence du typage sur les performances (vitesse d'exécution) d'un langage : significatif ou non ?

Pour rappel, un petit tableau :

Typage	Fort	Faible
Statique	Ada, Fortran	C
Dynamique	Ruby, Groovy	Javascript

Le coup du typage fort ou faible : c'est assez relatif, je rentre pas là dedans...

Un exemple en Ruby :

# Test typage
def meth_4_hash hashhh
hashhh.each_key{|k|
 puts k.to_s
}
end

conan = {
:dieu => "Crom !",
:arme => "Hache de bataille +4"
}

meth_4_hash conan
#meth_4_hash 455
# ==> erreur de type !

def meth_4_hash2 hashhh
if hashhh.is_a? Hash then
 hashhh.each_key{|k|
  puts k.to_s
 }
end
end

meth_4_hash2 conan
meth_4_hash2 456

def autre_meth hashhh
raise "erreur de type" unless hashhh.respond_to? :each_key
hashhh.each_key{|k|
  puts k.to_s
}
end

autre_meth conan
autre_meth 42 #error raised !

Il n'y a pas de type en Ruby : que des objets.

La méthode meth_4_hash doit "implicitement" recevoir un hachage, ou du moins un objet possédant la méthode each_key (doit pas y en avoir 50 !). Mais rien ne m'interdit à priori de lui donner autre chose à manger : 455 par exemple. Dans ce cas, le programme lève une exception et s'arrête.

Une façon de rendre son code plus "sûr" est de tester les entrées ou cibles de ses méthodes. Dans meth_4_hash2, le contenu de la méthode ne s'exécute que si l'input est du bon type (est une instance de la bonne classe plus rigoureusement...). Cette façon de "tester" en entrée de fonction permet ici d'éviter une exception, donc l'arrêt du programme...

... Mais ce n'est pas forcément satisfaisant. Si l'on souhaite être plus rigoureux, on se doit de lever soi-même les exceptions en cas d'erreur de type. C'est ce qui est fait dans autre_meth avec raise qui permet de lever l'exception avec un message qui pourrait être plus explicite (ici "erreur de type : un Hash est attendu en entrée" par exemple). A noter que dans mon exemple, cela comporte peu d'intérêt : il faudrait que le test soit placé en amont dans le code (avec une variable pas codé en dur...).

Groovy est un langage dynamique...

alcibiade = 5
println alcibiade.getClass()

alcibiade = [4,5,6]
println alcibiade.getClass()

assert alcibiade.getClass() == java.util.ArrayList

Tout ce qu'il y a de plus dynamique donc...

... mais peut être statique !

Integer alcibiade = 5
println alcibiade.getClass()

alcibiade = [4,5,6] // erreur !
println alcibiade.getClass()

En effet, sur la première ligne, dans un style "Java", on indique à l'interpréteur (ou au compilateur) que le type de alcibiade doit être statique : ne peut être modifié.

Groovyyyyyyyyyy !

J'aime bien cette fonctionnalité : en fait, j'apprécie assez quand un langage a un comportement par défaut connu (ici le typage dynamique), logique (en accord avec sa "philosophie", ses principes ou ses objectifs) et consistant ("ça marche toujours comme ça" : un minimum d'exceptions aux règles), mais qu'il permet aussi, moyennant un effort minimum, de faire autrement.

1 bon point pour Groovy !

Groovy + GraphicsBuilder

A l'installation (du moins sous Windows), Groovy propose outre sa petite mais sympathique GroovyConsole, une petite appli graphique : GraphicsBuilder. Elle présente grosso-modo l'aperçu graphique et la zone d'édition de code. Pratique pour générer des petites images donc.

Un très bon blog avec beaucoup d'articles sur Groovy en général, et sur GraphicsBuilder en particulier (et pas mal d'autres choses...) :

Andres Almiray's Weblog

Bonne lecture et bon hack !

RubyShyne v0.6

Allez hop, une petite mise à jour de RubyShyne qui commence à marcher pas trop mal...

• Ajout du Java et Groovy pour les langages
• Corrections de quelques petites erreurs
• Léger nettoyage

Pour rappel, il génère du HTML avec balises "pre" mais est facilement modifiable pour prendre "text-area" (peu pratique chez Blogger), et je l'utilise depuis quelques temps maintenant pour présenter mes bouts de codes sur ce blog (tag "code" pour voir des exemples).

Encore une fois, si vous utilisez cette modeste application, n'hésitez pas à me le faire savoir pour que je puisse l'améliorer.

RubyShyne v0.6 :

• Télécharger directement.
• Page RubyShyne.
  

Découvrons le Groovy !

En ce moment, sur les bons conseils de Poulet, un jeune programmeur de talent dont l'agressivité sur un forum n'a d'égal que le riche savoir, je jette un coup d'oeil sur un langage on ne peut plus exotique : le Groovy !

Pour résumer :

Groovy = ((Java) + Ruby + Python + Smalltalk) / JVM

avec JVM la Java Virtual Machine. Il s'agit donc d'un Nième langage de script pour la plateforme Java, aux cotés de Javascript, Rhino, JRuby, Jython, BeanShell et autres... Mais c'est peut-être le plus proche du Java sur certains points. Il possède diverses caractéristiques intéressantes :

• Orienté Objet (quasi-totalement comme le Ruby).
• Syntaxe à la fois "souple" (comme Ruby ou Python) mais proche du Java.
• Interprété OU compilé (en bytecode, comme Java).
• Utilisable dans des classes Java.
• Capable d'utiliser les classes Java.
• Typage dynamique ou statique, au choix.
• Exécutable en ligne de commande / interpréteur en shell (groovysh) / GroovyConsole (sympa !)
  
• Pas mal d'autres choses devenues classiques dans les langages modernes (regexp, closures, surcharge des opérateurs, etc...)

Exemple :

// Un aperçu de Groovy
a = 0
for (i in 0..9){
    a ++
    println "Iteration ${i+1} : ${a}"
}
assert a == 10

Divers liens en vrac :

• Groovy - :en
  
• Wikipedia - :fr
• Introduction, chez Projet Omega - :fr
  
• Petit tutoriel, par Eric Reboisson - :fr
• Tutos du Getting started Guide - :en
• Doc de l'API - :en
  
• Blog Odelia, sur Groovy - :fr

On en reparlera, notamment niveau perfs, petits tricks sympas et comparaisons de syntaxe...