Erreur du preprocesseur

[...]

J'ai peut-être des oeillères mais je ne suis intervenu dans ma carrière
(j'arrive à la retraite...) que sur des projets d'au moins 200 000 lignes de
code et ça approchait le plus souvent le million ou plusieurs millions. dans
ce cadre là, des langages comme Python font plutôt figure de langages jouets.

Et puisque tu cites quelques langages du même ordre, sache que ruby a toutes
mes faveurs dans cette famille de langages.

Merde, alors. Nous avions un génie, un gars qui a tout connu, qui
aurait pu tout nous expliquer - sauf le français, quand même - et voilà
qu'il enfantille avec un T-shirt "Ruby est mieux que Python".

J'ai audité des millions de lignes de code (à l'aide de Logiscope). Ce que je
peux dire c'est que, même dans les domaines les plus pointus et qui
requièrent une grande fiabilité et sûreté de fonctionnement comme le
nucléaire,

Le fonctionnement du nucléaire est basé sur le hasard...

l'avionique ou le spatial, il n'y a pas 10% de programmeurs qui
programment "proprement. Ce n'est pas avec des langages comme Python qu'ils
vons le faire...

Mais je suis d'accord que pour des non informaticiens scientifiques

?????

qui
doivent faire des petites simulations ou des petits modèles, ce genre de
langage peut rendre des services mais alors il ne faut pas parler
d'informatique au sens industriel du terme (quand je dis industriel, je
rapproche la fabrication de logiciels à la fabrication d'automobiles ou
d'avions).

Le problème dans l'avion comme dans le logiciel étant le bord d'aile.

--
Pierre Maurette

Le Mon, 31 Mar 2008 15:18:28 +0200, Marc Espie <espie@lain.home> a écrit:

In article <op.t8vs8oia54jsyq@lemacpro.local>, wykaaa
<wykaaa@yahoo.fr> wrote:

Comment comparer Java et Python ????
Java est utilisé dans des applications importantes qui requièrent
fiabilité, évolutivité, etc. (comme les applications militaires).
Où est Python dans l'industrie ??? NULLE PART
Python est bien un langage marginal.

Enleve tes oeilleres, ca te fera du bien...

+1

(snip)

Et puisque tu cites quelques langages du même ordre, sache que ruby a
toutes mes faveurs dans cette famille de langages.

Ruby dont le typage est tout aussi dynamique que celui de Python, et
dont l'implémentation est très loin derrière (pas de byte-code, des
sérieux problèmes de gestion mémoire...).

Très cohérent, tout ça.

Certes tout n'est pas parfait avec Ruby, loin de là (je ne suis pas non
plus un admirateur béat de Ruby, j'ai seuelement dit qu'il avait mes
faveurs dans la famille de langages citée par l'un des participants de
ce fil, à savoir, Python, Perl, PH et Ruby).
Encore une fois, je ne me place pas du point de vue des implémentations
mais bien du point de vue des spécifications du langage, alors pour être
clair, les spécifications de Ruby sont bien meilleures que celles de
Python. C'est mon point de vue et je conçois tout à fait qu'on puisse
être d'un avis contraire.
Par contre je n'aime pas la mauvaise fois qui consiste à dire que parce
que les implémentations sont merdiques, alors le langage est merdique.

Eiffel avait d'énormes problèmes de GC au début (les implémentations),
Java également (les implémentations). Avec le temps, tout ceci s'est
considérablement arrangé et ça n'en fait pas de mauvais langages pour
autant.

J'ai audité des millions de lignes de code (à l'aide de Logiscope). Ce
que je peux dire c'est que, même dans les domaines les plus pointus et
qui requièrent une grande fiabilité et sûreté de fonctionnement comme
le nucléaire, l'avionique ou le spatial, il n'y a pas 10% de
programmeurs qui programment "proprement. Ce n'est pas avec des
langages comme Python qu'ils vons le faire...

Le langage n'y est pour rien. La preuve, même avec ADA, on peut crasher
une fusée...
Sais-tu seulement pourquoi elle a crashé ?

Quand on reprend le module de navigation d'Ariane 4 tel quel pour Ariane
5 qui n'a pas le même V0 (vitesse par rapport au sol) et que le code de
récupération d'erreur pour l'overflow qui en résulte est inadéquat pour
Ariane 5, il faut s'attendre au pire.
Conclusion : pour ce crash, ce sont les procédures d'assurance qualité
liées à l'intégration/validation (matériel/logiciel) qui n'ont pas été
respectées. Mais là, on est dans le qomaine de l'ingénierie système et
non plus seulement dans l'ingénierie logicielle.

