import

Si un module est codé en Python, il n'est pas besoin d'être
spécialement talentueux pour vérifier s'il emploie exec ou non, tu
sais - une simple recherche dans le texte suffit !-)

C'est vrai, tu entends par là que je suis flemmard :) ?

Pas nécessairement - accessoirement, en ce qui me concerne, j'aurais
tendance à considérer la paresse comme une qualité !-)

Par contre, il m'a fallu quelques temps avant de prendre l'habitude
d'aller mettre le nez dans les sources des logiciels que j'utilise, et
j'ai remarqué que beaucoup de développeurs hésitent à le faire, alors
que c'est très instructif.

Justement non : on ne trouve pas une solution au problème, on le
déplace, voire pire : on le cache sous le module imp.

Ah bon ? C'est très particulier, comme approche, là. Je veux dire,
il y a dans les builtins tout le nécessaire pour gérer très
exactement ce genre de problème, mais ce n'est pas une solution ???
J'avoue ne pas suivre ton raisonnement...

Le raisonnement n'est tout du tout en cause ici, c'est mon hypothèse
qui était vérollée : pourquoi ne pas avoir dit de suite qu'il était
écrit en C.

Parce que j'ai vérifié après, tout simplement.

Prendre les gens de haut en se contentant de "c'est facile à
vérifier..." n'apporte pas grand chose à l'édifice.

Désolé si ma formulation t'a vexé, ce n'était pas mon intention. Ce
que je voulais dire en l'occurrence est qu'il est facile de savoir si
un module est implémenté en C ou en Python, et dans le second cas
d'aller consulter le code - ce qui constitue souvent une expérience
intéressante d'ailleurs (dans un sens ou dans un autre pour ce que ça
vaut : dès fois, ça décomplexifie très nettement !)).

Ne t'inquiète pas, je ne l'ai pas mal pris. On a le droit de discuter
quand même. Je retiens néanmoins ton conseil.

Cetes, ça reste pour moi toujours aussi flou...quels sont ces types
de problèmes justement ?

Pour le moment, les seuls cas que j'ai vu (où l'usage de exec était
justifié) concernait l'utilisation de Python comme langage de
scripting d'une autre application (codée en Python et/ou en C ou C++).

C'est plus clair, merci.

Notes qu'il y a certainement d'autres cas d'utilisation - je cite juste
ceux que j'ai observé.

D'autres sont même complètement obsolètes sur la version utilisée,
mais toujours utiles au sens du contenu qu'ils apportent, je pense
par exemple à "Text Procressing In Python".

Certes. Je ne dis pas que *tous* les bouquins d'informatique sont
mauvais ou inutiles, juste que même envers les meilleurs, il faut
savoir user de sens critique.

Oui, mais ce n'est jamais facile d'être critique lorsque l'on débute un
language. Pour critiquer il faut toujours connaître un peu, et on entre
ainsi dans spirale infernale (un "while True" quoi :)).

D'où l'utilité des newsgroups - du moins de ceux qui "fonctionnent
bien", dans le sens où il y a suffisament de contributeurs un peu
expérimentés prenant le temps de se corriger les uns les autres. C'est
un peu comme une revue de code gratuite, si tu veux :-)

Quand j'apprenais le C, essayer de répondre aux questions d'autres
débutants, et le cas échéant voir ma solution "corrigée" par des
développeurs C expérimentés m'a énormément aidé.

(snip)

Dans la plupart de celles où je suis passé, la notion même de "bonne
pratique" était lettre morte. Dans celles où je suis resté (!-), c'est
qu'au moins une autre personne partageais mes convictions à ce propos.

Ca fait peur...c'est vérolé à ce point ?

Le niveau moyen est assez catastrophique, oui - en tous cas en
informatique de gestion et dans le web, ce qui représente quand même une
grande part de l'activité. Quand tu vois un "chef de projet", lui-même
développeur "expérimenté", qui ne sait pas ce qu'est une machine à état
ni une fonction de rappel et qui n'est même pas capable de comprendre
une fonction récursive, tu te dis que c'est pas gagné...

