Ah, mais je ne dit pas qu'il faut fuir les outils simples, qui s'appuient sur quelques concepts puissants plutôt qu'une foultitude de fonctionnalités!
Au contraire, mes langages préférés tombent tous dans cette catégorie: Forth, Lua, Scheme, et dans une moindre mesure le regretté Eiffel. Je tiens Smalltalk en haute estime, même si je ne l'ai jamais pratiqué "en conditions réelles" (remarque, Forth non plus, hélas).
Je voulais simplement dire qu'il ne faut pas éliminer d'office un outil parce qu'il contient trop de fonctionnalités: parfois, il restera le meilleur choix.
D'autre part, même dans les langages "simples", il faut faire un choix, restreindre non pas la quantité de fonctionnalités qu'on va utiliser (vu que par définition elles sont déjà restreintes) mais la façon dont on va les utiliser. Par exemple dans Lua, un concept unique, la table, peut permettre une approche orientée classes, orientée prototype, simple conteneur, etc.
[^] # Re: Savoir choisir, plutôt que se restreindre
Posté par drakmaniso . En réponse au journal Programmation : la complexité c'est le mal. Évalué à 0.
Ah, mais je ne dit pas qu'il faut fuir les outils simples, qui s'appuient sur quelques concepts puissants plutôt qu'une foultitude de fonctionnalités!
Au contraire, mes langages préférés tombent tous dans cette catégorie: Forth, Lua, Scheme, et dans une moindre mesure le regretté Eiffel. Je tiens Smalltalk en haute estime, même si je ne l'ai jamais pratiqué "en conditions réelles" (remarque, Forth non plus, hélas).
Je voulais simplement dire qu'il ne faut pas éliminer d'office un outil parce qu'il contient trop de fonctionnalités: parfois, il restera le meilleur choix.
D'autre part, même dans les langages "simples", il faut faire un choix, restreindre non pas la quantité de fonctionnalités qu'on va utiliser (vu que par définition elles sont déjà restreintes) mais la façon dont on va les utiliser. Par exemple dans Lua, un concept unique, la table, peut permettre une approche orientée classes, orientée prototype, simple conteneur, etc.