Le dim. 26 mars 2023 à 21:16, Yves Martin <ymartin59@???> a écrit :
>
> On Sat, 2023-02-18 at 10:14 +0000, Yth wrote:
> > Le 18 février 2023 09:23:36 UTC, Patrice Karatchentzeff
> > <patrice.karatchentzeff@???> a écrit :
> > > Le sam. 18 févr. 2023 à 09:30, Yth <yth@???> a écrit :
> > >
> > > En fait, j'ai oublié de dire que python geulait sur la syntaxe
> > > quand
> > > j'ajoutais un \ (avec match ou find) :
> > >
> > > textframe = re.find("Text\d+", obj)
> > > ^^^^^^^^^
> > > SyntaxError: invalid escape sequence '\d'
> >
> > Mais là il fait mettre le r pour ne pas interpréter les caractères
> > spéciaux :
> > r"Text\d+"
>
> Je rebondis sur le sujet en proposant à Patrice de vérifier un hexdump
> du source pour s'assurer que le fichier Python ne commence pas avec le
> BOM UTF-8, ou contiendrait un caractère UTF-8 pour la double-quote ou
> le backslash au lieu de l'ascii correspondant.
Non, rien de tout cela.
> Le nombre de fois où un copier-coller de ligne de commande ou de code
> depuis un document "office" m'a fait perdre du temps, notamment ephen
> au lieu du tiret, O au lieu de 0, quand le rendu visuel est (quasi)
> identique m'a amené à contrôler directement le contenu texte... en mode
> "binaire" ! (ou avec une fonte "terminale")
>
> Idéalement, il faudrait un mode visuel dans les IDE pour "marquer au
> fer rouge" les caractères non ascii dans les sources.
C'est peu ou prou ce que je fais avec Emacs, uniquement pour Python,
notamment pour détecter « visuellement » les espaces.
Mais c'est ce que j'ai dit un peu plus haut : Python a supprimé les
délimiteurs de fonction pour faciliter la tâche des débutants, afin
d'alléger le code. Ils n'ont en réalité rien supprimé : Ils ont juste
déplacé le problème dans la structure du code. Or cette structure est
fragile, car en partie invisible, ce qui fait que les codeurs
débutants peuvent singulièrement être perdus. Coder du python sans un
bon éditeur est tout simplement presque impossible.
Qu'est-ce qu'il vaut mieux ? Un apprentissage pas à pas de la logique
de la programmation de haut-niveau avec des repères bornés ET visibles
({} ou begin/end) ou bien cacher la difficulté ? Je ne crois pas au
miracle de la connaissance qui descend tout seul par miracle chez le
gars qui apprend... même suppléer par un IDE. Soit on a un générateur
de code via un truc qui code à sa place, soit on code à la main, mais
dans ce cas, il faut de la connaissance ET de la maîtrise.
Le problème de python est qu'il est né d'un rapport malsain qu'avaient
certains codeurs avec Perl. Perl était (et dans beaucoup de cas est
toujours) la Rolls des langages web des années 90. Son auteur, Larry
Wall, était davantage un linguiste qu'un vrai informaticien. Il était
fasciné par l'aspect malléable d'un langage informatique, au point
qu'il en a fait une méthodologie, une doctrine, dans Perl, ce qui se
traduit par « il y a plus d'une manière de faire ». Coupler cette
liberté avec des gens qui codent n'importe comment n'importe quoi rend
problématique la relecture du code, et encore pire son entretien.
De plus, avoir plusieurs méthodes est la porte ouverte à la difficulté
d'apprentissage : si j'ai plusieurs choix, lequel prendre ? Il y a en
sûrement un de plus pertinent pour mon problème (et de fait, dans la
majorité des cas, c'est vrai). Il faut donc se poser des questions
avant de coder. Et là, patatra... L'explosion du web dans les années
90 a amené sur le marché des gens qui ne se posent pas ces questions,
mais qui se plaignent beaucoup : « Perl, c'est trop dur » (et en plus,
elle est trop molle... comprenne qui pourra :) ). Bref, perl est un
langage pour les véritables, comme on disait à l'époque.
Et c'est là que Python est né, sur ce paradigme (juré : c'était le
leitmotive de l'époque). Si Perl est trop « dur » pour vous, alors
venez chez nous, ce que j'ai toujours traduit par « si vous êtes trop
mauvais, codez en python ». La masse des incapables est donc passé à
Python.
Alors, oui, c'est vrai. Python est (un peu) plus simple. Surtout un
peu plus simple à relire. Mais bon, cela n'enlève en rien les
paradigmes de base de la programmation. Relire du mauvais code python
(et c'est la majorité des codes) est tout aussi pénible que du mauvais
perl, sans doute même encore plus. Je me suis mis à coder en python
car j'ai voulu améliorer un script de scribus. C'était un enfer.
J'avais l'impression de lire un truc écrit par un gars qui avait
abouté une série de trucs trouvés sur Internet. La dernière fois que
j'avais vu cela, c'était en PHP (qui a un peu le même syndrome que
Python, en moins pire).
Bref, tout reprendre de zéro, apprendre python et généraliser le
script pour répondre à tous les problèmes, m'a pris une semaine (avec
un coup de main ici, merci !). Mon script est propre, bien codé (même
si pas codé en objet, spéciale dédicace pour Fred :) ) : il est
reprenable par n'importe qui et extensible à souhait facilement. Le
problème n'est donc pas vraiment le langage, mais les codeurs. Python
a été inventé pour suppléer les mauvais codeurs. C'est juste
impossible.
Le seul intérêt que je vois avec Python, c'est que je méfie d'entrée
des codes python, car statiquement, il y a beaucoup plus de chance
qu'ils soient mal codés :)
Ça n'enlève rien à la qualité des super projets codés en Python, juste
que ce sont des bons codeurs à la base, et qu'ils auraient pu même
codé en assembleur si cela les avaient amusés :)
> <pub>
> Du coup, je vois maintenant l'autre discussion qui débattait IDE, et
> oui Emacs est très bien, et même si Patrice se plaint des propositions
> "commerciales" que j'utilise (mon employeur se fournit chez JetBrains),
> je recommande chaudement PyCharm en version communautaire qui fournit
> un grand nombre de supports très pratiques:
C'est un peu le problème des environnements modernes. Je me suis mis à
JavaScript (bon, comme moderne, on repassera, mais le JavaScript
moderne n'a plus grand-chose à voir avec ce que j'ai connu il y a une
vingtaine d'années, à ses débuts). Il faut une usine à gaz pour les
faire fonctionner. Il y a eu Eclipse, puis toute une série d'outils
plus imbitables les uns les autres. Je viens d'ouvrir celui
d'Android... Faut juste trois mois de boulot pour seulement
apprivoiser l'interface.
J'ai mis des années à apprendre à me servir d'Emacs (vi...) pour être
efficace. Je ne veux pas changer d'éditeur pour un script pondu tous
les 2 ans.
Cela dit, j'ai trouvé comment rendre Emacs à la mode IDE moderne avec
le mode lsp, couplé avec le mode du langage qui va bien (rjsx-mode
pour React par exemple). C'est sans doute moins performant qu'un gros
bouzin qui fait tout le café, mais pour coder, ça couvre 99% des
besoins.
Ce qui me fait marrer aujourd'hui, c'est qu'Emacs avait une réputation
de lourdeur dans les années 90. Il s'ouvre aujourd'hui instantanément
et consomme que dalle en mémoire, en comparaison des outils modernes,
qui après quelques heures, peuvent mettre à genoux une machine de
compétition moderne... pour coder un bête langage informatique !
PK
--
|\ _,,,---,,_ Patrice KARATCHENTZEFF
ZZZzz /,`.-'`' -. ;-;;,_ mailto:patrice.karatchentzeff@gmail.com
|,4- ) )-,_. ,\ ( `'-'
'---''(_/--' `-'\_)