(snip - je regarderai l'astuce firefox plus tard)

Dans la plupart de celles où je suis passé, la notion même de "bonne
pratique" était lettre morte. Dans celles où je suis resté (!-), c'est
qu'au moins une autre personne partageais mes convictions à ce propos.

Ca fait peur...c'est vérolé à ce point ?

Le niveau moyen est assez catastrophique, oui - en tous cas en
informatique de gestion et dans le web, ce qui représente quand même une
grande part de l'activité. Quand tu vois un "chef de projet", lui-même
développeur "expérimenté", qui ne sait pas ce qu'est une machine à état ni
une fonction de rappel et qui n'est même pas capable de comprendre une
fonction récursive, tu te dis que c'est pas gagné...

Si, comme vous dites, le niveau moyen est assez catastrophique, alors un
développeur "moyen" ne produira le plus souvent qu'un code "lourd" qui
"marchouille"... Quelle difficulté alors pour relire et faire évoluer le
code des mois ou années plus tard ? En particulier si la "reprise" du code
et réalisée par une autre personne ?

Bref, en pareille situation, un langage à typage dynamique (comme Python,
Ruby, PHP, Javascript, etc...) ne complique-t-il pas encore la maintenance
du code ? Un langage à typage statique (C#, Java, Delphi/Pascal, Visual
Basic.Net, etc...) n'est-il-pas plus "rassurant" car explicite et
"encadrant" quelque peu les choses ?

C#, Java, ou Delphi sont largement utilisés dans le milieu "pro"...
Ces langages sont populaires et "soutenus" par de (très) grandes
entreprises...

Comparitivement, Python ou Ruby (et peut-être même PHP) semblent [assez]
[nettement] moins utilisés...

Le passé est aux langages à typage statique, incontestablement. L'avenir
aussi ?

D'ailleurs, si "explicit is better than implicit", alors autant le dire
clairement lorsqu'un bout de code est prévu pour fonctionner avec un objet
"canard", ou au moins un objet qui implémente l'interface ICoinCoin ? Non ?

Au final, pourquoi pas un Python 3 avec, quelque part la possibilité d'un
"Option Explicit" ? Bref, la possibilité d'un typage statique ?

Bonsoir !

Un langage à typage statique n'est-il-pas plus "rassurant"

Perso, je crois que cette

"encadrant" quelque peu les choses ?

En fait, l'encadrement se résume souvent à des limitations.

C#, Java, ou Delphi sont largement utilisés dans le milieu "pro"...
Ces langages sont populaires et "soutenus" par de (très) grandes
entreprises...

D'abord, il y a C (et sa dérivation C++). Historiquement, C a acquit une
quasi hégémonie, pour deux raisons (selon moi) :
- le langage avait des possibilités supérieures aux autres langages
de l'époque (milieu des 70) ;
- les compilateurs étant assez faciles à produire, il y a eu
quantité d'implémentation du langage (donc une offre pléthorique).

Ensuite, ça a été l'effet boule de neige. Comme il était répandu, on a
formé des gens dessus, ce qui a augmenté son audience.

De fait, actuellement, C est encore le langage le plus répandu et le
plus utilisé. Il faut se rappeler qu'il a été utilisé pour développer
linux, windows, Ruby, Python, etc.

Java et C# ne sont, finalement, que des dérivés de C/C++ ; malgré
quelques extensions, ils ont hérité de beaucoup de vision du début des
années 80.

Delphi est un épiphénomène. C'est un langage très pauvre, mais qui
bénéficie de librairies importantes. Son succès a été plus commercial
que technique. Du coup, il est quand même en perte de vitesse.

Python ou Ruby (et peut-être même PHP)

On peut comparer Python et Ruby. Mais, AMHA, PHP est quand même
nettement en dessous (conceptuellement parlant).

Le passé est aux langages à typage statique, incontestablement.
L'avenir aussi ?

Rien n'est moins sûr.

D'ailleurs, si "explicit is better than implicit", alors autant le
dire clairement lorsqu'un bout de code est prévu pour fonctionner avec
un objet
"canard", ou au moins un objet qui implémente l'interface ICoinCoin ?

Non ?

Bertrand Russel dirait que tu utilises me laxisme sémantique des
définitions du langage usuel pour développer des paradoxes sorites, qui
ne correspondent pas à la réalité des notions formelles.

Au final, pourquoi pas un Python 3 avec, quelque part la possibilité
d'un "Option Explicit" ? Bref, la possibilité d'un typage statique ?

Mieux vaut un bon analyseur de code / syntaxe, que d'introduire un truc
limitatif, et qui n'apporterait que des ennuis.



@-salutations
--
Michel Claveau

Un langage à typage statique n'est-il-pas plus "rassurant"

Perso, je crois que cette

Il manque un morceau ;-)

