Quand je discute avec des développeurs Java.Net, j'entends souvent des réflexions négatives sur les langages à typage dynamique. Ils trouvent que cela donnes des applis moisies, peu maintenanble et vas-y que je pleurniche. J'imagine que ces mêmes développeurs poussent des hauts cris lorsqu'on utilise l'inférence de type en C#. Tss.
Personnellement, j'en ai marre des langages à typage statique. Je trouve que leurs apports sont bien loin de supplanter leurs inconvénients.
Les apports sont les suivants :
- l'aspect documentant via les interfaces ;
- les contrôles à la compilation qui assurent que tout ce qu'on utilise est bien décrit quelque part ;
- le code écrit avec ces langages est réputé plus rapide.
En contre partie, les inconvénients :
- les interfaces figent la structure de l'information attendue jusqu'au namespace / package ;
- la compilation est longue (si vous voulez passer un sale quart d'heure, utilisez VS 2008) ;
- c'est extrêmement verbeux (même si certains langages permettent de faire de l'inférénce de type à la compilation).
Les développeurs sus nommés argumentent souvent sur le fait que le build leur permet de trouver des erreurs. Avec les langages à typage dynamique, les erreurs apparaissent au Run. On peut se reposer uniquement sur des tests pour s'assurer que notre programme fonctionne. Cependant, la compilation ne permettant pas de se passer de test, je me dis que l'inconvénient du typage dynamique est minime à ce niveau là.
Mon gros problème du moment est l'aspect figé complètement débile. En .Net, j'utilise des web service SOAP dont les proxies sont fournis par WCF. Et bien, la configuration simple via l'ajout de service reference me crée un name space par référence de services, que ce soit pour les méthodes comme les types utilisés. Il n'y a aucune méthode simple pour faire autrement, tout en conservant l'aspect magique de « je fais clic droit + mettre à jour la référence pour mettre à jour la référence de service » (même là ce n'est pas simple car on doit faire un gros search and replace pour changer la gestion des valeurs par défaut).
Nous avons essayé une tonne de solutions alternatives, aucune n'est simple.
Au final, on va utiliser les référence de service WCF et faire du mapping d'objet pour les passer d'un namespace à l'autre. Oui c'est de la merde.
Avec un langage dynamique on n'aurait pas du tout ce problème. On pourrait oublier la plomberie pour se consacrer sur la création de valeur.
Alors amis développeurs, n'ayez pas peur, le typage dynamique est votre ami ! Lâchez vos Java et C# et commencez à être efficaces.
Et SOAP, ah quel malheur ! Je le laisse pour un prochain coup de gueule...
Une dernière remarque sur mon problème : le fait de pouvoir utiliser un namespace par service ne me parait pas choquant en soi. Le fait d'utiliser les mêmes objets dans plusieurs web services différents reflète un problème de design. C'est une rupture d'orthogonalité car la modification d'un service et des types associés a des répercussions sur d'autres services.
Mais si on passait notre temps sur des applis bien conçus, on n'aurait vite plus de travail.
