Re: [SSFR] quel langage ?

[ Thread Index | Date Index | More debianworld.org/shellscript-fr Archives ]


j'ai depuis quelques temps perdu l'habitude d'intervenir dans ce
genre de discussions lorsque quasi aucun des arguments exposés n'est
technique; Mais sugerer une ou deux pistes de reflexion ne peu nuire
a personne...

On Tue, Nov 29, 2005 at 10:20:11PM +0000, Sébastien Aperghis-Tramoni wrote:
> > L'indentation, on aime ou on aime pas, mais elle est significative en
> > python. Attention aux editeurs de textes mal configurés..
> 
> Probablement la pire "fonctionnalité" de Python : les longs blocs
> composants les boucles et fonctions, perdant leurs frontières deviennent
> difficiles à distinguer. Rien pour faciliter la tâche du mainteneur.

On peut noter en passant que quelque soit le langage, lorsque la
delimitation de "blocs" trop longs n'est plus visible, et ce quelqu'en
soit la forme, le resultat est le meme. Ta critique va de ce point de
vue bien au dela de python et s'applique tout aussi bien a perl que
beaucoup d'autres.

> > Support des fonctions lambda, équivalent des fonctions anonymes de perl.
> 
> Dommage, les fonctions map(), filter() et reduce() ont été jugées trop
> lispiennes par Guido qui va les supprimer de Python 3000

Quoi que l'on pense de Python et de la proposition en question il est
ici important de savoir ce qu'est python 3000, en particulier que ce
n'est _pas_ malgré comme a cause du bon vieux PEP a son origine une
version a venir du langage que nous nommons ici Python (vaporware
qd tu nous tiens :).

> typique du n'importe quoi de Python : le mot-clé pour déclarer la
> gestion d'une exception est "except". Résultat, en anglais
>   "try: execute something / except: Exception"
> se lit
>   "essaye d'exécuter tel code / [gérer] sauf telle exception"

es tu sur que cela se lit ainsi ou est ce par ce que tu aurais
la mauvaise habitude de vouloir traduire en un langage naturel
une construction syntaxique d'un langage artificiel...

(avec unlambda ca doit pas etre facile %-)

> Pourquoi ne pas avoir utilisé "exception" comme mot-clé ? Ou "error"

Peut etre par ce que si nous le remplacons par un de ceux-ci
dans ton exemple en y appliquant la methode que tu proposes pour
en determiner la "lisibilité" (concept quelque peu subjectif s'il
en est) le resultat sera au mieux identique, au pire un non sens.
On peut alors se demander on se trouve le "n'importe quoi".

> si économiser la frappe de 3 caractères était si important ?

Sans ce limiter a cet unique mot clef, et plus precisement en
elargissant ta remarque a divers identificateurs (au sens large)
des langages concernés. Que faut'il penser des "traductions" qui
pourraient etres faites d'autres expressions/statements dans un
langage naturel ou, plus specifiquement pour perl, des choix de
"nommages" faits pour nombre de ses "identificateurs"...
j'ai d'avance froid dans le dos a l'idée des adjectifs que tu
pourrais alors etre ammené a utiliser concernant ces deux langages :-)

Plus globalement concernant les syntaxes des langages informatique
pour ceux qui les utilises; Il est interessant de constater que
l'importance de celles-ci en termes de lisibilité ou de facilités
d'ecriture pour les humains se trouve doucement mais surement (enfin)
deplacée vers les IDE et autres editeurs plus ou moins specialisés.

Se pose alors la question, vers quoi devraient elles (les syntaxes)
s'orienter pour encore apporter quelque chose a l'utilisateur; Fouiner
dans les langages naturels dans un monde ou l'ambiguité n'est pas de
 mise, certainement pas. Une structure simple, un parsing trivial
(ce qui n'est pas le cas de python loins de là, meme s'il est
_relativement_ simple), permettant des transformations aisées,
facilitant l'implementation des dits IDE/editeurs ainsi que bien
d'autres traitements en tout genre me semble une approche plus
raisonnable de cette question (toutes ressemblances avec des
propriétés de langages existant serait purement fortuite tout ca... :)

Apres tout remplacer "except" par "suce les $fesses d3 \ma 'grand' @mere^3"
dans un langage quelconque sous un IDE adapté a celui-ci, a l'affichage
comme a l'ecriture, le code generé etant indifferent puisque ma grand
mere preferera parler des fesses de mon grand pere, reste encore le
meilleur moyen de faire de toi un programmeur heureux %)

KAMOULOX \o/ !

Mais de ce point de vue python n'est malheureusement qu'un peu moins
catastrophique que perl, et je suis presque sur qu'il peut ponctuellement
faire pire en cherchant un peu. Mais il est pour moi l'heure de faire
dodo, la fatigue m'ayant ammené a pondre ces quelques lignes alors que
je sais que cai mal(tm) :-)

                                             xavier.




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/