"encadrant" quelque peu les choses ?

En fait, l'encadrement se résume souvent à des limitations.

Bien sûr, "encadrement" et "limitation", ça marche un peu ensemble !
La question est de savoir si c'est une Bonne Chose ?
Si vous voullez bien, replaçons ma phrase dans son contexte ?
C'est à dire en réaction à une remarque de Bruno D. : "Le niveau moyen est
assez catastrophique"
Dans ce contexte là, un langage à typage dynamique laisse d'avantage la
porte ouverte à du code "confus"
D'ailleurs, Python offre bien plus de souplesse que PHP, par exemple, et
donc au delà même du typage dynamique, toute cette souplesse dans les mains
du "programmeur-moyen-qui-doit-terminer-son-travail-pour-hier" peut
potentiellement accroitre le risque que soit produit un code confus, ou pire
!?

En pareille situation (banale?), vive les langages statiques ?

C#, Java, ou Delphi sont largement utilisés dans le milieu "pro"... Ces
langages sont populaires et "soutenus" par de (très) grandes
entreprises...

D'abord, il y a C (et sa dérivation C++). Historiquement, C a acquit une
quasi hégémonie, pour deux raisons (selon moi) :
- le langage avait des possibilités supérieures aux autres langages de
l'époque (milieu des 70) ;
- les compilateurs étant assez faciles à produire, il y a eu quantité
d'implémentation du langage (donc une offre pléthorique).

Ensuite, ça a été l'effet boule de neige. Comme il était répandu, on a
formé des gens dessus, ce qui a augmenté son audience.

Je ne me risque pas à expliquer le pourquoi du succès du "C/C++"

Toutefois, C++ me semble d'avantage qu'une "dérivation" du C...

Même si, "dérivation" peut sembler un mot bien choisi pour un langage
Orienté Objet, contrairement à son ancètre :-)

Le passé est aux langages à typage statique, incontestablement. L'avenir
aussi ?

Rien n'est moins sûr.

Je veux bien vos "sources" :-)
Pour le présent, pour quelqu'un cherchant du boulot, meilleurs sont ses
chances si son CV mentionne "C#-Java" que "Python-Ruby" !
Au moins en France.

D'ailleurs, si "explicit is better than implicit", alors autant le dire
clairement lorsqu'un bout de code est prévu pour fonctionner avec un
objet
"canard", ou au moins un objet qui implémente l'interface ICoinCoin ? Non

?

Bertrand Russel dirait que tu utilises me laxisme sémantique des
définitions du langage usuel pour développer des paradoxes sorites, qui ne
correspondent pas à la réalité des notions formelles.

C'est une façon de ne pas répondre ?

Pourtant, je suis 100% d'accord avec le "explicit is better than implicit"
Pourtant, ça ne colle pas du tout avec "typage dynamique" !

Mieux vaut un bon analyseur de code / syntaxe, que d'introduire un truc
limitatif, et qui n'apporterait que des ennuis.

analyseur de code / syntaxe ?
Dites m'en d'avantage, je passe peut-être à coté d'un truc ???

kib wrote:

<HS>
Oui, c'est un des problèmes avec les langages fonctionnels : la
communauté est souvent composée avant tout de "grosses têtes", et la
littérature associée s'en ressent. C'est dommage d'ailleurs parce
qu'il serait intéressant que ces langages se répandent davantage...
</HS>
Je ne peux qu'approuver.

Oui mais non. Quand les langages sont enseignés à la fac ou au lycée, on
trouve quand meme des ouvrages semi accessibles.
Prendre l'exemple OCaml: je trouve chez Eyrolles et Gibert Jeunes (les
librairies) suffisament de bouquins pour _découvrir_ le langage, ça
necessite encore un certain bagage mathématique que n'ont pas tous les
bacheliers.
Mais avec un Bac S (et ses variantes) ou ES on s'en sort tres bien.

Et je ne sais pas si c'est uniquement lié au fait que le langage en
question soit fonctionnel ou pas, mais effectivement entre le niveau
moyen général (et la qualité) des ouvrages sur PHP et ceux sur
Python/Ocaml, je sens une différence au moins dans le fond.

Attention! Suivi sur le groupe fr.comp.lang.general.

Dans la plupart de celles où je suis passé, la notion même de "bonne
pratique" était lettre morte. Dans celles où je suis resté (!-), c'est
qu'au moins une autre personne partageais mes convictions à ce propos.

Ca fait peur...c'est vérolé à ce point ?

