J’ai beaucoup fait de PHP en début de carrière, et voilà ce que je trouve problématique pour la lisibilité :

• beaucoup de caractères spéciaux ($ pour les variables, (){} pour les blocks, & pour les références, -> pour les accès, etc). Donc il faut parser tout ça dans sa tête.
• les litéraux sont confus : les arrays ont trop de casquettes, et il faut regarder tout le code contextetuel pour savoir pour quoi on faire. ” et ‘ ne fait pas pareil. etc.
• bind() c’est un mauvais design de langage, autant en JS qu’en PHP.
• l’API de PHP est plein de fonctions avec des noms à ralonge, faire aka_truc_bidlule_chose(machine_chouette(ma_var)) plutôt que ma_var.machine.bidule() c’est pas pratique.
• la lib standard est dans le name space global. include/require/autoload charge aussi tout dans le namespace global. Du coup ça demande de faire très gaffe aux effets de bords de ses imports.
• il faut faire gaffe à la convertion de type implicite partout, donc ça demande de s’arrêter et réfléchir au code.
• pas de culture de la lisibilité et plein de conventions de formatage différentes qu’on retrouve dans plein de bases de code.
• langage initialelement orienté WEB, et donc un paradigme un peu batard pour les autres usages.
• c’est verbeux. Tout est long à lire.
• les anciennes bases de code PHP (avant l’air de Symfony) sont immondes. C’est culturel : beaucoup de bidouilleurs à l’arrache (j’en étais). D’autres langages ont un héritage beaucoup moins lourd.

Je reviens sur la partie lisibilité et ta remarque à propos de Php et javascript. Pour php, si tu as vu ce genre de chose c’est que tu as à faire à quelque chose de peu sèrieux et donc c’est selon moi un mauvais exemple. Je t’invite à regarder par exemple du Laravel, le code est propre, lisible mais il est sur que cela a était codé par des gens dont c’est le métier. Donc l’idée ici n’est pas de critiquer mais simplement faire remarquer que le langage permet de grandes largesses mais dés que c’est du travail en équipe, il existe des reco et même des outils pour s’assurer qu’il n’y a pas du code de porc. Bref tous ca pour dire que ce n’est pas inhérent au langage car même en python tu peux faire le porc.

Concernant le callback hell de javascript, je n’ai jamais eu de soucis pour débugguer et selon moi le soucis ce trouve plus dans l’imcompréhension du langage qui certe est trés putassier et demande beaucoup plus d’efforts d’apprentissage que python. Je t’invite d’ailleurs à lire/voir ce que Douglas Crockford en dit la dessus, on peut difficelement faire plus limpide.

Pour en revenir au sujet inital, je partage le même point de vue sur la FP. Et même d’un point de vue pédagogie je trouve que python est plus simple comme introduction à un langage. (php aussi mais là c’est certainement moins objectif :D )

</partie utile>

Ben, vu que c’est l’occasion pour moi de commenter pour la première fois, merci d’exister les gars. Depuis que j’ai le nez quasiment à temps plein dans du Python, vous vous êtes rapidement imposé en première place de mes recherches quand j’ai une couille de néophyte (on la reconnaît, elle est petite, moche, et facilement résolvable), et vous y restez depuis que les questions de plus haut niveau apparaissent entre deux élégantes lignes de script.

Bref. Merci à vous d’avoir fait en sorte que l’une des premières bases d’information Python en français ait pour slogan “Du code, du cul.”

</partie suce-boules>

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.