Mais je suis d'accord que pour des non informaticiens scientifiques
qui doivent faire des petites simulations ou des petits modèles, ce
genre de langage peut rendre des services mais alors il ne faut pas
parler d'informatique au sens industriel du terme (quand je dis
industriel, je rapproche la fabrication de logiciels à la fabrication
d'automobiles ou d'avions).

Réveille-toi, Mossieur le consultant, il y a beaucoup d'autres domaines
d'application de l'informatique que les fusées et les centrales
nucléaires. Ce n'est pas parce qu'un tournevis n'est pas l'outil
approprié pour planter un clou qu'il faut en conclure que les tournevis
ne sont pas de bons outils. Et ce n'est pas parce qu'un domaine
d'application échappe à ta grande expérience qu'il est marginal ou
secondaire.

Indépendamment des domaines d'application, il y a suffisamment de traits
de langage merdiques dans Python pour ne pas en faire le Phénix des
langages.
C'est curieux comme les admirateurs de Python ressemblent à une secte !

Amis prétentieux, bonsoir...

Il n'y a aucune prétention, seulement un peu de bon sens.

Le Mon, 31 Mar 2008 15:18:28 +0200, Marc Espie <espie@lain.home> a
écrit:

In article <op.t8vs8oia54jsyq@lemacpro.local>, wykaaa
<wykaaa@yahoo.fr> wrote:

Comment comparer Java et Python ????
Java est utilisé dans des applications importantes qui requièrent
fiabilité, évolutivité, etc. (comme les applications militaires).
Où est Python dans l'industrie ??? NULLE PART
Python est bien un langage marginal.

Enleve tes oeilleres, ca te fera du bien...

+1

(snip)

Et puisque tu cites quelques langages du même ordre, sache que ruby a
toutes mes faveurs dans cette famille de langages.

Ruby dont le typage est tout aussi dynamique que celui de Python, et
dont l'implémentation est très loin derrière (pas de byte-code, des
sérieux problèmes de gestion mémoire...).

Très cohérent, tout ça.

Certes tout n'est pas parfait avec Ruby, loin de là (je ne suis pas non
plus un admirateur béat de Ruby, j'ai seuelement dit qu'il avait mes
faveurs dans la famille de langages citée par l'un des participants de
ce fil, à savoir, Python, Perl, PH et Ruby).

Je m'étonne qu'un langage à typage dynamique (et bien plus que le typage
d'ailleurs...) ait tes faveurs vu les propos que tu tiens par ailleurs,
je cite:

"""
Le fait de povoir utiliser des variables ssans les déclarer est une
source d'erreur inépuisable même pour des professionnels aguerris !
De tels langages doivent être bannis dans l'industrie du logiciel et
rester dans les labos pour du maquettage et surtout ne pas être montrés
à des étudiants.
"""

Encore une fois, je ne me place pas du point de vue des implémentations
mais bien du point de vue des spécifications du langage, alors pour être
clair, les spécifications de Ruby sont bien meilleures que celles de
Python.

J'aurais tendance à penser que c'est là un a priori dépourvu de
fondement et fondé sur une méconnaissance assez abyssale de Python. Mais
je peux me tromper, bien sûr...

C'est mon point de vue et je conçois tout à fait qu'on puisse
être d'un avis contraire.
Par contre je n'aime pas la mauvaise fois qui consiste à dire que parce
que les implémentations sont merdiques, alors le langage est merdique.

Où ai-je dis que Ruby était merdique ? Tu peux chercher sur le web
entier, je te mets au défi de trouver une seule occurrence d'un tel
propos de ma part. Tu risques plutôt de trouver le contraire...

Personnellement, ce que je n'aime pas, c'est la mauvaise foi consistant
à répéter qu'un langage est merdique sans apporter le moindre argument
(celui du typage dynamique étant contredit par tes propos sur Ruby).

Eiffel avait d'énormes problèmes de GC au début (les implémentations),
Java également (les implémentations). Avec le temps, tout ceci s'est
considérablement arrangé et ça n'en fait pas de mauvais langages pour
autant.

<troll>
En me plaçant du point de vue des spécifications du langages, Java est
un des langages les plus merdiques jamais inventés (avec vb). Mais comme
tu dis, "c'est mon point de vue et je conçois tout à fait qu'on puisse
être d'un avis contraire"...
</troll>

J'ai audité des millions de lignes de code (à l'aide de Logiscope).
Ce que je peux dire c'est que, même dans les domaines les plus
pointus et qui requièrent une grande fiabilité et sûreté de
fonctionnement comme le nucléaire, l'avionique ou le spatial, il n'y
a pas 10% de programmeurs qui programment "proprement. Ce n'est pas
avec des langages comme Python qu'ils vons le faire...