Le niveau moyen est assez catastrophique, oui - en tous cas en

informatique de gestion et dans le web, ce qui représente quand même une
grande part de l'activité. Quand tu vois un "chef de projet", lui-même
développeur "expérimenté", qui ne sait pas ce qu'est une machine à état ni
une fonction de rappel et qui n'est même pas capable de comprendre une
fonction récursive, tu te dis que c'est pas gagné...

Si, comme vous dites, le niveau moyen est assez catastrophique, alors un
développeur "moyen" ne produira le plus souvent qu'un code "lourd" qui
"marchouille"... Quelle difficulté alors pour relire et faire évoluer le
code des mois ou années plus tard ? En particulier si la "reprise" du code
et réalisée par une autre personne ?

Bref, en pareille situation, un langage à typage dynamique (comme Python,
Ruby, PHP, Javascript, etc...) ne complique-t-il pas encore la maintenance
du code ? Un langage à typage statique (C#, Java, Delphi/Pascal, Visual
Basic.Net, etc...) n'est-il-pas plus "rassurant" car explicite et
"encadrant" quelque peu les choses ?

C#, Java, ou Delphi sont largement utilisés dans le milieu "pro"...
Ces langages sont populaires et "soutenus" par de (très) grandes
entreprises...

Comparitivement, Python ou Ruby (et peut-être même PHP) semblent [assez]
[nettement] moins utilisés...

Le passé est aux langages à typage statique, incontestablement. L'avenir
aussi ?

D'ailleurs, si "explicit is better than implicit", alors autant le dire
clairement lorsqu'un bout de code est prévu pour fonctionner avec un objet
"canard", ou au moins un objet qui implémente l'interface ICoinCoin ? Non ?

Au final, pourquoi pas un Python 3 avec, quelque part la possibilité d'un
"Option Explicit" ? Bref, la possibilité d'un typage statique ?

Mon cher anonyme,

Soit tu es très ignorant du sujet que tu abordes, soit tu es un vilain
troll poilu. Te laissant le bénéfice du doute pour cette fois, j'attire
ton attention sur quelques faits:

* Un mauvais programmeur écrit du mauvais code, quelque soit le langage.
Tous les langages visant à protéger le programmeur de sa stupidité ont
échoué. Point.

* Une grande part de la complexité des programmes écrits dans des
langages "rigides" comme Java provient précisément de cette rigidité
(une grande partie des design patterns n'a d'autre raison d'être que de
contourner cette rigidité)

* Cette complexification inutile a pour conséquence d'augmenter très
nettement le nombre de lignes de code nécessaire pour implémenter une
même fonctionnalité - et on sait que le ratio erreurs/lignes de code est
à peu près constant quelque soit le langage.

* la visibilité d'un langage (je ne pense pas que le terme 'popularité'
ait le moindre sens ici) est sans rapport avec son utilisation
effective. Par contre, un gros budget com peut aider à imposer un
langage quelque soient ses qualités effectives.

* Python est un composant indispensable de la plupart des distribs
linux, et un des langages les plus employés par Google (qui a d'ailleurs
embauché GvR et Alex Martelli). Youtube a été codé en Python. Ansi que
pas mal d'autre sites, connus ou non. De nombreux jeux videos très
populaires utilisent Python pour toute la logique. Les machines Dell
sous Windows sont livrées avec des applis Python nécessaires au bon
fonctionnement de l'ensemble. Je pourrais continuer longtemps, la
conclusion est la même: la visibilité d'un langage est sans grand
rapport avec sons utilisation effective.

* accessoirement, PHP est à ce jour le langage le plus utilisé pour les
applications web côté serveur.

* les langages à typages dynamiques existent depuis les débuts de
l'informatique (déjà entendu parler de Lisp ?) - et accessoirement, les
langages les plus 'bas niveau' sont souvent très faiblement typés (déjà
codé en C ?)

