Depuis peu, je joue avec Boo et le framework Mono. Même s’il est très dommage que Boo ait perdu pour l’instant son auto-complétion dans Monodevelop 2, la syntaxe python-like est un réel plaisir à utiliser. J’attends avec impatience la nouvelle version du plugin pour Monodevelop et de tester la version alpha du plugin pour VS 2008.
Je me suis rendu compte à l’usage que ce que je préfèrais dans les langages inspirés de python n’était pas leurs capacité intrinsèques.
Soyons honêtes, on ne code pas de la même manière en Boo ou IronPython qu’en python. Le fait de se reposer sur un framework (.Net or Mono) change énormément la donne et dans la plupart des cas, l’approche même du problème.
Bien sûr, les possibilités offertes par le langage sont importantes. Très importantes même. Il s’avère juste que ce n’est pas la raison la plus importante du pourquoi j’affectionne les langages issus de python.
Si ce qui compte le plus n’est pas ce que le langage fait, qu’est-ce ?
J’ai réalisé récemment que ce que j’aimais vraiment, c’était d’être enfin libéré des délimitateurs de blocs.
Ca, et le fait que le compilateur/interpréteur ait l’air un peu moins crétain et qu’il soit finalement capable de deviner quel type j’utilise sans lui spécifier deux fois systématiquement.
Pourquoi faudrait-il que ‘jaie à taper
?
Est-ce que le compilateur ne peut pas deviner à partir de la partie droite de l’assertion que var est de type T? Je sais, C#3 y arrive finalement, mais il aura falu une éternité pour que cela advienne si vous voulez mon avis.
Mais le meilleur point est définitement de ne plus avoir à taper d’acoolades en codant.
Si, comme moi, vous utilisez un clavier AZERTY, il vous faut appuyer sur AltRight + 4 et AltrRight + « + » pour faire les accolades.
Clairement, le type qui a designé le clavier AZERTY n’était pas un codeur C…
Bien sûr, avec le temps, tout développeur qui se respecte apprend à étendre son annulaire pour atteindre la combinaison de touche sans y réfléchir. Mais j’ai toujours considéré ce point comme une difficulté supplémentaire et inutile à l’apprentissage de la programmaion.
Mais à y réfléchir, la situation a été encore pire fût un temp! Je me rappelle un temps où il fallait taper des mots entiers (!) pour délimiter un bloc de code.
Je suis arrivé à la programmation à la fin des années 80. A cette époque, j’expérimentais mes premières douleurs programmationistiques en GFA basic sur mon Atari ST. Les commentaires suivants sont aussi valables à l’école qui est venue à la programmation par le VB.
Le Basic, une fois qu’il est devenu assez mature pour intégrer des réels contrôles de flux et plus uniquement les GOTO et GOSUB, de nouveaux mots ont été intégré pour délimiter ces blocs d’instructions.
Pour chaque boucle ou bloc conditionnel, on a un délimiteur de début et un de fin.
Dans le but, j’imagine (sic), de rendre les choses plus claires pour les developpeurs Basic, il a été décidé de définir des délimiteur spécifiques par type de bloc
If IWantAnIf Then
'... DoSomeStuff
EndIf
Do
'... Whatever
Until done
Do
'.. Loop
Loop
For i = 0 To 1
'...
Next
Etc.
A noter que cette syntaxe est toujours valide, par exemple en VB.Net ou VBA.
Après le Basic, le second langage que j’ai appris a été le Pascal, à l’école.
Avec le Pascal, il m’était introduit le concept de délimiteurs de blocs universels. Une fois que le type du bloc est défini et les conditions remplis, le bloc est toujours délimité par un begin et un end.
program WHILE_DEMO (output);
const PI = 3.14;
var XL, Frequency, Inductance : real
begin
Inductance := 1.0;
Frequency := 100.00;
while Frequency < 1000.00 do
begin
XL := 2 * PI * Frequency * Inductance;
writeln('XL at ',Frequency:4:0,' hertz = ', XL:8:2 );
Frequency := Frequency + 100.00
end
endLes choses devenaient déjà un peu plus simples, mais il me fallait toujours taper 8 charactères uniquement pour que le compiler comprenne où le bloc commence et où il finit.
On retrouve ce genre de syntaxe par exemple en PL/SQL et en T-SQL.
C’est ensuite que j’ai rencontré le C…
A l’époque, passer de begin … end à {…} était déjà un gros soulagement pour moi. Il était évident qu’il s’agissait de LA manière de procéder. D’ailleurs, la grande majorité des langages courants que j’ai ensuite appréhendés utilisaient la même méthode: C++, Java, Javascript, Perl, PHP, C# etc.
Très vite, j’ai commencé à croire que les accolades étaient un paradigme universel.
Jusqu’à ce que je tombe sur du code en ruby et python… Ma première réaction a été négative. Le code me semblait « sale » et probablement sujet à erreur. J’utilisais les accolades avec tous mes langages depuis 10 ans et il avait certainement une bonne raison pour cela. C’était la manière de faire.
Point barre.
A part qu’il a fallu que je change d’avis. A force de croiser d’excellentes applications développées à partir de Django ou en voyant que Google utilisait massivement python en interne, je me suis forcé à y jeter un nouveau coup d’oeil. Et ça déchire.
Une chose est certaine: Au bout du compte, coder, c’est taper. Et plus on a à taper, moins on pense au code.
Plus la syntaxe est simple, plus on peut se concentrer sur ce que le code doit faire et pas sur comment l’écrire. Cela permet aussi d’avoir un code plus lisible et donc plus facilement débuggable.
Comparons juste les deux bouts de code suivants :
C#
class MyClass
{
private string _name;
public string Name
{
get { return this._name; }
set { this._name = value; }
}
}Et maintenant, en Boo
class MyClass:
[Property(Name)]
_name as string
Les deux font exactement la même chose et vont produire virtuellement le même code MSIL.
Lequel des deux est le plus rapide à écrire ?
Lequel des deux est le plus facile à lire ?
Mais même si il y a un gros buzz atour de ruby, python et consors depuis un certain temps, je ne suis pas persuadé que ces langages, basés sur ce nouveau type de syntaxe aient encore atteint leur pleine maturité.
Premier symptôme: La relative pauvreté en matière d’intégration dans les IDE.
Concernant Python:
- Boo a perdu son auto-completion dans MonoDevelop avec la version 2.0. Un plugin pour VS est dispo depuis peu, en version alpha.
- PyDev, sur Eclipe, apporte la complétion des méthodes natives mais a encore un gros chemin à parcourir. On est encore très loin de la qualité d’un CDT, PDT ou JDT.
- Cobra en est encore juste au stade de la coloration syntaxique, sans intégration réelle dans aucun IDE à ma connaissance.
- IronPython fait figure d’exception. Il est relativement bien intégré à Visual Studio mais il faut alors se limiter à Windows.
Je suis très loin d’être un expert en ruby mais j’ai l’impression que la situation pour ce langage est un peu inverse (assez bonne intégration dans Eclipse, à un stade très jeune pour IronRuby)
De plus, notamment concernant python, trop de dialectes concurrents existent encore, dont aucun n’a encore rendu l’âme.
Le python « natif » a naturellement l’avantage grâce à son age mais les performances sont un problèmes. Autre souci: le manque de portabilité. Sous Windows, il faut encore ajouter la relative confidentialité de ce langage.
IronPython est assez mature lorsqu’il s’agit de faire du .Net mais n’est toujours pas officiellement supporté au sein de l’écosystème Mono. Boo est excellent et offre des possibilités supplémentaires comme le duck typing mais est encore très jeune.
De manière intéressante, on peut observer à peu près la même évolution pour les formats d’échange de données pour le web
Depuis le début des années 90, le roi est sans conteste XML. Il a été décliné en un nombre quasi infini de spécifcations, formats ou standards que tous, nous utilisons ou devrions utiliser tous les jours (XHTML, SOAP & WSDL, XSL(T), XSD, RDF, OWL, XMAL, XUL, SVG, OpenDocument ou autres standards Oasis…)
XML a été si largement adopté que certains ne peuvent même s’imaginer autre chose pour échanger des données.
Je regardais l’autre jour une conférence de Douglas Crockford, le père de JSON. J’ai été choqué de voir que certains clients refusaient d’utiliser JSON au prétexte que leur politique était « de se conformer à XML ».
Si on regarde un message XML, on se retrouve devant quelque chose de verbeux, qui donne plus d’importace aux méta-informations qu’à l’information elle-même. Tous les délimiters de bloc sont spécifiques par bloc et utilisent des mots entiers.
D’une certaine manière, XML est aux formats d’échange de données ce que Basic est aux langages de programmation.
JSon utilise les accolades. Il est déjà beaucoup plus facile à lire, permet généralement des tailles de message plus réduites, ce qui peut rapidement devenir un avantage de poids sur un réseau.
Enfin, on a YAML, le python|ruby des formats d’échange de données.
Et là encore, les deux derniers formats paraissent bien imatures comparés à XML. Je dois concéder qu’il y a de bonnes raisons à cela.
Toutes les plateformes de développement offrent au moins une, souvent plus, bibliothèque de parsing XML. Cela commence aussi à être vrai pour JSON, pas encore pour YAML.
Seul XML offre la possibilité d’être validé par schéma ou DTD.
ET bien sûr, la base installée des applications web basées sur XML est par beaucoup plus importante que n’importe quel autre format.
Et vous, êtes-vous prêt pour les syntaxes basées sur l’indentation ?
*[EDIT:] Je viens de réinstaller PyDev et je dois dire que de gros progès ont été faits. PyDev est maintenant capable d’indiquer quels imports sont nécessaires ou pas et de chercher dans vos imports pour vous offrir de la complétion sur vos types. Je n’arrive toujours pas à forcer l’autocompletion d’un type dans un for mais je suis à peu près sûr qu’il doit y avoir un moyen en utilisant des commentaires.
