Et BTW, j'attends toujours de voir le langage maintenable (et donc à la philosophie compréhensible par tout le monde, ce qui tend à exclure les langages fonctionnels qui ne sont pas dans les moeurs), sécurisé, et tout et tout.
Ben forcément si tu refuses la réponse par principe...
La programmation fonctionnel à l’immense avantage :
— d’avoir un système de type excellent : en Caml ou Haskell, si ça compile c’est qu’à priori il n’y a pas de bug (évidemment il peut rester des bugs, mais le gros des bugs ne passe pas la compilation) ; par contre erlang est moyen de ce côté là
— d’avoir une gestion de la mémoire facile et locale : la seule subtilité c’est la récursion terminale, mais c’est pas non plus compliqué à comprendre et ça ne concerne à chaque fois qu’une fonction. Locale parce que si aucune fonction n’as de fuite mémoire (comprendre récursion non terminal) tu sais que ton code entier n’as pas de fuite.
— gère le multi threading de manière naturelle (cf Erlang)
Je ne dis pas que c’est l’alpha et l’omega et que tout est parfait. Mais si tu veux un langages maintenable la solution consiste peut-être à changer de paradigme ! C’est justement la raison qui à pousser Erlang à ne pas être objet ; cf un article du fondateur du langage : http://harmful.cat-v.org/software/OO_programming/why_oo_sucks
Je programme trop peu pour dire que l’objet pue et que le fonctionnel déchire ; mais si tu ne trouve aucun langage objet/impératif maintenable, peut-être que le problème c’est l’objet/impératif et c’est idiot de refuser par principe d’autre paradigme.
[^] # Re: C'est pourtant évident.
Posté par Diagonale de Cantor (site web personnel) . En réponse à la dépêche Coder efficacement, bonnes pratiques et erreurs à éviter. Évalué à 7. Dernière modification le 17 avril 2014 à 13:52.
Ben forcément si tu refuses la réponse par principe...
La programmation fonctionnel à l’immense avantage :
— d’avoir un système de type excellent : en Caml ou Haskell, si ça compile c’est qu’à priori il n’y a pas de bug (évidemment il peut rester des bugs, mais le gros des bugs ne passe pas la compilation) ; par contre erlang est moyen de ce côté là
— d’avoir une gestion de la mémoire facile et locale : la seule subtilité c’est la récursion terminale, mais c’est pas non plus compliqué à comprendre et ça ne concerne à chaque fois qu’une fonction. Locale parce que si aucune fonction n’as de fuite mémoire (comprendre récursion non terminal) tu sais que ton code entier n’as pas de fuite.
— gère le multi threading de manière naturelle (cf Erlang)
Je ne dis pas que c’est l’alpha et l’omega et que tout est parfait. Mais si tu veux un langages maintenable la solution consiste peut-être à changer de paradigme ! C’est justement la raison qui à pousser Erlang à ne pas être objet ; cf un article du fondateur du langage : http://harmful.cat-v.org/software/OO_programming/why_oo_sucks
Je programme trop peu pour dire que l’objet pue et que le fonctionnel déchire ; mais si tu ne trouve aucun langage objet/impératif maintenable, peut-être que le problème c’est l’objet/impératif et c’est idiot de refuser par principe d’autre paradigme.