ma_vie:
J'ai appris le C, et le C++ durant mes études, ainsi que de l'assembleur (6809,68hc11, 68000 et x86), ainsi que du shell unix, et du turbo pascal en stage. Ensuite dans ma vie professionnelle, j'ai fait shell, perl, awk, python, ruby, javascript, php, sql, lua (un peu) ainsi que du VBA , un peu de TCL. Depuis peu je me suis mis un peu à Groovy. A titre personnel, je me suis intéressé à Ada, Rebol, prolog, smalltalk, erlang, elixir, java, go, rust (très peu pour ces deux derniers) ainsi que Forth, j'ai refait du C, de l'assembleur (AVR et 8051), je me suis intéressé de loin à Lisp et ses dérivés et comme indiqué dans un précédent journal, du BASIC dans les années 80 sur T07.
Ce que j'en déduis de tout ça, c'est qu'il n'y a pas de langage parfait. Chaque langage que j'ai utilisé a été développé dans un contexte et pour des besoins particuliers, avec certaines contraintes, et quand on sort un peu trop du cadre initial, on commence à avoir des problèmes.
Parmi les langages que j'apprécie le plus, je peux citer Ruby, Erlang, C et ADA. Parmi ceux que j'aime le moins, il y a elixir, python, java, php.
Ce que je n'aime pas pour les 3 derniers langages, c'est le fait qu'ils ne soient pas toujours très cohérents. Pour le PHP, ça fait trop longtemps que je n'ai plus fait donc je le laisserai de côté car les versions récentes corrigent peut-être ce que je n'aimais pas lorsque j'en faisais. Pour Java, un des trucs que je n'aime pas et que je trouve dangereux c'est la conversion implicite. Je n'aime pas non plus la gestion des exceptions.
Pour python, je n'aime pas son manque de cohérence général (par exemple, on ne sait jamais si on doit faire des trucs du style str(machin) ou machin.str(), alors qu'en ruby par exemple c'est plus clair). On sent que le langage a été plus ou moins enrichi au fur et à mesure avec des trucs venus d'ailleurs, sans se poser trop de question sur la cohérence générale. Je n'aime pas non plus le manque de switch/case. Je n'aime pas trop non plus le mix de paradigme objet/fonctionnel qui casse la fluidité de la lecture du code (mais on peut s'en arranger en incluant ces bouts de code dans des fonctions qui permettent d'isoler ces changements de paradigme et améliorer la fluidité de lecture). Je n'aime pas non plus les décorateurs de Python (je n'ai jamais vraiment biern compris comment ça marche, je préfère largement les mixin de Ruby). Par contre il y a quelques concepts de métaprogrammation que je trouve intéressant en Python (notamment les métaclasses), mais je trouve que le langage ne va pas assez loin sur ces concepts. Je trouve que l'obligation d'indenter le code est une bonne idée, mais que s'en servir pour définir les blocs est une mauvaise idée, et rend la refactorisation de code compliqué. Et fondaentalement, je n'aime pas l'esprit rigide de python ("ce n'est pas la bonne façon de faire") et qui oblige souvent à se faire des noeuds au cerveau alors que d'autres langages ont l'élégance de s'effacer devant la créativité du développeur. Et pour Elixir, je n'ai pas poussé très loin, mais par rappoort à Erlang, je trouve qu'il casse un certain nombre de concepts qui font l'intéret du langage (je pense par exemple aux variables à affectation unique).
Tout ça pour dire que bien souvent, le choix d'un langage adapté dépendra du type de problème à traiter, tout comme le choix de n'importe quel outil. Je suis d'avis qu'il n'existe pas de langage réellement "généraliste". Dans certains cas d'usages, on pourra choisir indifféremment plusieurs langages, mais on peut avoir certaines contraintes qui font que choisir le bon langage pourra permettre de s'éviter des difficultés de développement parce que le langage sera plus adapté aux problèmes à traiter.
# je ne suis pas développeur à temps plein, mais je fais quand même du développement.
Posté par totof2000 . En réponse au journal La ronde (boucle?) des langages. Évalué à 4.
ma_vie:
J'ai appris le C, et le C++ durant mes études, ainsi que de l'assembleur (6809,68hc11, 68000 et x86), ainsi que du shell unix, et du turbo pascal en stage. Ensuite dans ma vie professionnelle, j'ai fait shell, perl, awk, python, ruby, javascript, php, sql, lua (un peu) ainsi que du VBA , un peu de TCL. Depuis peu je me suis mis un peu à Groovy. A titre personnel, je me suis intéressé à Ada, Rebol, prolog, smalltalk, erlang, elixir, java, go, rust (très peu pour ces deux derniers) ainsi que Forth, j'ai refait du C, de l'assembleur (AVR et 8051), je me suis intéressé de loin à Lisp et ses dérivés et comme indiqué dans un précédent journal, du BASIC dans les années 80 sur T07.
Ce que j'en déduis de tout ça, c'est qu'il n'y a pas de langage parfait. Chaque langage que j'ai utilisé a été développé dans un contexte et pour des besoins particuliers, avec certaines contraintes, et quand on sort un peu trop du cadre initial, on commence à avoir des problèmes.
Parmi les langages que j'apprécie le plus, je peux citer Ruby, Erlang, C et ADA. Parmi ceux que j'aime le moins, il y a elixir, python, java, php.
Ce que je n'aime pas pour les 3 derniers langages, c'est le fait qu'ils ne soient pas toujours très cohérents. Pour le PHP, ça fait trop longtemps que je n'ai plus fait donc je le laisserai de côté car les versions récentes corrigent peut-être ce que je n'aimais pas lorsque j'en faisais. Pour Java, un des trucs que je n'aime pas et que je trouve dangereux c'est la conversion implicite. Je n'aime pas non plus la gestion des exceptions.
Pour python, je n'aime pas son manque de cohérence général (par exemple, on ne sait jamais si on doit faire des trucs du style str(machin) ou machin.str(), alors qu'en ruby par exemple c'est plus clair). On sent que le langage a été plus ou moins enrichi au fur et à mesure avec des trucs venus d'ailleurs, sans se poser trop de question sur la cohérence générale. Je n'aime pas non plus le manque de switch/case. Je n'aime pas trop non plus le mix de paradigme objet/fonctionnel qui casse la fluidité de la lecture du code (mais on peut s'en arranger en incluant ces bouts de code dans des fonctions qui permettent d'isoler ces changements de paradigme et améliorer la fluidité de lecture). Je n'aime pas non plus les décorateurs de Python (je n'ai jamais vraiment biern compris comment ça marche, je préfère largement les mixin de Ruby). Par contre il y a quelques concepts de métaprogrammation que je trouve intéressant en Python (notamment les métaclasses), mais je trouve que le langage ne va pas assez loin sur ces concepts. Je trouve que l'obligation d'indenter le code est une bonne idée, mais que s'en servir pour définir les blocs est une mauvaise idée, et rend la refactorisation de code compliqué. Et fondaentalement, je n'aime pas l'esprit rigide de python ("ce n'est pas la bonne façon de faire") et qui oblige souvent à se faire des noeuds au cerveau alors que d'autres langages ont l'élégance de s'effacer devant la créativité du développeur. Et pour Elixir, je n'ai pas poussé très loin, mais par rappoort à Erlang, je trouve qu'il casse un certain nombre de concepts qui font l'intéret du langage (je pense par exemple aux variables à affectation unique).
Tout ça pour dire que bien souvent, le choix d'un langage adapté dépendra du type de problème à traiter, tout comme le choix de n'importe quel outil. Je suis d'avis qu'il n'existe pas de langage réellement "généraliste". Dans certains cas d'usages, on pourra choisir indifféremment plusieurs langages, mais on peut avoir certaines contraintes qui font que choisir le bon langage pourra permettre de s'éviter des difficultés de développement parce que le langage sera plus adapté aux problèmes à traiter.