Je préfèrerais l'inverse : un langage ou par défaut la valeur de la variable soit immuable par défaut, et qu'un type particulier serve à définir une variable qui peut être modifiée.
Tu peux toujours définir des types constants, et t'y limiter. Personnellement, ça fait belle lurette que je n'utilise plus les types char, short, int et long: ils rendent les programmes peu portables, trop sensibles à un changement d'architecture ou de compilateur. Je leur préfère les FOOBAR_intXY_t. Si tu préfères des types constants par défaut, rien ne t'empêche de te faire un fichier qui définit des alias constants à coup de typedef.
Personnellement je pense le contraire
Toutes les opinions se défendent.
le multi-paradigme, c'est risquer de perdre les avantages du fonctionnel dans un bout de code qui ferait appel à du non-fonctionnel.
Je n'ai vu dans tes réponses que l'argument de la constance. Dans ce cas, et dans le cas du C++, c'est faux: il est impossible (bon, ok, je mens: comme toujours en C++ on peut forcer la main au langage. La raison de cet état de fait, c'est que C++ est compatible avec le code crade, ce qui permets de nettoyer au fur et à mesure les bases... mais aussi de faire de la merde!) de modifier un objet via des méthodes marquées const. Il est aussi impossible de modifier tout paramètre constant passé de la même manière.
Personnellement, je me sers énormément du const, en m'inspirant de la programmation par contrat*.
Les autres avantages du fonctionnel, je ne les connais pas.
*: je vérifie systématiquement toutes mes pré-conditions.
Je ne fais que m'inspirer, parce que je ne vérifie jamais les invariants: beaucoup de code pour un intérêt très limité à mes yeux, le langage lui-même permettant une bonne sûreté de ce côté là, tant qu'on utilise pas friend à la légère et que l'on mets un maximum de chose en private, le tout couplé avec des classes réellement spécialisées.
[^] # Re: Pur ou pas ?
Posté par freem . En réponse au message Langage fonctionnel "bas niveau" (genre C). Évalué à 2.
Tu peux toujours définir des types constants, et t'y limiter. Personnellement, ça fait belle lurette que je n'utilise plus les types char, short, int et long: ils rendent les programmes peu portables, trop sensibles à un changement d'architecture ou de compilateur. Je leur préfère les FOOBAR_intXY_t. Si tu préfères des types constants par défaut, rien ne t'empêche de te faire un fichier qui définit des alias constants à coup de typedef.
Toutes les opinions se défendent.
Je n'ai vu dans tes réponses que l'argument de la constance. Dans ce cas, et dans le cas du C++, c'est faux: il est impossible (bon, ok, je mens: comme toujours en C++ on peut forcer la main au langage. La raison de cet état de fait, c'est que C++ est compatible avec le code crade, ce qui permets de nettoyer au fur et à mesure les bases... mais aussi de faire de la merde!) de modifier un objet via des méthodes marquées const. Il est aussi impossible de modifier tout paramètre constant passé de la même manière.
Personnellement, je me sers énormément du const, en m'inspirant de la programmation par contrat*.
Les autres avantages du fonctionnel, je ne les connais pas.
*: je vérifie systématiquement toutes mes pré-conditions.
Je ne fais que m'inspirer, parce que je ne vérifie jamais les invariants: beaucoup de code pour un intérêt très limité à mes yeux, le langage lui-même permettant une bonne sûreté de ce côté là, tant qu'on utilise pas friend à la légère et que l'on mets un maximum de chose en private, le tout couplé avec des classes réellement spécialisées.