En news:, 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.
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.
En news:, 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.
En news:47f0f724$0$26796$, 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 ?
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 ?
En news:47f0f724$0$26796$, 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 ?
In article <47f24354$0$898$,
Wykaaa 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...
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...
In article <47f24354$0$898$,
Wykaaa 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:, 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$, 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 ?
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 ?
En news:, 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$, 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 ?
Il est "pur objet", un peu à la SmallTalk (même les types sont des
objets). Un langage "pur objet" est toujours un plus dans l'approche objet.
Et immense avantage, il a les threads indépendants du système
d'exploitation (on ne peut se passer du multi-threading aujourd'hui...)
Ce dernier trait a effectivement une contrepartie : une certaine lenteur.
Il suffira de faire pour Ruby ce qui a été fait pour Java (des JIT :
Just in Time Compilers) et la question sera réglée.
Il est "pur objet", un peu à la SmallTalk (même les types sont des
objets). Un langage "pur objet" est toujours un plus dans l'approche objet.
Et immense avantage, il a les threads indépendants du système
d'exploitation (on ne peut se passer du multi-threading aujourd'hui...)
Ce dernier trait a effectivement une contrepartie : une certaine lenteur.
Il suffira de faire pour Ruby ce qui a été fait pour Java (des JIT :
Just in Time Compilers) et la question sera réglée.
Il est "pur objet", un peu à la SmallTalk (même les types sont des
objets). Un langage "pur objet" est toujours un plus dans l'approche objet.
Et immense avantage, il a les threads indépendants du système
d'exploitation (on ne peut se passer du multi-threading aujourd'hui...)
Ce dernier trait a effectivement une contrepartie : une certaine lenteur.
Il suffira de faire pour Ruby ce qui a été fait pour Java (des JIT :
Just in Time Compilers) et la question sera réglée.
Il existe un test pour les navigateurs (ACID3. Voir :
http://www.depannetonpc.net/actualite/lire_2702_un-nouveau-test-pour-les-navigateurs-acid-3.html)
Il existe un test pour les navigateurs (ACID3. Voir :
http://www.depannetonpc.net/actualite/lire_2702_un-nouveau-test-pour-les-navigateurs-acid-3.html)
Il existe un test pour les navigateurs (ACID3. Voir :
http://www.depannetonpc.net/actualite/lire_2702_un-nouveau-test-pour-les-navigateurs-acid-3.html)
In article <47f24354$0$898$,
Wykaaa 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 sujet s
(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...
Dans l'enseignement de l'approche objet, j'ai toujours adopté l'approche
de Grady Booch.
Je dis (et je décris) que les 4 concepts majeurs de l'objet sont :
- le concept d'abstraction
- le concept d'encapsulation
- le concept de modularité
ancien) qui s'appuie sur les deux principes de : 1- Forte cohésion
interne d'une abstraction, 2- faible couplage entre abstraction
- La notion de hiérarchie : héritage, mais aussi agrégation et
composition qui sont toutes 3 des relations d'ordre strict entre
abstractions (c'est fondamental de comprendre ça pour éviter des erreu rs
de conception)
Une fois exposer ces 4 concepts majeurs, j'indique, en insistant
fortement, que ce n'est qu'à la condition que ces 4 concepts soient mis
en oeuvre conjointement qu'on peut parler d'approche objet.
Après, il faut faire de nombreuses études de cas pour montrer comment,
EFFECTIVEMENT, ces 4 concepts doivent être mis en oeuvre ENSEMBLE dans
une réelle approche objet et comment ils contribuent les uns aux autres
à cette approche.
Pédagogiquement parlant, je ne passe pas plus de temps sur la notion de
hiérarchie (et pas seulement l'héritage, c'est ça la clé) que sur les
autres concepts.
Enfin, je ne suis pas d'accord que les "vraies" bases s'expliquent en 5
minutes car moi j'y passe 3 (oui trois) jours sur les 4 concepts.
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 sujet s
(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...
Dans l'enseignement de l'approche objet, j'ai toujours adopté l'approche
de Grady Booch.
Je dis (et je décris) que les 4 concepts majeurs de l'objet sont :
- le concept d'abstraction
- le concept d'encapsulation
- le concept de modularité
ancien) qui s'appuie sur les deux principes de : 1- Forte cohésion
interne d'une abstraction, 2- faible couplage entre abstraction
- La notion de hiérarchie : héritage, mais aussi agrégation et
composition qui sont toutes 3 des relations d'ordre strict entre
abstractions (c'est fondamental de comprendre ça pour éviter des erreu rs
de conception)
Une fois exposer ces 4 concepts majeurs, j'indique, en insistant
fortement, que ce n'est qu'à la condition que ces 4 concepts soient mis
en oeuvre conjointement qu'on peut parler d'approche objet.
Après, il faut faire de nombreuses études de cas pour montrer comment,
EFFECTIVEMENT, ces 4 concepts doivent être mis en oeuvre ENSEMBLE dans
une réelle approche objet et comment ils contribuent les uns aux autres
à cette approche.
Pédagogiquement parlant, je ne passe pas plus de temps sur la notion de
hiérarchie (et pas seulement l'héritage, c'est ça la clé) que sur les
autres concepts.
Enfin, je ne suis pas d'accord que les "vraies" bases s'expliquent en 5
minutes car moi j'y passe 3 (oui trois) jours sur les 4 concepts.
In article <47f24354$0$898$,
Wykaaa 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 sujet s
(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...
Dans l'enseignement de l'approche objet, j'ai toujours adopté l'approche
de Grady Booch.
Je dis (et je décris) que les 4 concepts majeurs de l'objet sont :
- le concept d'abstraction
- le concept d'encapsulation
- le concept de modularité
ancien) qui s'appuie sur les deux principes de : 1- Forte cohésion
interne d'une abstraction, 2- faible couplage entre abstraction
- La notion de hiérarchie : héritage, mais aussi agrégation et
composition qui sont toutes 3 des relations d'ordre strict entre
abstractions (c'est fondamental de comprendre ça pour éviter des erreu rs
de conception)
Une fois exposer ces 4 concepts majeurs, j'indique, en insistant
fortement, que ce n'est qu'à la condition que ces 4 concepts soient mis
en oeuvre conjointement qu'on peut parler d'approche objet.
Après, il faut faire de nombreuses études de cas pour montrer comment,
EFFECTIVEMENT, ces 4 concepts doivent être mis en oeuvre ENSEMBLE dans
une réelle approche objet et comment ils contribuent les uns aux autres
à cette approche.
Pédagogiquement parlant, je ne passe pas plus de temps sur la notion de
hiérarchie (et pas seulement l'héritage, c'est ça la clé) que sur les
autres concepts.
Enfin, je ne suis pas d'accord que les "vraies" bases s'expliquent en 5
minutes car moi j'y passe 3 (oui trois) jours sur les 4 concepts.
En news:47f0f724$0$26796$, 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 ?
Oui, et aussi une belle preuve de ce que je disais à propos de Python.
Car dans le "programmer propre", il y a évidemment la portabilité...
(dans différents environnements et pas seulement sur des machines
différentes).
Il suffit de penser simplement au immenses possibilités de paramétrage
d'Emacs pour s'imaginer les tortures subies par les scripts Python !
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 ?
Oui, et aussi une belle preuve de ce que je disais à propos de Python.
Car dans le "programmer propre", il y a évidemment la portabilité...
(dans différents environnements et pas seulement sur des machines
différentes).
Il suffit de penser simplement au immenses possibilités de paramétrage
d'Emacs pour s'imaginer les tortures subies par les scripts Python !
En news:47f0f724$0$26796$, 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 ?
Oui, et aussi une belle preuve de ce que je disais à propos de Python.
Car dans le "programmer propre", il y a évidemment la portabilité...
(dans différents environnements et pas seulement sur des machines
différentes).
Il suffit de penser simplement au immenses possibilités de paramétrage
d'Emacs pour s'imaginer les tortures subies par les scripts Python !
En news:47f0f724$0$26796$, 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 ;-) ).
Tout ce que ça prouve, c'est que le compilateur (pas l'interpréteur)
fait correctement son boulot en détectant une erreur de syntaxe.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 ?
Oui, et aussi une belle preuve de ce que je disais à propos de Python.
Car dans le "programmer propre", il y a évidemment la portabilité...
(dans différents environnements et pas seulement sur des machines
différentes).
Il suffit de penser simplement au immenses possibilités de paramétrage
d'Emacs pour s'imaginer les tortures subies par les scripts Python !
J'utilise Python depuis =~ debut 2000 et je n'ai *absolument jamais* eu
de problème de cet ordre (en n'étant pas le seul à travailler sur les
projets, en utilisant différents éditeurs configurés différement . Non
que l'indentation significative soit AMHA une tellement bonne idée au
final, mais mon expérience est qu'en pratique ce type de problème est
rarissime. Bien plus que l'oubli des {} dans du C / C++ / java /
Javascript / PHP etc..., oubli qui, générant une erreur de logique mais
pas une erreur de syntaxe, n'est détecté par aucun compilo ou
interpréteur...
Arrêtez de fantasmer, les gars.
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 ;-) ).
Tout ce que ça prouve, c'est que le compilateur (pas l'interpréteur)
fait correctement son boulot en détectant une erreur de syntaxe.
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 ?
Oui, et aussi une belle preuve de ce que je disais à propos de Python.
Car dans le "programmer propre", il y a évidemment la portabilité...
(dans différents environnements et pas seulement sur des machines
différentes).
Il suffit de penser simplement au immenses possibilités de paramétrage
d'Emacs pour s'imaginer les tortures subies par les scripts Python !
J'utilise Python depuis =~ debut 2000 et je n'ai *absolument jamais* eu
de problème de cet ordre (en n'étant pas le seul à travailler sur les
projets, en utilisant différents éditeurs configurés différement . Non
que l'indentation significative soit AMHA une tellement bonne idée au
final, mais mon expérience est qu'en pratique ce type de problème est
rarissime. Bien plus que l'oubli des {} dans du C / C++ / java /
Javascript / PHP etc..., oubli qui, générant une erreur de logique mais
pas une erreur de syntaxe, n'est détecté par aucun compilo ou
interpréteur...
Arrêtez de fantasmer, les gars.
En news:47f0f724$0$26796$, 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 ;-) ).
Tout ce que ça prouve, c'est que le compilateur (pas l'interpréteur)
fait correctement son boulot en détectant une erreur de syntaxe.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 ?
Oui, et aussi une belle preuve de ce que je disais à propos de Python.
Car dans le "programmer propre", il y a évidemment la portabilité...
(dans différents environnements et pas seulement sur des machines
différentes).
Il suffit de penser simplement au immenses possibilités de paramétrage
d'Emacs pour s'imaginer les tortures subies par les scripts Python !
J'utilise Python depuis =~ debut 2000 et je n'ai *absolument jamais* eu
de problème de cet ordre (en n'étant pas le seul à travailler sur les
projets, en utilisant différents éditeurs configurés différement . Non
que l'indentation significative soit AMHA une tellement bonne idée au
final, mais mon expérience est qu'en pratique ce type de problème est
rarissime. Bien plus que l'oubli des {} dans du C / C++ / java /
Javascript / PHP etc..., oubli qui, générant une erreur de logique mais
pas une erreur de syntaxe, n'est détecté par aucun compilo ou
interpréteur...
Arrêtez de fantasmer, les gars.
Il est "pur objet", un peu à la SmallTalk (même les types sont des
objets). Un langage "pur objet" est toujours un plus dans l'approche
objet.
Cet argument m'amuse toujours. Qu'est-ce qui n'est pas objet dans
Python?
C'est d'ailleurs un des modèles objets les plus élégants que je
connaisse
Et immense avantage, il a les threads indépendants du système
d'exploitation (on ne peut se passer du multi-threading aujourd'hui...)
Comme à peu près tous les langages modernes, y compris Java ou Python.
Ce dernier trait a effectivement une contrepartie : une certaine lenteur.
Il suffira de faire pour Ruby ce qui a été fait pour Java (des JIT :
Just in Time Compilers) et la question sera réglée.
Ce n'est pas aussi simple. Pour Python, il existe Psyco et le projet
PyPy dont le JIT pour RPython (un sous-ensemble de Python) promet beaucoup.
Il est "pur objet", un peu à la SmallTalk (même les types sont des
objets). Un langage "pur objet" est toujours un plus dans l'approche
objet.
Cet argument m'amuse toujours. Qu'est-ce qui n'est pas objet dans
Python?
C'est d'ailleurs un des modèles objets les plus élégants que je
connaisse
Et immense avantage, il a les threads indépendants du système
d'exploitation (on ne peut se passer du multi-threading aujourd'hui...)
Comme à peu près tous les langages modernes, y compris Java ou Python.
Ce dernier trait a effectivement une contrepartie : une certaine lenteur.
Il suffira de faire pour Ruby ce qui a été fait pour Java (des JIT :
Just in Time Compilers) et la question sera réglée.
Ce n'est pas aussi simple. Pour Python, il existe Psyco et le projet
PyPy dont le JIT pour RPython (un sous-ensemble de Python) promet beaucoup.
Il est "pur objet", un peu à la SmallTalk (même les types sont des
objets). Un langage "pur objet" est toujours un plus dans l'approche
objet.
Cet argument m'amuse toujours. Qu'est-ce qui n'est pas objet dans
Python?
C'est d'ailleurs un des modèles objets les plus élégants que je
connaisse
Et immense avantage, il a les threads indépendants du système
d'exploitation (on ne peut se passer du multi-threading aujourd'hui...)
Comme à peu près tous les langages modernes, y compris Java ou Python.
Ce dernier trait a effectivement une contrepartie : une certaine lenteur.
Il suffira de faire pour Ruby ce qui a été fait pour Java (des JIT :
Just in Time Compilers) et la question sera réglée.
Ce n'est pas aussi simple. Pour Python, il existe Psyco et le projet
PyPy dont le JIT pour RPython (un sous-ensemble de Python) promet beaucoup.
