Re: Blurb

j’élimine ceux qui utilisent des machines virtuelles comme java, puis d’une moindre mesure ceux écris dans des langages non-compilés comme python, ruby, etc… Je regarde aussi le degré de « vie » du logiciel : date du dernier commit…

Je regarde également les mêmes points, mais pas dans le même ordre, et surtout pas avec la même décision :

• Date du dernier commit : Je regarde aussi ce point. Mais à lui seul il ne donne pas toute l'info necessaire. Faut-il preferer un logiciel dont le dernier commit date de 6 mois avec 2500 bugs d'ouvert dans le bugreport dont 150 de critiques, ou un logiciel dont le dernier commit date d'un an et demi dont tout les bugs sont résolus ? Je prefère clairement le second logiciel.
• machine virtuelle à la java : Je regarde ce point, j'en tire les même conclusion, mais je n'en suis pas fier. J'ai les poils qui s'herissent dès que je dois utiliser un logiciel en java, j'ai toujours des problèmes. Mais j'ai un préjugé fort contre java, je ne me permettrai pas d'en tirer des conclusions générales.
• Language interprété : j'aime bien regarder en quoi c'est codé, je n'en tire pas de conclusions particulière uniquement sur ce point. J'ai même tendance à penser que quand c'est codé dans un language de haut niveau que la maintenance du logiciel sera plus facile. Prenons un programme avec un seul dev, imaginons dans un premier temps qu'il est en C (et en bon vieux C, pas en C++), même si le code est bien écrit et documenté, il est plus difficile pour un dev externe de se plonger dans le code pour le faire évoluer que si il est écrit (avec niveau de documentation égal) dans un language de haut niveau comme Python. Je fais une exception pour Perl, bien que ce soit un language de haut niveau que j'adore, il faut avouer que de code Perl, même documenté, peut se réveler parfaitement illisible.