Le langage n'y est pour rien. La preuve, même avec ADA, on peut
crasher une fusée...
Sais-tu seulement pourquoi elle a crashé ?

Oui, merci. J'ai lu et relu la littérature sur cet incident et ses
causes. Avec comme conclusion qu'aucun langage ne pourra constituer une
protection efficace contre les erreurs humaines.

Conclusion : pour ce crash, ce sont les procédures d'assurance qualité
liées à l'intégration/validation (matériel/logiciel) qui n'ont pas été
respectées.

Comme quoi (bis) il ne suffit pas d'avoir un des langages les plus
psycho-rigides du monde pour être à l'abri des conneries à un niveau ou
à un autre.

Comme je le disais, donc, le langage n'y est pour rien. Donc, ton
argument non plus.

Mais je suis d'accord que pour des non informaticiens scientifiques
qui doivent faire des petites simulations ou des petits modèles, ce
genre de langage peut rendre des services mais alors il ne faut pas
parler d'informatique au sens industriel du terme (quand je dis
industriel, je rapproche la fabrication de logiciels à la fabrication
d'automobiles ou d'avions).

Réveille-toi, Mossieur le consultant, il y a beaucoup d'autres
domaines d'application de l'informatique que les fusées et les
centrales nucléaires. Ce n'est pas parce qu'un tournevis n'est pas
l'outil approprié pour planter un clou qu'il faut en conclure que les
tournevis ne sont pas de bons outils. Et ce n'est pas parce qu'un
domaine d'application échappe à ta grande expérience qu'il est
marginal ou secondaire.

Indépendamment des domaines d'application, il y a suffisamment de traits
de langage merdiques dans Python pour ne pas en faire le Phénix des
langages.

Indépendamment des domaines d'applications, on peut en dire autant
d'absolument tous les langages existants. Et en plus, on peut être sûr
de ne jamais trouver deux personnes *exactement* d'accord sur la
définition de ces "traits de langage merdiques", quel que soit le langage.

Mais bon, pour ta gouverne, Mossieur le Consultant, je parlais là des
langages dynamiques en général (Ruby inclus), pas spécifiquement de Python.

C'est curieux comme les admirateurs de Python ressemblent à une secte !

On n'est pas loin du point godwin, là. Allez, encore un effort, je suis
sûr que tu peux y arriver.

Amis prétentieux, bonsoir...

Il n'y a aucune prétention,

Non, à peine. Y pas que les oeillères que tu devrais enlever.

En news:op.t8wcxilw54jsyq@lemacpro.local, wykaaa va escriure:

J'ai peut-être des oeillères mais je ne suis intervenu dans ma
carrière (j'arrive à la retraite...) que sur des projets d'au moins
200 000 lignes de code et ça approchait le plus souvent le million ou
plusieurs millions. dans ce cadre là, des langages comme Python font
plutôt figure de langages jouets.

Euh, dans un projet de cette taille, tu dois avoir plusieurs langages, non ?
Genre, essentiellement du C++ et un peu de Make et de
LALRspécifiqueSimpleFaitMaison (histoire de caricaturer un peu). Est-ce que
les deux derniers doivent être classés dans la catégorie « jouets » ?

J'ai audité des millions de lignes de code (à l'aide de Logiscope).
Ce que je peux dire c'est que [...] il n'y
a pas 10% de programmeurs qui programment "proprement. Ce n'est pas
avec des langages comme Python qu'ils vons le faire...

Je ne comprends pas le syllogisme. J'ai appris à programmer en Basic, puis
en langages d'assemblage, puis en Ada, puis en Pascal, puis en C. Bien plus
tard, dans un autre boulot, j'ai eu à programmer des petits scripts en
Python.
Si on suppose (hypothèse de nécessité) que je programmai*s*
« proprement » avant, pourquoi est-ce que j'aurais alors basculé
définitivement hors de cette catégorie ? Quelle tâche indélébile ce langage
a-t-il marqué sur mon parcours ?
Et pourquoi C n'a-t-il pas imprimé une telle tâche ?

Évidemment, tout est contenu dans l'½uf « proprement », qui n'est pas
explicité. Si je retourne le syllogisme, tu affirmes (axiome) qu'il est
impossible de programmer « proprement » en Python. Même si j'ai des idées
(nombreuses) sur les raisons qui pourraient pousser à prouver de tels
axiomes, je préférerai que ce soit explicité.

