Il n'y a rien qui m'énerve plus que le relativisme absolu, alors forcément, je réagis :)
Et c'est pas avec le langage informatique, mais avec sa cervelle qu'on travaille.
En une heure de temps, la cervelle peut résoudre un nombre limité de problèmes. Selon les cas, la cervelle peut travailler à résoudre le problème sur lequel elle travaille, ou bien travailler à résoudre les problèmes posés par son outil. L'informaticien est donc plus efficace lorsque son outil n'oblige pas sa cervelle à penser à l'outil, mais la laisse se concentrer sur le problème réel.
Je préfère Ruby à Perl parce que j'ai moins besoin de réfléchir à son fonctionnement (et je préférais Perl à C pour les mêmes raisons). Je n'ai pas à me souvenir si le nom de ma variable doit commencer par un ,ドル un % ou un @, si je dois utiliser des crochets ou des accolades, comment sont automatiquement convertis les types, etc. De nombreuses fois, plutôt que d'ailler regarder dans l'API comment on fait une chose, je l'ai écrite comme je pensais que ça devrait s'écrire... et ça a marché.
Pour reprendre ton argument, je pourrais dire qu'un bon mathématicien n'est pas là pour aimer les mathématiques, mais pour trouver des théorèmes. Ce n'est pas avec un formalisme qu'on travaille, mais avec sa cervelle. Par conséquent, il ne sert pas à grand chose de développer de nouveaux formalismes équivalents à des formalismes existants. Par exemple, le lambda calcul ne sert à rien puisqu'il est équivalent aux machines de Turing.
Et pourtant, en formulant les choses différemment, on peut parfois trouver une solution plus facilement. Quand il est difficile/pénible d'exprimer un concept dans un langage, on ne peut pas attendre du programmeur d'utiliser ce concept naturellement. Ce n'est pas qu'une histoire de concision.
Évidemment, la plupart des langages de programmation visent l'universalité, et donc essayent d'incorporer le plus possible de concepts. Ce n'est pas pour cela que ces concepts sont naturels, et ce n'est pas suffisant pour conclure que tous les langages se valent.
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Yusei (Mastodon) . En réponse à la dépêche Ruby 1.9.0 est sorti pour Noël. Évalué à 4.
En une heure de temps, la cervelle peut résoudre un nombre limité de problèmes. Selon les cas, la cervelle peut travailler à résoudre le problème sur lequel elle travaille, ou bien travailler à résoudre les problèmes posés par son outil. L'informaticien est donc plus efficace lorsque son outil n'oblige pas sa cervelle à penser à l'outil, mais la laisse se concentrer sur le problème réel.
Je préfère Ruby à Perl parce que j'ai moins besoin de réfléchir à son fonctionnement (et je préférais Perl à C pour les mêmes raisons). Je n'ai pas à me souvenir si le nom de ma variable doit commencer par un ,ドル un % ou un @, si je dois utiliser des crochets ou des accolades, comment sont automatiquement convertis les types, etc. De nombreuses fois, plutôt que d'ailler regarder dans l'API comment on fait une chose, je l'ai écrite comme je pensais que ça devrait s'écrire... et ça a marché.
Pour reprendre ton argument, je pourrais dire qu'un bon mathématicien n'est pas là pour aimer les mathématiques, mais pour trouver des théorèmes. Ce n'est pas avec un formalisme qu'on travaille, mais avec sa cervelle. Par conséquent, il ne sert pas à grand chose de développer de nouveaux formalismes équivalents à des formalismes existants. Par exemple, le lambda calcul ne sert à rien puisqu'il est équivalent aux machines de Turing.
Et pourtant, en formulant les choses différemment, on peut parfois trouver une solution plus facilement. Quand il est difficile/pénible d'exprimer un concept dans un langage, on ne peut pas attendre du programmeur d'utiliser ce concept naturellement. Ce n'est pas qu'une histoire de concision.
Évidemment, la plupart des langages de programmation visent l'universalité, et donc essayent d'incorporer le plus possible de concepts. Ce n'est pas pour cela que ces concepts sont naturels, et ce n'est pas suffisant pour conclure que tous les langages se valent.