Discussion :

[Jamatronic]

Ouais, les mecs chez Google, Reddit et Dropbox n'aiment pas coder...

Ils aiment coder. Mais cela n'empêche pas que Python est le langage préféré de ceux qui n'aiment pas programmer.

Interroge n'importe quelle promo de Miage ou de BTS. Tu verras que tous les neuneus (ceux qui ne savent toujours pas faire un programme correct de dix lignes après leurs années d'études) te diront que Python est leur langage préféré, parce que c'est (celui qui parait) le plus simple au départ.

Avant le début de la popularité de Python, c'était Java qui avait ce rôle de "langage préféré de ceux qui n'aiment pas programmer".

Lorsqu'un autre langage aura détrôné Python à son tour, je respecterai peut-être à nouveau Python

[jedema]

<<Et n'étant pas un pro, je ne connais pas la syntaxe du C dont découle celle de C+, Java, JS, et tant d'autres, absconse, voire rebutante, et préfère un langage lisible tel que Ruby (mais trop cantonné au Web seul) ou python.

Et bien tu vois, moi, c'est le contraire. Je trouve la syntaxe Python immonde et globalement les IDE dédiés bien pourris. Concevoir une interface adaptée au code, ça fait aussi partie des indispensables d'un IDE... Quelle galère avec Python. Quand on sait ce que font les autres... Et surtout comment il le font. Effectivement, je suis bien content d'avoir le choix d'être parfaitement satisfait de mon utilisation quotidienne de Visual Studio et de C#, d'Eclipse et de Java/Javascript/PHP. Côté IDE orienté code, on a aussi Visual Studio Code (quand même bien plus sympa que Notepad++). Bref! Python, c'est pour la domotique et assimilé, les scienteux. Sorti de ça je me demande encore à quoi ça sert. Je l'ai testé trois semaines et... Jamais plus. En tout cas pas en l'état.

Je vais essayer d'expliquer rapidement pourquoi j'aime particulièrement la syntaxe de Python. En la comparant à celle d'autres langages :

Chercher dans une chaine en PHP :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
if (strstr($ma_chaine, "texte"))

En Python :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
if "texte" in ma_chaine:

Chercher un élément dans un tableau en PHP (notez l'inversion de paramètres en strstr() et in_array()). :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
if (in_array("valeur", $mon_tableau))

En Python :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
if "valeur" in mon_tableau:

Ternaire en PHP :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$frais_de_port = ($prix > 30) ? 8 : 0;

En Python :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
frais_de_port = 8 if prix > 30 else 0

Je comprend que le Python soit déstabilisant au début, notamment le fait de baser les blocs sur l'indentation. Mais on s'y fait vraiment bien. Je codais en PHP/JS avant de me mettre à Python. On oublie les accolades et on utilise l'indentation. A chacun son problème.
Et Python ne sert pas que dans l'éducation où les projets scientifiques. Je l'ai utilisé pour :

• Un projet de centralisation de tous les certificats SSL stocké sur les serveurs Certificate Transparency de Google
• Un projet de robot effectuant des trades automatisés sur le marché des crypto
• Des outils de contrôle de qualité du code.
• Des outils de minification automatisé.
• Un outil de monitoring de serveur utilisant inotify de Linux
• Des sites WEB avec Django (ayant aussi codé en Laravel, Django m'offre une productivité 3 fois supérieure).
• etc....

Et la liste n'est pas fini, car c'est uniquement ma liste personnelle.

En bref, je comprend ceux qui n'aiment pas Python. On ne peut pas tout aimer, surtout lorsqu'on est attaché à une techno. Mais la montée de Python est indéniable et la justifier par l'éducation est très réducteur.

Ce sont surement les mêmes personnes qui disaient : Le Minitel c'est largement mieux qu'Internet. Internet est lié à l'éducation, la preuve HTML a été créé par un scientifique

[Sodium]

J'avoue que moi qui fais du PHP et n'ai jamais touché au Python, je trouve ça limpide, surtout pour l'opérateur ternaire que je trouve particulièrement immonde dans les autres langages.

[dad3zero]

Je n'ai jamais compris la vogue de Python qui, au vu de n'importe quel bout de programme, me paraît mal structuré.
En particulier les instructions composites comme if ne se terminent jamais. Résultat, si j'ai bien compris, le programme est étroitement dépendant non seulement des retours à la ligne (comme les shells et les anciens Basic) mais des indentations.

Je suppose que cela donne lieu à des bogues peu visibles inconnues des autres langages, selon les blancs et les tabulations présents en début de ligne.
Et l'absence de mots clés de fin d'instruction (ou d'accolades comme en C) ne contribue sûrement pas à la clarté de programmes un peu longs.
Et dans quel but ? une "simplification" minime et illusoire ?

Petite précision : il existe bien un indicateur de fin de bloc (pas d'instruction, un bloc étant composé de plusieurs instructions) : désindenter.

Oui, je confirme, le risque de bogs est réel et je l'ai régulièrement observé, mais ce n'est pas un problème du langage mais des développeurs qui ne prêtent aucune attention au code qu'ils écrivent. Dans leur techno d'origine où les blocs sont définis par les accolades, ils se reposent en général sur le ctrl-f pour retrouver un semblant de lisibilité et les bogs existent car il n'y a évidemment aucun test unitaire.

Donc à la question de pourquoi, simplement pour une question de rigueur, lisibilité et maintenabilité.

[dad3zero]

Chercher un élément dans un tableau en PHP (notez l'inversion de paramètres en strstr() et in_array()). :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
if (in_array("valeur", $mon_tableau))

En Python :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
if "valeur" in mon_tableau:

Et encore, ajoute les

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
if "valeur" in mon_tableau[len(mon_tableau // 2:]:

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
if "valeur" in [extract_value(element) for element in mon_tableau]:

et

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
for element in mon_tableau:
    if validate(element):
        break
else:
    print('no such element')

[el_slapper]

Ils aiment coder. Mais cela n'empêche pas que Python est le langage préféré de ceux qui n'aiment pas programmer.
(.../...)

Possible, quoique je n'en sache rien.

Mais ça pose une question : doit-on juger un langage juste sur le fait que des gnous l'utilisent? A ce titre, VBA pour excel est une sombre bouse. Pourtant, eu égard à son âge, il est très puissant, et j'ai vu des trucs en béton fait avec(et j'ai aussi fait quelques trucs pas mal moi-même, même si je ne suis pas le meilleur). Ses seules vraies limites sont l'absence d'héritage(largement contournable) et surtout l'aspect "partage des données" d'EXCEL qui est, euh, comment rester poli? Plus quelques sucres syntaxiques modernes qui montrent l'âge du truc(pas de typage des collections, argh).

Python permet de tout faire, avec un parti pris fort de conception, qui plait ou pas (l'indentation sert de séparateur de bloc). Comme avec tout langage, on peut faire du meilleur comme du pire. La vraie question, pour mol, c'est juste : est-ce le meilleur outil pour mon besoin spécifique? Et si mon besoin spécifique change? La réponse est généralement non à la première question, un langage généraliste est généralement moins fort qu'un langage de niche sur un domaine précis. La réponse à la deuxième question est diablement plus complexe. Et le simple fait de la poser justifie l'existence de langages généralistes comme le Python ou le Java.

De toutes façon, il y aura toujours des para-programmeurs, des gens dont le métier n'est pas de programmer mais qui programment à l'occasion pour des besoins ponctuels. Et la plupart d'entre eux iront au plus direct, qui est généralement une sombre bouse. Accuser le langage, ça me parait un peu injuste. Critiquer le Python sur son choix de délimiteur de bloc, pourquoi pas(même si je ne suis pas d'accord). Ou sur ces choix de conception, ou sur sa syntaxe(que j'aime bien, mais encore une fois, je suis ouvert au débat). Mais parceque des gens moins bien formés que nous font des choses avec qui nous déplaisent? Non.

[Christian_B]

Je vais essayer d'expliquer rapidement pourquoi j'aime particulièrement la syntaxe de Python. En la comparant à celle d'autres langages : [...]

Je reconnais que sur les exemples simples que tu donnes la syntaxe de Python paraît plus agréable car proche du langage naturel (enfin surtout pour les anglo-saxons). Et en PHP, un nom de fonction comme strstr est assez bizarre.
Mais Python n'est pas le seul langage qui utilise des mots clés comme in ou is sous if.

Le problème est que sous prétexte de simplification on supprime des délimiteurs, ce qui aboutit à une dépendance rigide à la mise en page.
Notamment les notations fonctionnelles (d'origine mathématique) qui peuvent paraître moins évidentes au départ, permettent facilement et de façon succincte et cohérente d'utiliser des notions complexes (comme la récursivité).
Je me demande comment Python se comporte dans de telles situations.
Et je suppose que pour une longue suite linéaire d'instructions on doit aller à la ligne à chaque fois, ce qui nuit à une vue d'ensemble rapide.

Quand à l'opérateur conditionnel ternaire, on n'est pas obligé de l'utiliser mais il présente l'avantage d'une grand compacité et on peut l'inclure n'importe où en tant que fonction.
A ce propos :

J'avoue que moi qui fais du PHP et n'ai jamais touché au Python, je trouve ça limpide, surtout pour l'opérateur ternaire que je trouve particulièrement immonde dans les autres langages.

De quoi parles-tu ? Cette syntaxe provient du langage C. Dans quel langage cet opérateur est-il "immonde" ?

Par ailleurs le rapport avec la comparaison Minitel/Internet n'est pas sérieux. Le Minitel était certes pionnier mais demandait un matériel spécialisé et possédait évidemment des possibilités beaucoup plus limitées qu'Internet. Ici c'est un peu l'inverse : certains langages demandent sans doute un apprentissage plus long au départ mais facilitent ensuite l'inventivité et la réalisation de programmes complexes.
Il est vrai que pour n'importe quel langage, le succès appelle le succès indépendamment de ses qualités syntaxiques. La disponibilité de nombreuses bibliothèques, l'interopérabilité et un apprentissage précoce en facilitent l'usage. Mais une syntaxe trop primaire garde quand même des inconvénients.

[Sodium]

De quoi parles-tu ? Cette syntaxe provient du langage C. Dans quel langage cet opérateur est-il "immonde" ?

Je disais que la syntaxe =?: était immonde quel que soit le langage, que ce soit en PHP, C, JavaScript ou autre. Pour moi un code doit être aussi proche du langage naturel que possible.

[dad3zero]

Je reconnais que sur les exemples simples que tu donnes la syntaxe de Python paraît plus agréable car proche du langage naturel (enfin surtout pour les anglo-saxons). […]
Mais Python n'est pas le seul langage qui utilise des mots clés comme in ou is sous if.

Certes, mais dans le cas de Python, c'est une intention dès la conception. C'est un des points présentés par Van Rossum lors de l'initiative Computer Programming for Everybody en 1999 : que le code soit aussi lisible que du texte en anglais (et il faudra s'y faire que l'anglais est la langue de l'informatique).

Le problème est que sous prétexte de simplification on supprime des délimiteurs, ce qui aboutit à une dépendance rigide à la mise en page.

Pour Van Rossum, le choix de l'indentation n'est pas motivé par la simplification (ce n'est pas le cas) mais par l'esthétisme et la lisibilité. La mise en page n'est pas plus rigide mais structurée. Toutes les règles de la PEP8 ont pour objectif d'améliorer la relecture du code et donc sa maintenance et son évolutivité.

Je me demande comment Python se comporte dans de telles situations.
Et je suppose que pour une longue suite linéaire d'instructions on doit aller à la ligne à chaque fois, ce qui nuit à une vue d'ensemble rapide.

Python est aussi un langage fonctionnel, donc je ne vois pas trop le problème. Attention par contre à ne pas confondre "une instruction par ligne" et "l'instruction doit tenir sur une ligne". Le contenu d'une ligne peut en prendre plusieurs. Chose intéressante, l'alignement est aussi cadré par la PEP8…

Quand à l'opérateur conditionnel ternaire, on n'est pas obligé de l'utiliser mais il présente l'avantage d'une grand compacité et on peut l'inclure n'importe où en tant que fonction.

On va quand même rappeler que dans un langage comme Java, l'usage de l'opérateur ternaire ( ? : ) est considéré une mauvaise pratique sous le prétexte qu'il est peu lisible. Ce qui est mis en avant par jedema, c'est la syntaxe qui rend l'opérateur ternaire Python plus agréable à utiliser. Et au fait, là aussi, l'intérêt de l'opérateur ternaire ne devrait pas être la compacité mais la compréhension de l'intention. Un opérateur ternaire informe immédiatement que nous obtiendrons une valeur puis que cette valeur sera fournie de manière conditionnelle. Sans opérateur ternaire, le code nous informe d'abord qu'il va faire quelque chose en fonction d'une condition. En gros, il faut lire toute la structure pour comprendre qu'on extraie une valeur. Je chipotte peut-être juste sur le terme, mais "compact" et "lisible" ne sont pas la même chose.

certains langages demandent sans doute un apprentissage plus long au départ mais facilitent ensuite l'inventivité et la réalisation de programmes complexes.
Il est vrai que pour n'importe quel langage, le succès appelle le succès indépendamment de ses qualités syntaxiques. La disponibilité de nombreuses bibliothèques, l'interopérabilité et un apprentissage précoce en facilitent l'usage. Mais une syntaxe trop primaire garde quand même des inconvénients.

Personnellement, c'est ce que j'apprécie avec Python : c'est un langage qui permet de faire les choses simples simplement et les choses complexes tout aussi simplement.

[MiaowZedong]

Je n'aime pas trop le Python, car ma préférence va à la programmation fonctionelle, avec une syntaxe plus mathématique que celle du Python (ah, le Haskell). Cela dit, le Python a un cahier des charges précis (pour un langage généraliste) et y répond assez bien. Et si l'importance de l'indentation est une particularité, elle n'est pas si étrange quand tu considère que souvent on se repère avec les indentations plutot que les parenthèses/crochets dans les langages old school (comme le LISP, on ne compte pas le nombre de parenthèses...).

[dad3zero]

Je n'aime pas trop le Python, car ma préférence va à la programmation fonctionelle

Et vu que Python est un langage fonctionnel, j'ai du mal à comprendre l'argumentaire…

[Christian_B]

A ce titre, VBA pour excel est une sombre bouse. Pourtant, eu égard à son âge, il est très puissant, et j'ai vu des trucs en béton fait avec [...]

Certes Visual Basic peut être qualifié de "puissant" comme beaucoup de langages généralistes.
Et Excel fournit une interface graphique toute faite si on n'est pas trop regardant sur la présentation. Son emploi va de soi si on veut manipuler des tableaux Excel. J'ai aussi eu l'occasion de l'utiliser (il y a longtemps) quoique sans conviction.

Mais VBA est une usine à gaz avec une syntaxe hétéroclite et lourde.
Un bout de système à objets par ci, une syntaxe partiellement inspirée des anciens Basic par là, des fonctions Excel avec des syntaxes et des limitations peu cohérentes, et bien d'autres possibilités directement incluses plutôt que traitées par des bibliothèques. Y compris le réputé dangereux (et défunt j'espère) ASP.

Et il est étroitement lié à l'environnement Windows.
Heureusement qu'il y a une aide abondante (enfin pas pour tout). Mais curieusement divisée en deux systèmes indépendants selon qu'il s'agit d'objets ou non.

[MiaowZedong]

Et vu que Python est un langage fonctionnel, j'ai du mal à comprendre l'argumentaire…

Mais oui bien sûr. Python est un langage multi-paradigmes qui veut pouvoir faire du fonctionnel, mais il n'offre pas le même support et la même optimisation qu'un vrai langage fonctionnel come Haskell (). Il y a de grandes différences.

[Christian_B]

Et vu que Python est un langage fonctionnel, j'ai du mal à comprendre l'argumentaire…

Dans quel sens Python est-il fonctionnel ?
Le terme recouvre au moins deux sens :

- une syntaxe fonctionnelle, avec en général des paramètres entre parenthèses et donc des inclusions (ou imbrications) possibles représentant une composition de fonctions. De ce point de vue la syntaxe de Python (comme celle du langage C d'ailleurs) est clairement impérative et séquentielle à la base.

- dans le cas des vrais langages fonctionnels, une garantie (en principe) que l'environnement d'exécution d'une fonction n'est pas manipulable et donc qu'une fonction donne toujours le même résultat pour les mêmes entrées, ce qui facilite le débogage. Avec sans doute des limitations en contrepartie (faute d'expérience de ces langages je ne suis pas sûr). Est-ce le cas de Python ?

Par ailleurs un langage impératif peut avoir des capacités étendues de manipulation de fonctions (comme le langage C). Veux-tu dire que c'est le cas de Python ?

[Pyramidev]

Et je suppose que pour une longue suite linéaire d'instructions on doit aller à la ligne à chaque fois, ce qui nuit à une vue d'ensemble rapide.

Le code suivant n'a pas un style conseillé, mais est valide en Python :

Code Python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
print('Saisie : ', end=''); inputStr = input()
if   inputStr == '7':  print("C'est le nombre de jours de la semaine.")
elif inputStr == '12': print("C'est le nombre de mois dans l'année.")
else:                  print('Je ne sais que dire.')

Et vu que Python est un langage fonctionnel, j'ai du mal à comprendre l'argumentaire…

Ouh là, non. Si un jour tu as le temps d'apprendre le Haskell, tu verras que c'est trèèès différent du Python.
La vraie programmation fonctionnelle ne se limite pas aux fonctions d'ordre supérieur et aux fermetures. Il y a aussi un fort accent mis sur la pureté des fonctions et l'immuabilité.

[Christian_B]

Une idée me vient.
Ne pourrait-on pas concevoir un langage source utilisant les mêmes instructions que Python, ajoutant ce qu'il faudrait pour le rendre indépendant de la mise en page et traductible automatiquement en Python ? Donc 100% compatible avec le compilateur.
J'ai l'impression (mais je peux me tromper) que syntaxiquement il y aurait peu à faire. Quelques ";" et mots clés de fin en plus.
Mais je ne me sens pas de le faire (sauf nécessité peu probable) ce qui suppose de bien connaître Python (paradoxal pour moi qui ne l'aime pas) et faire des traducteurs dans les deux sens

[Pyramidev]

Une idée me vient.
Ne pourrait-on pas concevoir un langage source utilisant les mêmes instructions que Python, ajoutant ce qu'il faudrait pour le rendre indépendant de la mise en page et traductible automatiquement en Python ? Donc 100% compatible avec le compilateur.

Tout ça juste pour avoir une syntaxe qui se rapproche davantage du langage C ?
Je suis régulièrement surpris que tant de développeurs soient à ce point focalisés sur ce genre de détail. C'est dommage car, en dehors des langages dérivés du C, certains sont très enrichissants (par exemple Haskell et les dialectes du Lisp).

J'ai l'impression (mais je peux me tromper) que syntaxiquement il y aurait peu à faire. Quelques ";" et mots clés de fin en plus.

On peut déjà ajouter des ";" à la fin des instructions, même si c'est inutile quand il n'y a pas une autre instruction sur la même ligne.
Le code suivant est valide en Python :

Code Python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
a = 1
b = 2;
c = 3; d = 4
print(a); print(b); print(c); print(d);

Concernant les accolades, actuellement, elles sont utilisées pour délimiter les ensembles et les dictionnaires :

Code Python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
mySet = {1, 2, 3, 4}
myDict = {2: 'deux', 3: 'trois', 5: 'cinq'}
for key in sorted(mySet):
	if key in myDict:
		print(myDict[key])

Je n'ai pas analysé quelles seraient les conséquences pour le parseur si les accolades servaient aussi à délimiter des blocs dans des structures de contrôle.
Si ça intéresse quelqu'un, voici la page qui spécifie la grammaire du Python 3 : Full Grammar specification.

[Christian_B]

Tout ça juste pour avoir une syntaxe qui se rapproche davantage du langage C ?
Je suis régulièrement surpris que tant de développeurs soient à ce point focalisés sur ce genre de détail. C'est dommage car, en dehors des langages dérivés du C, certains sont très enrichissants (par exemple Haskell et les dialectes du Lisp).

Je ne pensais pas forcément à des accolades (dont je n'ai pas parlé), encore que ce soient des délimiteurs de blocs utilisés par beaucoup de langages. D'ailleurs, je suis familier de la syntaxe Lisp (trop éloignée de celle de Python pour qu'on songe ici à s'en inspirer).
Mais pour moi n'importe quel moyen simple d'éviter de considérer les retours de ligne, tabulations ou blancs multiples comme éléments syntaxiquement distincts du séparateur de base (le blanc) ferait l'affaire.

Pour les instructions composites je pense que les mots clés de fin sont plus explicites car plus spécifiques que les parenthèses, par exemple endif ou fi après if, ou wend après while. Ils aident à se repérer et à détecter et mieux situer certaines erreurs comme l'effacement accidentel d'un caractère séparateur.

Quand au conflit avec les tableaux, on peut modifier simplement leur syntaxe de bien des manières s'il y a conflit puisque je ne songe pas à un sur-ensemble de la syntaxe de Python mais seulement à une syntaxe proche.

Je ne connaissais Haskell que de réputation, je m'aperçois qu'il semble dépendre des indentations et des lignes vides . Décidément cette mode est envahissante. Mais j'ai l'impression que c'est facultatif, car je vois qu'on peut écrire :

Code Haskell :

Sélectionner tout - Visualiser dans une fenêtre à part

doubleSmallNumber' x = (if x > 100 then x else x*2) + 1

Ce style d'inclusion est exclu en Python je suppose.

[Pyramidev]

Je ne connaissais Haskell que de réputation, je m'aperçois qu'il semble dépendre des indentations et des lignes vides . Décidément cette mode est envahissante.

En Haskell, la manière normale d'écrire du code est effectivement de s'appuyer sur l'indentation. Mais, à la place, on peut aussi s'appuyer sur les point-virgules et les accolades. Par exemple, voici trois manières équivalentes de définir la fonction liftM2 de la bibliothèque standard :

Code Haskell :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
liftM2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r
liftM2 f m1 m2 = do
    x1 <- m1
    x2 <- m2
    return (f x1 x2)

Code Haskell :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
liftM2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r
liftM2 f m1 m2 = do {
    x1 <- m1;
    x2 <- m2;
    return (f x1 x2)
}

Code Haskell :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
liftM2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r
liftM2 f m1 m2 = do { x1 <- m1; x2 <- m2; return (f x1 x2) }

La dernière version est un copié-collé du code source de GHC. Visiblement, les auteurs aiment bien utiliser les accolades pour tout faire tenir sur une seule ligne. Par contre, quand le code est sur plusieurs lignes, ils se basent sur l'indentation.

Mais j'ai l'impression que c'est facultatif, car je vois qu'on peut écrire :

Code Haskell :

Sélectionner tout - Visualiser dans une fenêtre à part

doubleSmallNumber' x = (if x > 100 then x else x*2) + 1

Ce style d'inclusion est exclu en Python je suppose.

En Python, le code équivalent serait :

Code Python :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
def doubleSmallNumber(x):
	return (x if x > 100 else x*2) + 1

Ou alors, si on veut vraiment le faire tenir sur une ligne :

Code Python :

Sélectionner tout - Visualiser dans une fenêtre à part

def doubleSmallNumber(x): return (x if x > 100 else x*2) + 1

Code Python :

Sélectionner tout - Visualiser dans une fenêtre à part

doubleSmallNumber = lambda x: (x if x > 100 else x*2) + 1

[Christian_B]

Merci Pyramidev,
Pour Haskell, je suis tout à fait rassuré.
Je présume que si on code dans le style de ton exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
liftM2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r
liftM2 f m1 m2 = do {
    x1 <- m1;
    x2 <- m2;
    return (f x1 x2)
}

on est pratiquement affranchi syntaxiquement des contraintes de mise en page (ce qui n'empêche pas d'adopter une présentation cohérente), sauf peut-être pour le passage de la 1ère à la 2e ligne et sans doute on peut aussi modifier ce point.
Et en somme, pour un langage qui peut être utilisé interactivement (comme un shell) il est compréhensible que le retour à la ligne joue un rôle.

Tout ce qui manque (de mon point de vue) pour garantir une bonne structuration à des "vrais programmes" destinés à être compilés serait un environnement d'édition qui réduise ou élimine la dépendance à la mise en forme en considérant l'absence de délimiteurs comme erronée.
Cela éviterait un mélange des styles confus et dangereux.
D'ailleurs, j'ai l'impression au vu de ton exemple que les rédacteurs du code source de GHC sont de cet avis.

En somme Haskell cache son jeu. La syntaxe par indentation est là pour rassurer ceux qui ne sont pas à l'aise avec les notations fonctionnelles (ce qui est assez paradoxal pour un langage fonctionnel ).

Pour Python c'est moins clair. La notation "(x if x > 100 else x*2)" m'apparaît très illogique avec une valeur au début et une à la fin. Et pas même proche d'une tournure du langage naturel.
Mais elle me suggère une question. Est-ce que les parenthèses utilisées comme délimiteurs d'expressions sont propres à if, ou est-ce que toutes les instructions (ou la plupart) peuvent être considérées comme des fonctions et imbriquées de cette façon ?
Cela changerait beaucoup mon point de vue sur Python ...
D'autant plus que la présence de "lambda" dans ton dernier exemple suggère que Python serait moins éloigné de langages comme Lisp qu'il n'y paraît.