Ca ne passera jamais sous cette forme, heureusement. Mais pour ceux qui veulent s’y essayer, c’est facile à implémenter:

class pipe:
    def __init__(self, data):
        self.data = data
    def __rshift__(self, other):
        return piped(self, other)
    def __iter__(self):
        return iter(self.data)
 
class piped(pipe):
    def __init__(self, data, process):
        self.data = data
        self.process = process
    def __iter__(self):
        for x in self.data:
            yield self.process(x)
 
res = pipe(["1", "2", "3"]) >> int >> (lambda x: x * 2) >> (lambda x: "#%s" % x)
for x in res:
    print(x)

Perso, quand je vois ce genre de code, je pleure. Tout devient plus dur à debugger : pdb, la stack trace, les prints, tu peux tout te mettre au cul.

Après je ne me positionne pas sur les la prolongation aux langages de prog, comme le dit Eric je trouve ça très subjectif; le sens de codes en Haskell/Ocaml m’apparaissent beaucoup plus clairement que ceux en C ou même en Python (no joke), mais j’ai bien vu que masse de gens qui ont publié ici ne sont pas de mon avis.

@dineptus Bien sur qu’il faut une formation specifique, tout autant que pour lire du code python.

J’ai enseigné le PHP, le Java, le Python et le Javascript. J’ai vu enseigné le VM, le lisp, l’erlang et le C. Le temps et l’effort de la formation est toujours bien plus faible en Python.

Est ce que ca veut dire que le japonais a une charge cognitive plus forte? Je ne pense pas, les japonais lisent aussi vite et sans efforts particuliers. La charge est juste repartie differement.

Oui, la charge cognitive est plus importante en japonais.

Ce n’est pas un hasard si les japonais favorisent les personnages très stéréotypés, les expressions exagérées et les onomatopées dans les arts. Cela donne un contexte important pour la compréhension d’un message.

Apres, je comprends mal cette peur de la recursion,

Prend un sociologue, et apprends lui la programmation. Et tu comprendras.

Après, je ne retire en aucun cas les mérites des mécanismes des langages que tu cites. Je dis simplement qu’ils se font au prix d’autres qualités, et que souvent, je donne la priorité à ces dernières. Et Guido aussi.

Bravo, en un exemple tu viens de me faire passer l’envie de toucher à ce langage, c’est complètement illisible le deuxième exemple ! Il faut avoir une formation spécifique pour comprendre ce machin.

@dineptus Bien sur qu’il faut une formation specifique, tout autant que pour lire du code python.

Les langages fonctionnels encourages un style où les instructions sont compressées et chaînées, où il y a moins de mot clés, et plus de symbole. Cela augmente ce qu’on appelle “la charge cognitive”, c’est à dire le nombre de cycle cpu que le cerveau doit consacrer, non pas à la tache de comprendre le sens du code, mais à décortiquer la structure.

@Sam “La charge cognitive” est une notion tres relative.

Si l’on compare par exemple l’anglais et le japonais:

• 26 lettres en anglais contre environ 2000 caracteres en japonais

• des mots espaces en anglais, aucun espace en japonais

Est ce que ca veut dire que le japonais a une charge cognitive plus forte? Je ne pense pas, les japonais lisent aussi vite et sans efforts particuliers. La charge est juste repartie differement.

Pour les langages fonctionnels je pense que c’est un peu la meme idee, c’est juste une facon differente d’apprehender le code.

Apres, je comprends mal cette peur de la recursion, si la fonction est pure elle peut etre testee independament (et prouvee comme logiquement correcte avec un peu d’effort). Et la plupart du temps une solution basee sur fold ou map suffisent.

Pour apporter deux trois choses au debats tests / typage:

• Le typage statique et les monades dans haskell apportent une securite dans le code que peu d’autres langages ont. Sur le sujet A Pragmatic Case for Static Typing with Brian Hurt est vraiment interessante.

• Les langages fonctionels peuvent etre teste avec des tests de proprietes qui permettent de trouver des bugs plutot bien caches via generation de tests automatiques. Sur le sujet Testing for the Unexpected de Ulf Wiger et Testing the Hard Stuff and Staying Sane de John Hughes.

Elixir c’est pas mal et ca apporte de vrais choses en plus a erlang comme une bonne gestion de l’unicode et mix.

Dans un autre genre, il y a Elm qui est base sur haskell et qui permet de creer des applis web/js.

Nb: Guido van Rossum. Sans V majuscule. Cf sa bio twitter.

@Noir: Le fait que le typage était seul me paraissait assez évident…

@PeuLeuBeu T’as jamais eu de problème de signe dans tes programmes ? C’est le genre de truc difficile à voir et où le typage ne t’apporte rien (pour les petits malins, dans les calculs on utilise plus souvent des floats que des unsigned int), la seule vérification possible c’est le test (ou la preuve formelle).

J’ai regardé vite fait si ça se faisait le calcul numérique avec des langages fonctionnels (c’est mon domaine, j’y peux rien !). Il y a des librairies existantes en Haskell, OCaml et F#. J’ai vu aussi que certains algos numériques simples ne s’écrivent pas de manière optimale en FP. Par contre la lib FFTW (pour faire des FFTs ultra-rapides) utilise OCaml, tout n’est pas perdu ! ;)

Enfin dans mon expérience en OCaml, quand je code un truc qui ressemble à peu près à l’algo que j’ai en tête et que ça type, ben je suis à peu près sûr que le code est ok à réglages près.

Bon, je sais pas si je m’exprime bien, z’avez qu’à tous coder en Caml et vous verrez par vous-même bordel.