* la vocation première du typage statique n'est pas d'aider le
programmeur, c'est d'aider le compilateur (d'où l'utilisation de
langages à typage statique pour les couches basses d'un système)

* le typage statique n'implique en rien le typage déclaratif (cf les
systèmes d'inférence de type)

* en ce qui concerne Python, il est évident pour n'importe qui connait
le langage que même un système d'inférence de type est à la limite de
l'impossible - ou alors en transformant tellement le langage que ce ne
sera plus Python.

On 31 jan, 10:06, "Omme Nay" <ano.m...@pas.de.spam.fr> wrote:

Un langage à typage statique n'est-il-pas plus "rassurant"

Pour ceux qui ont besoin de se rassurer avec ça, peut-être. Comme
disait l'autre, s'il suffisait de déclarer trois fois le type d'un
objet pour être assuré d'avoir un logiciel correct et robuste, je le
ferais volontier. Comme ce n'est pas le cas et que ça ne le sera
jamais, remettons le typage statique à sa vrai place: un moyen pour le
compilateur de se permettre certaines optimisations. Ce qui est certes
louable quand on recherche ces optimisations, mais n'a aucun rapport
avec la qualité du code écrit par le programmeur.

(snip)

Bien sûr, "encadrement" et "limitation", ça marche un peu ensemble !
La question est de savoir si c'est une Bonne Chose ?
Si vous voullez bien, replaçons ma phrase dans son contexte ?
C'est à dire en réaction à une remarque de Bruno D. : "Le niveau moy en est
assez catastrophique"
Dans ce contexte là, un langage à typage dynamique laisse d'avantage l a
porte ouverte à du code "confus"

Chapitre et verset, s'il te plait ? Pour le moment; dans la pratique,
les pires horreurs que j'ai vu était dans des langages impératifs à
typage statique déclaratif.

D'ailleurs, Python offre bien plus de souplesse que PHP, par exemple,

Oui, mais moins de permissivité. Faudrait peut-être pas confondre.

et
donc au delà même du typage dynamique, toute cette souplesse dans les mains
du "programmeur-moyen-qui-doit-terminer-son-travail-pour-hier" peut
potentiellement accroitre le risque que soit produit un code confus, ou pi re
!?

Doit-on encore le répéter ? Un mauvais programmeur produit du mauvais
code, quelque soit le langage. Ajouter des contraintes à la majorité
en raison de l'incompétence d'une minorité est tout simplement stupide
- ça pénalise inutilement le plus grand nombre sans améliorer en rien
le niveau des plus mauvais.

En pareille situation (banale?), vive les langages statiques ?

Et la cohorte de complexification arbitraire qu'ils imposent, avec en
résultat plus de code donc plus de bugs ? Cette "logique" m'échappe.

(snip)

Le passé est aux langages à typage statique, incontestablement. L'a venir
aussi ?

Rien n'est moins sûr.

Je veux bien vos "sources" :-)
Pour le présent, pour quelqu'un cherchant du boulot, meilleurs sont ses
chances si son CV mentionne "C#-Java" que "Python-Ruby" !
Au moins en France.

Tiens, c'est curieux, ça fait bien longtemps que je n'ai pas eu à
chercher du travail (en général, c'est le travail qui vient me
chercher), et c'est essentiellement pour mes compétences sur des
langages dynamiques qu'on vient me chercher. Ce qui me convient fort
bien d'ailleurs, puisque je préfère me faire plombier que de supporter
un langage comme Java.

D'ailleurs, si "explicit is better than implicit", alors autant le dire
clairement lorsqu'un bout de code est prévu pour fonctionner avec un
objet
"canard", ou au moins un objet qui implémente l'interface ICoinCoin ? Non

?

C'est dit clairement. Dans la doc d'une part, et par les exceptions
qui se déclenchent si l'objet n'implémente pas le protocole attendu.

Pourtant, je suis 100% d'accord avec le "explicit is better than implicit"
Pourtant, ça ne colle pas du tout avec "typage dynamique" !

Et pourtant, elle tourne.

Sais-tu, mon cher anonyme, que les systèmes de typage statique
modernes (ceux avec inférence de type) ne nécessitent forcément pas la
déclaration des types attendus, celle-ci étant déduite de l'usage ?
Bref, que "typage statique" n'implique pas nécessairement "typage
déclaratif" ?

Bon, assez marché dans le troll, j'ai d'autres serpents à fouetter...

Bonsoir !

Attention! Suivi sur le groupe fr.comp.lang.general.

Sauf que, moi, je ne vais pas sur de NG-là.

@-salutations

Michel Claveau

Méta-MCI (MVP) wrote:

Bonsoir !

Attention! Suivi sur le groupe fr.comp.lang.general.
Sauf que, moi, je ne vais pas sur de NG-là.

Ok. Mais... est-ce parceque tu n'aime pas le groupe, ou bien que tu
économise de la BP, ou...
Parceque si il y a autant de groupes, autant qu'on s'en serve.