Mais je suis d'accord que pour des non informaticiens scientifiques
qui doivent faire des petites simulations ou des petits modèles, ce
genre de langage peut rendre des services mais alors il ne faut pas
parler d'informatique au sens industriel du terme (quand je dis
industriel, je rapproche la fabrication de logiciels à la fabrication
d'automobiles ou d'avions).

1º La fabrication des automobiles (au sens où on le comprend généralement)
et celles des avions sont industriellement différentes : dans un cas on est
sur des pratiques de grande série (comme pour des yaourts ou des paquets de
lessive), dans l'autre il s'agit d'artisanat et de toute petite séries
(comme pour l'industrie du luxe). À quoi compares-tu l'industrie du logiciel
? Je ne peux qu'être d'accord si tu compares avec la grande série et ses
chaînes...

2º Si on regarde l'aéronautique, entre Airbus ou Boeing et celui qui
assemble son ULM dans son garage, il y a d'énormes différences. Pourtant,
tous les deux fabriquent des avions, non ?

3º Même dans la fabrication des automobiles, certaines tâches sont très
artisanales. Mais alors, très très très artisanales ! Genre, on ne veut
surtout pas qu'il existe une procédure précise qui décrive un processus
donné, soit parce que l'on ne veut pas que la dite procédure puisse «
disparaître » (sachant qu'elle ne sera pas « disparue » pour tout le monde),
soit parce que l'expérience a prouvé qu'en laissant faire les spécialistes
on obtenait de meilleurs résultats qu'en appliquant les procédures.
Si on ramène cela au cas des langages d'utilisation marginale comme Python,
on voit bien que même si le corps principal peut être dans un langage «
adulte », il reste aussi de la place autour pour les jouets.


Antoine

En news:47f0f724$0$26796$426a74cc@news.free.fr, Francois va escriure:

Je pensais que l'indentation chez Python était une force et je
découvre qu'en fait ce point est un vrai sujet de controverse. C'est
vrai que ça peur d'imaginer qu'un script Python très très long puisse
s'effondrer parce qu'une personne inamicale ajoute un minuscule espace
quelque part au beau milieu du code.

Euh, il n'y a pas besoin d'un cas aussi extrême.
Perso, un script très court exploité sur deux machines, donc deux éditeurs
de texte différents, dont les paramètres par défaut pour la génération
correspondant à la touche TAB du clavier étaient différents (HT d'un côté et
série d'espace de l'autre).
Résultat, au premier coup de correction à chaud pour « réparer » une c***ie
au milieu d'une focntion sur « l'autre » machine, crac tu casses le script
(en fait, il ne charge même pas, l'interpréteur détecte le souci, preuve
selon moi que je ne suis pas le premier à qui cela arrive ;-) ).

Depuis, j'ai sur les *deux* machines reconfigurer les éditeurs pour
visualiser les espaces et les tabulations « dures ».
Cela doit s'appeler l'expérience, non ?


Antoine

In article <47f24354$0$898$ba4acef3@news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:

Ca dépend. Si seulement c'était bien enseigné !
Et aujourd'hui, il y a quand même de très bon bouquins sur ces sujets
(la plupart en anglais, hélas...)
J'ai fabriqué des cours sur tout ça, faudrait que je les mette en ligne...

Le plus gros probleme est d'ordre psychologique: les vraies bases sont
tres simples. Elles s'expliquent en cinq minutes, mais sont dures a
appliquer correctement... je crois plus a l'approche _refactoring_ pour
enseigner ces notions.

Prend un cours `classique' d'oriente objet, tu vas expliquer abstraction et
encapsulation en cinq minutes, et passer 3/4 h sur l'heritage... et apres,
si tu demandes a un etudiant de te caracteriser programmation OO, forcement
il va te parler d'heritage...

En news:op.t8wd2csm54jsyq@lemacpro.local, wykaaa va escriure:

Pour le Web, les gens utilisent n'importe quoi et il n'y a qu'à
regarder les résultats catastrophiques concernant l'interopérabilité
multi-plateformes (les sites qui ne marchent qu'avec tel OS ou tel
navigateur, ou le machin flash dernier cri, etc.).

Il semble clair que l'interopérabilité multi-plateforme n'est *PAS* le
critère primordial d'un serveur web.
Par contre, en ce qui concerne le délivré, actuellement les choses
s'améliorent beaucoup, les normes étant nettement moins mouvantes... En
effet, quand la période entre deux versions incompatibles entre elles des
« standards » est inférieure au temps moyen de développement d'un site web,
il est difficile de réussir l'impossible. Depuis que 1º Microsoft a imposé
un navigateur sur >90% des machines cibles, et que 2º --en rupture complète
avec le passé immédiat-- a cessé de le développer dans toutes les directions
pendant 6 ans, c'est beaucoup mieux ! Le bienfait des standards...

Ce qui nous amène à...

Je rappelle (étant
un très vieil utilisateur d'Arpanet et d'Internet, bien avant le Web)
que les développeurs pionniers du réseau des réseaux se sont toujours
efforcé, dans leur choix, de faire en sorte que les protocoles et les
outils soient indépendants des plateformes.

Hou, je ne suis pas franchement d'accord avec le « toujours » ci-dessus. En
fait, j'en connais plusieurs qui ont essayé justement le contraire, imposer
leurs plateformes ou leurs outils ou leurs protocoles au dépend de
l'interopérabilité (en général sans succès).

Ce qui est vrai (et intéressant), c'est que dans leur majorité les normes
d'internet qui ont eu du succès sont celles qui ont favorisé
l'interopérabilité (souvent en standardisant sur un existant-qui-fonctionne,
parfois en cassant exprès quelque chose d'existant dont on « sentait » que
cela était suboptimal, l'exemple le plus évident étant le modèle OSI).

Je remarque une forte poussée de Ruby, qui est un bien meilleur
langage que Python , dans le même genre de famille de langage

Après le web, on continue sur l'analyse des phénomènes de mode ?

Il est hors de question d'utiliser un langage à typage dynamique dans
des applications qui requièrent une très grande fiabilité et une
excellente sûreté de fonctionnement.

C'est marrant, moi cela me rappelle des phrases entendues il y a peut-être
15 ou 20 ans, où l'on parlait de langages-objets et C++ et d'inadaptation au
temps réel.


En news:47f16b4b$0$904$ba4acef3@news.orange.fr, Wykaaa va escriure:

[...] syntaxe simple, inspirée par Eiffel et Ada (ce qui
est forcément un plus, ces deux langages étant reconnus
pour leur "propreté syntaxique").

Connais pas Eiffel, mais je ne trouve pas Ada (83) très propre
syntaxiquement : en fait, par rapport à Pascal qui était ma référence à
l'époque, je trouvais Ada plutôt sale à cause des multiples concepts
supplémentaires pas franchement orthogonaux (generic, task) ou carrément
lourdingues (TEXT_IO, ASCII). Évidemment, Ada devait cela en partie à sa
richesse sans commune mesure avec celle du Pascal ISO. Et évidemment aussi,
à la même époque C était pour moi bien pire, en particulier à cause de sa
manière anglo-saxone/germanique de définir les objets.
Mais on se fait à tout, n'est-ce-pas ?


Antoine

[...]

si tu demandes a un etudiant de te caracteriser programmation OO, forcement
il va te parler d'heritage...

C'est une raison suffisante pour ne pas tenter d'enseigner la
programmation objet à ses enfants, ça pourrait jeter un froid...

--
Pierre Maurette

Personnellement, je hais Python (et le mot est faible) en raison de

Haïr ??? On t'a fait programmer du Python sous la torture ? ;)

Bref, c'est peut-être lisible, mais ce n'est pas pérenne.

Ça c'est la pérennité du code-source. Mais je m'interroge sur la
"pérennité" du langage.
(snip)

La question que je me pose c'est : que sera Python dans 5 ans ?
Peut-être un langage complètement délaissé.

Attendu que Python existe depuis 1990, ne cesse depuis de gagner en
popularité et en "parts de marchés", qu'il est devenu une dépendance
pour la plupart des distribs linux, et de certaines distribs "OEM" de
Windows (particulièrement Dell si ma mémoire est bonne), que MS a
embauché il y a un ou deux ans l'auteur de Jython (port de Python pour
la JVM) et de IronPython (port de Python pour .NET), que Google a
embauché GvR (l'auteur de Python), et que Sun viens d'embaucher le
mainteneur de Jython (avec budget et mission de rattraper le retard par
rapport à CPython), je doute très franchement que le langage disparaisse
de si tôt.

Je ne vois pas qu'on
enseigne Python dans les facs ou dans les écoles,

Je n'ai pas de sources sous le coude, mais il me semble au contraire que
Python est de plus en plus souvent utilisé comme premier langage dans
l'enseignement.

j'ai l'impression que
c'est un langage marginal

Moins visible que Java ou C#, certainement. D'un autre côté, il y a sur
les machines que j'utilise (bureau, perso, serveurs de prod etc) bien
plus d'applis Python que d'applis Java ou C#.

voire déconsidéré.

???

Par contre, Java, lui est
toujours là.

Comme COBOL...

[...]

Donc, ce que je proposerai, c'est un repas complet ;)

N'oubliez pas une petite pipe

bof, apparemment t'as du mal à avaler ...

avec le café,