Pédagogie de la programmation
Wykaaa
tel ou tel langage de programmation (principalement dans les forums
C/C++), j'initie un fil de discussion pour discuter sur la pédagogie de
l'enseignement de la programmation pour des débutants (étudiants ou
informaticiens professionnels mais ne connaissant pas la programmation.
Si, si, ça existe...).
Attention, il ne s'agit pas de se quereller sur tel ou tel langage mais
d'essayer de répondre à des questions telles que :
- Par quoi commence-t-on : directement par un langage et lequel
(attention aux querelles...), par du pseudo-code (séquence, alternative,
itérative, récursion), par des concepts (qu'est-ce qu'une variable, un
littéral, une constante, les classes d'allocation mémoire, les tableaux,
les structures, les modules, etc.) ?
- Quels exercices, quelle progression, quel ordre dans la progression,
quels types de projets ?
- Où place-t-on la qualité du code (en cours, dans les exercices, dans
les projets ?
- Parle-t-on des métriques logicielles ?
- les met-on en oeuvre avec un outil (type logiscope ou son équivalent
(?) dans le monde du libre
- Les tests : unitaire, d'intégration, de validation, les taux de
couverture . Comment parle-t-on de tout ça ?
- Niveau espéré en sortie ? (que sait-on faire ?)
- Par quoi compléter dans la "vraie vie" en entreprise ?
Questions subsidiaires :
Parle-t-on (à quelle "dose")
- des automates (finis, à pile, à mémoire linéairement borné, machine de
Turing)
- de la BNF
- de l'indécidabilité (de l'équivalence de programmes, par exemple)
- problème de l'arrêt
- de la description de la sémantique des langages. Des différentes
sortes de sémantiques, du lambda-calcul, etc.
- de la preuve de programme
- etc. (je sais c'est pas bien mais c'est pour laisser ouvert à d'autres
sujets éventuellement)
L'objectif, à la fin, c'est d'avoir un cursus concernant l'enseignement
de la programmation, avec des indications de pédagogie, et des options
ou des variantes.
Je veux bien faire des synthèses ponctuellement et veiller à ce que la
discussion ne parte pas dans tous les sens.
Je précise que je n'ai aucun intérêt dans l'histoire car je suis depuis
4 mois à la retraite (du privé) mais que j'ai beaucoup développé,
encadré des développeurs (tous ingénieurs), beaucoup donné de formations
en entreprise sur les langages(divers et variés), la conception objet,
uml, la qualité logicielle, les méthodes de tests logiciels,
l'ingénierie des exigences, etc.
Marc Boyer
> Suite à différentes discussions dans différents forums spécialisés sur
> tel ou tel langage de programmation (principalement dans les forums
> C/C++), j'initie un fil de discussion pour discuter sur la pédagogie de
> l'enseignement de la programmation pour des débutants (étudiants ou
> informaticiens professionnels mais ne connaissant pas la programmation.
> Si, si, ça existe...).
Oulà... Ce que tu demandes, c'est de discuter et de construire un plan
de formation. C'est un exercice super long, et déjà difficile en
vis-à-vis, alors sur Usenet...
De plus, il est impossible de faire ce genre de chose sans avoir
le contexte, les objectifs de la formation, etc. On batit pas
le même programme pour un IUT informatique, pour l'option info
d'une ENS ou pour l'approfondissement informatique d'une école
aéronautique.
> L'objectif, à la fin, c'est d'avoir un cursus concernant l'enseignement
> de la programmation, avec des indications de pédagogie, et des options
> ou des variantes.
C'est bien ça le problème: je ne connais pas "un" cursus, mais
des dizaines, avec des objectifs et des contraintes diverses.
> Je précise que je n'ai aucun intérêt dans l'histoire car je suis depuis
> 4 mois à la retraite (du privé) mais que j'ai beaucoup développé,
> encadré des développeurs (tous ingénieurs), beaucoup donné de formations
> en entreprise sur les langages(divers et variés), la conception objet,
> uml, la qualité logicielle, les méthodes de tests logiciels,
> l'ingénierie des exigences, etc.
Moi j'ai enseigné l'informatique dans divers contextes (IUT, IUP,
Ecole ingé Télécom)...
Marc Boyer
--
Au XXIème siècle, notre projet de société s'est réduit
à un projet économique...
Wykaaa
> On 2009-02-05, Wykaaa <wyk...@yahoo.fr> wrote:
>> Suite à différentes discussions dans différents forums spécialisés sur
>> tel ou tel langage de programmation (principalement dans les forums
>> C/C++), j'initie un fil de discussion pour discuter sur la pédagogie de
>> l'enseignement de la programmation pour des débutants (étudiants ou
>> informaticiens professionnels mais ne connaissant pas la programmation.
>> Si, si, ça existe...).
>
>
> Oulà... Ce que tu demandes, c'est de discuter et de construire un plan
> de formation. C'est un exercice super long, et déjà difficile en
> vis-à-vis, alors sur Usenet...
>
> De plus, il est impossible de faire ce genre de chose sans avoir
> le contexte, les objectifs de la formation, etc. On batit pas
> le même programme pour un IUT informatique, pour l'option info
> d'une ENS ou pour l'approfondissement informatique d'une école
> aéronautique.
Je ne parlais de pédagogie que pour les débutants en programmation, pas
des cours d'approfondissement.
Quand on démarre l'apprentissage, ça doit être, grossièrement, pour tout
le monde pareil.
On pourrait restreindre le sujet à : comment on aborde la programmation
au début. Ce qui correspond à ma première question : par quoi on commence ?
>
>> L'objectif, à la fin, c'est d'avoir un cursus concernant l'enseignement
>> de la programmation, avec des indications de pédagogie, et des options
>> ou des variantes.
>
> C'est bien ça le problème: je ne connais pas "un" cursus, mais
> des dizaines, avec des objectifs et des contraintes diverses.
Oui mais pour débuter, quel que soit l'objectif final ou la cible métier.
>
>> Je précise que je n'ai aucun intérêt dans l'histoire car je suis depuis
>> 4 mois à la retraite (du privé) mais que j'ai beaucoup développé,
>> encadré des développeurs (tous ingénieurs), beaucoup donné de formations
>> en entreprise sur les langages(divers et variés), la conception objet,
>> uml, la qualité logicielle, les méthodes de tests logiciels,
>> l'ingénierie des exigences, etc.
>
> Moi j'ai enseigné l'informatique dans divers contextes (IUT, IUP,
> Ecole ingé Télécom)...
>
> Marc Boyer
Justement, c'est un parcours intéressant pour faire part de ton
expérience. Moi j'ai surtout l'expérience de la formation d'adultes dans
un cadre non universitaire.
Marc Boyer
> Marc Boyer a écrit :
>> On 2009-02-05, Wykaaa <wyk...@yahoo.fr> wrote:
>>> Suite à différentes discussions dans différents forums spécialisés sur
>>> tel ou tel langage de programmation (principalement dans les forums
>>> C/C++), j'initie un fil de discussion pour discuter sur la pédagogie de
>>> l'enseignement de la programmation pour des débutants (étudiants ou
>>> informaticiens professionnels mais ne connaissant pas la programmation.
>>> Si, si, ça existe...).
>>
>>
>> Oulà... Ce que tu demandes, c'est de discuter et de construire un plan
>> de formation. C'est un exercice super long, et déjà difficile en
>> vis-à-vis, alors sur Usenet...
>>
>> De plus, il est impossible de faire ce genre de chose sans avoir
>> le contexte, les objectifs de la formation, etc. On batit pas
>> le même programme pour un IUT informatique, pour l'option info
>> d'une ENS ou pour l'approfondissement informatique d'une école
>> aéronautique.
>
> Je ne parlais de pédagogie que pour les débutants en programmation, pas
> des cours d'approfondissement.
> Quand on démarre l'apprentissage, ça doit être, grossièrement, pour tout
> le monde pareil.
Ben non, je ne pense pas.
Tient, si tu as du temps dans l'ensemble de ta formation pour
voir 4-5 langages, tu peux commencer par un langage un peu marginal
(Caml, Pascal, python, Ada) puis aborder des langages mainstream ensuite
(C, C++, Java).
Si tu as a à peine le volume pour faire 1 ou 2 langages, le choix est
contraint de façon très différentes.
Idem, il y a des formations qui vont être ammenées à programmer de petites
choses. J'avais des collègues de traitement du signal, qui faisaient du
Matlab, des codes qui dépassaient très rarement 5000LOC, et dont les
utilisateurs étaient des gens qui faisaient du traitement du signal, donc
qui iront voir le code.
La problématique qualité est très différente d'un logiciel de 500KLOC
dont les utilisateurs ne verront que le binaire.
> On pourrait restreindre le sujet à : comment on aborde la programmation
> au début. Ce qui correspond à ma première question : par quoi on commence ?
Variable, sequence, test, boucle.
> Oui mais pour débuter, quel que soit l'objectif final ou la cible métier.
C'est là que je ne suis pas d'accord. L'objectif importe dès le début.
Wykaaa
Si on a le temps, c'est effectivement ce qu'il faut faire.
Au début des années 90, j'avais expérimenté l'apprentissage de la
programmation avec Ada (en remplacement de Pascal parce qu'il y a les
packages qui sont propres en Ada) et ensuite on passait au C en disant
que l'équivalent d'un package Ada c'était un .h et un .c. Du coup les
participants programmaient très proprement en C car ils avaient pris de
bonnes habitudes avec Ada.
> Si tu as a à peine le volume pour faire 1 ou 2 langages, le choix est
> contraint de façon très différentes.
Oui c'est sûr.
>
> Idem, il y a des formations qui vont être ammenées à programmer de petites
> choses. J'avais des collègues de traitement du signal, qui faisaient du
> Matlab, des codes qui dépassaient très rarement 5000LOC, et dont les
> utilisateurs étaient des gens qui faisaient du traitement du signal, donc
> qui iront voir le code.
> La problématique qualité est très différente d'un logiciel de 500KLOC
> dont les utilisateurs ne verront que le binaire.
En traitement de signal, la problématique est très différente pour la
programmation. Matlab me paraît une bonne idée et, effectivement, ils
ne'auront pas à tremper dans des projets de centaines de milliers de
lignes de code.
>
>> On pourrait restreindre le sujet à : comment on aborde la programmation
>> au début. Ce qui correspond à ma première question : par quoi on commence ?
>
> Variable, sequence, test, boucle.
En pseudo-code au tout début ou directement dans un langage ? si oui,
quel langage , (je penche toujours pour Ada, mais je suis peut-être
influencé par les milieux et les applications que j'ai fréquentées :
essentiellement des très grosses applis toujours > à 200 à 300 KLOC)
>
>> Oui mais pour débuter, quel que soit l'objectif final ou la cible métier.
>
> C'est là que je ne suis pas d'accord. L'objectif importe dès le début.
Finalement tu a certainement raison. Et pour les administrateurs ? du
Shell ?
Marc Boyer
>> Tient, si tu as du temps dans l'ensemble de ta formation pour
>> voir 4-5 langages, tu peux commencer par un langage un peu marginal
>> (Caml, Pascal, python, Ada) puis aborder des langages mainstream ensuite
>> (C, C++, Java).
>
> Si on a le temps, c'est effectivement ce qu'il faut faire.
>
> Au début des années 90, j'avais expérimenté l'apprentissage de la
> programmation avec Ada (en remplacement de Pascal parce qu'il y a les
> packages qui sont propres en Ada) et ensuite on passait au C en disant
> que l'équivalent d'un package Ada c'était un .h et un .c. Du coup les
> participants programmaient très proprement en C car ils avaient pris de
> bonnes habitudes avec Ada.
Pareil.
Mais l'arrivée de Java a changé la donne: obligé de faire C et Java
dans le volume dans lequel tenait Ada+C, la formation à laquelle
je pense a remplacé Ada par Java...
>>> On pourrait restreindre le sujet à : comment on aborde la programmation
>>> au début. Ce qui correspond à ma première question : par quoi on commence ?
>>
>> Variable, sequence, test, boucle.
>
> En pseudo-code au tout début ou directement dans un langage ? si oui,
> quel langage , (je penche toujours pour Ada, mais je suis peut-être
> influencé par les milieux et les applications que j'ai fréquentées :
> essentiellement des très grosses applis toujours > à 200 à 300 KLOC)
Ce furent de longues discussions avec un collègue.
J'était très content de Pascal, mais la disponibilité du compilo
laisse à désire.
J'aime beaucoup Ada, mais le collègue trouvait le traitement des E/S
rebuttant pour les débutants.
>>> Oui mais pour débuter, quel que soit l'objectif final ou la cible métier.
>>
>> C'est là que je ne suis pas d'accord. L'objectif importe dès le début.
>
> Finalement tu a certainement raison. Et pour les administrateurs ? du
> Shell ?
Existe-il quelque part une formation spécifique pour les Admins ?
J'ai toujours eut l'impression que c'était des informaticiens généralistes
formés à l'admin sur le tas.
Mihamina Rakotomandimby (R12y)
>> Finalement tu a certainement raison. Et pour les administrateurs ? du
>> Shell ?
> Existe-il quelque part une formation spécifique pour les Admins ?
> J'ai toujours eut l'impression que c'était des informaticiens généralistes
> formés à l'admin sur le tas.
Un bon admin système UNIX sait packager et donc patcher du code.
Je dirais que pour la branche UNIX, le C est à aborder tres tot.
Moi j'ai manqué le train du C à la Fac, je le regrette amèrement
aujourd'hui.
Apres, en général, un admin reprend du code, il en crée rarement.
Donc pour lui c'est plutot apprendre à lire le code de quelqu'un qu'il
lui faut.
Wykaaa
question : que faut-il apprendre de la programmation pour les
administrateurs ?
Je relève tout de même que packager et patcher ce n'est pas tout à fait
la même chose.
Dans un environnement Unix, pour les admins, il faut donc leur apprendre
le C et le Shell, est-ce cela ?
Je suis d'accord avec toi pour dire qu'ils doivent essentiellement
savoir lire du code et que, donc, la pédagogie peut être un peu
différente (mais pas tant que ça). La différence se fera principalement
au niveau des exercices il me semble.
Wykaaa
> On 2009-02-06, Wykaaa <wyk...@yahoo.fr> wrote:
>> Marc Boyer a écrit :
>>> Ben non, je ne pense pas.
>>> Tient, si tu as du temps dans l'ensemble de ta formation pour
>>> voir 4-5 langages, tu peux commencer par un langage un peu marginal
>>> (Caml, Pascal, python, Ada) puis aborder des langages mainstream ensuite
>>> (C, C++, Java).
>> Si on a le temps, c'est effectivement ce qu'il faut faire.
>>
>> Au début des années 90, j'avais expérimenté l'apprentissage de la
>> programmation avec Ada (en remplacement de Pascal parce qu'il y a les
>> packages qui sont propres en Ada) et ensuite on passait au C en disant
>> que l'équivalent d'un package Ada c'était un .h et un .c. Du coup les
>> participants programmaient très proprement en C car ils avaient pris de
>> bonnes habitudes avec Ada.
>
> Pareil.
> Mais l'arrivée de Java a changé la donne: obligé de faire C et Java
> dans le volume dans lequel tenait Ada+C, la formation à laquelle
> je pense a remplacé Ada par Java...
Pourquoi pas. A l'époque actuelle, remplacer Ada par Java me paraît une
bonne chose.
>
>>>> On pourrait restreindre le sujet à : comment on aborde la programmation
>>>> au début. Ce qui correspond à ma première question : par quoi on commence ?
>>> Variable, sequence, test, boucle.
>> En pseudo-code au tout début ou directement dans un langage ? si oui,
>> quel langage , (je penche toujours pour Ada, mais je suis peut-être
>> influencé par les milieux et les applications que j'ai fréquentées :
>> essentiellement des très grosses applis toujours > à 200 à 300 KLOC)
>
> Ce furent de longues discussions avec un collègue.
> J'était très content de Pascal, mais la disponibilité du compilo
> laisse à désire.
> J'aime beaucoup Ada, mais le collègue trouvait le traitement des E/S
> rebuttant pour les débutants.
C'est vrai que les E/S ne sont pas le must en Ada mais ça me semble un
défaut mineur par rapport à ses avantages.
De toute façon, le "noyau" du langage Java n'est pas très difficile à
appréhender (moins que C++ à mon avis). Aujourd'hui, ce qui compte
surtout c'est la maîtrise des librairie car on réutilise beaucoup et ça
c'est difficile à enseigner compte tenu du temps disponible dans un
cursus. Il faut donc insister, dans l'enseignement, sur la façon de
d'utiliser et de réutiliser des librairies existantes plus que de se
focaliser sur les détails de telle ou telle qui relève de
l'apprentissage en entreprise en fonction des besoins.
>
>>>> Oui mais pour débuter, quel que soit l'objectif final ou la cible métier.
>>> C'est là que je ne suis pas d'accord. L'objectif importe dès le début.
>> Finalement tu a certainement raison. Et pour les administrateurs ? du
>> Shell ?
>
> Existe-il quelque part une formation spécifique pour les Admins ?
> J'ai toujours eut l'impression que c'était des informaticiens généralistes
> formés à l'admin sur le tas.
Hélas !
Marc Boyer
> Marc Boyer a écrit :
>> On 2009-02-06, Wykaaa <wyk...@yahoo.fr> wrote:
>>> Marc Boyer a écrit :
>>>> Ben non, je ne pense pas.
>>>> Tient, si tu as du temps dans l'ensemble de ta formation pour
>>>> voir 4-5 langages, tu peux commencer par un langage un peu marginal
>>>> (Caml, Pascal, python, Ada) puis aborder des langages mainstream ensuite
>>>> (C, C++, Java).
>>> Si on a le temps, c'est effectivement ce qu'il faut faire.
>>>
>>> Au début des années 90, j'avais expérimenté l'apprentissage de la
>>> programmation avec Ada (en remplacement de Pascal parce qu'il y a les
>>> packages qui sont propres en Ada) et ensuite on passait au C en disant
>>> que l'équivalent d'un package Ada c'était un .h et un .c. Du coup les
>>> participants programmaient très proprement en C car ils avaient pris de
>>> bonnes habitudes avec Ada.
>>
>> Pareil.
>> Mais l'arrivée de Java a changé la donne: obligé de faire C et Java
>> dans le volume dans lequel tenait Ada+C, la formation à laquelle
>> je pense a remplacé Ada par Java...
>
> Pourquoi pas. A l'époque actuelle, remplacer Ada par Java me paraît une
> bonne chose.
Mais Java ne permet qu'un type de passage de paramètre sur les
types utilisateurs (struct/objet)...
Java sans la POO, c'est pas facile.
La POO avant l'algorithmique, j'ai du mal à voir.
> De toute façon, le "noyau" du langage Java n'est pas très difficile à
> appréhender (moins que C++ à mon avis). Aujourd'hui, ce qui compte
> surtout c'est la maîtrise des librairie car on réutilise beaucoup et ça
> c'est difficile à enseigner compte tenu du temps disponible dans un
> cursus. Il faut donc insister, dans l'enseignement, sur la façon de
> d'utiliser et de réutiliser des librairies existantes plus que de se
> focaliser sur les détails de telle ou telle qui relève de
> l'apprentissage en entreprise en fonction des besoins.
C'est extrèmement compliqué.
D'un côté, il faut passer par la programmation de liste, chaine de
caractère, vecteur.
Dans la vraie vie, il faut ré-utiliser.
Là ou j'enseigne actuellement, la fin du cursus prog fini (en Java)
en les invitant à utiliser ces qui existe et en tapant sur les doigts
quand ils prennent une liste quand il fallait une map.
Pascal J. Bourguignon
> Mihamina Rakotomandimby (R12y) a écrit :
>> Marc Boyer wrote:
>>>> Finalement tu a certainement raison. Et pour les administrateurs ?
>>>> du Shell ?
>>> Existe-il quelque part une formation spécifique pour les Admins ?
>>> J'ai toujours eut l'impression que c'était des informaticiens
>>> généralistes
>>> formés à l'admin sur le tas.
>> Un bon admin système UNIX sait packager et donc patcher du code.
>> Je dirais que pour la branche UNIX, le C est à aborder tres tot.
>> Moi j'ai manqué le train du C à la Fac, je le regrette amèrement
>> aujourd'hui.
>> Apres, en général, un admin reprend du code, il en crée rarement.
>> Donc pour lui c'est plutot apprendre à lire le code de quelqu'un
>> qu'il lui faut.
> Ton intervention est très intéressante car je me suis toujours posé la
> question : que faut-il apprendre de la programmation pour les
> administrateurs ?
Disons que tous les informaticiens doivent être capables de
programmer, car ils doivent le faire tous plus ou moins (mais surtout
dans des différents langages).
> Je relève tout de même que packager et patcher ce n'est pas tout à
> fait la même chose.
> Dans un environnement Unix, pour les admins, il faut donc leur
> apprendre le C et le Shell, est-ce cela ?
Oui. Tous les admins passent leur temps à écrire des scripts shells
(et donc, sed, awk, perl, et certains même Scheme ou Common Lisp).
Certains admins écrivent même des outils en C (qui finissent parfois
par être utilisés par tout le monde).
> Je suis d'accord avec toi pour dire qu'ils doivent essentiellement
> savoir lire du code et que, donc, la pédagogie peut être un peu
> différente (mais pas tant que ça). La différence se fera
> principalement au niveau des exercices il me semble.
Tous les programmeurs doivent être capable de lire du code. Il est
même recommandé de lire beaucoup de _bon_ code pour apprendre à
programmer. (Pour ma part, j'ai plutôt une approche constructiviste
en programmation, alors je n'ai jamais lu beaucoup de code (je n'ai
pas forcément trouvé beaucou de bon code il faut dire)).
En fait, d'une manière générale, je crois que dans la société
actuelle, il faudrait que tous les enfants apprennent à programmer
pour leur culture générale, comme ils apprennent à calculer une
dérivée. Bien entendu, il n'est pas question d'apprendre du C, ni
même du Basic ou du Common Lisp. Il faudrait concevoir un langage
d'enseignement spécifique, permettant de comprendre ce qu'est la
programmation sans entrer dans les détails (et sans forcément pouvoir
l'utiliser pour développer des vrais applications). Peut être quelque
chose dérivé de scheme.
Si le grand public avait une petite idée de ce qu'est la programmation
on aurait des demandes plus réalistes de la part des utilisateurs.
Cette initiation pourrait aussi susciter des vocations.
--
__Pascal Bourguignon__
Wykaaa
Ben oui, c'est pas fait pour !
C'est peut-être un peu radical mais la programmation aujourd'hui,
peut-elle encore se faire sans passer par l'objet ?
> La POO avant l'algorithmique, j'ai du mal à voir.
L'algorithmique c'est la description de types abstraits et de leur
utilisation en fonction des algorithmes qu'on veut développer.
Même si, dans l'absolu, il peut y avoir des exceptions, un type abstrait
s'implémente par une classe, donc où est le problème ?
On peut commencer la POO avant l'algorithmique en montrant des objets
simples comme la pile LIFO.
On peut même commencer la POO en montrant l'héritage, le polymorphisme
avec l'exemple d'un compte bancaire (avec les méthodes ouvrir, débiter,
créditer, supprimer) en faisant des sous-classes compte non rémunéré,
compte rémunéré, etc. avec des calculs d'intérêts différents. Je l'ai
fait, ça marche très bien.
Evidemment on ne va pas commencer les TP de POO en faisant faire la
classes des arbres d'arité n-aire !
>
>> De toute façon, le "noyau" du langage Java n'est pas très difficile à
>> appréhender (moins que C++ à mon avis). Aujourd'hui, ce qui compte
>> surtout c'est la maîtrise des librairie car on réutilise beaucoup et ça
>> c'est difficile à enseigner compte tenu du temps disponible dans un
>> cursus. Il faut donc insister, dans l'enseignement, sur la façon de
>> d'utiliser et de réutiliser des librairies existantes plus que de se
>> focaliser sur les détails de telle ou telle qui relève de
>> l'apprentissage en entreprise en fonction des besoins.
>
> C'est extrèmement compliqué.
> D'un côté, il faut passer par la programmation de liste, chaine de
> caractère, vecteur.
Je vais être un peu extrêmiste (bien que j'ai fait aussi des cours
d'algo sur les structures de données classiques, illustrées en Ada).
Aujourd'hui, aucun développeur ne devrait coder des algorithmes de tri,
de recherche, de liste, d'arbre, etc. Tout ceci existe. C'est un peu
comme si on se préoccupait encore de la gestion des registres en
programmation.
De ce point de vue, les cursus mériteraient un grand coup de balai...
Construire une application, aujourd'hui, c'est surtout un travail
d'ensemblier, d'intégrateur où le développeur choisi les abstractions
adéquates pour représenter les objets proches de la machines qui
correspondent à son problèmes et il met la sauce autour pour répondre
aux besoins des clients.
Les concepteurs doivent concevoir les objets et les processus métiers et
donner des indications sur la transition vers "la machinerie
informatique" c'est-à-dire indiquer quelles sont les structures de
données les plus adéquates pour représenter les objets métiers.
> Dans la vraie vie, il faut ré-utiliser.
Tout à fait
> Là ou j'enseigne actuellement, la fin du cursus prog fini (en Java)
> en les invitant à utiliser ces qui existe et en tapant sur les doigts
> quand ils prennent une liste quand il fallait une map.
Ca correspond un peu à ce que je disais plus haut. Cela ne me choque pas
car c'est comme ça dans la vraie vie...
Wykaaa
> On Fri, 06 Feb 2009 17:19:50 +0100, Wykaaa wrote:
>> Ton intervention est très intéressante car je me suis toujours posé la
>> question : que faut-il apprendre de la programmation pour les
>> administrateurs ?
>> Je relève tout de même que packager et patcher ce n'est pas tout à fait
>> la même chose.
>
> qu'indirectement lié. patcher requiert juste de savoir se servir de
> patch et packager cela dépend de ce que l'on package et sous quelle
> forme. C'est plutôt lié à des outils précis qu'à du développement.
> Il m'est déjà arrivé de patcher sur autre chose que du code, et de
> packager avant même de savoir coder.
J'avoue que packager avant de savoir coder, ça me laisse perplexe...
>
>> Dans un environnement Unix, pour les admins, il faut donc leur apprendre
>> le C et le Shell, est-ce cela ?
>
> Même en étant simple user, l'usage basique du shell est obligatoire !
> Pour un admin il a intérêt à être bien à l'aise avec son shell, et au
> fait qu'il existe différentes « familles » de shell qui différent dans
> leur fonctionnement.
Là je suis totalement d'accord.
>
> Le C n'est selon moi pas obligatoire, mais super utile. Cela peut
> aider à comprendre comment fonctionne son OS, comprendre des traces de
> debug, se plonger dans les sources d'un service qu'on administre pour
> en comprendre un comportement non-documenté...
Tu te places dans le contexte d'un OS écrit en C ?
Tous ne sont pas écrits dans ce langage.
>
>> Je suis d'accord avec toi pour dire qu'ils doivent essentiellement
>> savoir lire du code et que, donc, la pédagogie peut être un peu
>> différente (mais pas tant que ça). La différence se fera principalement
>> au niveau des exercices il me semble.
>
> Là je ne suis pas vraiment d'accord, car selon moi pour savoir *bien*
> lire du code, il faut déjà savoir l'écrire. De plus, tout au long des
> tâches d'admin qui m'ont été confiées, j'estime que j'ai pissé beaucoup
> plus de code que j'en ai lu. Ce n'était que rarement du gros dev mais
> on pond un nombre incalculable de scripts sh, perl, ruby...
C'est bien ce qu'il me semblait. Il n'y aurait donc, selon toi, pas de
différence spécifique dans la pédagogie d'apprentissage de la
programmation pour les admins ?
Rien qu'à la lumière de ce début de discussion, on s'aperçoit que les
situations sont très diverses, même pour une même profession...
Wykaaa
> On Fri, 06 Feb 2009 18:33:44 +0100, Wykaaa wrote:
>> J'avoue que packager avant de savoir coder, ça me laisse perplexe...
>
> simple en tête qui m'ai déjà arrivé en tant qu'admin :
>
> Un admin peut avoir besoin de déployer régulièrement des outils ou
> données qui n'existent pas dans le système de paquets de l'UNIX utilisé
> sur différentes machines. Dans ce cas il peut s'avérer préférable de
> packager pour gagner du temps soit-même ou faciliter la vie des autres
> admins.
Je pensais à packager au sens de packager du code (ce qui se fait en
programmation système).
>
> C'est dans ce genre de situation que je disais avoir packagé avant de
> savoir développer.
J'ai compris tes explications. Merci
>
>>> Le C n'est selon moi pas obligatoire, mais super utile. Cela peut
>>> aider à comprendre comment fonctionne son OS, comprendre des traces de
>>> debug, se plonger dans les sources d'un service qu'on administre pour
>>> en comprendre un comportement non-documenté...
>> Tu te places dans le contexte d'un OS écrit en C ?
>
> En fait je pensais juste à un UNIX « connu », un BSD, GNU/Linux ou
> autre, en tout cas moi c'est ceux auxquels j'ai été confrontés.
>
>> Tous ne sont pas écrits dans ce langage.
>
> Je pensais que les *nix étaient majoritairement écrits en C, mais
> peut-être à tord ?
Non ça c'est vrai ou à peu près. Mac OS est codé en Objective-C et
Chorus Système en C++ à 95%.
Mais Multics (dont Unix s'est beaucoup inspiré et qui peut être
considéré comme son ancêtre) était codé en... PL/1.
GCOS7 de BULL est codé en HPL (un pseudo-PL/1).
MVS d'IBM est codé en PLM (aussi un pseudo-PL/1).
>
> En plus c'est vrai que de nos jours de plus en plus de services sont
> écrits dans des langages différents, voir exotiques.
Tu penses à quels langages exotiques ?
>>> Là je ne suis pas vraiment d'accord, car selon moi pour savoir *bien*
>>> lire du code, il faut déjà savoir l'écrire. De plus, tout au long des
>>> tâches d'admin qui m'ont été confiées, j'estime que j'ai pissé beaucoup
>>> plus de code que j'en ai lu. Ce n'était que rarement du gros dev mais
>>> on pond un nombre incalculable de scripts sh, perl, ruby...
>> C'est bien ce qu'il me semblait. Il n'y aurait donc, selon toi, pas de
>> différence spécifique dans la pédagogie d'apprentissage de la
>> programmation pour les admins ?
>
> Cet avis n'engage que moi et je ne suis pas pédagogue, mais
> effectivement, je ne pense pas que la pédagogie devrait différer, en
> tout cas pour les bases.
>
> Cependant si la formation est ciblée pour les admins, c'est sûr que
> les sujets devraient être adaptés. Par exemple peut-être qu'il n'est pas
> utile d'apprendre de suite la programmation OO car ce n'est pas ce qui
> servira le plus au quotidien. Par contre des petits exercices avec le
> shell seraient super pour commencer, ça couvre un certain nombre de
> notions de programmation de base (au moins les concept), c'est assez
> « interactif », et l'aide est accessible facilement.
Tout à fait d'accord avec toi.
>
>> Rien qu'à la lumière de ce début de discussion, on s'aperçoit que les
>> situations sont très diverses, même pour une même profession...
>
> Oui je pense que suivant les différents contextes les besoins (en
> formation) ne sont pas les même. J'ai rencontré certains admins qui ne
> codent pas du tout et installent en tout premier package webmin ou autre
> et après fuiront le shell, je n'aime pas trop mais c'est un autre débat.
> De plus ces derniers n'auront donc pas un besoin en formation de
> programmation pour les admins.
>
> Un admin UNIX peut faire pas mal de choses sympa sans savoir coder et
> avec un usage basique du shell, mais arriveront des situations où ça
> l'aidera de savoir coder, ou le nécessitera !
Il me semble que pour être un admin Unix digne de ce nom et reconnu, la
connaissance assez précise du Shell est une nécessité (et même de
quelques unes de ses variantes).
Wykaaa
> On Fri, 06 Feb 2009 21:47:10 +0100, Wykaaa wrote:
>> Je pensais à packager au sens de packager du code (ce qui se fait en
>> programmation système).
>
> vraiment mis :-)
Non, non, je parle du packaging que peuvent faire les développeurs
système dans les couches basses d'un OS (comme les E/S physiques, le job
scheduling (séquenceur) ou la gestion mémoire (virtuelle en
particulier). Ca se fait quasiment à la main. Par exemple, on répartira
des bouts de code dans différents segments mémoire, sur une machine à
segment, en fonction de leur "localité).
>
>>> Je pensais que les *nix étaient majoritairement écrits en C, mais
>>> peut-être à tord ?
>> Non ça c'est vrai ou à peu près. Mac OS est codé en Objective-C et
>> Chorus Système en C++ à 95%.
>>
>> Mais Multics (dont Unix s'est beaucoup inspiré et qui peut être
>> considéré comme son ancêtre) était codé en... PL/1.
>> GCOS7 de BULL est codé en HPL (un pseudo-PL/1).
>> MVS d'IBM est codé en PLM (aussi un pseudo-PL/1).
>
> Merci pour la précision !
>
>>> En plus c'est vrai que de nos jours de plus en plus de services sont
>>> écrits dans des langages différents, voir exotiques.
>> Tu penses à quels langages exotiques ?
>
> Par exemple Erlang, ce en quoi est développé ejabberd. Quand je dis
> exotique c'est pas péjoratif, juste que je pense qu'un admin est moins
> confronté à ces langages (mais pourrait l'être de plus en plus à
> l'avenir). Perso je n'y connais rien en Erlang, mais jusqu'à maintenant
> pas eu besoin de mettre les mains dans ejabberd donc ça me dérange pas
> plus que ça mais surtout j'ai d'autres chats à fouetter.
Erlang est un très bon langage pour faire ce qu'il adresse (langage
fonctionnel concurrent, temps réel et distribué basé sur le modèle
d'acteur). Il faut dire que j'ai une préférence pour les langages
fonctionnels ;-)
Ceci dit, je ne suis pas certain que la connaissance d'Erlang soit
indispensable, loin de là, à un administrateur système.
Bruno Desthuilliers
(snip).
>
> Je ne parlais de pédagogie que pour les débutants en programmation, pas
> des cours d'approfondissement.
> Quand on démarre l'apprentissage, ça doit être, grossièrement, pour tout
> le monde pareil.
Bin non. Ca dépend de la personne qui apprend, de son "profil", de son
parcours, de sa façon d'apprendre, bref il n'y a pas de "taille unique".
Bruno Desthuilliers
(snip)
> Dans un environnement Unix, pour les admins, il faut donc leur apprendre
> le C et le Shell, est-ce cela ?
Le shell est indispensable. Le C est tellement intimement lié à unix
qu'il est difficile de faire l'impasse dessus, mais on ne demande pas à
un admin d'avoir une grande maîtrise de ce langage. Un langage
applicatif de haut niveau sera plus utile pour les cas les scripts shell
montrent leurs limites - Perl à longtemps tenu ce rôle, mais il semble
être de plus en plus supplanté par Python.
Wykaaa
J'avais peut-être un autre pseudo à l'époque.
Je parlais du contenu du cursus. Quand tu fais cours à 10 ou 20
étudiants ou plus, tu ne peux pas tenir compte du "profil" de chacun. Ca
ne peut se réguler (un peu) qu'en TP, hélas...
Bruno Desthuilliers
> Bruno Desthuilliers a écrit :
>> Wykaaa a écrit :
>> (snip).
>>>
>>> Je ne parlais de pédagogie que pour les débutants en programmation,
>>> pas des cours d'approfondissement.
>>> Quand on démarre l'apprentissage, ça doit être, grossièrement, pour
>>> tout le monde pareil.
>>
>> Bin non. Ca dépend de la personne qui apprend, de son "profil", de son
>> parcours, de sa façon d'apprendre, bref il n'y a pas de "taille unique".
>>
> Bonjour Bruno. On s'est déjà causé à propos de Python ;-)
Oui, je sais. Ma mémoire vaut (encore) un peu mieux que celle d'un
poisson rouge !-)
> Je parlais du contenu du cursus. Quand tu fais cours à 10 ou 20
> étudiants ou plus, tu ne peux pas tenir compte du "profil" de chacun.
Non, mais généralement, il y a un minimum d'homogénéité dans ce groupe -
ça peut être par exemple un groupe de matheux, ou un groupe
d'électroniciens. Et il est probable que les premiers se trouvent 'en
moyenne) plus à l'aise avec un langage fonctionnel de haut niveau, et
les seconds (toujours en moyenne) avec un langage procédural de bas niveau.
Wykaaa
discussion mais aussi du fil "Pédagogie : C++ ou Java ?" dans
fr.comp.lan.c++.
Merci de me dire si j'ai oublié des points importants ou si je n'ai pas
rapporté fidèlement certaines de vos pensées.
Je constate d'ailleurs que la discussion, c'est normal sur ce genre de
sujet même si ça le parasite, tourne plutôt autour du choix d'un langage
ou de langages pour apprendre la programmation qu'autour des concepts et
de la pédagogie proprement dite.
Alors allons-y sur le choix du langage pour apprendre la programmation :
Il semble que le choix du premier langage se situe quasi exclusivement
entre C++ et Java.
* Premier langage :
=>C++
Certains jugent plus riche le langage C++, donc c'est lui qu'il faut
prendre bien que certains traits doivent être abordés dans un second
temps comme la gestion mémoire ou l'héritage multiple, voire la
surcharge des opérateurs.
D'autres, dont je suis, jugent qu'il est justement trop riche et que le
débutant risque d'être noyé par cette richesse.
Pour le Web, la majorité d'entre vous jugent que C++ n'est pas adéquat.
=>Java
Les avantages qui sont recensés en faveur de Java comme premier langage
sont :
- une plus grande simplicité que C++
- Java peut être facilement utilisé dans un contexte Web, ce qui n'est
pas le cas de C++
- Certains avancent la pérennité de Java, je cite : "il y aura encore
des programmes Java dans 30 ans", comme le COBOL aujourd'hui
- Sur le marché, aujourd'hui, un programmeur doit connaître Java
- mise en oeuvre facile de la programmation concurrente avec le
threading (c'est moi qui rajoute)
Au niveau des inconvénients :
- On peut écrire un peu n'importe comment en Java et essayer jusqu'à ce
que ça marche. C'est plus difficile en C++
- Il y a des concepts de programmation qu'on n'aborde pas en Java comme
l'héritage multiple, la gestion mémoire, la surcharge des opérateurs
* Quel langage après le premier ?
Alors là, je dois dire que c'est, pour le moins, le bazar car la pluaprt
des participants aux discussion se mettent à prendre en compte le
contexte (ce n'est pas un reproche, au contraire)
Les langages cités varient donc suivants les contextes :
- Pour les grosses applications (hors Web) : soit C++, soit Java suivant
que le premier langage était l'un ou l'autre
- Pour le Web : Perl, Python, Ruby, JavaScript (l'ordre n'est pas
significatif). certains parle également de PHP côté serveur et
Flash/Flex côté client.
- Pour les administrateurs : Shell et C. Certains parlent aussi de Perl,
Python voire Erlang et Scheme
* De quoi faut-il parler "à côté" de la programmation pour bien comprendre
Là, des étudiants (pas assez nombreux à mon goût, hélas) entrent en
scène et c'est intéressant car, tous les deux mentionnent que voir
l'architecture d'une machine et un peu d'assembleur permet de mieux
comprendre certains concepts de programmation, même pour les langages de
haut niveau.
En amont de la programmation, l'un d'entre eux parle de UML comme aide à
la compréhension de la programmation objet (en l'occurence C++)
Certains insistent sur le fait, qu'un véritable programmeur, doit avoir
vu de la programmation procédurale (non objet), de la programmation
objet (et pas seulement des langages "avec les classes" mais d'autres
modèles) et de la programmation fonctionnelle.
* Mon avis personnel
Puisqu'on est parti des langages, je propose le cheminement suivant :
Java -> C++ -> Python -> C
Je considère que le Shell (la programmation Shell, je veux dire) est vu
en parallèle mais après avoir une première expérience de la
programmation, donc après Java.
Pour C++, ne voir que les traits de langages "non Java"
En suivant ce cheminement, C devrait être "expédié en peu de temps.
En parallèle il faut un cours d'architecture des machines (plus ou moins
détaillé suivant les objectifs métier cibles) et un cours de conception
objet (je ne suis pas sûr qu'il faut, dans tous les cursus, un cours
d'UML. Dans certains cursus, il faut probablement surtout exposer les
principes de COO : abstraction, encapsulation, modularité hiérarchie
(i.e. héritage, composition, agrégation), ainsi que les concepts de
typage, de persistance et de concurrence.
Python permet de voir des aspects de la programmation fonctionnelle (je
sais que certains vont me taper dessus).
Pour la programmation fonctionnelle, s'il faut la détailler pour
certaines cibles, je suis partisan de Ocaml (normalement, ça devrait
permettre de comprendre ensuite la plupart des langages fonctionnels).
* Questions non résolues
- Les bases des bases de la programmation, à savoir : variables,
constantes, litéraux, séquence, itératives, alternatives, récursion
s'apprennent-t-elles directement avec un langage ou en "pseudo-code ?
- Quid des aspects qualité logicielle, bonnes pratiques, "programmer
proprement, etc. ?
- Liaison conception, programmation, tests (vaste sujet)
- Articulation programmation/algorithmique (autre vaste sujet) ?
Bonne semaine à tous :-)
Gilles
498f21c2$0$18391$ba4a...@news.orange.fr...
> Dans cette première synthèse, je tiens compte du présent fil de discussion
> mais aussi du fil "Pédagogie : C++ ou Java ?" dans fr.comp.lan.c++.
>
Merci beaucoup d'avoir fait cette synthèse, je comptais tenter d'en faire
autant prochainement pour moi et mes collègues, j'ai maintenant grâce à
votre travail une bonne base pour nourrir nos discussions à venir. Merci
aussi à tous ceux qui ont argumenté sur le fil "Pédagogie : C++ ou Java ?"
sur l'autre forum (j'avais vu l'invite à venir sur ce forum malheureusement
juste après avoir posté mon message initial...)
Je note que bien que cette première discussion se soit déroulée sur un forum
C++, les intervenants sont suffisamment objectifs pour avoir donné (au moins
pour cette question pédagogique) la première place au Java ;o)
> * Questions non résolues
> - Les bases des bases de la programmation, à savoir : variables,
> constantes, litéraux, séquence, itératives, alternatives, récursion
> s'apprennent-t-elles directement avec un langage ou en "pseudo-code ?
Vous précédez mes propres questions : je voulais justement en venir à cette
même interrogation, concernant le langage utilisé pour les "bases de la
programmation" et aussi l'algorithmique. Dans mon IUT nous sommes passés
l'an dernier d'un pseudo-code (basé sur le français) au C++ (langage utilisé
jusque cette année pour la POO) avec comme principale justification de ne
pas ajouter (en début de cursus) un langage de plus pour les étudiants
(langage complètement "maison" qui plus est), et de tenter de leur faciliter
du même coup la mémorisation des mots clés et structures du C++ (utilisé de
fait dans deux matières). Si nous passons à Java pour la POO, la question du
pseudo-code va revenir d'actualité puisqu'il serait sûrement malvenu de
conserver le C++ en parallèle en première année.
Merci d'avance pour vos contributions sur ces questions et d'autres, et
bonne semaine.
Gilles
Marc Espie
Marc Boyer <Marc....@cert.onera.fr.invalid> wrote:
> Tient, si tu as du temps dans l'ensemble de ta formation pour
>voir 4-5 langages, tu peux commencer par un langage un peu marginal
>(Caml, Pascal, python, Ada) puis aborder des langages mainstream ensuite
>(C, C++, Java).
Mais quel est l'interet d'aborder un langage procedural/objet (pascal, python,
ada) si tu vas refaire du procedural/objet derriere ?
Au moins, caml est un peu plus sense comme choix, meme si perso, s'il s'agit
d'ouvrir un peu les etudiants, je serais plus penche vers scheme (parce que
pas de soucis de syntaxe contrairement a caml), prolog, ou smalltalk (oui,
c'est de l'objet, mais tres eloigne du monde C++/Java).
Marc Espie
Wykaaa <wyk...@yahoo.fr> wrote:
>Je suis d'accord avec toi pour dire qu'ils doivent essentiellement
>savoir lire du code et que, donc, la pédagogie peut être un peu
>différente (mais pas tant que ça). La différence se fera principalement
>au niveau des exercices il me semble.
tout developpeur doit savoir lire du code.
Ca evite le syndrome du mec qui debarque sur un gros projet et qui veut
tout reecrire "parce que c'est pas comme ca qu'il aurait fait".
Jean-Marc Bourguet
> tout developpeur doit savoir lire du code.
>
> Ca evite le syndrome du mec qui debarque sur un gros projet et qui veut
> tout reecrire "parce que c'est pas comme ca qu'il aurait fait".
Ca me rappelle quelque chose...
Broken: Having seen what other designers/programmers have done,
I think I can now do better.
-- P.J. Plauger
A+
--
Jean-Marc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Marc Boyer
> In article <slrngoo8kr.m...@gavarnie.cert.fr>,
> Marc Boyer <Marc....@cert.onera.fr.invalid> wrote:
>> Tient, si tu as du temps dans l'ensemble de ta formation pour
>>voir 4-5 langages, tu peux commencer par un langage un peu marginal
>>(Caml, Pascal, python, Ada) puis aborder des langages mainstream ensuite
>>(C, C++, Java).
>
> Mais quel est l'interet d'aborder un langage procedural/objet (pascal, python,
> ada) si tu vas refaire du procedural/objet derriere ?
1) parce que ça évite d'avoir à présenter le même langage de deux façons
distinctes (une fois le ss ensemble procédural, une fois l'ensemble) ce
qui perd souvent les étudiants
2) parce que c'est bien de voir différents langages
> Au moins, caml est un peu plus sense comme choix, meme si perso, s'il s'agit
> d'ouvrir un peu les etudiants, je serais plus penche vers scheme (parce que
> pas de soucis de syntaxe contrairement a caml), prolog, ou smalltalk (oui,
> c'est de l'objet, mais tres eloigne du monde C++/Java).
Prolog ? C'est intéressant Prolog, mais je ne vois pas comment s'en
servir pour présenter la prog procédurale avec.
Wykaaa
crayons, c'est nous-mêmes qui avons dit : maintenant on sait comment il
aurait fallu faire...
Il faut bien se rendre compte que chaque logiciel construit est un
prototype puisqu'il n'y a pas de fabrication en série (on duplique
seulement).
Jean-Marc Bourguet
> Sauf que je me rappelle, sur un gros projet système, quand on a posé les
> crayons, c'est nous-mêmes qui avons dit : maintenant on sait comment il
> aurait fallu faire...
Plan to make it twice, you'll anyway. The only question is if you'll try
to sell the first version. -- Brooks
Et sur le web qqun a ajoute "Si vous planifiez de le faire deux fois, il en
faudra trois".
Marc Boyer
En tout cas, on ne peut pas former un programmeur sans le
former en POO.
>> La POO avant l'algorithmique, j'ai du mal à voir.
>
> L'algorithmique c'est la description de types abstraits et de leur
> utilisation en fonction des algorithmes qu'on veut développer.
Ou, ça fait bien longtemps que tu n'as pas vu de débutant.
Tu sais, des gens qui ne savent pas trouver le minimum dans un
tableau de taille 10, ou faire la somme et la moyenne
en une seule boucle...
> On peut commencer la POO avant l'algorithmique en montrant des objets
> simples comme la pile LIFO.
T'a déjà introduit les tableaux là.
> On peut même commencer la POO en montrant l'héritage, le polymorphisme
> avec l'exemple d'un compte bancaire (avec les méthodes ouvrir, débiter,
> créditer, supprimer) en faisant des sous-classes compte non rémunéré,
> compte rémunéré, etc. avec des calculs d'intérêts différents. Je l'ai
> fait, ça marche très bien.
Oui, nous aussi on fait ça. Et puis tu mets un livret A, qui n'a
pas le droit d'être à découvert, et qui viole le principe de subsitution
de Lipscov (on utilisait pas ce gros mot, mais on rajoutait une
exception, et le compilo ralait...).
>>> De toute façon, le "noyau" du langage Java n'est pas très difficile à
>>> appréhender (moins que C++ à mon avis). Aujourd'hui, ce qui compte
>>> surtout c'est la maîtrise des librairie car on réutilise beaucoup et ça
>>> c'est difficile à enseigner compte tenu du temps disponible dans un
>>> cursus. Il faut donc insister, dans l'enseignement, sur la façon de
>>> d'utiliser et de réutiliser des librairies existantes plus que de se
>>> focaliser sur les détails de telle ou telle qui relève de
>>> l'apprentissage en entreprise en fonction des besoins.
>>
>> C'est extrèmement compliqué.
>> D'un côté, il faut passer par la programmation de liste, chaine de
>> caractère, vecteur.
>
> Je vais être un peu extrêmiste (bien que j'ai fait aussi des cours
> d'algo sur les structures de données classiques, illustrées en Ada).
> Aujourd'hui, aucun développeur ne devrait coder des algorithmes de tri,
> de recherche, de liste, d'arbre, etc. Tout ceci existe.
Sauf que dans certains langage (genre C), ça prend plus de temps
de rechercher le bout de code qui fait ce que tu veux, de vérifier
qu'il fait ce que tu veux, que de le faire soit même.
> De ce point de vue, les cursus mériteraient un grand coup de balai...
Sauf que pour comprendre la différence entre sdt::list et std::vector,
ben, c'est aussi bien de les avoir codé. Même si l'enseignant explique
dès le début du TP que ce qu'on code dans l'exo existe déjà.
De toute façon, 90% des sujets de TP existent déjà en mieux ailleurs
(passer à la date du lendemain, rechercher le min dans un tableau,
coder un mini vi...)
> Construire une application, aujourd'hui, c'est surtout un travail
> d'ensemblier, d'intégrateur où le développeur choisi les abstractions
> adéquates pour représenter les objets proches de la machines qui
> correspondent à son problèmes et il met la sauce autour pour répondre
> aux besoins des clients.
Mais le type qui fait ça, il a quand même appris à coder un jour.
Wykaaa
C'est en fait ce que je voulais dire :-)
>
>>> La POO avant l'algorithmique, j'ai du mal à voir.
>> L'algorithmique c'est la description de types abstraits et de leur
>> utilisation en fonction des algorithmes qu'on veut développer.
>
> Ou, ça fait bien longtemps que tu n'as pas vu de débutant.
> Tu sais, des gens qui ne savent pas trouver le minimum dans un
> tableau de taille 10, ou faire la somme et la moyenne
> en une seule boucle...
Aïe, j'ai un peu oublié en effet...
>
>> On peut commencer la POO avant l'algorithmique en montrant des objets
>> simples comme la pile LIFO.
>
> T'a déjà introduit les tableaux là.
Ou l'allocation dynamique, ce qui n'est pas "mieux", je l'avoue...
>
>> On peut même commencer la POO en montrant l'héritage, le polymorphisme
>> avec l'exemple d'un compte bancaire (avec les méthodes ouvrir, débiter,
>> créditer, supprimer) en faisant des sous-classes compte non rémunéré,
>> compte rémunéré, etc. avec des calculs d'intérêts différents. Je l'ai
>> fait, ça marche très bien.
>
> Oui, nous aussi on fait ça. Et puis tu mets un livret A, qui n'a
> pas le droit d'être à découvert, et qui viole le principe de subsitution
> de Lipscov (on utilisait pas ce gros mot, mais on rajoutait une
> exception, et le compilo ralait...).
Justement, c'est un très bon exemple et ça montre qu'il y avait au moins
une "catégorie" de compte qu'on avait oublié.
Autre exemple : les oiseaux. En général on va coller dans la classe une
méthode voler(), et une méthode fuir() qui utilisera voler(). Sauf que
tous les oiseaux ne volent pas (pingouins, autruche, par exemple). Et
que l'autruche, devant le danger, ne va donc pas voler mais mettre la
tête dans le sable (tiens, elle est où cette méthode ?). J'aime bien cet
exemple ;-)
>
>>>> De toute façon, le "noyau" du langage Java n'est pas très difficile à
>>>> appréhender (moins que C++ à mon avis). Aujourd'hui, ce qui compte
>>>> surtout c'est la maîtrise des librairie car on réutilise beaucoup et ça
>>>> c'est difficile à enseigner compte tenu du temps disponible dans un
>>>> cursus. Il faut donc insister, dans l'enseignement, sur la façon de
>>>> d'utiliser et de réutiliser des librairies existantes plus que de se
>>>> focaliser sur les détails de telle ou telle qui relève de
>>>> l'apprentissage en entreprise en fonction des besoins.
>>> C'est extrèmement compliqué.
>>> D'un côté, il faut passer par la programmation de liste, chaine de
>>> caractère, vecteur.
>> Je vais être un peu extrêmiste (bien que j'ai fait aussi des cours
>> d'algo sur les structures de données classiques, illustrées en Ada).
>> Aujourd'hui, aucun développeur ne devrait coder des algorithmes de tri,
>> de recherche, de liste, d'arbre, etc. Tout ceci existe.
>
> Sauf que dans certains langage (genre C), ça prend plus de temps
> de rechercher le bout de code qui fait ce que tu veux, de vérifier
> qu'il fait ce que tu veux, que de le faire soit même.
Oui mais bon. J'ai toujours pensé que si la réutilisation ne s'est
jamais développé comme elle aurait du, c'était d'abord à cause d'un
manque d'organisation et de logistique justement...
>
>> De ce point de vue, les cursus mériteraient un grand coup de balai...
>
> Sauf que pour comprendre la différence entre sdt::list et std::vector,
> ben, c'est aussi bien de les avoir codé. Même si l'enseignant explique
> dès le début du TP que ce qu'on code dans l'exo existe déjà.
> De toute façon, 90% des sujets de TP existent déjà en mieux ailleurs
> (passer à la date du lendemain, rechercher le min dans un tableau,
> coder un mini vi...)
Il faut en faire un peu mais pas passer son temps à ça. Il me semble
qu'il est préférable de donner un projet pratiquement dès le début du
cursus où il faudra énormément réutiliser car, aujourd'hui, c'est cela
la réalité dans la "vraie vie". On réserve les TP pour montrer les algos
essentiels comme, par exemple le balayage d'arbre binaire de façon
récursive sous les 3 formes (préfixe, infixe, postfixe).
>
>> Construire une application, aujourd'hui, c'est surtout un travail
>> d'ensemblier, d'intégrateur où le développeur choisi les abstractions
>> adéquates pour représenter les objets proches de la machines qui
>> correspondent à son problèmes et il met la sauce autour pour répondre
>> aux besoins des clients.
>
> Mais le type qui fait ça, il a quand même appris à coder un jour.
Je n'ai jamais dit le contraire car pour choisir les abstractions
adéquates, il faut avoir un minimum (maximum ?) d'expérience de la
programmation.
Marc Boyer
> Marc Boyer a écrit :
>> On 2009-02-06, Wykaaa <wyk...@yahoo.fr> wrote:
>> En tout cas, on ne peut pas former un programmeur sans le
>> former en POO.
>
> C'est en fait ce que je voulais dire :-)
>>
>>>> La POO avant l'algorithmique, j'ai du mal à voir.
>>> L'algorithmique c'est la description de types abstraits et de leur
>>> utilisation en fonction des algorithmes qu'on veut développer.
>>
>> Ou, ça fait bien longtemps que tu n'as pas vu de débutant.
>> Tu sais, des gens qui ne savent pas trouver le minimum dans un
>> tableau de taille 10, ou faire la somme et la moyenne
>> en une seule boucle...
>
> Aïe, j'ai un peu oublié en effet...
Et bon, rien que ça, ça nous bouffait un semestre dans
ma dernière formation.
>>> On peut même commencer la POO en montrant l'héritage, le polymorphisme
>>> avec l'exemple d'un compte bancaire (avec les méthodes ouvrir, débiter,
>>> créditer, supprimer) en faisant des sous-classes compte non rémunéré,
>>> compte rémunéré, etc. avec des calculs d'intérêts différents. Je l'ai
>>> fait, ça marche très bien.
>>
>> Oui, nous aussi on fait ça. Et puis tu mets un livret A, qui n'a
>> pas le droit d'être à découvert, et qui viole le principe de subsitution
>> de Lipscov (on utilisait pas ce gros mot, mais on rajoutait une
>> exception, et le compilo ralait...).
>
> Justement, c'est un très bon exemple et ça montre qu'il y avait au moins
> une "catégorie" de compte qu'on avait oublié.
> Autre exemple : les oiseaux. En général on va coller dans la classe une
> méthode voler(), et une méthode fuir() qui utilisera voler(). Sauf que
> tous les oiseaux ne volent pas (pingouins, autruche, par exemple). Et
> que l'autruche, devant le danger, ne va donc pas voler mais mettre la
> tête dans le sable (tiens, elle est où cette méthode ?). J'aime bien cet
> exemple ;-)
Le pb des oiseaux, c'est qu'il n'est pas très informatique, et
les étudiants peuvent en conclure que la POO c'est pas fait
pour la zoologie.
>> Sauf que dans certains langage (genre C), ça prend plus de temps
>> de rechercher le bout de code qui fait ce que tu veux, de vérifier
>> qu'il fait ce que tu veux, que de le faire soit même.
>
> Oui mais bon. J'ai toujours pensé que si la réutilisation ne s'est
> jamais développé comme elle aurait du, c'était d'abord à cause d'un
> manque d'organisation et de logistique justement...
Je suis trop jeune pour avoir un avis sur l'histoire. Il y a
des aspects techniques (la généricité à base de void*, c'est
pas idéal ; il y avait peut-être des pb de perf), surement
de la psychologie aussi (je suis un vrai programmeur moi,
je code mes outils), etc.
Mais il est clair que les nouveaux langages qui arrivent
avec leur bibliothèque standard, leur doc, impulsent
la réutilisation.
>>> De ce point de vue, les cursus mériteraient un grand coup de balai...
>>
>> Sauf que pour comprendre la différence entre sdt::list et std::vector,
>> ben, c'est aussi bien de les avoir codé. Même si l'enseignant explique
>> dès le début du TP que ce qu'on code dans l'exo existe déjà.
>> De toute façon, 90% des sujets de TP existent déjà en mieux ailleurs
>> (passer à la date du lendemain, rechercher le min dans un tableau,
>> coder un mini vi...)
>
> Il faut en faire un peu mais pas passer son temps à ça. Il me semble
> qu'il est préférable de donner un projet pratiquement dès le début du
> cursus où il faudra énormément réutiliser car, aujourd'hui, c'est cela
> la réalité dans la "vraie vie". On réserve les TP pour montrer les algos
> essentiels comme, par exemple le balayage d'arbre binaire de façon
> récursive sous les 3 formes (préfixe, infixe, postfixe).
Je crois que tu es vraiment loin des débutants. Tu sais, le premier
projet (en Pascal), après un semestre, c'était un truc du genre
"bataille navalle", émulateur d'un processeur à 12 instructions,
aucune allocation dynamique, et déjà, c'est dur...
Wykaaa
> On 2009-02-09, Wykaaa <wyk...@yahoo.fr> wrote:
>> Marc Boyer a écrit :
>>> On 2009-02-06, Wykaaa <wyk...@yahoo.fr> wrote:
>>> En tout cas, on ne peut pas former un programmeur sans le
>>> former en POO.
>> C'est en fait ce que je voulais dire :-)
>>>>> La POO avant l'algorithmique, j'ai du mal à voir.
>>>> L'algorithmique c'est la description de types abstraits et de leur
>>>> utilisation en fonction des algorithmes qu'on veut développer.
>>> Ou, ça fait bien longtemps que tu n'as pas vu de débutant.
>>> Tu sais, des gens qui ne savent pas trouver le minimum dans un
>>> tableau de taille 10, ou faire la somme et la moyenne
>>> en une seule boucle...
>> Aïe, j'ai un peu oublié en effet...
>
> Et bon, rien que ça, ça nous bouffait un semestre dans
> ma dernière formation.
Ca ne m'étonne pas...
>
>>>> On peut même commencer la POO en montrant l'héritage, le polymorphisme
>>>> avec l'exemple d'un compte bancaire (avec les méthodes ouvrir, débiter,
>>>> créditer, supprimer) en faisant des sous-classes compte non rémunéré,
>>>> compte rémunéré, etc. avec des calculs d'intérêts différents. Je l'ai
>>>> fait, ça marche très bien.
>>> Oui, nous aussi on fait ça. Et puis tu mets un livret A, qui n'a
>>> pas le droit d'être à découvert, et qui viole le principe de subsitution
>>> de Lipscov (on utilisait pas ce gros mot, mais on rajoutait une
>>> exception, et le compilo ralait...).
>> Justement, c'est un très bon exemple et ça montre qu'il y avait au moins
>> une "catégorie" de compte qu'on avait oublié.
>> Autre exemple : les oiseaux. En général on va coller dans la classe une
>> méthode voler(), et une méthode fuir() qui utilisera voler(). Sauf que
>> tous les oiseaux ne volent pas (pingouins, autruche, par exemple). Et
>> que l'autruche, devant le danger, ne va donc pas voler mais mettre la
>> tête dans le sable (tiens, elle est où cette méthode ?). J'aime bien cet
>> exemple ;-)
>
> Le pb des oiseaux, c'est qu'il n'est pas très informatique, et
> les étudiants peuvent en conclure que la POO c'est pas fait
> pour la zoologie.
Ca peut être très informatique car dans un jeu vidéo, par exemple, tu ne
vas pas faire voler les vautors comme, mettons, les piafs.
>
>>> Sauf que dans certains langage (genre C), ça prend plus de temps
>>> de rechercher le bout de code qui fait ce que tu veux, de vérifier
>>> qu'il fait ce que tu veux, que de le faire soit même.
>> Oui mais bon. J'ai toujours pensé que si la réutilisation ne s'est
>> jamais développé comme elle aurait du, c'était d'abord à cause d'un
>> manque d'organisation et de logistique justement...
>
> Je suis trop jeune pour avoir un avis sur l'histoire. Il y a
> des aspects techniques (la généricité à base de void*, c'est
> pas idéal ; il y avait peut-être des pb de perf), surement
> de la psychologie aussi (je suis un vrai programmeur moi,
> je code mes outils), etc.
La généricité à base de void, même si ça peut rendre des services dans
un langage comme C qui ne la possède pas, n'est, à mon avis, pas à
recommander, du moins pour des débutants car il faut vraiment comprendre
ce que l'on fait.
> Mais il est clair que les nouveaux langages qui arrivent
> avec leur bibliothèque standard, leur doc, impulsent
> la réutilisation.
>
Je pense que c'est un problème pour l'enseignement, toutes ces
bibliothèques. Il faut malgré tout en parler en cours et surtout bâtir
un projet qui forcera à en utiliser une (petite) partie comme Liste,
Vecteur, Map en Java ou en C++. On ne parlera pas, du moins pour les
débutants, des bibliothèques concernant des choses spécifiques comme
Corba ou autre telles que des bibliothèques sophistiquées concernant les
telecoms (qui elles sont à montrer dans un cours réseau, éventuellement).
>>>> De ce point de vue, les cursus mériteraient un grand coup de balai...
>>> Sauf que pour comprendre la différence entre sdt::list et std::vector,
>>> ben, c'est aussi bien de les avoir codé. Même si l'enseignant explique
>>> dès le début du TP que ce qu'on code dans l'exo existe déjà.
>>> De toute façon, 90% des sujets de TP existent déjà en mieux ailleurs
>>> (passer à la date du lendemain, rechercher le min dans un tableau,
>>> coder un mini vi...)
>> Il faut en faire un peu mais pas passer son temps à ça. Il me semble
>> qu'il est préférable de donner un projet pratiquement dès le début du
>> cursus où il faudra énormément réutiliser car, aujourd'hui, c'est cela
>> la réalité dans la "vraie vie". On réserve les TP pour montrer les algos
>> essentiels comme, par exemple le balayage d'arbre binaire de façon
>> récursive sous les 3 formes (préfixe, infixe, postfixe).
>
> Je crois que tu es vraiment loin des débutants. Tu sais, le premier
> projet (en Pascal), après un semestre, c'était un truc du genre
> "bataille navalle", émulateur d'un processeur à 12 instructions,
> aucune allocation dynamique, et déjà, c'est dur...
Tu as raison mais je n'ai jamais dit qu'on commençait par l'algo sur les
arbres ...
Un émulateur de processeur avec quelques instructions, c'est déjà très
bien pour débuter ou une calculette.
Marc Espie
Wykaaa <wyk...@yahoo.fr> wrote:
>Marc Espie a écrit :
>> In article <498c6327$0$18395$ba4a...@news.orange.fr>,
>> Wykaaa <wyk...@yahoo.fr> wrote:
>>> Je suis d'accord avec toi pour dire qu'ils doivent essentiellement
>>> savoir lire du code et que, donc, la pédagogie peut être un peu
>>> différente (mais pas tant que ça). La différence se fera principalement
>>> au niveau des exercices il me semble.
>>
>> tout developpeur doit savoir lire du code.
>>
>> Ca evite le syndrome du mec qui debarque sur un gros projet et qui veut
>> tout reecrire "parce que c'est pas comme ca qu'il aurait fait".
>>
>Sauf que je me rappelle, sur un gros projet système, quand on a posé les
>crayons, c'est nous-mêmes qui avons dit : maintenant on sait comment il
>aurait fallu faire...
Ce qui suppose d'avoir lu et compris la premiere version, en particulier
d'avoir un vrai regard critique dessus, plus profond que "ouh la, ca colle
pas avec mes habitudes de programmeur => c'est forcement mauvais".
Marc Espie
Marc Boyer <Marc....@cert.onera.fr.invalid> wrote:
> Prolog ? C'est intéressant Prolog, mais je ne vois pas comment s'en
>servir pour présenter la prog procédurale avec.
Disons que je rejoins le point de vue de certains.
La programmation procedurale n'a rien de naturel. Mais si tu formes
des etudiants a un langage procedural pour commencer, tu vas avoir un
mal fou a les faire "sortir des rails" plus tard, en particulier sur du
fonctionnel ou du declaratif.
Alors que si tu commences sur du fonctionnel, tu as des chances qu'ils
comprennent un jour la notion de fonction recursive et la notion de
preuve de programme.
(comment ca, j'exagere ? oui sans doute un peu... mais je maintiens que le
sens scheme -> procedural est plus simple que l'inverse. C'est pas un hasard
si l'excellent cours de base du MIT se fonde sur scheme...)
Wykaaa
Oui, tout à fait.
Marc Boyer
> Marc Boyer <Marc....@cert.onera.fr.invalid> wrote:
>> Prolog ? C'est intéressant Prolog, mais je ne vois pas comment s'en
>>servir pour présenter la prog procédurale avec.
>
> Disons que je rejoins le point de vue de certains.
> La programmation procedurale n'a rien de naturel. Mais si tu formes
> des etudiants a un langage procedural pour commencer, tu vas avoir un
> mal fou a les faire "sortir des rails" plus tard, en particulier sur du
> fonctionnel ou du declaratif.
Tout à fait. Si tu as le temps dans ta formation.
> Alors que si tu commences sur du fonctionnel, tu as des chances qu'ils
> comprennent un jour la notion de fonction recursive et la notion de
> preuve de programme.
Oui, Lisp, caml, ok. Mais Prolog pour débuter...
Mihamina Rakotomandimby (R12y)
>>>> Finalement tu a certainement raison. Et pour les administrateurs ?
>>>> du Shell ?
>>> Existe-il quelque part une formation spécifique pour les Admins ?
>>> J'ai toujours eut l'impression que c'était des informaticiens
>>> généralistes
>>> formés à l'admin sur le tas.
>> Un bon admin système UNIX sait packager et donc patcher du code.
>> Je dirais que pour la branche UNIX, le C est à aborder tres tot.
>> Moi j'ai manqué le train du C à la Fac, je le regrette amèrement
>> aujourd'hui.
>>
>> Apres, en général, un admin reprend du code, il en crée rarement.
>> Donc pour lui c'est plutot apprendre à lire le code de quelqu'un qu'il
>> lui faut.
> Ton intervention est très intéressante car je me suis toujours posé la
> question : que faut-il apprendre de la programmation pour les
> administrateurs ?
> Je relève tout de même que packager et patcher ce n'est pas tout à fait
> la même chose.
Mais l'un va avec l'autre: on a beau dire qu'un programme en C a été
codé pour etre multiplateforme, si l'auteur n'a qu'une machine windows
(par exemple) il faudra patcher un peu pour que ça fonctionne sous Linux.
C'est la cas, par exemple, de la suite xxx2iso de Luigi A.:
http://aluigi.org/mytoolz.htm
On retrouve un patch de code:
http://packages.ubuntu.com/intrepid/nrg2iso
http://archive.ubuntu.com/ubuntu/pool/universe/n/nrg2iso/nrg2iso_0.4-3.diff.gz
Bon, ce n'est en rien significatif, mais si je veux maitnenant packager
les autres xxx2iso qui ne sont pas packagés, je dois comprendre ce que
le premier packager à fait.
> Je suis d'accord avec toi pour dire qu'ils doivent essentiellement
> savoir lire du code et que, donc, la pédagogie peut être un peu
> différente (mais pas tant que ça). La différence se fera principalement
> au niveau des exercices il me semble.
Et aussi que le C est majoritaire, mais on retrouve un nombre croissant
de logiciels en Java, C++,... pour divers usages.
Finalement, ben je sais pas si ça peut s'enseigner... l'expérience est
selon moi le meilleur formateur pour ce genre d'activité.
Marc Espie
Mihamina Rakotomandimby (R12y) <miha...@lab.vectoris.fr> wrote:
>Finalement, ben je sais pas si ça peut s'enseigner... l'expérience est
>selon moi le meilleur formateur pour ce genre d'activité.
Si, ca s'enseigne. Essentiellement sur des exemples.
Montrer aux gens les automatismes de lecture de code qui permettent de
rentrer rapidement dans un projet, et tous les trucs et astuces qui
permettent d'aller plus vite.
Mon favori, generalement peu connu des neophytes: pour du langage compile
tel que C, parfois il est plus simple de regarder ce qui se passe apres
le preprocesseur ou le compilateur que le code source tel quel.
En particulier, ca va souvent plus vite de retrouver une fonction a coups
de nm que de grep dans du code un peu ardu...
Marc Espie
Marc Boyer <Marc....@cert.onera.fr.invalid> wrote:
> Oui, Lisp, caml, ok. Mais Prolog pour débuter...
Prolog: juste mentionner que ca existe apres scheme, et passer une seance
de 3h a leur montrer.
Cote fonctionnel: si on a peu de temps, scheme et rien d'autres. caml est
trop gros cote typage et syntaxe. Et lisp aussi. scheme a ete "concu" pour
etre enseigne, autant en profiter (en plus, c'est plus facile de trouver
des implementations de scheme utilisables et rigolotes et portables, telles
que DrScheme).
Wykaaa
les langages fonctionnels (probablement à cause de ma formation en
sémantique dénotationnelle...). mais aujourd'hui, dans l'industrie, on
ne peut pas dire qu'on voit beaucoup de Lisp ou Caml.
Même Ilog, qui avait tous ses logiciels (MassaÏ et autres) en Lisp les a
recodés en C++ il y a plus de 10 ans.. (je en sais pas où ils en sont
maintenant), pourtant Jérôme Chailloux (Le_Lisp) était chez eux ;-)
D'ailleurs j'ai fr.comp.lang.lisp et fr.comp.lang.caml sous les yeux :
c'est le désert ! (pascal aussi d'ailleurs)
Marc Espie
Wykaaa <wyk...@yahoo.fr> wrote:
>Sur le fond, je ne vais pas te contredire car j'ai une préférence pour
>les langages fonctionnels (probablement à cause de ma formation en
>sémantique dénotationnelle...). mais aujourd'hui, dans l'industrie, on
>ne peut pas dire qu'on voit beaucoup de Lisp ou Caml.
Je pense que, pour un programmeur experimente, le langage a beaucoup moins
d'importance que les techniques de programmation. On peut faire de l'objet
en assembleur, ou du fonctionnel en C++...
Si on parle de programmeurs debutants, si tu ne les exposes pas a certains
styles de programmation, ils vont au devant de severes limitations plus
tard.
Quand ils devront intervenir sur du code ecrit en utilisant des paradigmes
qu'ils ne connaissent pas, ils auront enormement de mal a entrer dans le
code.
J'ai meme un exemple personnel tres ancien. J'ai commence l'informatique
avec une TI57, puis un PC 1211, puis un Atom, petite machine a base de 6502...
J'ai passe pas mal de temps avec son basic, puis son assembleur, y compris
un desassembleur fait main. Comme la rom n'etait pas tres grosse, j'en
ai desassemble de gros bouts. J'ai bloque sur deux trucs:
- le trace de lignes. Bresenham en assembleur, sans connaitre les formules,
c'est incomprehensible.
- l'interpreteur basic a proprement parler. Un automate pondu par un
generateur automatique, si on ne connait pas la technique, c'est
incomprehensible.
Il a fallu quelques annees avant que je me retrouve avec des cours
d'informatique formels et que je comprenne ce qui m'avait bloque.
Quand je travaille sur du code existant, encore aujourd'hui, je vois des
tonnes de concepts un peu avances. Et normalement, le developpeur qui a
ecrit le code met juste un bref commentaire qui rappelle quelle technique
il utilise, si on a de la chance... pour comprendre les choses, ca suppose
d'avoir la meme culture que lui. Et il y a des tonnes d'idiomes de
programmation fonctionnelle qui se cachent dans la plupart des codes
proceduraux un peu "avances"... bonne chance au malheureux qui n'a jamais
ete expose a un dialecte de lisp qu'on va larguer la-dedans...
Pascal J. Bourguignon
etags + emacs M-.
ou utiliser un IDE digne de ce nom...
--
__Pascal Bourguignon__
Marc Espie
Pascal J. Bourguignon <p...@informatimago.com> wrote:
>es...@lain.home (Marc Espie) writes:
>> Mon favori, generalement peu connu des neophytes: pour du langage compile
>> tel que C, parfois il est plus simple de regarder ce qui se passe apres
>> le preprocesseur ou le compilateur que le code source tel quel.
>>
>>
>> En particulier, ca va souvent plus vite de retrouver une fonction a coups
>> de nm que de grep dans du code un peu ardu...
>
>etags + emacs M-.
>
>ou utiliser un IDE digne de ce nom...
>
Mais au secours quoi, parle de ce que tu connais, ou au moins lis la totalite
du message auquel tu reponds.
Tu t'imagines que je n'utilise pas d'outils qui fonctionnent la plupart
du temps ? Si tu veux m'apprendre l'informatique, faudra commencer un peu plus
haut (moi ma drogue, c'est vim, qui gere tres bien les tags lui-aussi...
quand ceux-ci fonctionnent, et souvent id-utils plutot que etags).
Tu ne t'es jamais retrouve face a du code C qui utilise le preprocesseur
de facon quelque peu abondante, de sorte que tu as beaucoup, beaucoup de
mal a savoir ou telle ou telle fonction est definie, parce que meme
son NOM est genere par le preprocesseur ?
Ou un enchevetrement de #ifdef lies a une facon un peu bizarre de gerer
la portabilite ?
C'est les deux cas de figures ou etags ne va pas trouver grand chose (soit
parce que tu ne sauras pas LAQUELLE des 15 fonctions est la bonne, soit parce
que tu ne verras pas du tout la bonne fonction).
oui, bien sur, ca n'est pas forcement la meilleure facon d'ecrire du code.
Mais quand tu interviens sur des trucs deja existants, tu n'as pas le
choix. Et quand il s'agit de debugguer, bizarrement, ca n'est pas dans les
endroits clairs et simples que tu trouves les problemes, en general...
Pascal J. Bourguignon
> In article <49903450$0$4094$ba4a...@news.orange.fr>,
> Wykaaa <wyk...@yahoo.fr> wrote:
>>Sur le fond, je ne vais pas te contredire car j'ai une préférence pour
>>les langages fonctionnels (probablement à cause de ma formation en
>>sémantique dénotationnelle...). mais aujourd'hui, dans l'industrie, on
>>ne peut pas dire qu'on voit beaucoup de Lisp ou Caml.
>
> Je pense que, pour un programmeur experimente, le langage a beaucoup moins
> d'importance que les techniques de programmation. On peut faire de l'objet
> en assembleur, ou du fonctionnel en C++...
Oui, on peut. Mais même le programmeur expérimenté peut se lasser du
"boldplate" nécessaire dans ces langages, et pourrait vouloir prendre
son envol avec quelqu'abstration syntactic ou métalinguistique.
> Si on parle de programmeurs debutants, si tu ne les exposes pas a certains
> styles de programmation, ils vont au devant de severes limitations plus
> tard.
>
> Quand ils devront intervenir sur du code ecrit en utilisant des paradigmes
> qu'ils ne connaissent pas, ils auront enormement de mal a entrer dans le
> code.
Ça dépend à quel niveau. Le paradigme se traduit concrêtement par un
langage spécifique au domaine (eg. prolog pour la programmation
logique) et quand le langage est de haut niveau, c'est à dire du
niveau du problème, il devrait pouvoir se maitriser assez
facilement. (Sinon ça veut dire que le programmeur n'a rien compris au
problème en question, et alors on a un autre problème). La difficulté
vient quand on est forcé d'exprimer la solution dans un langage de bas
niveau (tout est relatif, pas bas niveau je veux dire simplement d'un
niveau différent de celui du problème), alors on peut effectivement
faire intervenir des mécanismes nécessaires dans ce langage
informatique mais qui ne correspondent à rien dans le problème. Par
exemple si on veut traiter le domaine des transaction immobilières:
Bien* b=new Maison(p);
...
delete b;
est totalement incompréhensible, car nouveau et supprimer ne sont pas
des opérations correspondant à quoi que ce soit dans le domaine des
transaction immobilières, sans rentrer dans le détail des pointeurs.
À contrario:
(let ((b (maison :proprietaire p)))
...)
;; = soit b une maison appartenant au propriétaire p
me semble comporter moins de difficulté aussi bien pour un programmeur
expérimenté qu'un programmeur débutant, et on n'a même pas commencé à
aborder les abstractions syntaxiques et métalinguistiques...
> J'ai meme un exemple personnel tres ancien. J'ai commence l'informatique
> avec une TI57, puis un PC 1211, puis un Atom, petite machine a base de 6502...
>
> J'ai passe pas mal de temps avec son basic, puis son assembleur, y compris
> un desassembleur fait main. Comme la rom n'etait pas tres grosse, j'en
> ai desassemble de gros bouts. J'ai bloque sur deux trucs:
> - le trace de lignes. Bresenham en assembleur, sans connaitre les formules,
> c'est incomprehensible.
> - l'interpreteur basic a proprement parler. Un automate pondu par un
> generateur automatique, si on ne connait pas la technique, c'est
> incomprehensible.
En effet. Le _source_ de la solution à ces problèmes n'était pas
exprimé en assembleur. Tu observais une expression de bas niveau avec
des détails sans aucune pertinance aux problèmes en question.
> Il a fallu quelques annees avant que je me retrouve avec des cours
> d'informatique formels et que je comprenne ce qui m'avait bloque.
>
> Quand je travaille sur du code existant, encore aujourd'hui, je vois des
> tonnes de concepts un peu avances. Et normalement, le developpeur qui a
> ecrit le code met juste un bref commentaire qui rappelle quelle technique
> il utilise, si on a de la chance... pour comprendre les choses, ca suppose
> d'avoir la meme culture que lui. Et il y a des tonnes d'idiomes de
> programmation fonctionnelle qui se cachent dans la plupart des codes
> proceduraux un peu "avances"... bonne chance au malheureux qui n'a jamais
> ete expose a un dialecte de lisp qu'on va larguer la-dedans...
Hé hé! Ça continue. Bien entendu, les bons programmeurs ont des
concepts plus avancés que ce proposent les langages habituels. Si ils
peuvent les exprimer dans un langage spécifique au domaine, ils le
feront, (et écriront les quelques macros et autres abstractions
syntaxiques et métalinguistiques) pour produire un source
compréhensible. Mais si ils sont forcés de travailler avec des
langages de bas niveau (cf plus haut), ils vont automatiquement
compiler dans leur tête les solutions de haut niveau dans le langage
de bas niveau, et ainsi produire du code aussi comprehénsible que le
code généré par n'importe quel compilateur. Et ceci même s'ils ne
connaissent pas Lisp. Le mouvement des "design patterns" n'est qu'un
exemple de ce phénomène où ils essayent de formaliser et documenter ce
processus (un "design pattern" correspond à une macro lisp).
--
__Pascal Bourguignon__
Marc Espie
>exemple de ce phénomène où ils essayent de formaliser et documenter ce
>processus (un "design pattern" correspond à une macro lisp).
Non, pas vraiment. Il y a bien d'autre chose dans les designe pattern
que des macros lisp...
ca finit par etre chiant que tu voies tout a travers les memes oeilleres !
Wykaaa
Bien entendu, les bons programmeurs ont des
> concepts plus avancés que ce proposent les langages habituels. Si ils
> peuvent les exprimer dans un langage spécifique au domaine, ils le
> feront, (et écriront les quelques macros et autres abstractions
> syntaxiques et métalinguistiques) pour produire un source
> compréhensible. Mais si ils sont forcés de travailler avec des
> langages de bas niveau (cf plus haut), ils vont automatiquement
> compiler dans leur tête les solutions de haut niveau dans le langage
> de bas niveau, et ainsi produire du code aussi comprehénsible que le
> code généré par n'importe quel compilateur. Et ceci même s'ils ne
> connaissent pas Lisp. Le mouvement des "design patterns" n'est qu'un
> exemple de ce phénomène où ils essayent de formaliser et documenter ce
> processus (un "design pattern" correspond à une macro lisp).
>
je veux bien mais alors dis-nous si chacun des "design patterns" ici :
http://www.soapatterns.org/masterlist_c.asp#ch11
peut s'implémenter comme une macro Lisp ;-)
Wykaaa
> In article <49903450$0$4094$ba4a...@news.orange.fr>,
> Wykaaa <wyk...@yahoo.fr> wrote:
>> Sur le fond, je ne vais pas te contredire car j'ai une préférence pour
>> les langages fonctionnels (probablement à cause de ma formation en
>> sémantique dénotationnelle...). mais aujourd'hui, dans l'industrie, on
>> ne peut pas dire qu'on voit beaucoup de Lisp ou Caml.
>
> Je pense que, pour un programmeur experimente, le langage a beaucoup moins
> d'importance que les techniques de programmation. On peut faire de l'objet
> en assembleur, ou du fonctionnel en C++...
Tout à fait d'accord
>
> Si on parle de programmeurs debutants, si tu ne les exposes pas a certains
> styles de programmation, ils vont au devant de severes limitations plus
> tard.
>
> Quand ils devront intervenir sur du code ecrit en utilisant des paradigmes
> qu'ils ne connaissent pas, ils auront enormement de mal a entrer dans le
> code.
[couic]
le problème c'est qu'avec les cursus on est toujours pris par le temps.
Il faut trouver le bon compromis entre ce qu'on sait qui va être
utilisable quasi directement dans la vraie vie et ce qui est
éventuellement possible de rencontrer plus tard.
Ceci étant, si la cible c'est de former de "vrais "développeurs", je
suis d'accord avec toi qu'il faut montrer les différents styles de
programmation : procédural, objet, fonctionnel et déclaratif (et non pas
logic comme le dit Bourguignon à propos de Prolog).
Il faudra savamment doser les volumes respectifs de chaque style en
prenant en compte l'ensemble des contraintes (volumes du cursus,
objectifs de la filière, profil des étudiants).
Wykaaa
> "Wykaaa" <wyk...@yahoo.fr> a écrit dans le message de news:
> 498f21c2$0$18391$ba4a...@news.orange.fr...
>> Dans cette première synthèse, je tiens compte du présent fil de discussion
>> mais aussi du fil "Pédagogie : C++ ou Java ?" dans fr.comp.lan.c++.
>>
>
> Merci beaucoup d'avoir fait cette synthèse, je comptais tenter d'en faire
> autant prochainement pour moi et mes collègues, j'ai maintenant grâce à
> votre travail une bonne base pour nourrir nos discussions à venir. Merci
> aussi à tous ceux qui ont argumenté sur le fil "Pédagogie : C++ ou Java ?"
> sur l'autre forum (j'avais vu l'invite à venir sur ce forum malheureusement
> juste après avoir posté mon message initial...)
Je m'étais engagé à faire une synthèse dans mon message initial.
>
> Je note que bien que cette première discussion se soit déroulée sur un forum
> C++, les intervenants sont suffisamment objectifs pour avoir donné (au moins
> pour cette question pédagogique) la première place au Java ;o)
Comme quoi les informaticiens, malgré leurs querelles de clocher,
peuvent se montrer raisonnables :-)
>
>> * Questions non résolues
>> - Les bases des bases de la programmation, à savoir : variables,
>> constantes, litéraux, séquence, itératives, alternatives, récursion
>> s'apprennent-t-elles directement avec un langage ou en "pseudo-code ?
>
> Vous précédez mes propres questions : je voulais justement en venir à cette
> même interrogation, concernant le langage utilisé pour les "bases de la
> programmation" et aussi l'algorithmique. Dans mon IUT nous sommes passés
> l'an dernier d'un pseudo-code (basé sur le français) au C++ (langage utilisé
> jusque cette année pour la POO) avec comme principale justification de ne
> pas ajouter (en début de cursus) un langage de plus pour les étudiants
> (langage complètement "maison" qui plus est), et de tenter de leur faciliter
> du même coup la mémorisation des mots clés et structures du C++ (utilisé de
> fait dans deux matières). Si nous passons à Java pour la POO, la question du
> pseudo-code va revenir d'actualité puisqu'il serait sûrement malvenu de
> conserver le C++ en parallèle en première année.
Maintenant la balle est dans votre camp...
Je pense que pour les débutants, Java peut servir de pseudo code si on
ne s'embarque pas dans les détails, du moins en début de cursus. Et pour
les exceptions, le mécanismes est assez propre puisque chaque méthode
doit déclarer les exception qu'elle lève si elle ne les traite pas et
que le compilateur force à faire soit l'un, soit l'autre.
>
> Merci d'avance pour vos contributions sur ces questions et d'autres, et
> bonne semaine.
Si cette discussion vous permet d'avancer alors nous n'aurons pas agi
pour rien !
Marc Espie
Pascal J. Bourguignon <p...@informatimago.com> wrote:
>> J'ai passe pas mal de temps avec son basic, puis son assembleur, y compris
>> un desassembleur fait main. Comme la rom n'etait pas tres grosse, j'en
>> ai desassemble de gros bouts. J'ai bloque sur deux trucs:
>> - le trace de lignes. Bresenham en assembleur, sans connaitre les formules,
>> c'est incomprehensible.
>> - l'interpreteur basic a proprement parler. Un automate pondu par un
>> generateur automatique, si on ne connait pas la technique, c'est
>> incomprehensible.
>En effet. Le _source_ de la solution à ces problèmes n'était pas
>exprimé en assembleur. Tu observais une expression de bas niveau avec
>des détails sans aucune pertinance aux problèmes en question.
Okay, je reformule, parce que tu n'as vu que le bout emerge de l'iceberg.
Non, le probleme n'est pas la et d'ailleurs, je pense que tu n'as que
partiellement raison.
Tout d'abord, vu l'encombrement memoire de la machine en question, je
soupconne qu'une enorme partie de sa ROM a ete programme directement en
assembleur. Ca ne serait pas rentre autrement, surtout avec les technos
de compilation de l'epoque...
Ensuite, le souci est d'ordre conceptuel. Bresenham repose sur des choses
assez fines cote arithmetique, que j'etais loin d'avoir vues a l'epoque, et
meme avec le source, je n'y aurais rien capte.
Pour la partie interpreteur Basic, c'est la-aussi les techniques de
representation compactes d'automates que je n'avais pas encore vues.
Tu m'aurais file le source lex (ou assimile), j'aurais compris ce qu'il
etait cense faire, mais ca ne m'aurait pas avance d'un poil pour comprendre
le code auquel j'avais affaire, et pourquoi il etait si efficace (le basic
de l'atom etait redoutablement rapide, surtout compare aux autres basic
que j'ai pu voir quelques annees plus tard sur le C64 et assimile).
Michael DOUBEZ
> es...@lain.home (Marc Espie) writes:
>
>> In article <49903450$0$4094$ba4a...@news.orange.fr>,
>> Wykaaa <wyk...@yahoo.fr> wrote:
>>> Sur le fond, je ne vais pas te contredire car j'ai une préférence pour
>>> les langages fonctionnels (probablement à cause de ma formation en
>>> sémantique dénotationnelle...). mais aujourd'hui, dans l'industrie, on
>>> ne peut pas dire qu'on voit beaucoup de Lisp ou Caml.
>> Je pense que, pour un programmeur experimente, le langage a beaucoup moins
>> d'importance que les techniques de programmation. On peut faire de l'objet
>> en assembleur, ou du fonctionnel en C++...
>
> Oui, on peut. Mais même le programmeur expérimenté peut se lasser du
> "boldplate"
"boilerplate"
> nécessaire dans ces langages, et pourrait vouloir prendre
> son envol avec quelqu'abstration syntactic ou métalinguistique.
En pratique, on a très peu à dire sur le langage utilisé et, dans le cas
contraire, à moins de vouloir se faire un job à vie ou laisser son
employeur dans l'embarras, les langages classiques s'imposent.
Les seuls cas ou un langage innovant peut être utilisé est dans le cas
d'outsourcing de développement où le client n'achète pas ou ne se
préoccupe pas des sources - ce qui doit être rare aujourd'hui vu les
claques que certains se sont pris.
[snip]
> Hé hé! Ça continue. Bien entendu, les bons programmeurs ont des
> concepts plus avancés que ce proposent les langages habituels. Si ils
> peuvent les exprimer dans un langage spécifique au domaine, ils le
> feront, (et écriront les quelques macros et autres abstractions
> syntaxiques et métalinguistiques) pour produire un source
> compréhensible. Mais si ils sont forcés de travailler avec des
> langages de bas niveau (cf plus haut), ils vont automatiquement
> compiler dans leur tête les solutions de haut niveau dans le langage
> de bas niveau, et ainsi produire du code aussi comprehénsible que le
> code généré par n'importe quel compilateur.
Ce n'est pas spécifique aux bon programmeurs mais - normalement - à tous
les programmeurs: voir les capacités d'expression d'un langage et
exprimer un design dans ce cadre.
> Et ceci même s'ils ne
> connaissent pas Lisp. Le mouvement des "design patterns" n'est qu'un
> exemple de ce phénomène où ils essayent de formaliser et documenter ce
> processus (un "design pattern" correspond à une macro lisp).
C'est sûr que Lisp offre une bonne souplesse pour l'expression des
design pattern mais, en pratique, leur combinaison pour obtenir quelque
chose d'utile n'est pas aussi simple.
Ensuite, pour les pattern d'architecture (qui s'appellent aussi design
pattern - merci GoF), une macro est loin de suffire.
--
Michael
Pascal J. Bourguignon
> In article <7c63jjw...@pbourguignon.anevia.com>,
> Pascal J. Bourguignon <p...@informatimago.com> wrote:
>>connaissent pas Lisp. Le mouvement des "design patterns" n'est qu'un
>>exemple de ce phénomène où ils essayent de formaliser et documenter ce
>>processus (un "design pattern" correspond à une macro lisp).
>
> Non, pas vraiment. Il y a bien d'autre chose dans les designe pattern
> que des macros lisp...
C'est parce que tu as une vision restrictive des macros.
http://groups.google.com/group/comp.lang.lisp/msg/ee09f8475bc7b2a0
http://groups.google.com/group/comp.programming/msg/9e7b8aaec1794126
Le fait d'écrire formellement ce qui peut s'écrire formellement
n'empêche pas d'écrire sous forme de documentation ce qui doit rester
informel.
> ca finit par etre chiant que tu voies tout a travers les memes oeilleres !
--
__Pascal Bourguignon__
Pascal J. Bourguignon
On est dans fr.comp, pas dans fr.entreprise.
Mais ceci dit, c'est une question de processeur. Les instructions
d'un design pattern entrepreneurial devront être exécutées par des
cadres et salariés de l'entreprise. La macro lisp sera le bout de
code qui prendra l'appel paramétré au désign pattern et qui génèrera
ces instructions. Ceci peut s'implémenter de la même manière qu'on
utilise le système de macro de Lisp pour générer du code non lisp.
--
__Pascal Bourguignon__
Pascal J. Bourguignon
Ça arrive, mais ce n'est pas le plus souvent. Le plus souvent l'usage
de tags donne le bon résultat, et c'est plus rapide qu'un grep sur la
sortie de nm.
Ceci dit (mais ce n'est pas non plus le plus souvent), il est vrai que
gcc -E peut être utile.
--
__Pascal Bourguignon__
Marc Espie
>d'un design pattern entrepreneurial devront être exécutées par des
>cadres et salariés de l'entreprise. La macro lisp sera le bout de
>code qui prendra l'appel paramétré au désign pattern et qui génèrera
>ces instructions. Ceci peut s'implémenter de la même manière qu'on
>utilise le système de macro de Lisp pour générer du code non lisp.
Et ca, tu sais implementer en macro lisp ?
"Si, dans ta boite a outils, il ne reste qu'un marteau, meme les vis se
mettent a ressembler a des clous."
Pascal J. Bourguignon
> In article <7c7i3yz...@pbourguignon.anevia.com>,
> Pascal J. Bourguignon <p...@informatimago.com> wrote:
>>Mais ceci dit, c'est une question de processeur. Les instructions
>>d'un design pattern entrepreneurial devront être exécutées par des
>>cadres et salariés de l'entreprise. La macro lisp sera le bout de
>>code qui prendra l'appel paramétré au désign pattern et qui génèrera
>>ces instructions. Ceci peut s'implémenter de la même manière qu'on
>>utilise le système de macro de Lisp pour générer du code non lisp.
>
> Et ca, tu sais implementer en macro lisp ?
Bien sur, je l'ai déjà fait plusieurs fois personnellement.
Tu peux jeter un oeuil sur: http://common-lisp.net/project/parenscript/
> "Si, dans ta boite a outils, il ne reste qu'un marteau, meme les vis se
> mettent a ressembler a des clous."
In a profession plagued by, "when all you have is a hammer, everything
looks like a nail," we get really excited when someone is able to come
along and prove that everything really *is* a nail if lambda is the
hammer.
B.R.Lewis (comp.lang.scheme)
--
__Pascal Bourguignon__
Wykaaa
cjps...@gmail.com
> Pascal J. Bourguignon a écrit :
>
> > es...@lain.home (Marc Espie) writes:
>
Votre discussion est intéressante, un éclairage sur le sujet du
langage se trouve sur le site d'adacore :
http://www.adacore.com/wp-content/uploads/2009/02/principled_approach.pdf
et un autre plus complet sur le site de l'ACM : http://www.acm.org/education/curric_vols.
Wykaaa
Je vous remercie pour ces pointeurs; Je connais très bien le second
étant moi-même membre de l'ACM et de l'IEEE depuis maintenant 25 ans.
Par ailleurs j'ai travaillé dans le domaine des compilateurs de façon
industrielle et j'ai participé (un peu) à l'élaboration du premier
compilateur Ada (langage que j'ai enseigné mais seulement Ada 83).
Le papier d'Adacore pose des questions essentielles dans le cadre de
l'ingénierie logicielle, mais c'est Adacore donc forcément partisan.
Néanmoins certaines remarques sont pertinentes et il y aurait matière à
une discussion approfondie sur certains points, en particulier sur la
séparation spécification/implémentation qui, je le reconnais est une
totale réussite en Ada (mais c'était un besoin jugé comme important dans
le cahier des charge du DoD). Cette séparation n'existe effectivement
pas en Java et c'est très dommage effectivement. Ceci étant, dans mes
questions initiales, j'avais mentionné la modularité qui, à mon avis,
doit être exposée conceptuellement le plus tôt possible pour des
débutants. Curieusement, et cela m'étonnera toujours, ce n'est mentionné
par presque personne dans ce genre de discussion sur la pédagogie, du
moins en France. Il est vrai qu'en Ada, et j'en ai fait l'expérience, on
peut (doit) définir l'ensemble des spécifications des packages avant de
coder et que c'est une aide précieuse puisqu'en Ada, on peut compiler
ces spécifications ce qui permet de "voir" si l'on est sur la bonne voie
(dépendances, encapsulation, typage, etc.).
Cependant une bonne utilisation (des bonnes pratiques) de la notion
d'interface et de package en Java peut pallier, un peu, le manque de
séparation entre spécification et implémentation. Il y a aussi des
personnes qui, elles l'ont dit dans la discussion et elles se
reconnaîtront, font souvent peut de cas de l'encapsulation, en
particulier celles qui sont dans le monde Python ou langages similaires.
Ceci est probablement du au fait qu'elles ne pratique pas la
"programmation en grand ou en très grand".
Un autre point concerne "l'ingénierie Java" avec la machine virtuelle et
le ramasse-miette qui, effectivement, ne permet pas de faire prendre
conscience au débutant, de ce qui se passe réellement à l'exécution. Il
me semble cependant que certains, en particuliers et curieusement, les
étudiants eux-mêmes reconnaissent qu'exposer l'architecture d'un
processeur ou faire un peu d'assembleur peut permettre de mieux
comprendre comment les choses se passent au niveau de l'exécution et
pourquoi certains langages possèdent certains traits concernant ces
aspects (gestion mémoire en C++ par exemple).
Je ne reviendrai pas, par contre, sur la "querelle" types, sous-types,
classes, héritage qui est au moins aussi vieille que l'apparition de
l'héritage en programmation c'est à dire depuis plus de 40 ans
maintenant mais là aussi il y aurait matière à expliciter ces aspects
dans un enseignement sérieux de la programmation.
Je crains fort cependant que la remarque concernant la multiplicité des
objets en Java ne soit vaine car mon expérience montre qu'aujourd'hui,
du moins en COO/POO, c'est une pratique courante de programmation malgré
ce que disait Guillaume d'Ockham "Pluralitas non est ponenda sine
neccesitate" ou "la multiplicité ne devrait pas être postulée sans
nécessité." (mais il ne connaissais pas la POO !).
Enfin concernant la concurrence, s'il est vrai que la sémantique de Java
ne permet pas la communication entre threads ni un comportement
totalement déterministe, je persiste à penser que sa mise en oeuvre (la
concurrence) en Java est aisée et que, avec une bonne pédagogie, nombre
de pièges pourront être évités par les débutants. Il me semble que c'est
suffisant pour l'apprentissage car "la science dure du temps réel" ne
relève pas de l'apprentisage de la programmation mais de son
approfondissement réservé, qui plus est, à des futurs spécialistes qui
travaillerons dans des domaines spécifiques de l'informatique
industrielle (et plutôt dans l'ingénierie des systèmes complexes).
Personnellement, je pense que la discussion s'est arrêtée bien trop tôt,
que quantité de problèmes concernant la pédagogie de l'apprentissage de
la programmation n'ont pas été abordés. Je pensais que nous irions bien
plus loin et de façon plus approfondie mais peut-être que l'essentiel
est dit dans les cursus de l'ACM...
J'avais d'ailleurs intitulé ma synthèse : 1ère synthèse, pensant que
d'autres suivraient...
En tout cas, merci pour votre intervention judicieuse.
cjps...@gmail.com
> cjpsi...@gmail.com a écrit :
>
>
>
> > On 10 fév, 16:30, Wykaaa <wyk...@yahoo.fr> wrote:
> >> Pascal J. Bourguignon a écrit :
>
> >>> es...@lain.home (Marc Espie) writes:
> >>>> In article <7c7i3yzi1v....@pbourguignon.anevia.com>,
> >>>> Pascal J. Bourguignon <p...@informatimago.com> wrote:
> >>>>> Mais ceci dit, c'est une question de processeur. Les instructions
> >>>>> d'un design pattern entrepreneurial devront être exécutées par des
> >>>>> cadres et salariés de l'entreprise. La macro lisp sera le bout de
> >>>>> code qui prendra l'appel paramétré au désign pattern et qui génèrera
> >>>>> ces instructions. Ceci peut s'implémenter de la même manière qu'on
> >>>>> utilise le système de macro de Lisp pour générer du code non lisp.
> >>>> Et ca, tu sais implementer en macro lisp ?
> >>> Bien sur, je l'ai déjà fait plusieurs fois personnellement.
> >>> Tu peux jeter un oeuil sur:http://common-lisp.net/project/parenscript/
> >>>> "Si, dans ta boite a outils, il ne reste qu'un marteau, meme les vis se
> >>>> mettent a ressembler a des clous."
> >>> In a profession plagued by, "when all you have is a hammer, everything
> >>> looks like a nail," we get really excited when someone is able to come
> >>> along and prove that everything really *is* a nail if lambda is the
> >>> hammer.
> >>> B.R.Lewis (comp.lang.scheme)
> >> Joli : +1 ;-)
>
> > Votre discussion est intéressante, un éclairage sur le sujet du
> > langage se trouve sur le site d'adacore :
Il y a aussi le problème des connaissances auto (plus ou moins bien)
acquises et plus ou moins bien assimilées qu'il faut recadrer.
Je ne suis pas sur que l'objet soit assimilable correctement sans être
passé par une phase moins abstraite. Pour faire comprendre le besoin
d'abstraction il est bon de faire du bas niveau et d'en mesurer toutes
les difficultés en terme de génie logiciel.
Pour les passionnés de hardware il leur est difficile de quitter ce
bas niveau. Passer de l'assembleur au C peut être vécu comme un
traumatisme alors passer du C à C++ java ou Ada...
Par contre Ada offre quelque chose d'intéressant c'est le contrôle du
mapping entre le haut et le bas niveau ainsi que les possibilité
d'interfaçage entre langages différents.
Dans mon activité professionnelle je suis toujours resté pragmatique,
n'utiliser que les choses dont j'ai besoin. J'utilise l'objet
essentiellement pour ses capacités de liaison dynamique et les types
de données abstraits pour le reste car je préfère la composition à
l'héritage. Donc des arbres d'héritage plats (du type balais quoi).
Pour le reste j'ai apprécié le tasking Ada pour paralléliser une
grosse application de calcul en fortran sans en changer la structure
(quelque dizaines de lignes de code très localisées) grâce à une
librairie Ada très simple d'utilisation assurant le parallèlisme.
J'ai apprécié la généricité de Ada qui m'a permis de gagner un ordre
de grandeur en taille de code et en maintenabilité sur un module
important d'une grosse application de 800k lignes. Sans parler de la
séparation entre les spécifications et le codage qui est devenue pour
moi un outil de design indépendant du langage de programmation. Je
code les specs en Ada en conception et je programme en C++ en ce
moment (je n'ai pas le choix du langage de programmation)..
La majorité du code développé dans mon unité a été développée en
fortran. Aujourd'hui ils veulent passer en C++, c'est difficile car C+
+ n'est pas bien adapté au calcul scientifique notamment le traitement
des tableaux : résultat chaque programmeur à sa propre solution. Il y
a assez peu d'unité de style malgré un manuel de programmation
conséquent.
Après 40 ans de développement je suis atterré par la prolifération des
langages, qui réinventent (mal) la roue. L'informatique est redevenue
une tour de Babel. Avant on spécialisait un langage pour un hardware
aujourd'hui on invente un nouveau langage pour chaque nouveau type
d'application. Et chaque nouveau langage apporte un petit plus et
beaucoup de moins car il est centré sur un type de traitement et
néglige les fondamentaux : exemple python qui ne connait pas
l'encapsulation, résultat : impossible de garantir le bon
fonctionnement.
Au lieu d'apprendre 4 ou 5 langages importants et établis on doit en
apprendre une vingtaine qui évoluent rapidement dans le temps pour
pouvoir faire face à la prolifération des applications. Et avec cela
la gestion de configuration est devenue un problème à l'échelle
mondiale (J.P. Rosen).
Pardon pour ces récriminations d'un candidat à la retraite mais je
souhaite bon courage aux enseignants et aux élèves. J'espère que
quelques esprits avisés auront le courage de dire stop à la
prolifération des "technologies" obsolètes avant d'être matures. Si
l'on doit se différencier c'est dans les services qu'on rend et la
satisfaction des besoins et non dans l'invention d'un autre langage de
programmation. Il vaut mieux faire progresser les langages établis,
tout le monde en tirera profit.
Un bon moyen d'avancer c'est de promouvoir les normes. Si tous les
cahiers des charges avaient comme obligation d'obliger à utiliser les
normes et on serait tenus de faire avancer ces normes pour progresser.
Marc Espie
Wykaaa <wyk...@yahoo.fr> wrote:
>Cependant une bonne utilisation (des bonnes pratiques) de la notion
>d'interface et de package en Java peut pallier, un peu, le manque de
>séparation entre spécification et implémentation. Il y a aussi des
>personnes qui, elles l'ont dit dans la discussion et elles se
>reconnaîtront, font souvent peut de cas de l'encapsulation, en
>particulier celles qui sont dans le monde Python ou langages similaires.
>Ceci est probablement du au fait qu'elles ne pratique pas la
>"programmation en grand ou en très grand".
Personnellement, je suis plus fan des langages qui permettent "les deux".
En general, sur un gros projet, tu vas pouvoir organiser les choses en
sous-systemes relativement bien definis. C'est important de pouvoir avoir
des specs extremement formelles avec une bonne "barriere d'abstraction"
qui permettra de coder d'apres les specs.
Ensuite, tu peux souvent te permettre d'etre un peu plus liberal sur chaque
sous-systeme... Typiquement, parce que l'exces d'abstraction et de specs
va juste te bouffer du temps et ne pas t'apporter grand chose...
Dans les cas ou il faut continuer un peu, ca n'est pas juste des specs que
tu voudrais, mais bien des mecanismes beaucoup plus forts de preuve de ton
code. Et ca, a part le debut d'approche d'Eiffel, on est encore loin du
compte...
A cote de ca, je suis aussi un grand adepte des concepts de refactoring,
pour avoir travaille avec de facon experimentale. Dans la prog que je fais,
il est extremement frequent de reprendre du code mal ecrit par d'autres,
sans specs tres formelles, et de vouloir le faire evoluer... toutes les
transformations que tu peux faire qui ne modifient pas le sens du code,
mais permettent de le rendre plus clair s'averent extremement utile.
Une fois debarrasse du "bruit" d'implementation, on peut reellement enlever
les bouts qui depassent, deployer de meilleurs algorithmes, et rajouter les
evolutions demandees.
J'ai d'ailleurs un souci pedagogique que je ne sais pas vraiment resoudre:
je suis tres souvent confronte a des questions d'etudiants qui cherchent
midi a 14h. Ils resolvent des projets de maniere trop complexe, en mettant
en place des structures de donnees inutiles, et en calculant dix fois trop
de chose par rapport a ce qui est reellement demande. La seule reponse
a leur faire, evidemment, c'est de formaliser un peu plus leur demande
avant de commencer a coder (une bonne approche top-down, quoi), mais quand
ils ne sont pas tres surs d'eux, ca n'est pas du tout naturel, et "les
bonnes pratiques" du TP de 50 lignes disparaissent sous la pression, des
qu'il faut faire 3000 lignes de code...
En fait, je suis tres schizophrene vis-a-vis de l'approche objet: c'est
un outil d'abstraction extremement utile et puissant, mais ca peut rendre
effroyablement complexe la tache d'audit de code. Tres souvent, du code
objet bien concu va contenir pas mal de couches intermediaires, et il n'est
pas du tout simple, de classe en classe, de savoir au bout du compte qu'est-ce
qui execute reellement du code. Tres difficile a apprehender pour le
debutant.
Pour ce genre de manip, je crois que je ne peux guere que recommander une
exposition rapide a smalltalk (surtout maintenant qu'il y a une vm sexy
et utilisable et portable -- squeak), histoire d'aller fouiller dans le
browser, et de regarder par exemple comment, de renvoi en renvoi, sont
implementees les "multi-methodes" de calcul arithmetique...
>Je crains fort cependant que la remarque concernant la multiplicité des
>objets en Java ne soit vaine car mon expérience montre qu'aujourd'hui,
>du moins en COO/POO, c'est une pratique courante de programmation malgré
>ce que disait Guillaume d'Ockham "Pluralitas non est ponenda sine
>neccesitate" ou "la multiplicité ne devrait pas être postulée sans
>nécessité." (mais il ne connaissais pas la POO !).
??? j'ai du rater la remarque en question. Tu peux expliciter.
Wykaaa
> In article <49933ef0$0$18378$ba4a...@news.orange.fr>,
> Wykaaa <wyk...@yahoo.fr> wrote:
>> Cependant une bonne utilisation (des bonnes pratiques) de la notion
>> d'interface et de package en Java peut pallier, un peu, le manque de
>> séparation entre spécification et implémentation. Il y a aussi des
>> personnes qui, elles l'ont dit dans la discussion et elles se
>> reconnaîtront, font souvent peut de cas de l'encapsulation, en
>> particulier celles qui sont dans le monde Python ou langages similaires.
>> Ceci est probablement du au fait qu'elles ne pratique pas la
>> "programmation en grand ou en très grand".
>
> Personnellement, je suis plus fan des langages qui permettent "les deux".
Sans vouloir polémiquer, il ne s'agit pas d'être fan mais, avec
objectivité, de critiquer (positivement ou négativement) les langages
qui permettent de "faire les choses proprement" (je sais, ça peut
paraître vague mais pour moi c'est extrêmement précis car ça veut dire :
faire des logiciels qui soient maintenables, évolutifs,
interopérables,portables( si possible, quand le contexte n'est pas hyper
contraignant), rutilisables (tout ou partie dans un autre contexte
éventuellement), compréhensibles sans des tonnes de documentation,
pérennent (donc qui s'appuient et utilisent les standards), qui
correspondent aux besoins exprimés, qui soient faciles d'emploi (pas
seulement pour les utilisateurs mais qui soient faciles à installer, à
configurer, à administrer). Il y a encore d'autre impératifs mais
ceux-ci sont les plus importants.
> En general, sur un gros projet, tu vas pouvoir organiser les choses en
> sous-systemes relativement bien definis. C'est important de pouvoir avoir
> des specs extremement formelles avec une bonne "barriere d'abstraction"
> qui permettra de coder d'apres les specs.
Je ne vois pas pourquoi ce que tu dis serait réservé seulement aux gros
projets. J'ai tendance à dire que plus c'est compliqué et plus il faut
faire simple (pas simpliste !) mais c'est très dur. Ce n'est pas pour
autant que les choses simples doivent être construites malproprement ou
de façon compliquée !
>
> Ensuite, tu peux souvent te permettre d'etre un peu plus liberal sur chaque
> sous-systeme... Typiquement, parce que l'exces d'abstraction et de specs
> va juste te bouffer du temps et ne pas t'apporter grand chose...
Non justement. Ce sont l'erreur et le raisonnement que que font et
tiennent plus de 90% des développeurs. Car si on est laxiste à ce niveau
là, le temps qu'on aura soi-disant "économisé" sera perdu au centuple en
maintenance et lors des évolutions ultérieures.
>
> Dans les cas ou il faut continuer un peu, ca n'est pas juste des specs que
> tu voudrais, mais bien des mecanismes beaucoup plus forts de preuve de ton
> code. Et ca, a part le debut d'approche d'Eiffel, on est encore loin du
> compte...
Ce n'est certainement pas Eiffel qui nous montre la voie de la preuve.
Ok sont mécanisme de pré et post conditions reliées à son mécanisme
d'exception, c'est très bien mais ça ne ressemble en rien à ne serait-ce
que l'esquisse d'un système de preuve.
D'ailleurs il y a belle lurette que les spécialistes ont abandonné
l'idée de pratiquer des preuves formelles sur le code.
La seule méthode que je connaisse (mais je ne connais pas tout dans ce
domaine) concernant les preuves formelles qui a quelques réussites dans
l'industrie, c'est la méthode B utilisée pour le métro Météor, entre autre.
>
>
> A cote de ca, je suis aussi un grand adepte des concepts de refactoring,
> pour avoir travaille avec de facon experimentale. Dans la prog que je fais,
> il est extremement frequent de reprendre du code mal ecrit par d'autres,
> sans specs tres formelles, et de vouloir le faire evoluer...
Si les principes de l'ingénierie logicielle, tels qu'ils sont décrits,
par exemple, dans les document de l'IEEE (Software Engineering Pratices)
étaient respectés on ne devrait pas se retrouver avec du code tel que tu
le décris...
Il n'y a quasiment que dans l'informatique où des gens peuvent se faire
passer pour informaticien alors qu'ils n'y connaissent rien et, qu'au
mieux, ils bricolent comme ils peuvent du code en amateurs, au mieux,
éclairés ...
> toutes les
> transformations que tu peux faire qui ne modifient pas le sens du code,
> mais permettent de le rendre plus clair s'averent extremement utile.
> Une fois debarrasse du "bruit" d'implementation, on peut reellement enlever
> les bouts qui depassent, deployer de meilleurs algorithmes, et rajouter les
> evolutions demandees.
Je ne sais pas ce que veut dire : "de meilleurs algorithmes". Là encore,
si le code était écrit seulement par des professionnels qui connaissent
leur métier, les algorithmes seraient ceux qui sont adaptés à une
situation données et surtout ce seraient ceux qui résultent des
structures de données adéquates en fonction des problèmes à résoudre.
Les besoins exprimés conditionnent les abstractions à choisir qui
conditionnent les algorithmes à écrire (ou mieux à réutiliser car dans
l'industrie, on n'invente pas d'algorithmes (il y a les chercheurs pour
ça, les algorithmes portent leur nom, en général), on réutilise ou on
adapte des algorithmes existants). Ceux qui programment en croyant
inventer un algorithme tout les jours sont des ignorants et n'ont que
faire dans la profession !
>
> J'ai d'ailleurs un souci pedagogique que je ne sais pas vraiment resoudre:
> je suis tres souvent confronte a des questions d'etudiants qui cherchent
> midi a 14h.
S'ils cherchent midi à 14h c'est qu'ils n'ont pas été mis sur la bonne
voie au départ. Quand je commence un cours de programmation, j'énonce 2
choses avec force :
- on ne met pas son ego dans la programmation (egoless programming).
Voir les 10 "commandements que ça recouvre ici :
http://articles.techrepublic.com.com/5100-10878_11-1045782.html
- Principe du KISS : Keep It Short and Simple (et non Stupid !)
> Ils resolvent des projets de maniere trop complexe, en mettant
> en place des structures de donnees inutiles, et en calculant dix fois trop
> de chose par rapport a ce qui est reellement demande.
Il faut commencer par leur apprendre à lire des cahiers des charges
(besoins et exigences) et à les respecter ! (même dans un TP de 50 lignes)
> La seule reponse
> a leur faire, evidemment, c'est de formaliser un peu plus leur demande
> avant de commencer a coder (une bonne approche top-down, quoi),
C'est au prof de formaliser sa demande ou, du moins, de se comporter en
"client", sinon ce n'est pas étonnant que les étudiants partent dans
tous les sens. C'est même normal et humain...
> mais quand
> ils ne sont pas tres surs d'eux, ca n'est pas du tout naturel, et "les
> bonnes pratiques" du TP de 50 lignes disparaissent sous la pression, des
> qu'il faut faire 3000 lignes de code...
Justement c'est là qu'il faut une main de fer dans un gant de velours et
les encadrer fortement en leur montrant les "bonnes pratiques".
>
> En fait, je suis tres schizophrene vis-a-vis de l'approche objet: c'est
> un outil d'abstraction extremement utile et puissant, mais ca peut rendre
> effroyablement complexe la tache d'audit de code.
Ah ben sauf que non. J'ai audité énormément de code (sur de très grosses
applications industrielles, en général (> 200 KLOC et souvent > 1000
KLOC) en COBOL, C, C++, Java et Ada. J'utilise, la plupart du temps,
LOGISCOPE pour ce faire.
Je préfère nettement audité du code objet, même s'il est mal écrit, que
le moindre programme COBOL ou C car o s'y retrouve bien mieux.
> Tres souvent, du code
> objet bien concu va contenir pas mal de couches intermediaires, et il n'est
> pas du tout simple, de classe en classe, de savoir au bout du compte qu'est-ce
> qui execute reellement du code. Tres difficile a apprehender pour le
> debutant.
Pour le débutant certes, mais on ne va pas le confronter d'emblée à des
centaines de milliers de lignes de code non plus, hein ;-)
Le mieux c'est de lui montrer du code bien écrit tant il est vrai que
les premiers exemples de code nous marquent tous et qu'au début de toute
activité, l'humain procède par mimétisme. Donc s'il voit du mauvais code
en premier, c'est la catastrophe.
D'accord c'est difficile de trouver du bon code mais il y en a chez Sun
en Java, par exemple ou la bibliothèque de Grady Booch en C++
(initialement en Ada) de chez ex-rational.
>
> Pour ce genre de manip, je crois que je ne peux guere que recommander une
> exposition rapide a smalltalk (surtout maintenant qu'il y a une vm sexy
> et utilisable et portable -- squeak), histoire d'aller fouiller dans le
> browser, et de regarder par exemple comment, de renvoi en renvoi, sont
> implementees les "multi-methodes" de calcul arithmetique...
C'est peut-être une possibilité mais ceci doit être commenté précisément
par un très bon pédagogue connaisant très bien le sujet.
>
>> Je crains fort cependant que la remarque concernant la multiplicité des
>> objets en Java ne soit vaine car mon expérience montre qu'aujourd'hui,
>> du moins en COO/POO, c'est une pratique courante de programmation malgré
>> ce que disait Guillaume d'Ockham "Pluralitas non est ponenda sine
>> neccesitate" ou "la multiplicité ne devrait pas être postulée sans
>> nécessité." (mais il ne connaissais pas la POO !).
>
> ??? j'ai du rater la remarque en question. Tu peux expliciter.
Je commentais le papier référencé par cjpsimon (celui-ci :
http://www.adacore.com/wp-content/uploads/2009/02/principled_approach.pdf)
où il est dit (à replacer dans le contexte du papier) :
"As a result Java design leads to a proliferation of objects"
Marc Espie
Wykaaa <wyk...@yahoo.fr> wrote:
>éventuellement), compréhensibles sans des tonnes de documentation,
>pérennent (donc qui s'appuient et utilisent les standards), qui
>correspondent aux besoins exprimés, qui soient faciles d'emploi (pas
>seulement pour les utilisateurs mais qui soient faciles à installer, à
>configurer, à administrer). Il y a encore d'autre impératifs mais
>ceux-ci sont les plus importants.
Tu raisonnes sur un cas precis de projet fortement industriel, ou le cahier
des charges est parfaitement defini avant d'ecrire la moindre ligne de code,
et ou il y a separation complete entre la maitrise d'ouvrage et la maitrise
d'oeuvre.
Ca n'est pas toujours le cas. Il m'arrive tres souvent d'etre dans des
situations ou on va commencer par resoudre un gros bout du probleme, histoire
de savoir comment resoudre la suite... sachant qu'il faut deja la premiere
version a montrer au client avant d'ecrire la suivante.
C'est juste une question de contexte. Comme je fais une grosse partie
de mon dev. plus ou moins "tout seul" sur du logiciel libre, la ressource
cruciale, c'est mon temps, et toute technique qui me permet d'en faire plus
en un temps fini (sans sacrifier a la qualite, et meme en obtenant une
meilleure qualite) est bonne a prendre.
Les techniques de developpement rapide d'applications et de refactoring
se sont averees cruciales pour pas mal de mes projets, qui tournent
maintenant dans 100% des cas. Alors que, a temps egal, si j'avais fait
l'approche specs formelles -> codage, j'en serais a 25% ou a peu pres...
>> En general, sur un gros projet, tu vas pouvoir organiser les choses en
>> sous-systemes relativement bien definis. C'est important de pouvoir avoir
>> des specs extremement formelles avec une bonne "barriere d'abstraction"
>> qui permettra de coder d'apres les specs.
>
>Je ne vois pas pourquoi ce que tu dis serait réservé seulement aux gros
>projets. J'ai tendance à dire que plus c'est compliqué et plus il faut
>faire simple (pas simpliste !) mais c'est très dur. Ce n'est pas pour
>autant que les choses simples doivent être construites malproprement ou
>de façon compliquée !
Ca veut juste dire que tu peux te permettre d'avoir quelques couplages au
sein d'un sous-systeme si celui-ci n'est pas trop technique (je presume
que tu es familier de Lakos et que je n'ai pas besoin de definir le terme
de couplage).
>Non justement. Ce sont l'erreur et le raisonnement que que font et
>tiennent plus de 90% des développeurs. Car si on est laxiste à ce niveau
>là, le temps qu'on aura soi-disant "économisé" sera perdu au centuple en
>maintenance et lors des évolutions ultérieures.
Je ne parle pas d'etre laxiste. Juste eviter d'etre abstrait pour le plaisir
et de surspecifier pour rien.
>D'ailleurs il y a belle lurette que les spécialistes ont abandonné
>l'idée de pratiquer des preuves formelles sur le code.
>La seule méthode que je connaisse (mais je ne connais pas tout dans ce
>domaine) concernant les preuves formelles qui a quelques réussites dans
>l'industrie, c'est la méthode B utilisée pour le métro Météor, entre autre.
J'en connais quelques autres qui marchent plus ou moins, ayant des camarades
qui se sont oriente sur la voie des preuves formelles. Il y a des choses
qui fonctionnent etonnamment bien, tant qu'ils ne se heurtent pas a une
grosse explosion combinatoire...
>Si les principes de l'ingénierie logicielle, tels qu'ils sont décrits,
>par exemple, dans les document de l'IEEE (Software Engineering Pratices)
>étaient respectés on ne devrait pas se retrouver avec du code tel que tu
>le décris...
Pas du tout d'accord. Il y a des choix a faire dans l'ecriture du code.
Certains sont evidents, d'autres sont des compromis. Et tu peux faire un
compromis dans un sens lors de l'ecriture d'une version, pour constater
ensuite que c'est trop general, ou pas assez, trop abstrait, ou pas assez.
Et devoir bouger les choses pour obtenir du code plus efficace.
Entre calculer une valeur a chaque fois, la garder en cache, mettre un
mecanisme plus complexe pour la manipuler, ca n'est pas du tout evident
ou se situe le bon choix, dans certains cas... et un bon choix pour une V0
se trouvera peut-etre ne pas resister a une V1.
Sans compter le fait que tu apprends tout le temps de nouvelles techniques.
L'utilisation de meilleurs design patterns, par exemple, peut t'amener
a manipuler ton code de facon assez brutale.
>Je ne sais pas ce que veut dire : "de meilleurs algorithmes". Là encore,
>si le code était écrit seulement par des professionnels qui connaissent
>leur métier, les algorithmes seraient ceux qui sont adaptés à une
>situation données et surtout ce seraient ceux qui résultent des
>structures de données adéquates en fonction des problèmes à résoudre.
Oh les oeilleres.
Les algorithmes classiques: bien sur qu'on ne va pas inventer grand chose.
Mais sur les problemes reels, tu as plusieurs facons d'organiser les choses
et de faire les calculs, et celles-ci ne vont pas conduire aux memes
solutions. Et tout n'est pas fini de defricher. Dans les systemes
interactifs, tu as souvent une bonne doses de probabilite et d'heuristiques.
Compare les premiers ordonnanceurs de systeme Unix avec ce qui se fait
aujourd'hui. Ou les algos de gestion de la memoire virtuelle. Et reviens
me dire que tout est fige et termine.
Bon, d'accord, je suis sans doute pas mal influence par ma formation.
Puisque j'ai fait mon doctorat en combinatoire, et que mon sujet de
these, c'etait precisement des techniques algorithmiques appliquees
a de gros problemes pas simples... donc je ne suis sans doute pas
informaticien purement industriel... ;-)
>> Ils resolvent des projets de maniere trop complexe, en mettant
>> en place des structures de donnees inutiles, et en calculant dix fois trop
>> de chose par rapport a ce qui est reellement demande.
>
>Il faut commencer par leur apprendre à lire des cahiers des charges
>(besoins et exigences) et à les respecter ! (même dans un TP de 50 lignes)
Sauf que dans mon cas, je leur donne les specs fonctionnelles, et des indices
sur une facon "correcte" de l'implementer. Et c'est a eux de finir les specs
techniques. Et parfois j'ai de grosses surprises.
C'est certainement lie aussi au fait que j'anime une formation relativement
courte, et qu'on n'a pas necessairement le temps de reprendre toutes les
bases proprement...
Wykaaa
Ceci est un vrai problème car de nombreux étudiants pensent que, parce
qu'ils ont écrit un programme, seul, de 200 lignes et qui "marchent",
ils sont de "vrais" programmeurs...
> Je ne suis pas sur que l'objet soit assimilable correctement sans être
> passé par une phase moins abstraite. Pour faire comprendre le besoin
> d'abstraction il est bon de faire du bas niveau et d'en mesurer toutes
> les difficultés en terme de génie logiciel.
Pédagogiquement, ça peut être une possibilité. En faisant un petit
historique des langages en introduction du cours de programmation, on
peut montrer comment, dans les langages, on va vers toujours plus
d'abstraction et que ce n'est pas un hasard.
Cette introduction pourra être illustrée, plus tard, lors de travaux
pratiques.
> Pour les passionnés de hardware il leur est difficile de quitter ce
> bas niveau. Passer de l'assembleur au C peut être vécu comme un
> traumatisme alors passer du C à C++ java ou Ada...
Certes. J'ai eu à former au langage C des gens qui ne connaissaient que
l'assembleur. Ils voulaient à tout prix savoir comment étaient
implémentés les "enum". J'ai satisfait leur curiosité mais je leur est
dit également que de tels traits de langage étaient là pour se détacher
des représentations "machines", justement !
> Par contre Ada offre quelque chose d'intéressant c'est le contrôle du
> mapping entre le haut et le bas niveau
Tu parles des clauses de représentation ?
> ainsi que les possibilité
> d'interfaçage entre langages différents.
De ce point de vue Ada n'est pas le seul...
>
> Dans mon activité professionnelle je suis toujours resté pragmatique,
> n'utiliser que les choses dont j'ai besoin. J'utilise l'objet
> essentiellement pour ses capacités de liaison dynamique et les types
> de données abstraits pour le reste car je préfère la composition à
> l'héritage. Donc des arbres d'héritage plats (du type balais quoi).
Ce n'est pas une question de préférence mais de "qui fait le mieux le job".
Réfléchis à ceci, que je répète en cours : "la chasse aux switches est à
la programmation objet ce que la chasse aux goto est à la programmation
structurée". Dans cette optique, il faut utiliser beaucoup l'héritage et
le polymorphisme.
Je considère qu'il vaut mieux programmer en C que de mal programmer en
C++ car on engendre plus de "catastrophes".
>
> Pour le reste j'ai apprécié le tasking Ada pour paralléliser une
> grosse application de calcul en fortran sans en changer la structure
> (quelque dizaines de lignes de code très localisées) grâce à une
> librairie Ada très simple d'utilisation assurant le parallèlisme.
Oui, ceci est un plus en Ada.
>
> J'ai apprécié la généricité de Ada qui m'a permis de gagner un ordre
> de grandeur en taille de code et en maintenabilité sur un module
> important d'une grosse application de 800k lignes. Sans parler de la
> séparation entre les spécifications et le codage qui est devenue pour
> moi un outil de design indépendant du langage de programmation. Je
> code les specs en Ada en conception et je programme en C++ en ce
> moment (je n'ai pas le choix du langage de programmation)..
La séparation entre les spécifications et le codage, en Ada, est une des
plus belles réussites du langage. Je suis plus réservé sur la façon dont
la généricité se fait en Ada.
>
> La majorité du code développé dans mon unité a été développée en
> fortran. Aujourd'hui ils veulent passer en C++, c'est difficile car C+
> + n'est pas bien adapté au calcul scientifique notamment le traitement
> des tableaux : résultat chaque programmeur à sa propre solution. Il y
> a assez peu d'unité de style malgré un manuel de programmation
> conséquent.
J'ai aussi formé des programmeurs Fortran au C++ sans passer par la case
C. Ca a été très difficile car en Fortran, il n'y a pas de type (au sens
où on l'entend dans les langages "modernes"), pas de pointeurs, le
passage de paramètres se fait par référence, etc.
>
> Après 40 ans de développement je suis atterré par la prolifération des
> langages, qui réinventent (mal) la roue. L'informatique est redevenue
> une tour de Babel.
C'est comme si on faisait table rase du passé. C'est totalement absurde,
je suis d'accord avec toi. Il y a quantité de "nouveaux" langages qui
sont des aberrations (je ne les citerais pas par charité...).
> Avant on spécialisait un langage pour un hardware
> aujourd'hui on invente un nouveau langage pour chaque nouveau type
> d'application. Et chaque nouveau langage apporte un petit plus et
> beaucoup de moins car il est centré sur un type de traitement et
> néglige les fondamentaux : exemple python qui ne connait pas
> l'encapsulation, résultat : impossible de garantir le bon
> fonctionnement.
Je ne comprends pas, qu'après 50 ans de catastrophes informatiques, on
invente un "nouveau" langage sans mécanisme d'encapsulation. S'il y a
bien un concept fondamental en programmation, c'est l'encapsulation.
>
> Au lieu d'apprendre 4 ou 5 langages importants et établis on doit en
> apprendre une vingtaine qui évoluent rapidement dans le temps pour
> pouvoir faire face à la prolifération des applications. Et avec cela
> la gestion de configuration est devenue un problème à l'échelle
> mondiale (J.P. Rosen).
Mais, à l'époque actuelle, on croirait que les "informaticiens" (je mets
des guillemets, surtout compte tenu de ce que j'ai répondu à Marc Espie)
n'ont tiré aucun bénéfice de toute la littérature existante sur
l'ingénierie du logiciel...
>
> Pardon pour ces récriminations d'un candidat à la retraite mais je
> souhaite bon courage aux enseignants et aux élèves. J'espère que
> quelques esprits avisés auront le courage de dire stop à la
> prolifération des "technologies" obsolètes avant d'être matures.
Et il y en a des quantités !
> Si
> l'on doit se différencier c'est dans les services qu'on rend et la
> satisfaction des besoins et non dans l'invention d'un autre langage de
> programmation. Il vaut mieux faire progresser les langages établis,
> tout le monde en tirera profit.
110% d'accord avec toi.
>
> Un bon moyen d'avancer c'est de promouvoir les normes. Si tous les
> cahiers des charges avaient comme obligation d'obliger à utiliser les
> normes et on serait tenus de faire avancer ces normes pour progresser.
>
Je suis depuis peu à la retraite et je n'ai cessé de milité pour les
normes et les standards mais j'avais souvent l'impression de prêcher
dans le désert. D'ailleurs on constate aujourd'hui, une très grande
disparité dans le traitement que font les navigateurs des pages HTML et
du Javascript alors qu'il existe des standards (EcmaScript pour
JavaScript). C'est tout simplement inadmissible et Microsoft n'est pas
pour rien dans cet état de fait...
D'ailleurs j'ai vu cette citation un jour quelque part sur Internet et
je la trouve assez juste :
"Microsoft a fait à l'informatique ce que MacDonald a fait à la
gastronomie."
Marc Espie
Wykaaa <wyk...@yahoo.fr> wrote:
>D'ailleurs j'ai vu cette citation un jour quelque part sur Internet et
>je la trouve assez juste :
>"Microsoft a fait à l'informatique ce que MacDonald a fait à la
>gastronomie."
Ca peut se decliner en
"Le logiciel Microsoft se compare au logiciel comme la musique militaire se
compare a la musique."
Wykaaa
> In article <49948f0e$0$4060$ba4a...@news.orange.fr>,
> Wykaaa <wyk...@yahoo.fr> wrote:
>> éventuellement), compréhensibles sans des tonnes de documentation,
>> pérennent (donc qui s'appuient et utilisent les standards), qui
>> correspondent aux besoins exprimés, qui soient faciles d'emploi (pas
>> seulement pour les utilisateurs mais qui soient faciles à installer, à
>> configurer, à administrer). Il y a encore d'autre impératifs mais
>> ceux-ci sont les plus importants.
>
> Tu raisonnes sur un cas precis de projet fortement industriel, ou le cahier
> des charges est parfaitement defini avant d'ecrire la moindre ligne de code,
> et ou il y a separation complete entre la maitrise d'ouvrage et la maitrise
> d'oeuvre.
Ce n'est pas un cas précis, ça concerne des centaines de millions de
lignes de code !
>
> Ca n'est pas toujours le cas. Il m'arrive tres souvent d'etre dans des
> situations ou on va commencer par resoudre un gros bout du probleme, histoire
> de savoir comment resoudre la suite... sachant qu'il faut deja la premiere
> version a montrer au client avant d'ecrire la suivante.
Ca s'appelle construire un prototype et il y a des méthodes pour faire
ça proprement. Quand on fait un prototype (je distingue maquette jetable
et prototype), on essaie de garder le code écrit tout au long du
processus pour le logiciel final.
>
> C'est juste une question de contexte. Comme je fais une grosse partie
> de mon dev. plus ou moins "tout seul" sur du logiciel libre, la ressource
> cruciale, c'est mon temps, et toute technique qui me permet d'en faire plus
> en un temps fini (sans sacrifier a la qualite, et meme en obtenant une
> meilleure qualite) est bonne a prendre.
J'ai fait aussi du logiciel pour moi (pour la musique, en particulier
communiquer des ordres à du matériel via le protocole MIDI). C'était en
assembleur et je n'ai pas documenté. Un an après, j'étais incapable de
comprendre mon propre code pour le modifier !
>
> Les techniques de developpement rapide d'applications et de refactoring
> se sont averees cruciales pour pas mal de mes projets, qui tournent
> maintenant dans 100% des cas. Alors que, a temps egal, si j'avais fait
> l'approche specs formelles -> codage, j'en serais a 25% ou a peu pres...
Donnes-tu ce code à d'autres à des fins de modifications ?
>
>
>>> En general, sur un gros projet, tu vas pouvoir organiser les choses en
>>> sous-systemes relativement bien definis. C'est important de pouvoir avoir
>>> des specs extremement formelles avec une bonne "barriere d'abstraction"
>>> qui permettra de coder d'apres les specs.
>> Je ne vois pas pourquoi ce que tu dis serait réservé seulement aux gros
>> projets. J'ai tendance à dire que plus c'est compliqué et plus il faut
>> faire simple (pas simpliste !) mais c'est très dur. Ce n'est pas pour
>> autant que les choses simples doivent être construites malproprement ou
>> de façon compliquée !
>
> Ca veut juste dire que tu peux te permettre d'avoir quelques couplages au
> sein d'un sous-systeme si celui-ci n'est pas trop technique (je presume
> que tu es familier de Lakos et que je n'ai pas besoin de definir le terme
> de couplage).
>
Faible couplage et forte cohésion n'ont aucun secret pour moi ;-)
>
>> Non justement. Ce sont l'erreur et le raisonnement que que font et
>> tiennent plus de 90% des développeurs. Car si on est laxiste à ce niveau
>> là, le temps qu'on aura soi-disant "économisé" sera perdu au centuple en
>> maintenance et lors des évolutions ultérieures.
>
> Je ne parle pas d'etre laxiste. Juste eviter d'etre abstrait pour le plaisir
> et de surspecifier pour rien.
La frontière entre abstraction/encapsulation et surspécification est un
vrai problème et pour les professionnels et pour les débutants. Trouver
la "bonne pédagogie" sur ce sujet est un défi, je te l'accorde.
>
>> D'ailleurs il y a belle lurette que les spécialistes ont abandonné
>> l'idée de pratiquer des preuves formelles sur le code.
>> La seule méthode que je connaisse (mais je ne connais pas tout dans ce
>> domaine) concernant les preuves formelles qui a quelques réussites dans
>> l'industrie, c'est la méthode B utilisée pour le métro Météor, entre autre.
>
> J'en connais quelques autres qui marchent plus ou moins, ayant des camarades
> qui se sont oriente sur la voie des preuves formelles. Il y a des choses
> qui fonctionnent etonnamment bien, tant qu'ils ne se heurtent pas a une
> grosse explosion combinatoire...
>
Je crois profondément qu'on ne peut pas grand chose face à l'explosion
combinatoire.
>> Si les principes de l'ingénierie logicielle, tels qu'ils sont décrits,
>> par exemple, dans les document de l'IEEE (Software Engineering Pratices)
>> étaient respectés on ne devrait pas se retrouver avec du code tel que tu
>> le décris...
>
> Pas du tout d'accord. Il y a des choix a faire dans l'ecriture du code.
> Certains sont evidents, d'autres sont des compromis. Et tu peux faire un
> compromis dans un sens lors de l'ecriture d'une version, pour constater
> ensuite que c'est trop general, ou pas assez, trop abstrait, ou pas assez.
> Et devoir bouger les choses pour obtenir du code plus efficace.
> Entre calculer une valeur a chaque fois, la garder en cache, mettre un
> mecanisme plus complexe pour la manipuler, ca n'est pas du tout evident
> ou se situe le bon choix, dans certains cas... et un bon choix pour une V0
> se trouvera peut-etre ne pas resister a une V1.
C'est pour cette raison qu'il faut écrire du code facilement évolutif
dès le début. Il n'y a pas de secret. Les choses dont on sait (on ne
sait pas toujours, raison de plus...) qu'elles vont bouger doivent être
particulièrement modulaires et encapsulées à coup d'abstraction, justement.
>
> Sans compter le fait que tu apprends tout le temps de nouvelles techniques.
> L'utilisation de meilleurs design patterns, par exemple, peut t'amener
> a manipuler ton code de facon assez brutale.
>
Tu apportes de l'eau à mon moulin. C'est le problème de la stabilité du
code face aux modifications. Pour qu'un code soit le plus stable
possible, il doit respecter toutes les qualités que j'ai énoncées au début.
>> Je ne sais pas ce que veut dire : "de meilleurs algorithmes". Là encore,
>> si le code était écrit seulement par des professionnels qui connaissent
>> leur métier, les algorithmes seraient ceux qui sont adaptés à une
>> situation données et surtout ce seraient ceux qui résultent des
>> structures de données adéquates en fonction des problèmes à résoudre.
>
> Oh les oeilleres.
>
J'ai été un peu brutal à dessein mais ne fais pas l'effarouché car je
sais que tu comprends très bien ce que je voulais dire ;-)
> Les algorithmes classiques: bien sur qu'on ne va pas inventer grand chose.
>
> Mais sur les problemes reels,
Les algorithmes classiques résolvent des problèmes réels !
> tu as plusieurs facons d'organiser les choses
> et de faire les calculs, et celles-ci ne vont pas conduire aux memes
> solutions. Et tout n'est pas fini de defricher. Dans les systemes
> interactifs, tu as souvent une bonne doses de probabilite et d'heuristiques.
> Compare les premiers ordonnanceurs de systeme Unix avec ce qui se fait
> aujourd'hui. Ou les algos de gestion de la memoire virtuelle. Et reviens
> me dire que tout est fige et termine.
>
Bien sûr que rien n'est figé, c'est bien pour ça que le code doit être
é-vo-lu-tif et je te laisse donc en déduire les conséquences sur le code
qu'on écrit...
> Bon, d'accord, je suis sans doute pas mal influence par ma formation.
> Puisque j'ai fait mon doctorat en combinatoire, et que mon sujet de
> these, c'etait precisement des techniques algorithmiques appliquees
> a de gros problemes pas simples... donc je ne suis sans doute pas
> informaticien purement industriel... ;-)
>
Ne prends pas argument de tes activités d'alors, qui relevaient
justement de la recherche et non de l'industrie, pour me contredire sur
le terrain industriel ;-D
>
>>> Ils resolvent des projets de maniere trop complexe, en mettant
>>> en place des structures de donnees inutiles, et en calculant dix fois trop
>>> de chose par rapport a ce qui est reellement demande.
>> Il faut commencer par leur apprendre à lire des cahiers des charges
>> (besoins et exigences) et à les respecter ! (même dans un TP de 50 lignes)
>
> Sauf que dans mon cas, je leur donne les specs fonctionnelles, et des indices
> sur une facon "correcte" de l'implementer. Et c'est a eux de finir les specs
> techniques. Et parfois j'ai de grosses surprises.
Mais en l'occurrence, si je comprends bien, ça fait partie de l'exercice
de leur laisser affiner les specs techniques. Ils faut bien qu'ils
apprennent !
Ne les accablent pas =8-)
>
> C'est certainement lie aussi au fait que j'anime une formation relativement
> courte, et qu'on n'a pas necessairement le temps de reprendre toutes les
> bases proprement...
Mais ça c'est un réel problème dans l'enseignement en général, hélas !
Marc Espie
Wykaaa <wyk...@yahoo.fr> wrote:
>> Les techniques de developpement rapide d'applications et de refactoring
>> se sont averees cruciales pour pas mal de mes projets, qui tournent
>> maintenant dans 100% des cas. Alors que, a temps egal, si j'avais fait
>> l'approche specs formelles -> codage, j'en serais a 25% ou a peu pres...
>
>Donnes-tu ce code à d'autres à des fins de modifications ?
Oui et non. D'autres personnes lisent ce code et suggerent des evolutions.
Une grosse partie du refactoring vise a simplifier et mieux documenter.
Souvent, trouver de meilleurs noms de fonctions, virer des commentaires,
rajouter de la doc formelle, et corriger des comportements specifiques.
Un de mes plus "gros" projets perso est le systeme de gestion de packages
d'OpenBSD. C'est un tout assez complexe, qui fait intervenir le systeme
de build (essentiellement du Makefile non portable et du shell) et les outils
de gestions de packages eux-memes (du perl construit a partir d'une
bibliotheque de gestion de formats de fichiers).
Il y eu un cahier des charges initial (remplacer les outils existants par
des outils equivalents et plus fiables...), pas mal d'evolutions (simplifier
au maximum la procedure de portage de nouveau logiciel, rajouter des outils
de verification de coherence), et un cahier des charges futur un peu flou
(gerer les mises-a-jour de la facon la plus simple possible pour
l'utilisateur final).
Pas mal de details de la version actuelle ne sont apparus qu'assez tard. Il
y a des cas de figure extremement tordus de mise-a-jour que personne n'avait
prevu initialement (on a eu une inversion de dependances entre packages dans
gnome par exemple), des contraintes liees aux systemes (une enorme couche
de compatibilite pour pouvoir "fonctionner" avec des serveurs ftp fortement
buggues, et des evolutions ulterieures qui ne sont pas encore finies
(minimiser la quantite d'annotation necessaire a placer dans un package pour
gerer des cas tordus).
Une grosse partie de la complexite du probleme, c'est qu'OpenBSD est fortement
sous-staffe pour ce bout du projet: tu dois avoir 30 developpeurs qui gerent
pas moins de 6000 ports. Toute simplification non abusive est bonne a
prendre. Tout outil de verification automatique aussi.
Je suis parti d'un existant assez bancal, j'ai completement abandonne ce
que faisaient les voisins (Net et Free) qui ont eu (a mon avis) l'idee
totalement idiote d'avoir des outils elementaires sur lesquels on empile
des couches plus complexes: le souci dans ce contexte etant que les outils
elementaires n'ont qu'une idee tres approximative de la semantique du probleme,
donc les couches superieures passent leur temps a essayer de reconstituer
des informations "perdues" qui devraient etre presentes des le depart, et
ce parfois a plusieurs niveaux (avec a chaque fois des implementations
differentes, et donc de gros soucis de coherence de l'information). Le fait
d'avoir une bibliotheque unifiee qui me permettait de parler de packing-list
(manifeste, si tu preferes) et de gerer les dependances de facon globale
et intelligente) s'est avere un progres capital.
Les outils sont "ouverts" depuis les debuts. Les premieres versions etaient
un "prototype fonctionnel", et l'API de la bibliotheque a ete documentee en
meme temps qu'elle s'est figee...
Pour le Makefile des ports, il y a environ 3000 lignes de Makefile et autant
de page de man.... le boulot de documentation a ete capital pour affiner
la semantique de la chose. J'avoue que j'ai beaucoup appris la-dessus,
arriver a obtenir quelque chose de coherent cote ordre d'evaluation d'un
Makefile est loin d'etre trivial (et il s'agit d'un vrai Makefile, alors
que l'objet dont je suis parti etait plus proche d'une collection de
shell-scripts mal recolles, avec la moitie des dependances mal explicitees
et des tonnes de cas ou l'evaluation ne se faisait pas dans le bon ordre).
Wykaaa
Je veux bien te croire !
> (et il s'agit d'un vrai Makefile, alors
> que l'objet dont je suis parti etait plus proche d'une collection de
> shell-scripts mal recolles, avec la moitie des dependances mal explicitees
> et des tonnes de cas ou l'evaluation ne se faisait pas dans le bon ordre).
C'est intéressant cette expérience mais elle se situe dans le domaine du
logiciel libre. Attention, je n'ai rien contre le logiciel libre, bien
au contraire, mais c'est quand même particulier car du point de vue de
la structure projet ça ne fonctionne pas du tout comme dans l'industrie
et, du coup, pas mal d'aspects "génie logiciel" n'ont pas cours.
Ceci n'empêche pas d'écrire ponctuellement du bon code mais personne ne
fait réellement la glue entre les interfaces et ce sont ces couches qui
sont souvent remises en question dans le libre.
Il est clair que mon discours, dans ce contexte, doit être nuancé, je te
l'accorde.
PS : à l'époque du zénith de X11, j'ai un ancien étudiant qui a
développé 60 000 lignes de gnu make (!) pour le rendre objet. C'était
génial. Dans son environnement (c'est juste un exemple de ce qu'on
pouvait faire), on cliquait (droit) sur un fichier et, en fonction de
son type, ça ouvrait un menu qui listait les actions possibles sur le
fichier et, par exemple, si le fichier était éditable et si on demandait
à le modifier, ça ouvrait le bon éditeur en fonction du type de fichier.
Michael DOUBEZ
A propos. Je viens d'apprendre que adware avait été écris en Scheme.
http://philosecurity.org/2009/01/12/interview-with-an-adware-author
[snip]
>> Je ne suis pas sur que l'objet soit assimilable correctement sans être
>> passé par une phase moins abstraite. Pour faire comprendre le besoin
>> d'abstraction il est bon de faire du bas niveau et d'en mesurer toutes
>> les difficultés en terme de génie logiciel.
>
> Pédagogiquement, ça peut être une possibilité. En faisant un petit
> historique des langages en introduction du cours de programmation, on
> peut montrer comment, dans les langages, on va vers toujours plus
> d'abstraction et que ce n'est pas un hasard.
Je me souviens des mes cours de langage et nous avions eu un topo sur
l'évolution des langages. L'évolution en abstraction était évidente mais
l'impression que j'en ai retiré est que le monde s'est arrêté aux
L3G/L4G sauf en environnement universitaire.
Beaucoup de langages présenté (comme ALGOL, Eiffel) restaient du domaine
de philosophique et ne témoignaient que de la nature empirique de la
création d'un langage.
Mon impression aujourd'hui est que le niveau d'abstraction augmente mais
pas du point de l'expression du langage mais des fonctionnalités
(orienté business). Il suffit de voir comment Java, C# ou PHP offrent
une foultitude d'abstraction de l'OS, des accès physiques ...
On pourrait penser que c'est une contrainte des langages dynamique ou
sur machine virtuelle mais il suffit de voir l'importance que prennent
par exemple les pattern pour voir que nous sommes dans une phase ou un
langage de programmation est une méthode de composition de systèmes et
non plus un générateur d'instruction.
Un autre exemple est qu'aujourd'hui il est possible de faire un jeux 3D,
complexe, efficaces avec juste du XML (voir le moteur CristalSpace).
[snip]
>> Dans mon activité professionnelle je suis toujours resté pragmatique,
>> n'utiliser que les choses dont j'ai besoin. J'utilise l'objet
>> essentiellement pour ses capacités de liaison dynamique et les types
>> de données abstraits pour le reste car je préfère la composition à
>> l'héritage. Donc des arbres d'héritage plats (du type balais quoi).
>
> Ce n'est pas une question de préférence mais de "qui fait le mieux le job".
> Réfléchis à ceci, que je répète en cours : "la chasse aux switches est à
> la programmation objet ce que la chasse aux goto est à la programmation
> structurée". Dans cette optique, il faut utiliser beaucoup l'héritage et
> le polymorphisme.
L'avantage du polymorphisme est surtout que c'est le moyen, à priori, de
réaliser l'inversion de dépendance. Là où le procédural impose une
conception bottom-up, l'objet permet une conception top-down.
> Je considère qu'il vaut mieux programmer en C que de mal programmer en
> C++ car on engendre plus de "catastrophes".
Surtout que bien programmer en C consiste souvent à y faire de l'objet.
La vrai innovation du c++ AMA est que là où la programmation objet
abstrait les données, le mécanisme des templates permet d'abstraire les
algorithmes (c'est le cheval de bataille d'Alexandre Stephanov).
Quand on pense que la base de la programmation est des données + des
algorithmes, on voit ici qu'il est possible d'abstraire les deux.
[snip]
>> Après 40 ans de développement je suis atterré par la prolifération des
>> langages, qui réinventent (mal) la roue. L'informatique est redevenue
>> une tour de Babel.
>
> C'est comme si on faisait table rase du passé. C'est totalement absurde,
> je suis d'accord avec toi. Il y a quantité de "nouveaux" langages qui
> sont des aberrations (je ne les citerais pas par charité...).
Il y a aussi, je pense, un effet de libération. La conception de langage
était réservée à une élite qui savait écrire un compilateur).
L'émergence des machines virtuelles, du JIT ... permet de développer
plus facilement un langage (plus la puissance des machines).
Par exemple, la publication de la machine virtuelle Java a permis à des
langages comme Groovy d'exister (plus JRuby, JPython ...).
>> Avant on spécialisait un langage pour un hardware
>> aujourd'hui on invente un nouveau langage pour chaque nouveau type
>> d'application. Et chaque nouveau langage apporte un petit plus et
>> beaucoup de moins car il est centré sur un type de traitement et
>> néglige les fondamentaux : exemple python qui ne connait pas
>> l'encapsulation, résultat : impossible de garantir le bon
>> fonctionnement.
>
> Je ne comprends pas, qu'après 50 ans de catastrophes informatiques, on
> invente un "nouveau" langage sans mécanisme d'encapsulation. S'il y a
> bien un concept fondamental en programmation, c'est l'encapsulation.
Beaucoup de gens pensent que l'encapsulation ne sers qu'à contrôler
l'accès aux données (ajouter des effets de bord ...). J'ai souvent vu
cette idée, dans des livres (un écrit par un MVP Microsoft) et même dans
un QCM de recrutement.
D'un point de vue pratique, ça ne change pas grand chose mais ça montre
que l'encapsulation n'est pas aussi populaire que ça.
>> Au lieu d'apprendre 4 ou 5 langages importants et établis on doit en
>> apprendre une vingtaine qui évoluent rapidement dans le temps pour
>> pouvoir faire face à la prolifération des applications. Et avec cela
>> la gestion de configuration est devenue un problème à l'échelle
>> mondiale (J.P. Rosen).
>
> Mais, à l'époque actuelle, on croirait que les "informaticiens" (je mets
> des guillemets, surtout compte tenu de ce que j'ai répondu à Marc Espie)
> n'ont tiré aucun bénéfice de toute la littérature existante sur
> l'ingénierie du logiciel...
Oui, ça fait froid dans le dos de penser que les problème de protocoles
déconnectés (HTTP) sur lesquels plus d'une organisation a buté étaient
résolus depuis 50 ans par ceux qui travaillent sur les mainframes.
Le mouvement des design pattern est là pour transmettre ces connaissance
et c'est un bon espoir mais aujourd'hui, quand on parle de pattern, on
parle de ceux du GoF-book. Récemment, en entretien, j'ai mentionné les
rencontres EuroPlop et POSA et ceux-ci étaient inconnus au bataillon de
même que les livres qui s'y rapportent.
[snip]
>> Si
>> l'on doit se différencier c'est dans les services qu'on rend et la
>> satisfaction des besoins et non dans l'invention d'un autre langage de
>> programmation. Il vaut mieux faire progresser les langages établis,
>> tout le monde en tirera profit.
>
> 110% d'accord avec toi.
C'est pas assez *morderne* :)
--
Michael
Marc Espie
<cjps...@gmail.com> wrote:
>Au lieu d'apprendre 4 ou 5 langages importants et établis on doit en
>apprendre une vingtaine qui évoluent rapidement dans le temps pour
>pouvoir faire face à la prolifération des applications. Et avec cela
>la gestion de configuration est devenue un problème à l'échelle
>mondiale (J.P. Rosen).
A cote de ca, il n'y a rien de neuf a apprendre. Les langages industriels
sont tous les memes. Tu en connais deux, tu les connais tous.
L'apprentissage de la prog va super-vite passe les deux premiers langages.
Le vrai souci, ce sont les langages sous-specifies, sur lesquels tu ne trouves
que des bouts eparts de doc (ou pour lequel il faut payer tres cher pour avoir
la vraie doc).
Apres, j'avais lu une interview d'un des createurs de smalltalk qui disaient
des choses tres justes et un peu choquantes la-dessus: selon lui, il y avait
un vrai nouveau langage novateur tous les dix ans ou a peu pres... mais le
dernier "saut" s'etait arrete en 1980... ce qui veut dire qu'on avait "perdu"
trois revolutions quelque part... ca correspond malheureusement trop bien
a une industrialisation precoce de l'informatique.
Cyniquement, je n'ai aucune raison de penser que l'histoire des langages
innovants doive s'arreter vers 1980. Je soupconne juste qu'on est (dans
notre ensemble) trop cons pour la suite, dans l'immediat...
Wykaaa
Les L4G ne sont pas des vrais langages de programmation car ils ne sont
pas "Turing complet" : ça signifie, du point de vue théorique, que tous
les algorithmes ne sont pas programmables en L4G.
De quoi parle-t-on en plus dans le monde universitaire au point de vue
des langages ? Y aurait-il des L5G ?
> Beaucoup de langages présenté (comme ALGOL, Eiffel) restaient du domaine
> de philosophique et ne témoignaient que de la nature empirique de la
> création d'un langage.
Je ne comprends pas ce sue tu veux dire. ALGOL est LE langage le plus
important dans l'histoire de la programmation car c'est le premier
langage de haut niveau à structure de bloc, possédant la récursion, etc.
Dans Pascal, Ada, Modula, etc. il y a au moins 60% d'Algol.
Tout langage moderne (c'est à dire depuis Pascal en 1970) est un langage
à structure de bloc.
Sur le papier Eiffel est un des plus beaux langages à objet. Hélas
Bertrand Meyer a confié la réalisation du premeir compilateur à des
étudiants. Il y avait des défauts dans le rammasse-miette. Ceci rendait
le langage inutilisable industriellement. C'est dommage car, sinon, on
aurait peut-être évité l'horreur C++ (qui est finalement plutôt un
langages de pointeurs qu'un langage à objets...)
Tout ça pour dire que les exemples de langages procéduraux avec Algol et
objets avec Eiffel sont tout à fait pertinents et ne ressortent
absolument pas que du domaine philosophique.
>
> Mon impression aujourd'hui est que le niveau d'abstraction augmente mais
> pas du point de l'expression du langage mais des fonctionnalités
> (orienté business). Il suffit de voir comment Java, C# ou PHP offrent
> une foultitude d'abstraction de l'OS, des accès physiques ...
Ce ne sont pas les langages qui offrent ces librairies mais ces
librairies qui sont offertes dans ces langages (la foultitude en
question permet d'ailleurs de mesurer la popularité de tel ou tel
langage en fonction du nombre de librairies "offertes").
>
> On pourrait penser que c'est une contrainte des langages dynamique ou
> sur machine virtuelle mais il suffit de voir l'importance que prennent
> par exemple les pattern pour voir que nous sommes dans une phase ou un
> langage de programmation est une méthode de composition de systèmes et
> non plus un générateur d'instruction.
Oui, c'est ce que je disais je ne sais plus où dans ce fil : les
programmeurs sont de plus en plus des ensembliers/intégrateurs qui
mettent de la glue autour de fonctions/librairies existantes.
Je ne suis pas d'accord avec "un langage de programmation est une
méthode de composition de systèmes et non plus un générateur d'instruction".
Un langage de programmation reste un langage de programmation car même
la notion de package ne date pas d'hier , ni la séparation
spécification/implémentation (cette séparation existait déjà dans le
Pascal UCSD des années 70 !).
C'est la notion de librairie "autour" des langages de programmation qui
s'est développée et encore, en Fortran il y a belle lurette que les
programmeurs font de la réutilisation avec des librairie scientifiques
(calculs en précision n, fonctions mathématiques spécialisées,
algorithmes de calculs numériques performants, etc.).
Dans les langages eux-mêmes, on n'a rien inventé d'extraordinaire depuis
SIMULA (donc 1967)... à part la généricité qui est apparue dans Ada 83
(je ne tiens compte que des langages visibles du "grand public").
>
> Un autre exemple est qu'aujourd'hui il est possible de faire un jeux 3D,
> complexe, efficaces avec juste du XML (voir le moteur CristalSpace).
Tu veux dire qu'on peut "scripter" Crystal Space en XML (aussi en Python
d'ailleurs) sinon Crystal Space et Ogre 3D sont écrits en C++ ainsi que
leurs bibliothèques (voir http://www.arcanoria.com/CS-Ogre.php).
>
> [snip]
>>> Dans mon activité professionnelle je suis toujours resté pragmatique,
>>> n'utiliser que les choses dont j'ai besoin. J'utilise l'objet
>>> essentiellement pour ses capacités de liaison dynamique et les types
>>> de données abstraits pour le reste car je préfère la composition à
>>> l'héritage. Donc des arbres d'héritage plats (du type balais quoi).
>>
>> Ce n'est pas une question de préférence mais de "qui fait le mieux le
>> job".
>> Réfléchis à ceci, que je répète en cours : "la chasse aux switches est
>> à la programmation objet ce que la chasse aux goto est à la
>> programmation structurée". Dans cette optique, il faut utiliser
>> beaucoup l'héritage et le polymorphisme.
>
> L'avantage du polymorphisme est surtout que c'est le moyen, à priori, de
> réaliser l'inversion de dépendance. Là où le procédural impose une
> conception bottom-up, l'objet permet une conception top-down.
Le procédural permet aussi le développement top-down (on écrit le main
d'abord avec des "stubs" vides ou rudimentaires et on raffine. On sait
faire ça depuis des lustres (50 ans)...
>
>> Je considère qu'il vaut mieux programmer en C que de mal programmer en
>> C++ car on engendre plus de "catastrophes".
>
> Surtout que bien programmer en C consiste souvent à y faire de l'objet.
> La vrai innovation du c++ AMA est que là où la programmation objet
> abstrait les données, le mécanisme des templates permet d'abstraire les
> algorithmes (c'est le cheval de bataille d'Alexandre Stephanov).
Le concept de template (généricité) n'est pas un concept objet. La
preuve, Ada 83, qui n'est pas un langage objet, possède la généricité et
ML (standardisé en 1983), qui est un langage fonctionnel (impur car on
peut y programmer en impératif) non objet, possède le polymorphisme
(polymorphisme universel, différent du polymorphisme d'héritage).
>
> Quand on pense que la base de la programmation est des données + des
> algorithmes, on voit ici qu'il est possible d'abstraire les deux.
> [snip]
>>> Après 40 ans de développement je suis atterré par la prolifération des
>>> langages, qui réinventent (mal) la roue. L'informatique est redevenue
>>> une tour de Babel.
>>
>> C'est comme si on faisait table rase du passé. C'est totalement
>> absurde, je suis d'accord avec toi. Il y a quantité de "nouveaux"
>> langages qui sont des aberrations (je ne les citerais pas par
>> charité...).
>
> Il y a aussi, je pense, un effet de libération. La conception de langage
> était réservée à une élite qui savait écrire un compilateur).
> L'émergence des machines virtuelles, du JIT ... permet de développer
> plus facilement un langage (plus la puissance des machines).
>
> Par exemple, la publication de la machine virtuelle Java a permis à des
> langages comme Groovy d'exister (plus JRuby, JPython ...).
Tu veux dire que la prolifération des langages est l'effet de la
démocratisation dans ce domaine ?
>
>>> Avant on spécialisait un langage pour un hardware
>>> aujourd'hui on invente un nouveau langage pour chaque nouveau type
>>> d'application. Et chaque nouveau langage apporte un petit plus et
>>> beaucoup de moins car il est centré sur un type de traitement et
>>> néglige les fondamentaux : exemple python qui ne connait pas
>>> l'encapsulation, résultat : impossible de garantir le bon
>>> fonctionnement.
>>
>> Je ne comprends pas, qu'après 50 ans de catastrophes informatiques, on
>> invente un "nouveau" langage sans mécanisme d'encapsulation. S'il y a
>> bien un concept fondamental en programmation, c'est l'encapsulation.
>
> Beaucoup de gens pensent que l'encapsulation ne sers qu'à contrôler
> l'accès aux données (ajouter des effets de bord ...). J'ai souvent vu
> cette idée, dans des livres (un écrit par un MVP Microsoft) et même dans
> un QCM de recrutement.
Je pense qu'il y a peu d'informaticiens, hélas, qui comprennent que
l'encapsulation ce n'est pas seulement la "privatisation" des données...
mais aussi des fonctions et que le trio
modularité/encapsulation/généricité est extrêmement puissant pour rendre
les logiciels évolutifs, portables, adaptatifs à différents contexte (je
parle de versatilité de modules dans mes cours).
>
> D'un point de vue pratique, ça ne change pas grand chose mais ça montre
> que l'encapsulation n'est pas aussi populaire que ça.
Ben si c'est censé modifier des choses dans la pratique si les
informaticiens comprenaient réellement ce concept et donc savaient
réellement l'utiliser...
>
>>> Au lieu d'apprendre 4 ou 5 langages importants et établis on doit en
>>> apprendre une vingtaine qui évoluent rapidement dans le temps pour
>>> pouvoir faire face à la prolifération des applications. Et avec cela
>>> la gestion de configuration est devenue un problème à l'échelle
>>> mondiale (J.P. Rosen).
>>
>> Mais, à l'époque actuelle, on croirait que les "informaticiens" (je
>> mets des guillemets, surtout compte tenu de ce que j'ai répondu à Marc
>> Espie) n'ont tiré aucun bénéfice de toute la littérature existante sur
>> l'ingénierie du logiciel...
>
> Oui, ça fait froid dans le dos de penser que les problème de protocoles
> déconnectés (HTTP) sur lesquels plus d'une organisation a buté étaient
> résolus depuis 50 ans par ceux qui travaillent sur les mainframes.
Exactement. HTTP est un très bon exemple de la réinvention de la poudre
en informatique.
>
> Le mouvement des design pattern est là pour transmettre ces connaissance
> et c'est un bon espoir mais aujourd'hui, quand on parle de pattern, on
> parle de ceux du GoF-book. Récemment, en entretien, j'ai mentionné les
> rencontres EuroPlop et POSA et ceux-ci étaient inconnus au bataillon de
> même que les livres qui s'y rapportent.
Tu veux parler de ceci : http://www.cs.wustl.edu/~schmidt/POSA/ ?
Ce sont des livres essentiels.
> [snip]
>>> Si
>>> l'on doit se différencier c'est dans les services qu'on rend et la
>>> satisfaction des besoins et non dans l'invention d'un autre langage de
>>> programmation. Il vaut mieux faire progresser les langages établis,
>>> tout le monde en tirera profit.
>>
>> 110% d'accord avec toi.
>
> C'est pas assez *morderne* :)
L'effet de mode, en informatique, est au moins aussi destructeur que
dans d'autres domaine ...
Marc Espie
Wykaaa <wyk...@yahoo.fr> wrote:
>Ce ne sont pas les langages qui offrent ces librairies mais ces
>librairies qui sont offertes dans ces langages (la foultitude en
>question permet d'ailleurs de mesurer la popularité de tel ou tel
>langage en fonction du nombre de librairies "offertes").
BIBLIOTHEQUES, bon sang !
Pourquoi utiliser un anglicisme alors que tu as un terme francais
parfaitement approprie, parfaitement clair, et qui est la traduction
correcte de l'anglais "library" ?
Wykaaa
> In article <109ca232-df0d-4d35...@d32g2000yqe.googlegroups.com>,
> <cjps...@gmail.com> wrote:
>> Au lieu d'apprendre 4 ou 5 langages importants et établis on doit en
>> apprendre une vingtaine qui évoluent rapidement dans le temps pour
>> pouvoir faire face à la prolifération des applications. Et avec cela
>> la gestion de configuration est devenue un problème à l'échelle
>> mondiale (J.P. Rosen).
>
> A cote de ca, il n'y a rien de neuf a apprendre. Les langages industriels
> sont tous les memes. Tu en connais deux, tu les connais tous.
Mis à part quelques subtilités, d'ailleurs pas toujours bienvenues.
>
> L'apprentissage de la prog va super-vite passe les deux premiers langages.
> Le vrai souci, ce sont les langages sous-specifies, sur lesquels tu ne trouves
> que des bouts eparts de doc (ou pour lequel il faut payer tres cher pour avoir
> la vraie doc).
Il ne faut JAMAIS utiliser des langages sous-spécifiés mais seulement
des langages stan-dar-di-sés !
>
> Apres, j'avais lu une interview d'un des createurs de smalltalk qui disaient
> des choses tres justes et un peu choquantes la-dessus: selon lui, il y avait
> un vrai nouveau langage novateur tous les dix ans ou a peu pres... mais le
> dernier "saut" s'etait arrete en 1980... ce qui veut dire qu'on avait "perdu"
> trois revolutions quelque part... ca correspond malheureusement trop bien
> a une industrialisation precoce de l'informatique.
>
> Cyniquement, je n'ai aucune raison de penser que l'histoire des langages
> innovants doive s'arreter vers 1980. Je soupconne juste qu'on est (dans
> notre ensemble) trop cons pour la suite, dans l'immediat...
Si on prend, du point de vue théorique, le lamda-calcul typé, polymorphe
du second ordre, le pi-calcul et une pincée d'omega-calcul pour te faire
plaisir ;-), il ne reste plus grand-chose à inventer dans les langages
si ce n'est de mettre tout ça en oeuvre pratiquement dans des langages
de programmation compréhensibles par le commun des programmeurs.
Wykaaa
Mea culpa. Je me suis laissé emporté par ma culture anglo-saxonne.
Je suis d'accord avec toi Marc. Pas taper :-)
Marc Espie
>l'encapsulation ce n'est pas seulement la "privatisation" des données...
>mais aussi des fonctions et que le trio
>modularité/encapsulation/généricité est extrêmement puissant pour rendre
>les logiciels évolutifs, portables, adaptatifs à différents contexte (je
>parle de versatilité de modules dans mes cours).
Je pose souvent la question sur des entretiens de candidature: c'est quoi
pour vous le principal benefice de l'objet ?
La plupart me repondent "heritage". Bien peu pensent a "abstraction propre
et encapsulation"...
>> Oui, ça fait froid dans le dos de penser que les problème de protocoles
>> déconnectés (HTTP) sur lesquels plus d'une organisation a buté étaient
>> résolus depuis 50 ans par ceux qui travaillent sur les mainframes.
>
>Exactement. HTTP est un très bon exemple de la réinvention de la poudre
>en informatique.
Si encore ca n'etait que la reinvention de la poudre... c'est surtout de
la poudre inventee par un gus qui ne connaissait rien aux reseaux (en vrai)
et qui a donc concu le protocole "a l'envers", avec une charge supplementaire
enorme pour les serveurs (puisque la deconnexion se fait a l'envers de ce
qui est pratique ailleurs). Le plus gros benefice, ca a ete de forcer les gens
a faire des piles TCP/IP plus efficaces pour un protocole boiteux, un peu
comme la maniere qu'a Windows de s'etaler a aider les gens a recuperer des
machines plus rapides et avec plus de memoire pour faire tourner de vrais
OS...
Marc Espie
Wykaaa <wyk...@yahoo.fr> wrote:
>Il ne faut JAMAIS utiliser des langages sous-spécifiés mais seulement
>des langages stan-dar-di-sés !
Donc exit Java, puisque Sun a refuse le passage par ANSI de peur de se faire
pourrir les specs par microsoft...
>> Apres, j'avais lu une interview d'un des createurs de smalltalk qui disaient
>> des choses tres justes et un peu choquantes la-dessus: selon lui, il y avait
>> un vrai nouveau langage novateur tous les dix ans ou a peu pres... mais le
>> dernier "saut" s'etait arrete en 1980... ce qui veut dire qu'on avait "perdu"
>> trois revolutions quelque part... ca correspond malheureusement trop bien
>> a une industrialisation precoce de l'informatique.
>>
>> Cyniquement, je n'ai aucune raison de penser que l'histoire des langages
>> innovants doive s'arreter vers 1980. Je soupconne juste qu'on est (dans
>> notre ensemble) trop cons pour la suite, dans l'immediat...
>
>Si on prend, du point de vue théorique, le lamda-calcul typé, polymorphe
>du second ordre, le pi-calcul et une pincée d'omega-calcul pour te faire
>plaisir ;-), il ne reste plus grand-chose à inventer dans les langages
>si ce n'est de mettre tout ça en oeuvre pratiquement dans des langages
>de programmation compréhensibles par le commun des programmeurs.
Par nature, un des principes d'une invention, c'est que tu ne peux pas
forcement savoir ce qu'elle va etre avant de l'avoir rencontree...
Il est fort possible qu'on ait rate un paradigme extremement utile,
super-interessant, raisonnablement simple a mettre en oeuvre, juste parce
que personne n'y a encore pense.
Si je mets mon autre casquette de mathematicien, et que je regarde des "vieux"
bouquins d'il y a un siecle ou deux, il y a pas mal de concepts pas encore
tres bien formalises (la notion de limite et la notion d'espace vectoriel,
par exemple) qui ont l'air super-complexes et pas utilisables, alors
qu'aujourd'hui, tout ceci a ete "nettoye" et apparait comme etant trivial au
premier mathematicien venu...
Wykaaa
> In article <49955088$0$4077$ba4a...@news.orange.fr>,
> Wykaaa <wyk...@yahoo.fr> wrote:
>> Il ne faut JAMAIS utiliser des langages sous-spécifiés mais seulement
>> des langages stan-dar-di-sés !
>
> Donc exit Java, puisque Sun a refuse le passage par ANSI de peur de se faire
> pourrir les specs par microsoft...
Oui mais bon. C'est un cas spécial et on comprend Sun d'un certain côté...
Et puis Sun a déjà été échaudé par le passé avec la machine virtuelle
Java de Microsoft (bien que Sun ait gagné le procès et que Microsoft ait
du retiré Java de Windows. C'est d'ailleurs pour ça qu'il a fabriqué C#,
langage jumeau de Java...)
>
>>> Apres, j'avais lu une interview d'un des createurs de smalltalk qui disaient
>>> des choses tres justes et un peu choquantes la-dessus: selon lui, il y avait
>>> un vrai nouveau langage novateur tous les dix ans ou a peu pres... mais le
>>> dernier "saut" s'etait arrete en 1980... ce qui veut dire qu'on avait "perdu"
>>> trois revolutions quelque part... ca correspond malheureusement trop bien
>>> a une industrialisation precoce de l'informatique.
>>>
>>> Cyniquement, je n'ai aucune raison de penser que l'histoire des langages
>>> innovants doive s'arreter vers 1980. Je soupconne juste qu'on est (dans
>>> notre ensemble) trop cons pour la suite, dans l'immediat...
>> Si on prend, du point de vue théorique, le lamda-calcul typé, polymorphe
>> du second ordre, le pi-calcul et une pincée d'omega-calcul pour te faire
>> plaisir ;-), il ne reste plus grand-chose à inventer dans les langages
>> si ce n'est de mettre tout ça en oeuvre pratiquement dans des langages
>> de programmation compréhensibles par le commun des programmeurs.
>
> Par nature, un des principes d'une invention, c'est que tu ne peux pas
> forcement savoir ce qu'elle va etre avant de l'avoir rencontree...
Oui c'est sûr.
>
> Il est fort possible qu'on ait rate un paradigme extremement utile,
> super-interessant, raisonnablement simple a mettre en oeuvre, juste parce
> que personne n'y a encore pense.
Attelons-nous à la tâche :-)
>
> Si je mets mon autre casquette de mathematicien, et que je regarde des "vieux"
> bouquins d'il y a un siecle ou deux, il y a pas mal de concepts pas encore
> tres bien formalises (la notion de limite et la notion d'espace vectoriel,
> par exemple) qui ont l'air super-complexes et pas utilisables, alors
> qu'aujourd'hui, tout ceci a ete "nettoye" et apparait comme etant trivial au
> premier mathematicien venu...
Il y aurait des langages "au-dessus" des récursivement énumérables (type
0 au sens de Chomsky)A part inventer le "comefrom" (l'inverse du goto),
je ne vois pas ;-)
Non, je plaisante. Il me semble qu'il y a à creuser du côté de l'ajout
dynamique de méthodes à des objets pour garantir la fiabilité à
l'exécution. Dans le massivement parallèle, il y a à "nettoyer" dans les
langages (théoriques et pratiques).
Peut-être as-tu d'autres exemples en tête.
Michael DOUBEZ
>>>> Je ne suis pas sur que l'objet soit assimilable correctement sans être
>>>> passé par une phase moins abstraite. Pour faire comprendre le besoin
>>>> d'abstraction il est bon de faire du bas niveau et d'en mesurer toutes
>>>> les difficultés en terme de génie logiciel.
>>>
>>> Pédagogiquement, ça peut être une possibilité. En faisant un petit
>>> historique des langages en introduction du cours de programmation, on
>>> peut montrer comment, dans les langages, on va vers toujours plus
>>> d'abstraction et que ce n'est pas un hasard.
>>
>> Je me souviens des mes cours de langage et nous avions eu un topo sur
>> l'évolution des langages. L'évolution en abstraction était évidente
>> mais l'impression que j'en ai retiré est que le monde s'est arrêté aux
>> L3G/L4G sauf en environnement universitaire.
>
> Les L4G ne sont pas des vrais langages de programmation car ils ne sont
> pas "Turing complet" : ça signifie, du point de vue théorique, que tous
> les algorithmes ne sont pas programmables en L4G.
Ils suffisent pour faire du PL/SQL.
> De quoi parle-t-on en plus dans le monde universitaire au point de vue
> des langages ? Y aurait-il des L5G ?
Prolog principalement (uniquement d'ailleurs à ma connaissance sauf
quand on travaille sur des choses plus évolués comme les bases de
connaissance et les systèmes expert).
>> Beaucoup de langages présenté (comme ALGOL, Eiffel) restaient du
>> domaine de philosophique et ne témoignaient que de la nature empirique
>> de la création d'un langage.
>
> Je ne comprends pas ce sue tu veux dire. ALGOL est LE langage le plus
> important dans l'histoire de la programmation car c'est le premier
> langage de haut niveau à structure de bloc, possédant la récursion, etc.
> Dans Pascal, Ada, Modula, etc. il y a au moins 60% d'Algol.
Oui mais c'est un langage qui n'a pas été utilisé de façon industrielle;
il est un échec commercial ...(suite après)
> Tout langage moderne (c'est à dire depuis Pascal en 1970) est un langage
> à structure de bloc.
>
> Sur le papier Eiffel est un des plus beaux langages à objet. Hélas
> Bertrand Meyer a confié la réalisation du premeir compilateur à des
> étudiants. Il y avait des défauts dans le rammasse-miette. Ceci rendait
> le langage inutilisable industriellement. C'est dommage car, sinon, on
> aurait peut-être évité l'horreur C++ (qui est finalement plutôt un
> langages de pointeurs qu'un langage à objets...)
>
> Tout ça pour dire que les exemples de langages procéduraux avec Algol et
> objets avec Eiffel sont tout à fait pertinents et ne ressortent
> absolument pas que du domaine philosophique.
... Ils font partie de la préhistoire et l'étudiant ne peut pas se
mettre en relation avec les enjeux de l'époque.
Algol est présenté comme un proof-of-concept de la programmation par
block, Eiffel de la programmation par contrat. Les langages eux même ne
sont pas étudiés.
>> Mon impression aujourd'hui est que le niveau d'abstraction augmente
>> mais pas du point de l'expression du langage mais des fonctionnalités
>> (orienté business). Il suffit de voir comment Java, C# ou PHP offrent
>> une foultitude d'abstraction de l'OS, des accès physiques ...
>
> Ce ne sont pas les langages qui offrent ces librairies mais ces
> librairies qui sont offertes dans ces langages (la foultitude en
> question permet d'ailleurs de mesurer la popularité de tel ou tel
> langage en fonction du nombre de librairies "offertes").
Mais du point de vue du /programmeur/, ces éléments font partie du
langage. D'ailleurs je ne suis pas sûr qu'ils aient tort. Si une
librairie est distribuée en standard, elle fait partie en quelque sorte
du langage (au sens large).
>> On pourrait penser que c'est une contrainte des langages dynamique ou
>> sur machine virtuelle mais il suffit de voir l'importance que prennent
>> par exemple les pattern pour voir que nous sommes dans une phase ou un
>> langage de programmation est une méthode de composition de systèmes et
>> non plus un générateur d'instruction.
>
> Oui, c'est ce que je disais je ne sais plus où dans ce fil : les
> programmeurs sont de plus en plus des ensembliers/intégrateurs qui
> mettent de la glue autour de fonctions/librairies existantes.
>
> Je ne suis pas d'accord avec "un langage de programmation est une
> méthode de composition de systèmes et non plus un générateur
> d'instruction".
>
> Un langage de programmation reste un langage de programmation car même
> la notion de package ne date pas d'hier , ni la séparation
> spécification/implémentation (cette séparation existait déjà dans le
> Pascal UCSD des années 70 !).
>
> C'est la notion de librairie "autour" des langages de programmation qui
> s'est développée et encore, en Fortran il y a belle lurette que les
> programmeurs font de la réutilisation avec des librairie scientifiques
> (calculs en précision n, fonctions mathématiques spécialisées,
> algorithmes de calculs numériques performants, etc.).
[snip]
Quand la librairie devient standard, il y a une sorte de fusion. On peut
voir aujourd'hui avec c++ que la STL fait partie du langage (bien qu''on
puisse utiliser une librairie alternative). On y voit aussi le mal qu'a
fait l'absence de certaines librairies standard (filesystem, thread ...)
qui créée une hétérogénéité déprimante.
>> Un autre exemple est qu'aujourd'hui il est possible de faire un jeux
>> 3D, complexe, efficaces avec juste du XML (voir le moteur CristalSpace).
>
> Tu veux dire qu'on peut "scripter" Crystal Space en XML (aussi en Python
> d'ailleurs) sinon Crystal Space et Ogre 3D sont écrits en C++ ainsi que
> leurs bibliothèques (voir http://www.arcanoria.com/CS-Ogre.php).
Mais le C++ n'est pas utilisé, à priori, en tant que glue. Le process
sera plutôt de développer un service dans une dll puis de la scripter.
Le script, en l'occurrence, ressemble plus à de la description.
>> [snip]
>>>> Dans mon activité professionnelle je suis toujours resté pragmatique,
>>>> n'utiliser que les choses dont j'ai besoin. J'utilise l'objet
>>>> essentiellement pour ses capacités de liaison dynamique et les types
>>>> de données abstraits pour le reste car je préfère la composition à
>>>> l'héritage. Donc des arbres d'héritage plats (du type balais quoi).
>>>
>>> Ce n'est pas une question de préférence mais de "qui fait le mieux le
>>> job".
>>> Réfléchis à ceci, que je répète en cours : "la chasse aux switches
>>> est à la programmation objet ce que la chasse aux goto est à la
>>> programmation structurée". Dans cette optique, il faut utiliser
>>> beaucoup l'héritage et le polymorphisme.
>>
>> L'avantage du polymorphisme est surtout que c'est le moyen, à priori,
>> de réaliser l'inversion de dépendance. Là où le procédural impose une
>> conception bottom-up, l'objet permet une conception top-down.
>
> Le procédural permet aussi le développement top-down (on écrit le main
> d'abord avec des "stubs" vides ou rudimentaires et on raffine. On sait
> faire ça depuis des lustres (50 ans)...
Mais une modification du stub se répercute sur toute l'arborescence.
C'est à dire qu'un mouvement d'aller retour est parfois nécessaire pour
s'adapter aux caractéristiques techniques de la couche inférieure.
[snip]
>>>> Après 40 ans de développement je suis atterré par la prolifération des
>>>> langages, qui réinventent (mal) la roue. L'informatique est redevenue
>>>> une tour de Babel.
>>>
>>> C'est comme si on faisait table rase du passé. C'est totalement
>>> absurde, je suis d'accord avec toi. Il y a quantité de "nouveaux"
>>> langages qui sont des aberrations (je ne les citerais pas par
>>> charité...).
>>
>> Il y a aussi, je pense, un effet de libération. La conception de
>> langage était réservée à une élite qui savait écrire un compilateur).
>> L'émergence des machines virtuelles, du JIT ... permet de développer
>> plus facilement un langage (plus la puissance des machines).
>>
>> Par exemple, la publication de la machine virtuelle Java a permis à
>> des langages comme Groovy d'exister (plus JRuby, JPython ...).
>
> Tu veux dire que la prolifération des langages est l'effet de la
> démocratisation dans ce domaine ?
Je pense; il y a aussi un phénomène d'évolution (comme sur un marché
commercial) croissance-fragmentation-phagocytation.
Il y a en même temps un recentrage sur l'aspect fonctionnel d'où
l'apparition des DSLs (en Ruby par exemple) pour personnaliser
l'expression des scripts. Là où, autrefois, il fallait faire du lex/yacc
avec les notion ardues de langage, aujourd'hui il est facile de faire un
interpréteur ou d'en réutiliser un. Cela permet de populariser la
personnalisation et la configuration.
Lua est un bon exemple de langage embarqué pour gérer la configuration
et l'extension d'une application.
[snip]
>>
>> Le mouvement des design pattern est là pour transmettre ces
>> connaissance et c'est un bon espoir mais aujourd'hui, quand on parle
>> de pattern, on parle de ceux du GoF-book. Récemment, en entretien,
>> j'ai mentionné les rencontres EuroPlop et POSA et ceux-ci étaient
>> inconnus au bataillon de même que les livres qui s'y rapportent.
>
> Tu veux parler de ceci : http://www.cs.wustl.edu/~schmidt/POSA/ ?
> Ce sont des livres essentiels.
Oui.
http://www.hillside.net/patterns/books/
En particulier POSA2 et POSA4 qui sont la base de nombreux pattern modernes.
--
Michael
Michael DOUBEZ
> Si une librairie est ...
Erratum: Si une bibliothèque est ...
> Quand la librairie devient ...
Erratum: Quand la bibliothèque devient ...
> librairie alternative/standard
Erratum: bibliothèque alternative/standard
C'est vrai, je devrais utiliser les version françaises.
--
Michael
Marc Boyer
> Marc Espie a écrit :
>> In article <49933ef0$0$18378$ba4a...@news.orange.fr>,
>> Wykaaa <wyk...@yahoo.fr> wrote:
> D'ailleurs il y a belle lurette que les spécialistes ont abandonné
> l'idée de pratiquer des preuves formelles sur le code.
> La seule méthode que je connaisse (mais je ne connais pas tout dans ce
> domaine) concernant les preuves formelles qui a quelques réussites dans
> l'industrie, c'est la méthode B utilisée pour le métro Météor, entre autre.
En effet, la méthode B est utilisée par les pro du rail (train et metro).
On fait aussi de la preuve automatique par interprétation abstraite
chez Airbus pour éviter les tests unitaires.
Marc Boyer
--
Au XXIème siècle, notre projet de société s'est réduit
à un projet économique...
Wykaaa
> Wykaaa wrote:
>> Michael DOUBEZ a écrit :
>>> Wykaaa wrote:
>>>> cjps...@gmail.com a écrit :
> [snip]
>>>>> Je ne suis pas sur que l'objet soit assimilable correctement sans être
>>>>> passé par une phase moins abstraite. Pour faire comprendre le besoin
>>>>> d'abstraction il est bon de faire du bas niveau et d'en mesurer toutes
>>>>> les difficultés en terme de génie logiciel.
>>>>
>>>> Pédagogiquement, ça peut être une possibilité. En faisant un petit
>>>> historique des langages en introduction du cours de programmation,
>>>> on peut montrer comment, dans les langages, on va vers toujours plus
>>>> d'abstraction et que ce n'est pas un hasard.
>>>
>>> Je me souviens des mes cours de langage et nous avions eu un topo sur
>>> l'évolution des langages. L'évolution en abstraction était évidente
>>> mais l'impression que j'en ai retiré est que le monde s'est arrêté
>>> aux L3G/L4G sauf en environnement universitaire.
>>
>> Les L4G ne sont pas des vrais langages de programmation car ils ne
>> sont pas "Turing complet" : ça signifie, du point de vue théorique,
>> que tous les algorithmes ne sont pas programmables en L4G.
>
> Ils suffisent pour faire du PL/SQL.
Oui mais PL est un langage "au-dessus" de SQL, il ressemble d'ailleurs à
Ada, en particulier pour son mécanisme d'exceptions. Je parlais
exclusivement de SG
QL en tant que L4G.
>
>> De quoi parle-t-on en plus dans le monde universitaire au point de vue
>> des langages ? Y aurait-il des L5G ?
>
> Prolog principalement (uniquement d'ailleurs à ma connaissance sauf
> quand on travaille sur des choses plus évolués comme les bases de
> connaissance et les systèmes expert).
Pour que la formation d'un programmeur soit complète, je crois qu'on ne
peut éviter de parler de Prolog (mais pas faire un cours de 40h desuus
non plus).
>
>>> Beaucoup de langages présenté (comme ALGOL, Eiffel) restaient du
>>> domaine de philosophique et ne témoignaient que de la nature
>>> empirique de la création d'un langage.
>>
>> Je ne comprends pas ce sue tu veux dire. ALGOL est LE langage le plus
>> important dans l'histoire de la programmation car c'est le premier
>> langage de haut niveau à structure de bloc, possédant la récursion, etc.
>> Dans Pascal, Ada, Modula, etc. il y a au moins 60% d'Algol.
>
> Oui mais c'est un langage qui n'a pas été utilisé de façon industrielle;
> il est un échec commercial ...(suite après)
Comme PL/1 qui a été utilisé principalement (ou des dialectes) pour
coder les systèmes d'exploitation d'avant Unix (comme MVS d'IBM en PLM,
GCOS7 de Bull en HPL et Multics, ancêtre de UNix.
Cependant l'IGN (Institut géographique national) avait beaucoup de PL/1.
>
>> Tout langage moderne (c'est à dire depuis Pascal en 1970) est un
>> langage à structure de bloc.
>>
>> Sur le papier Eiffel est un des plus beaux langages à objet. Hélas
>> Bertrand Meyer a confié la réalisation du premeir compilateur à des
>> étudiants. Il y avait des défauts dans le rammasse-miette. Ceci
>> rendait le langage inutilisable industriellement. C'est dommage car,
>> sinon, on aurait peut-être évité l'horreur C++ (qui est finalement
>> plutôt un langages de pointeurs qu'un langage à objets...)
>>
>> Tout ça pour dire que les exemples de langages procéduraux avec Algol
>> et objets avec Eiffel sont tout à fait pertinents et ne ressortent
>> absolument pas que du domaine philosophique.
>
> ... Ils font partie de la préhistoire et l'étudiant ne peut pas se
> mettre en relation avec les enjeux de l'époque.
>
> Algol est présenté comme un proof-of-concept de la programmation par
> block, Eiffel de la programmation par contrat. Les langages eux même ne
> sont pas étudiés.
Eiffel a eu un certain succès aux US. Il y avait même un jornal pour
ses utilisateurs (à ma connaissance il n'y en a pas eu en France).
>
>>> Mon impression aujourd'hui est que le niveau d'abstraction augmente
>>> mais pas du point de l'expression du langage mais des fonctionnalités
>>> (orienté business). Il suffit de voir comment Java, C# ou PHP offrent
>>> une foultitude d'abstraction de l'OS, des accès physiques ...
>>
>> Ce ne sont pas les langages qui offrent ces librairies mais ces
>> librairies qui sont offertes dans ces langages (la foultitude en
>> question permet d'ailleurs de mesurer la popularité de tel ou tel
>> langage en fonction du nombre de librairies "offertes").
>
> Mais du point de vue du /programmeur/, ces éléments font partie du
> langage. D'ailleurs je ne suis pas sûr qu'ils aient tort. Si une
> librairie est distribuée en standard, elle fait partie en quelque sorte
> du langage (au sens large)
Assez d'accord. D'ailleurs aujourd'hui, à l'embauche, certaines SSII
accordent beaucoup d'importance à la connaissance de certaines
bibliothèques (j'ai utilisé librairie à tort, merci à Marc).
Tout à fait. Mais la STL ne fait-elle pas partie du standard C++ ?
>
>>> Un autre exemple est qu'aujourd'hui il est possible de faire un jeux
>>> 3D, complexe, efficaces avec juste du XML (voir le moteur CristalSpace).
>>
>> Tu veux dire qu'on peut "scripter" Crystal Space en XML (aussi en
>> Python d'ailleurs) sinon Crystal Space et Ogre 3D sont écrits en C++
>> ainsi que leurs bibliothèques (voir
>> http://www.arcanoria.com/CS-Ogre.php).
>
> Mais le C++ n'est pas utilisé, à priori, en tant que glue. Le process
> sera plutôt de développer un service dans une dll puis de la scripter.
> Le script, en l'occurrence, ressemble plus à de la description.
Un peu comme le WSDL pour décrire les interfaces des Web Services en SOA ?
>
>>> [snip]
>>>>> Dans mon activité professionnelle je suis toujours resté pragmatique,
>>>>> n'utiliser que les choses dont j'ai besoin. J'utilise l'objet
>>>>> essentiellement pour ses capacités de liaison dynamique et les types
>>>>> de données abstraits pour le reste car je préfère la composition à
>>>>> l'héritage. Donc des arbres d'héritage plats (du type balais quoi).
>>>>
>>>> Ce n'est pas une question de préférence mais de "qui fait le mieux
>>>> le job".
>>>> Réfléchis à ceci, que je répète en cours : "la chasse aux switches
>>>> est à la programmation objet ce que la chasse aux goto est à la
>>>> programmation structurée". Dans cette optique, il faut utiliser
>>>> beaucoup l'héritage et le polymorphisme.
>>>
>>> L'avantage du polymorphisme est surtout que c'est le moyen, à priori,
>>> de réaliser l'inversion de dépendance. Là où le procédural impose une
>>> conception bottom-up, l'objet permet une conception top-down.
>>
>> Le procédural permet aussi le développement top-down (on écrit le main
>> d'abord avec des "stubs" vides ou rudimentaires et on raffine. On sait
>> faire ça depuis des lustres (50 ans)...
>
> Mais une modification du stub se répercute sur toute l'arborescence.
> C'est à dire qu'un mouvement d'aller retour est parfois nécessaire pour
> s'adapter aux caractéristiques techniques de la couche inférieure.
A franchement parler, du moins dans de grosses applications, je n'ai
jamais vu du strictement ascendant ou descendant (plutôt que bottom-up
et top-down). On fait toujours du "yoyo" entre les 2.
D'ailleurs, quand on commence une conception, on part des besoins
utilisateurs, donc, en général, on commence par faire du "descendant"
mais très rapidement, parce qu'aujourd'hui on dispose de nombreuses
bibliothèques pour l'intergiciel (middleware), les protocoles, les
algorithmes, les motifs de conception (design patterns), etc. on se pose
la question de la réutilisabilité qui est typiquement de l'ascendant.
Oui mais je pense que tu y vas quand même un peu fort car, même avec les
outils modernes, faire un interpréteur (propre) n'est pas forcément à la
portée de tout le monde.
>
>
> [snip]
[snip]
>>
>> Tu veux parler de ceci : http://www.cs.wustl.edu/~schmidt/POSA/ ?
>> Ce sont des livres essentiels.
>
> Oui.
> http://www.hillside.net/patterns/books/
>
> En particulier POSA2 et POSA4 qui sont la base de nombreux pattern
> modernes.
Tout à fait d'accord.
Marc Espie
Dans les paradigmes peu utilises, j'aime beaucoup Icon et son mecanisme
de generateurs... pas tres loin de ce que fait prolog, mais bien plus
dirige par le programmeur, et extremement utile pour certains problemes
(tout ce qui est enumeration combinatoire en particulier).
La technique utiliser pour lire les chaines, assez eloignee des expressions
rationnelles, est aussi assez sympa... si le langage avait "pris", il y a
fort a parier qu'il y aurait des choses interessantes a faire cote compilation
et optimisation de code icon.
Evidemment, ca n'a rien de fondamental et c'est un peu anecdotique...
Je suis sur qu'il y a d'autres exemples...
Pascal J. Bourguignon
> Michael DOUBEZ a écrit :
[...]
>>>> Avant on spécialisait un langage pour un hardware
>>>> aujourd'hui on invente un nouveau langage pour chaque nouveau type
>>>> d'application. Et chaque nouveau langage apporte un petit plus et
>>>> beaucoup de moins car il est centré sur un type de traitement et
>>>> néglige les fondamentaux : exemple python qui ne connait pas
>>>> l'encapsulation, résultat : impossible de garantir le bon
>>>> fonctionnement.
>>>
>>> Je ne comprends pas, qu'après 50 ans de catastrophes informatiques,
>>> on invente un "nouveau" langage sans mécanisme
>>> d'encapsulation. S'il y a bien un concept fondamental en
>>> programmation, c'est l'encapsulation.
>> Beaucoup de gens pensent que l'encapsulation ne sers qu'à contrôler
>> l'accès aux données (ajouter des effets de bord ...). J'ai souvent
>> vu cette idée, dans des livres (un écrit par un MVP Microsoft) et
>> même dans un QCM de recrutement.
>
> Je pense qu'il y a peu d'informaticiens, hélas, qui comprennent que
> l'encapsulation ce n'est pas seulement la "privatisation" des
> données... mais aussi des fonctions et que le trio
> modularité/encapsulation/généricité est extrêmement puissant pour
> rendre les logiciels évolutifs, portables, adaptatifs à différents
> contexte (je parle de versatilité de modules dans mes cours).
Peut être qu'une traduction de SICP, et que sa lecture obligatoire par
tous les programmeurs s'imposerait.
SICP = Structure and Interpretation of Computer Programs
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html
http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/
http://eli.thegreenplace.net/category/programming/lisp/sicp/
http://www.codepoetics.com/wiki/index.php?title=Topics:SICP_in_other_languages
> Tu veux parler de ceci : http://www.cs.wustl.edu/~schmidt/POSA/ ?
> Ce sont des livres essentiels.
--
__Pascal Bourguignon__
Marc Espie
>tous les programmeurs s'imposerait.
>
>SICP = Structure and Interpretation of Computer Programs
> http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html
> http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/
> http://eli.thegreenplace.net/category/programming/lisp/sicp/
Une fois n'est pas coutume, je suis plutot d'accord avec toi.
Le plus gros defaut du SICP, c'est qu'il s'adresse a un public tres
specifique. En particulier, ca n'est pas adapte a des informaticiens
qui n'ont pas deja une culture mathematique/physique assez etendue (une
bonne partie des exemples de l'ouvrage ne va pas du tout leur parler).
Michael DOUBEZ
> Michael DOUBEZ a écrit :
>> Wykaaa wrote:
>>> Un langage de programmation reste un langage de programmation car
>>> même la notion de package ne date pas d'hier , ni la séparation
>>> spécification/implémentation (cette séparation existait déjà dans le
>>> Pascal UCSD des années 70 !).
>>>
>>> C'est la notion de librairie "autour" des langages de programmation
>>> qui s'est développée et encore, en Fortran il y a belle lurette que
>>> les programmeurs font de la réutilisation avec des librairie
>>> scientifiques (calculs en précision n, fonctions mathématiques
>>> spécialisées, algorithmes de calculs numériques performants, etc.).
>> [snip]
>>
>> Quand la librairie devient standard, il y a une sorte de fusion. On
>> peut voir aujourd'hui avec c++ que la STL fait partie du langage (bien
>> qu''on puisse utiliser une librairie alternative). On y voit aussi le
>> mal qu'a fait l'absence de certaines librairies standard (filesystem,
>> thread ...) qui créée une hétérogénéité déprimante.
>
> Tout à fait. Mais la STL ne fait-elle pas partie du standard C++ ?
Oui. La distinction langage/package n'est pas aussi net. Généralement,
aujourd'hui, les programmeurs (Java, C#, Python, Rubty, PHP ...)
attendent d'un langage un niveau de services/bibliothèques intéégré
assez grand.
D'un coté c'est assez séduisant car ça permet d'unifier les
représentations (comme la façon de représenter un chemin de fichier),
d'un autre coté, cela créé une grande variabilité et un gigantisme du
langage.
>>>> Un autre exemple est qu'aujourd'hui il est possible de faire un jeux
>>>> 3D, complexe, efficaces avec juste du XML (voir le moteur
>>>> CristalSpace).
>>>
>>> Tu veux dire qu'on peut "scripter" Crystal Space en XML (aussi en
>>> Python d'ailleurs) sinon Crystal Space et Ogre 3D sont écrits en C++
>>> ainsi que leurs bibliothèques (voir
>>> http://www.arcanoria.com/CS-Ogre.php).
>>
>> Mais le C++ n'est pas utilisé, à priori, en tant que glue. Le process
>> sera plutôt de développer un service dans une dll puis de la scripter.
>> Le script, en l'occurrence, ressemble plus à de la description.
>
> Un peu comme le WSDL pour décrire les interfaces des Web Services en SOA ?
Non, le WSDL décrit des interfaces données/fonctions (tout comme l'IDL).
Crystal Space n'est peut être pas le meilleur exemple.
Puisqu'on est dans l'éducation, on peut prendre Alice:
http://www.alice.org/
L'interface est graphique plutôt qu'en XML mais le principe est le même:
mise en place d'un environnements et des interactions entre les
éléments. Le moteur de jeux prends le relai de l'exécution.
Bon, c'est pas tous les langages comme ça et pour tout le monde mais il
y a cet aspet, je pense, d'assemblage de services qui prend plus
d'importance (sans parler de SOA qui n'a pas les mêmes enjeux).
--
Michael
Wykaaa
Ce livre, excellent, a été l'un de mes livres de chevet professionnels
mais je suis assez d'accord avec la remarque de Marc à ton message.
Pascal J. Bourguignon
> Michael DOUBEZ a écrit :
>> Il y a en même temps un recentrage sur l'aspect fonctionnel d'où
>> l'apparition des DSLs (en Ruby par exemple) pour personnaliser
>> l'expression des scripts. Là où, autrefois, il fallait faire du
>> lex/yacc avec les notion ardues de langage, aujourd'hui il est
>> facile de faire un interpréteur ou d'en réutiliser un. Cela permet
>> de populariser la personnalisation et la configuration.
>> Lua est un bon exemple de langage embarqué pour gérer la
>> configuration et l'extension d'une application.
>
> Oui mais je pense que tu y vas quand même un peu fort car, même avec
> les outils modernes, faire un interpréteur (propre) n'est pas
> forcément à la portée de tout le monde.
Bin si, justement. Car lorsqu'on fait un DSL en Common Lisp, on ne
jette rien, on garde tout le Common Lisp sous-jascent. Bien sur, ce
n'est pas quelque chose de facile à faire avec un compilateur C et
yacc (ça donne des facades Objective-C ou C++). Mais en Common Lisp
c'est trivial. N'importe quel programmeur lisp le fait tout les
jours, en écrivant quelques macros lisp. (Et ce n'est pas un
"interpréteur", le code du DSL peut être compilé au même titre que le
reste du code Common Lisp).
--
__Pascal Bourguignon__
Pascal J. Bourguignon
> In article <7ctz6y5...@pbourguignon.anevia.com>,
> Pascal J. Bourguignon <p...@informatimago.com> wrote:
>>Peut être qu'une traduction de SICP, et que sa lecture obligatoire par
>>tous les programmeurs s'imposerait.
>>
>>SICP = Structure and Interpretation of Computer Programs
>> http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html
>> http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/
>> http://eli.thegreenplace.net/category/programming/lisp/sicp/
>
> Une fois n'est pas coutume, je suis plutot d'accord avec toi.
> Le plus gros defaut du SICP, c'est qu'il s'adresse a un public tres
> specifique. En particulier, ca n'est pas adapte a des informaticiens
> qui n'ont pas deja une culture mathematique/physique assez etendue (une
> bonne partie des exemples de l'ouvrage ne va pas du tout leur parler).
Ça, les exemples ça s'adapte. c'est pour ça d'ailleurs qu'on conçoit
toujours l'enseignement via un professeur au contact direct des
étudiants.
--
__Pascal Bourguignon__
Wykaaa
Comme je l'ai dit plusieurs fois ici, aujourd'hui, effectivement, il
devient très important de connaître non seulement correctement le
langage utilisé mais aussi ses bibliothèque. C'est probablement le prix
à payer pour une mise en oeuvre effective de la réutilisation...
>
>>>>> Un autre exemple est qu'aujourd'hui il est possible de faire un
>>>>> jeux 3D, complexe, efficaces avec juste du XML (voir le moteur
>>>>> CristalSpace).
>>>>
>>>> Tu veux dire qu'on peut "scripter" Crystal Space en XML (aussi en
>>>> Python d'ailleurs) sinon Crystal Space et Ogre 3D sont écrits en C++
>>>> ainsi que leurs bibliothèques (voir
>>>> http://www.arcanoria.com/CS-Ogre.php).
>>>
>>> Mais le C++ n'est pas utilisé, à priori, en tant que glue. Le process
>>> sera plutôt de développer un service dans une dll puis de la scripter.
>>> Le script, en l'occurrence, ressemble plus à de la description.
>>
>> Un peu comme le WSDL pour décrire les interfaces des Web Services en
>> SOA ?
>
> Non, le WSDL décrit des interfaces données/fonctions (tout comme l'IDL).
> Crystal Space n'est peut être pas le meilleur exemple.
Ok
>
> Puisqu'on est dans l'éducation, on peut prendre Alice:
> http://www.alice.org/
>
> L'interface est graphique plutôt qu'en XML mais le principe est le même:
> mise en place d'un environnements et des interactions entre les
> éléments. Le moteur de jeux prends le relai de l'exécution.
Alice c'est un peu comme Logo avec la 3D en plus, non ?
Je trouve ça très bien pour l'apprentissage de la programmation par les
plus jeunes. Mon fils avait suivi des cours de Logo au collège, en son
temps, le mercredi après-midi.
>
> Bon, c'est pas tous les langages comme ça et pour tout le monde mais il
> y a cet aspet, je pense, d'assemblage de services qui prend plus
> d'importance (sans parler de SOA qui n'a pas les mêmes enjeux).
>
Ca devient même l'essentiel du travail du développeur, à mon avis.
Wykaaa
faire, j'en conviens.
Marc Espie
Hum... dans ce cas precis, les exemples font quand meme partie integrante
de la pedagogie, et ca n'est pas tres simple de les adapter, parce qu'ils
forment un tout progressif, et supposent deja certaines competences chez
les etudiants qui seront assez peu repandues sur pas mal de formations
actuelles en France.
En etant un peu "dans les tranchees", entre formations professionnelles en
informatique (entre un IUP et une formation privee), en voyant environ 50
soutenances de stage par an, et en ayant pas mal de collegues ou amis dans
l'informatique, je me demande si vous ne vous faites pas une vision un
peu idyllique du monde actuel. L'enorme majorite de la masse salariale
bosse en SSII. Je ne compte plus les histoires gores d'incommunication entre
la maitrise d'ouvrage et la maitrise d'oeuvre (voire tous les cas ou c'est
la TMA qui a l'obligation de resultats et qui se retrouve a devoir recoller
des bouts qui ne fonctionnent pas ensemble). Et si je regarde les profils,
il y a:
- peu de passionnes en info
- encore moins de passionnes qui ont un niveau correct en maths.
S'ils sont passes par la fac, ils se souviennent de ce que veut dire un
O(n log n) sur un algorithme. Assez peu sauront te demontrer des bornes
elementaires sur un algo de tri.
De crise en crise, et de besoin en besoin croissants en informatique, tu
y retrouves de plus en plus de gens qui font ca "faute de mieux" et qui
auraient largement prefere faire autre chose...
Pascal J. Bourguignon
C'est bien là où se trouve le problème.
> En etant un peu "dans les tranchees", entre formations professionnelles en
> informatique (entre un IUP et une formation privee), en voyant environ 50
> soutenances de stage par an, et en ayant pas mal de collegues ou amis dans
> l'informatique, je me demande si vous ne vous faites pas une vision un
> peu idyllique du monde actuel. L'enorme majorite de la masse salariale
> bosse en SSII. Je ne compte plus les histoires gores d'incommunication entre
> la maitrise d'ouvrage et la maitrise d'oeuvre (voire tous les cas ou c'est
> la TMA qui a l'obligation de resultats et qui se retrouve a devoir recoller
> des bouts qui ne fonctionnent pas ensemble). Et si je regarde les profils,
> il y a:
> - peu de passionnes en info
> - encore moins de passionnes qui ont un niveau correct en maths.
>
> S'ils sont passes par la fac, ils se souviennent de ce que veut dire un
> O(n log n) sur un algorithme. Assez peu sauront te demontrer des bornes
> elementaires sur un algo de tri.
>
> De crise en crise, et de besoin en besoin croissants en informatique, tu
> y retrouves de plus en plus de gens qui font ca "faute de mieux" et qui
> auraient largement prefere faire autre chose...
Je ne crois pas que le métier ni les clients ont intérêt à continuer
dans cette direction. Il vaudrait mieux annoncer que l'informatique
ce n'est pas si facile que ça, et sélectionner mieux pour pouvoir
former des professionnels plus compétents.
D'un autre côté, on peut imaginer des métiers intermédiaires. On
n'aurait pas idée d'appeler "programmeur" un infographiste ou un
administrateur system. Les "gestionaires" qui assemblent des briques
logiciels en java ou PHP pour répondre aux besoins des utilisateurs ne
sont peut être pas à considérer comme des programmeurs. Ils n'ont pas
besoin de savoir ce que O(n*log(n)) signifie; mais ils peuvent avoir
besoin d'une formation spécifique.
La solution est peut être dans la définition de nouveaux "métiers", et
donc dans la différenciation des formations, et de l'orientation.
--
__Pascal Bourguignon__
Michael DOUBEZ
> Michael DOUBEZ a écrit :
>> D'un coté c'est assez séduisant car ça permet d'unifier les
>> représentations (comme la façon de représenter un chemin de fichier),
>> d'un autre coté, cela créé une grande variabilité et un gigantisme du
>> langage.
>
> Comme je l'ai dit plusieurs fois ici, aujourd'hui, effectivement, il
> devient très important de connaître non seulement correctement le
> langage utilisé mais aussi ses bibliothèque. C'est probablement le prix
> à payer pour une mise en oeuvre effective de la réutilisation...
Je ne crois pas que le prix à payer soit la vision unique et le
gigantisme. D'autres langages ont utilisés des mécanismes alternatifs:
CPAN pour perl, Pear pour PHP, CTAN pour LateX ...
Les langages qui n'offrent pas ces services ou un système alternatif
sont aujourd'hui dépréciés. Par exemple C++, je viens d'ailleurs de lire
un mail intéressant qui rapporte une phrase de B. Stroustrup:
"... it is my regret that more work hasn't been done in providing a
consistent overview of library support for C++."
[snip]
>> Puisqu'on est dans l'éducation, on peut prendre Alice:
>> http://www.alice.org/
>>
>> L'interface est graphique plutôt qu'en XML mais le principe est le
>> même: mise en place d'un environnements et des interactions entre les
>> éléments. Le moteur de jeux prends le relai de l'exécution.
>
> Alice c'est un peu comme Logo avec la 3D en plus, non ?
> Je trouve ça très bien pour l'apprentissage de la programmation par les
> plus jeunes. Mon fils avait suivi des cours de Logo au collège, en son
> temps, le mercredi après-midi.
Sur MO5? J'ai du suivre les mêmes :)
>> Bon, c'est pas tous les langages comme ça et pour tout le monde mais
>> il y a cet aspet, je pense, d'assemblage de services qui prend plus
>> d'importance (sans parler de SOA qui n'a pas les mêmes enjeux).
>>
> Ca devient même l'essentiel du travail du développeur, à mon avis.
Et AMA ça va dans le bon sens (de l'industrialisation). Et c'est ce qui
me fait dire que pour la nouvelle génération, "un langage de
programmation est une méthode de composition de systèmes et non plus un
générateur d'instruction."
Je vais me faire traiter de vieux schnock (à 31 balais) mais notre grand
plaisir à l'école était de refaire tout de AàZ (moteur 3D, protocole
réseau ...), aujourd'hui le plaisir viens d'avoir sus correctement
agencer des éléments pour obtenir un produit.
Heureusement qu'il y a ce mouvement, sinon l'informatique serait restée
à l'age de l'assembleur et du bidouillage et resterais centrée sur la
technique plutôt que sur les besoins utilisateurs.
Je constate juste cette évolution et peut être l'enseignement doit-il
prendre cela en compte (il le fait surement déjà). Un historique des
langages (qui est le sujet originel) dois AMA montrer l'augmentation
dans le niveau d'abstraction mais aussi que, de façon pragmatique, ce
n'est plus un enjeux aujourd'hui et que l'abstraction se fait au niveau
de design, de l'architecture et des services que rends un langage.
En ce sens, je pense que Java est un bon choix pour un étudiant.
Maintenant, qu'en est-il pour les secteurs qui ont besoin d'informatique
traditionnelle ? Comment se situe l'éducation par rapport à cela ?
Ma position est comme je l'ai dit dans un autre thread, est que
l'éducation donne les bases et que la spécialisation ou
l'approfondissement, soit fait par les élèves et en training dans les
entreprises. C'est plus ou moins ce qui se passe (ou devrais se passer)
aujourd'hui.
--
Michael
Mihamina Rakotomandimby (R12y)
>> Après 40 ans de développement je suis atterré par la prolifération des
>> langages, qui réinventent (mal) la roue. L'informatique est redevenue
>> une tour de Babel.
>
> C'est comme si on faisait table rase du passé. C'est totalement absurde,
> je suis d'accord avec toi. Il y a quantité de "nouveaux" langages qui
> sont des aberrations (je ne les citerais pas par charité...).
A bas PHP! (pour le coté Web du développement)
Oui il a évolué dans le temps, comme tous, mais c'est dommage que
certains en fassent une référence.
cjps...@gmail.com
> Wykaaa wrote:
> > Michael DOUBEZ a écrit :
> [snip]
>
> > devient très important de connaître non seulement correctement le
> > langage utilisé mais aussi ses bibliothèque. C'est probablement le prix
> > à payer pour une mise en oeuvre effective de la réutilisation...
>
Aujourd'hui on assiste à une augmentation d'un ordre de grandeur de la
taille des applications. Il n'est plus possible de réinventer la roue
et donc on doit essayer d'utiliser ce qui existe déjà avant
d'entrevoir un développement nouveau. J'ai déjà dit cela à propos des
langages de programmation... Les applications d'aujourd'hui font appel
à un tas de fonctions indépendantes qui sont développées dans des
langages adaptés donc différents. Le problème est de pouvoir les
assembler facilement.
Le jour ou les bibliothèque seront indépendantes du langage de
programmation qui les utilise on aura fait un grand pas en avant.
L'interfaçage entre différents langages de programmation reste quelque
chose de problématique si on veut conserver la portabilité à priori.
Aujourd'hui on sait juste transférer en paramètre des scalaires ou des
adresses de tableaux de scalaires. En plus on doit jongler avec la
décoration des noms de fonction. Pour ce qui est des tableaux de
dimension variable, des objets et des chaines de caractères c'est
beaucoup plus problématique sans parler des exceptions et surtout pas
des DEFINE et des génériques.
Le concept d'objet pourrait facilement être implémenté de manière
portable. C'est ce qui est en train de naitre entre Ada et C++ (voir
les papier de Adacore). Pourquoi ne pas imaginer un binding et des Api
standards.
C'est comme l'interfaçage avec les bibliothèques dynamiques (DLL ou
autres) notamment pour faciliter la construction de plugins.
Je pourrais alors imaginer une application totalement portable à
priori (c'est à dire sans se soucier des extensions ou particularités
des compilateurs) qui serait constituée d'éléments rigides en langage
compilable en code natif et d'éléments interprétés. Cela existe déjà,
oui je sais, mais quel travail pour assurer la portabilité. Entre le
choix des options de compilation, le choix de compilateurs, la
construction des makes et les instructions pour les précompilateurs
dont le volume est parfois plus important que la bibliothèque elle
même; on se demande comment tout cela peut marcher, cela tient du
miracle; en tout cas je ne mettrais pas ce genre de logiciel dans
n'importe quelle application.
Pour que cet interfaçage soit réalisable il faut que chaque langage
évolue vers la conformité à un standard (je n'ose même plus parler de
norme) et fournisse des directives pour le compilateur genre "pragma"
en Ada qui permettent de générer des interfaces standards.
En fait cela existe (IDL) mais n'est utilisé que pour des applications
de type base de données distribuées.
Pour la généricité celle fournie par chaque langage peut être utilisée
à l'intérieur de chaque module.
Et on pourrait envisager de réaliser des traits de généricité dans les
langages interprétés (peut-être que cela existe ?).
> [snip]
> >> Bon, c'est pas tous les langages comme ça et pour tout le monde mais
> >> il y a cet aspet, je pense, d'assemblage de services qui prend plus
> >> d'importance (sans parler de SOA qui n'a pas les mêmes enjeux).
>
> > Ca devient même l'essentiel du travail du développeur, à mon avis.
>
> Et AMA ça va dans le bon sens (de l'industrialisation). Et c'est ce qui
> me fait dire que pour la nouvelle génération, "un langage de
> programmation est une méthode de composition de systèmes et non plus un
> générateur d'instruction."
Il y a des langage dont c'est le rôle de composer et d'autres qui font
d'autres choses. Je pense qu'un langage universel ne peut pas exister.
Mais des langages dédiés à des type de fonctions oui. Quand je
programme un composant de calcul scientifique dont la performance doit
être maximisée je ne vais pas prendre java. Il me reste fortran, C++
ou Ada par exemple.
Fortran est peu typé mais très optimisé, C++ est moyennement typé et
optimisé mais lourd pour certaines programmations (tableaux par
exemple), Ada est très typé mais les compilateurs ne sont pas aussi
optimisés que fortran. Si je veux du parallélisme j'opte pour Ada, ou
un mixte de fortran et Ada ou bien fortran ou C++ avec OpenMP. Après
c'est un choix plus subjectif qu'autre chose.
Par contre pour réaliser des IHM d'autres choix sont possibles. En
fonction des bibliothèques choisies.
La difficulté vient avec la composition de l'application. Le choix des
composant doit être judicieux et doit répondre aussi à des exigences
non fonctionnelles qui peuvent être faciles à exprimer et difficiles à
satisfaire en tout cas à vérifier. Tel composant me donne t-il les
performances que j'attends ? est-il multi-thread ? ...etc...est-il
pérenne ?
Mais une fois les choix individuels faits il faut s'assurer que les
composants peuvent fonctionner ensemble : qu'ils sont composables.
Et ne pas faire de l'inversion d'abstraction du genre utiliser un
tableur pour faire une multiplication.
>
> Je vais me faire traiter de vieux schnock (à 31 balais) mais notre grand
> plaisir à l'école était de refaire tout de AàZ (moteur 3D, protocole
> réseau ...), aujourd'hui le plaisir viens d'avoir sus correctement
> agencer des éléments pour obtenir un produit.
> Heureusement qu'il y a ce mouvement, sinon l'informatique serait restée
> à l'age de l'assembleur et du bidouillage et resterais centrée sur la
> technique plutôt que sur les besoins utilisateurs.
>
A l'école il me semble important d'aller au plus profond possible des
choses. Tâter de l'assembleur, du C et des protocole réseau,
programmer une carte graphique, gérer les interruptions, piloter un
traceur etc... permettent de savoir ce qu'il se passe sous
l'abstraction et de se faire une représentation mentale basée sur du
concret. Même si le soft a de plus en plus tendance a pénétrer dans le
hard, ce n'est qu'une transcription de réalisation. Le code devient
pseudo code. Les algorithmes sont fondamentalement les mêmes sauf
qu'ils sont optimisés en fonction de leur contexte.
Cette connaissance même succinte de ce qui se passe sous l'abstraction
permet aussi d'éviter l'inversion d'abstraction.
Mais c'est vrai que se limiter à cela est stupide. En sortie d'école à
moins d'entrer chez NVIDIA on ne va pas mettre les mains dans un
driver opengl ou directX encore moins dans le firmware. Mais quand on
réalise une application temps réel avec du graphique 3D la
connaissance du fonctionnement (les algo utilisés) du composant
utilisé sera primordiale.
> Je constate juste cette évolution et peut être l'enseignement doit-il
> prendre cela en compte (il le fait surement déjà). Un historique des
> langages (qui est le sujet originel) dois AMA montrer l'augmentation
> dans le niveau d'abstraction mais aussi que, de façon pragmatique, ce
> n'est plus un enjeux aujourd'hui et que l'abstraction se fait au niveau
> de design, de l'architecture et des services que rends un langage.
>
Oui, et même avec un niveau qui n'est pas présent dans les langages de
programmation : les "design pattern"
> En ce sens, je pense que Java est un bon choix pour un étudiant.
Java est limité. Ne faire que du java c'est cacher ce qui se passe
sous l'abstraction. Sauf à étudier la JVM.
Wykaaa
> On 16 fév, 10:27, Michael DOUBEZ <michael.dou...@free.fr> wrote:
>> Wykaaa wrote:
>>> Michael DOUBEZ a écrit :
>> [snip]
>>
>>> Comme je l'ai dit plusieurs fois ici, aujourd'hui, effectivement, il
>>> devient très important de connaître non seulement correctement le
>>> langage utilisé mais aussi ses bibliothèque. C'est probablement le prix
>>> à payer pour une mise en oeuvre effective de la réutilisation...
>
> Aujourd'hui on assiste à une augmentation d'un ordre de grandeur de la
> taille des applications. Il n'est plus possible de réinventer la roue
> et donc on doit essayer d'utiliser ce qui existe déjà avant
> d'entrevoir un développement nouveau. J'ai déjà dit cela à propos des
> langages de programmation... Les applications d'aujourd'hui font appel
> à un tas de fonctions indépendantes qui sont développées dans des
> langages adaptés donc différents. Le problème est de pouvoir les
> assembler facilement.
Que voilà un beau "serpent de mer" des informaticiens !
>
> Le jour ou les bibliothèque seront indépendantes du langage de
> programmation qui les utilise on aura fait un grand pas en avant.
Ce n'est pas demain la veille et je ne suis pas sûr que cela soit
toujours réalisable.
> L'interfaçage entre différents langages de programmation reste quelque
> chose de problématique si on veut conserver la portabilité à priori.
Ne serait-ce que pour les langages compilés, il faudrait, au moins,
qu'il existe un standard (une norme ?) de format de CU ("Compile Unit").
Cela faciliterait déjà la communication inter-langages mais ça implique
pleins de choses, y compris une standardisation des noms de fonctions et
des ordres donnés au lieur (pour la résolution des adresses des
variables externes par exemple).
Mais prenons par exemple les tableaux : en Fortran les indices
commencent à un et ce sont les colonnes qui varient le plus vite, en C à
zéro et ce sont les lignes qui varient le plus vite. Conclusion : passer
un tableau de C à Fortran oblige à "transposer" le tableau et faire une
translation d'indice. On règle ça à coup de méthodologie en appelant des
fonctions qui font le boulot... et ce n'est qu'un exemple.
> Aujourd'hui on sait juste transférer en paramètre des scalaires ou des
> adresses de tableaux de scalaires.
Ben non. Si on sait comment sont représentés les différents types de
bases pour un compilateur, on sait comment les récupérer (ce n'est pas
toujours simple).
> En plus on doit jongler avec la
> décoration des noms de fonction. Pour ce qui est des tableaux de
> dimension variable, des objets et des chaines de caractères c'est
> beaucoup plus problématique sans parler des exceptions et surtout pas
> des DEFINE et des génériques.
Oui, il y a tout cela à prendre en compte... Tu vois, on n'est pas
sortis du bourbier !
>
> Le concept d'objet pourrait facilement être implémenté de manière
> portable. C'est ce qui est en train de naitre entre Ada et C++ (voir
> les papier de Adacore). Pourquoi ne pas imaginer un binding et des Api
> standards.
> C'est comme l'interfaçage avec les bibliothèques dynamiques (DLL ou
> autres) notamment pour faciliter la construction de plugins.
Ceci est un effort de normalisation à l'échelle de l'ensemble de la
communauté des langages. Vaste projet !
Et les langages interprétés ?
>
> Je pourrais alors imaginer une application totalement portable à
> priori (c'est à dire sans se soucier des extensions ou particularités
> des compilateurs) qui serait constituée d'éléments rigides en langage
> compilable en code natif et d'éléments interprétés. Cela existe déjà,
> oui je sais, mais quel travail pour assurer la portabilité. Entre le
> choix des options de compilation, le choix de compilateurs, la
> construction des makes et les instructions pour les précompilateurs
> dont le volume est parfois plus important que la bibliothèque elle
> même; on se demande comment tout cela peut marcher, cela tient du
> miracle; en tout cas je ne mettrais pas ce genre de logiciel dans
> n'importe quelle application.
Tu as tout dit. Ce n'est pas viable dans tous les contextes, loin de là.
>
> Pour que cet interfaçage soit réalisable il faut que chaque langage
> évolue vers la conformité à un standard (je n'ose même plus parler de
> norme) et fournisse des directives pour le compilateur genre "pragma"
> en Ada qui permettent de générer des interfaces standards.
Il faudrait déjà un format de "CU" standards, c'est le minimum et ça, ce
n'est déjà pas donné avant que tout le monde se mette d'accord...
>
> En fait cela existe (IDL) mais n'est utilisé que pour des applications
> de type base de données distribuées.
Ca peut être utilisé à autre chose. Le problème c'est qu'il n'y a pas de
l'IDL pour tout le monde.
>
> Pour la généricité celle fournie par chaque langage peut être utilisée
> à l'intérieur de chaque module.
> Et on pourrait envisager de réaliser des traits de généricité dans les
> langages interprétés (peut-être que cela existe ?).
Excessivement coûteux en performance, en général.
>
>> [snip]
>>>> Bon, c'est pas tous les langages comme ça et pour tout le monde mais
>>>> il y a cet aspet, je pense, d'assemblage de services qui prend plus
>>>> d'importance (sans parler de SOA qui n'a pas les mêmes enjeux).
>>> Ca devient même l'essentiel du travail du développeur, à mon avis.
>> Et AMA ça va dans le bon sens (de l'industrialisation). Et c'est ce qui
>> me fait dire que pour la nouvelle génération, "un langage de
>> programmation est une méthode de composition de systèmes et non plus un
>> générateur d'instruction."
>
> Il y a des langage dont c'est le rôle de composer et d'autres qui font
> d'autres choses. Je pense qu'un langage universel ne peut pas exister.
> Mais des langages dédiés à des type de fonctions oui. Quand je
> programme un composant de calcul scientifique dont la performance doit
> être maximisée je ne vais pas prendre java. Il me reste fortran, C++
> ou Ada par exemple.
Il me semble que tout ceci est discutable...
>
> Fortran est peu typé mais très optimisé, C++ est moyennement typé et
> optimisé mais lourd pour certaines programmations (tableaux par
> exemple), Ada est très typé mais les compilateurs ne sont pas aussi
> optimisés que fortran. Si je veux du parallélisme j'opte pour Ada, ou
> un mixte de fortran et Ada ou bien fortran ou C++ avec OpenMP. Après
> c'est un choix plus subjectif qu'autre chose.
Oui la subjectivité reste le guide suprême.
>
> Par contre pour réaliser des IHM d'autres choix sont possibles. En
> fonction des bibliothèques choisies.
Peux-tu expliciter ?
>
> La difficulté vient avec la composition de l'application. Le choix des
> composant doit être judicieux et doit répondre aussi à des exigences
> non fonctionnelles qui peuvent être faciles à exprimer et difficiles à
> satisfaire en tout cas à vérifier. Tel composant me donne t-il les
> performances que j'attends ? est-il multi-thread ? ...etc...est-il
> pérenne ?
Il faudrait des description formelles sur la description des composants
mais, pour prendre un exemple que je connais bien, va décrire
formellement les performances d'un composant (ça encore, on peut y
arriver) mais surtout va comparer 2 descriptions formelles de
performances de n composants qui réalisent la même chose : ça relève
quasiment de l'indécidable...
>
> Mais une fois les choix individuels faits il faut s'assurer que les
> composants peuvent fonctionner ensemble : qu'ils sont composables.
Ah oui, et comment on s'y prend concrètement pour s'assurer qu'ils sont
composables ?
Ne me dit pas les tests, car il restera toujours des cas importants qui
n'auront pas été testés.
>
> Et ne pas faire de l'inversion d'abstraction du genre utiliser un
> tableur pour faire une multiplication.
>
>> Je vais me faire traiter de vieux schnock (à 31 balais) mais notre grand
>> plaisir à l'école était de refaire tout de AàZ (moteur 3D, protocole
>> réseau ...), aujourd'hui le plaisir viens d'avoir sus correctement
>> agencer des éléments pour obtenir un produit.
>> Heureusement qu'il y a ce mouvement, sinon l'informatique serait restée
>> à l'age de l'assembleur et du bidouillage et resterais centrée sur la
>> technique plutôt que sur les besoins utilisateurs.
>>
>
> A l'école il me semble important d'aller au plus profond possible des
> choses. Tâter de l'assembleur, du C et des protocole réseau,
> programmer une carte graphique, gérer les interruptions, piloter un
> traceur etc... permettent de savoir ce qu'il se passe sous
> l'abstraction et de se faire une représentation mentale basée sur du
> concret. Même si le soft a de plus en plus tendance a pénétrer dans le
> hard, ce n'est qu'une transcription de réalisation. Le code devient
> pseudo code. Les algorithmes sont fondamentalement les mêmes sauf
> qu'ils sont optimisés en fonction de leur contexte.
>
> Cette connaissance même succinte de ce qui se passe sous l'abstraction
> permet aussi d'éviter l'inversion d'abstraction.
Si tu sais expliquer tout ça à des débutants et qu'ils le comprennent,
chapeau !
>
> Mais c'est vrai que se limiter à cela est stupide. En sortie d'école à
> moins d'entrer chez NVIDIA on ne va pas mettre les mains dans un
> driver opengl ou directX encore moins dans le firmware. Mais quand on
> réalise une application temps réel avec du graphique 3D la
> connaissance du fonctionnement (les algo utilisés) du composant
> utilisé sera primordiale.
On y revient. Si on n'a pas de description formelle, on est "tout nu".
>
>> Je constate juste cette évolution et peut être l'enseignement doit-il
>> prendre cela en compte (il le fait surement déjà). Un historique des
>> langages (qui est le sujet originel) dois AMA montrer l'augmentation
>> dans le niveau d'abstraction mais aussi que, de façon pragmatique, ce
>> n'est plus un enjeux aujourd'hui et que l'abstraction se fait au niveau
>> de design, de l'architecture et des services que rends un langage.
>>
>
> Oui, et même avec un niveau qui n'est pas présent dans les langages de
> programmation : les "design pattern"
Combien de "design patterns" implicites dans les programmes produits
aujourd'hui et ceux qui existent ?
>
>> En ce sens, je pense que Java est un bon choix pour un étudiant.
>
> Java est limité. Ne faire que du java c'est cacher ce qui se passe
> sous l'abstraction. Sauf à étudier la JVM.
C'est vrai pour tous les langages dits de "haut niveau", pas seulement
pour Java.
>
[snip]
Wykaaa
> Wykaaa wrote:
>> Michael DOUBEZ a écrit :
> [snip]
>>> D'un coté c'est assez séduisant car ça permet d'unifier les
>>> représentations (comme la façon de représenter un chemin de fichier),
>>> d'un autre coté, cela créé une grande variabilité et un gigantisme du
>>> langage.
>>
>> Comme je l'ai dit plusieurs fois ici, aujourd'hui, effectivement, il
>> devient très important de connaître non seulement correctement le
>> langage utilisé mais aussi ses bibliothèque. C'est probablement le
>> prix à payer pour une mise en oeuvre effective de la réutilisation...
>
> Je ne crois pas que le prix à payer soit la vision unique et le
> gigantisme. D'autres langages ont utilisés des mécanismes alternatifs:
> CPAN pour perl, Pear pour PHP, CTAN pour LateX ...
Je ne vois pas ce que cela a d'alternatif. Vaut-il mieux avoir à sa
disposition l'ensemble standardisé des bibliothèques essentielles dans
un langage donné ou rechercher sur tout le réseau le module qui convient ?
>
> Les langages qui n'offrent pas ces services ou un système alternatif
> sont aujourd'hui dépréciés. Par exemple C++, je viens d'ailleurs de lire
> un mail intéressant qui rapporte une phrase de B. Stroustrup:
> "... it is my regret that more work hasn't been done in providing a
> consistent overview of library support for C++."
De toute façon, dans les langages C et C++, la notion de module est
totalement absente puisque c'est le fichier qui en fait office.
Stroustrup peut toujours avoir des regrets, c'est un peu hypocrite car,
à l'époque, quand cela lui a été fait remarqué, il n'a rien voulu
entendre. Il ne voulait même pas que la recherche pour les modules
génériques instanciés de la même façon, à plusieurs endroits dans une
application (afin de n'en instancié qu'un seul) soit standardisée...
Chaque compilo avait sa propre cuisine et certains ont "inventés" le
#pragma. Je ne sais pas ce qu'il en est aujourd'hui dans la "norme" C++
car, à l'époque (à l'introduction de la généricité), je me disais que
C++ n'était pas un langage sérieux compte tenu de toutes ces zones d'ombre.
>
>
> [snip]
>>> Puisqu'on est dans l'éducation, on peut prendre Alice:
>>> http://www.alice.org/
>>>
>>> L'interface est graphique plutôt qu'en XML mais le principe est le
>>> même: mise en place d'un environnements et des interactions entre les
>>> éléments. Le moteur de jeux prends le relai de l'exécution.
>>
>> Alice c'est un peu comme Logo avec la 3D en plus, non ?
>> Je trouve ça très bien pour l'apprentissage de la programmation par
>> les plus jeunes. Mon fils avait suivi des cours de Logo au collège, en
>> son temps, le mercredi après-midi.
>
> Sur MO5? J'ai du suivre les mêmes :)
Je ne me rappelle plus si ses cours Logo étaient sur MO5...
>
>
>>> Bon, c'est pas tous les langages comme ça et pour tout le monde mais
>>> il y a cet aspet, je pense, d'assemblage de services qui prend plus
>>> d'importance (sans parler de SOA qui n'a pas les mêmes enjeux).
>>>
>> Ca devient même l'essentiel du travail du développeur, à mon avis.
>
> Et AMA ça va dans le bon sens (de l'industrialisation). Et c'est ce qui
> me fait dire que pour la nouvelle génération, "un langage de
> programmation est une méthode de composition de systèmes et non plus un
> générateur d'instruction."
Enfin, il faut quand même que ça fasse tourner des algos :-)
>
[snip]
Michael DOUBEZ
[snip]
> De toute façon, dans les langages C et C++, la notion de module est
> totalement absente puisque c'est le fichier qui en fait office.
> Stroustrup peut toujours avoir des regrets, c'est un peu hypocrite car,
> à l'époque, quand cela lui a été fait remarqué, il n'a rien voulu
> entendre. Il ne voulait même pas que la recherche pour les modules
> génériques instanciés de la même façon, à plusieurs endroits dans une
> application (afin de n'en instancié qu'un seul) soit standardisée...
> Chaque compilo avait sa propre cuisine et certains ont "inventés" le
> #pragma. Je ne sais pas ce qu'il en est aujourd'hui dans la "norme" C++
> car, à l'époque (à l'introduction de la généricité), je me disais que
> C++ n'était pas un langage sérieux compte tenu de toutes ces zones d'ombre.
Si je me souviens bien, l'importation de module a été rejetée pour C++0x.
--
Michael
cjps...@gmail.com
> cjpsi...@gmail.com a écrit :
>
>
>
> > On 16 fév, 10:27, Michael DOUBEZ <michael.dou...@free.fr> wrote:
> >> Wykaaa wrote:
> >>> Michael DOUBEZ a écrit :
> >> [snip]
>
> >>> Comme je l'ai dit plusieurs fois ici, aujourd'hui, effectivement, il
> >>> devient très important de connaître non seulement correctement le
> >>> langage utilisé mais aussi ses bibliothèque. C'est probablement le prix
> >>> à payer pour une mise en oeuvre effective de la réutilisation...
>
> > Aujourd'hui on assiste à une augmentation d'un ordre de grandeur de la
> > taille des applications. Il n'est plus possible de réinventer la roue
> > et donc on doit essayer d'utiliser ce qui existe déjà avant
> > d'entrevoir un développement nouveau. J'ai déjà dit cela à propos des
> > langages de programmation... Les applications d'aujourd'hui font appel
> > à un tas de fonctions indépendantes qui sont développées dans des
> > langages adaptés donc différents. Le problème est de pouvoir les
> > assembler facilement.
>
> Que voilà un beau "serpent de mer" des informaticiens !
>
les fabricants de logiciels se lient à des solutions propriétaires.
Cela leur permet de rendre leurs clients captifs et de s'assurer une
rente.
Si les développeurs du libre tels que ceux qui développent GCC
voulaient se pencher sur ce problème cela pourrait évoluer
progressivement.
Si les programmeurs leurs faisaient remonter leurs besoins....
Si les programmeurs utilisaient le langage ad'hoc pour la fonction à
programmer et non le langage à la mode du jour.
Si dans l'enseignement de la programmation on enseignait les grandes
catégories de langage de programmation avec leur domaine de
prédilection.
Si .... bon d'accord, je rêve. Je sais que quand on découvre le
nouveau langage à la mode on veut l'employer pour tout faire. Tout
devient clou sous ce marteau.
>
> > Le jour ou les bibliothèque seront indépendantes du langage de
> > programmation qui les utilise on aura fait un grand pas en avant.
>
> Ce n'est pas demain la veille et je ne suis pas sûr que cela soit
> toujours réalisable.
>
Aujourd'hui si on veut assurer un maximum de portabilité à une
bibliothèque vis à vis des langages de programmation on la programme
en C. Parce que C ne connait que des scalaires de types de base (je
mets le pointeur dans les types de base).
> > L'interfaçage entre différents langages de programmation reste
quelque
> > chose de problématique si on veut conserver la portabilité à priori.
>
> Ne serait-ce que pour les langages compilés, il faudrait, au moins,
> qu'il existe un standard (une norme ?) de format de CU ("Compile Unit").
> Cela faciliterait déjà la communication inter-langages mais ça implique
> pleins de choses, y compris une standardisation des noms de fonctions et
> des ordres donnés au lieur (pour la résolution des adresses des
> variables externes par exemple).
Si on est obligé de masquer les variables globales c'est peut-être
préférable.
> Mais prenons par exemple les tableaux : en Fortran les indices
> commencent à un et ce sont les colonnes qui varient le plus vite, en C à
> zéro et ce sont les lignes qui varient le plus vite. Conclusion : passer
> un tableau de C à Fortran oblige à "transposer" le tableau et faire une
> translation d'indice. On règle ça à coup de méthodologie en appelant des
> fonctions qui font le boulot... et ce n'est qu'un exemple.
En C il n'y a pas de sémantique de tableau alors il faut bien se
débrouiller de toute façon. Par exemple en Ada (je sais je suis accro)
il y a un pragma qui indique que le tableau est un tableau fortran et
c'est le compilateur qui se débrouille avec la transposition d'indice.
>
> > Aujourd'hui on sait juste transférer en paramètre des scalaires ou des
> > adresses de tableaux de scalaires.
>
> Ben non. Si on sait comment sont représentés les différents types de
> bases pour un compilateur, on sait comment les récupérer (ce n'est pas
> toujours simple).
Pour les type de base d'accord mais pour les types composés il faut en
connaitre la représentation et la transposer dans les autres langages
au risque d'avoir à refaire le travail si on change de compilateur ou
si on porte sur une autre architecture.
>
> > En plus on doit jongler avec la
> > décoration des noms de fonction. Pour ce qui est des tableaux de
> > dimension variable, des objets et des chaines de caractères c'est
> > beaucoup plus problématique sans parler des exceptions et surtout pas
> > des DEFINE et des génériques.
>
> Oui, il y a tout cela à prendre en compte... Tu vois, on n'est pas
> sortis du bourbier !
Pour la décoration des noms de fonction on pourrait imposer aux
fabricants de compilateurs d'en fournir au moins les spécifications.
Pour le bourbier on est dedans de toute façon. Que je programme dans
n'importe quel langage je devrais à un moment ou un autre appeler une
fonction système ou des fonction d'IHM ou de transfert d'information
depuis et vers une autre application ou un autre composant.
Dans quelques application pour lesquelles j'ai travaillé on utilisait
une description plus ou moins formelle des interfaces et on générait
le code selon le langage de programmation.
Bien sur il y a toujours quelques petits problèmes du genre passage de
chaine de caractères qui dans un langage se termine par un zéro dans
un autre est composée d'une adresse et d'une longueur, dans un autre
encore composée d'une adresse qui référence une structure plus
élaborée. Les différences se portent à deux niveaux : le niveau
abstraction et le niveau implémentation. Les deux sont importants. La
sémantique d'une chaine en C n'est pas du tout le même qu'en fortran
et pas du tout la même qu'en Ada. Ce qui fait que si on connait cela
et si on veut pouvoir faire une interface indépendante du langage on
doit éviter la chaine de caractère et lui trouver un substitut qui est
même sémantique et même implémentation dans la majorité des langages.
Pour régler ces problèmes aujourd'hui on est amené à fournir une
interface de bas niveau et pour chaque langages des couches plus
épaisses qui se coulent dans les styles de programmation des langages
clients du composant.
>
>
Donc les techniques existent et sont utilisées, mais au prix d'un
effort de réalisation et de maintenance très important tant qu'on ne
dispose pas d'outils automatiques. Et surtout que les fabricants de
langages de programmation et de compilateur (et d'interpréteurs)
arrêtent de penser que toutes les applications et les composants
doivent impérativement être écrits dans leurs langage de
programmation.
>
> > Le concept d'objet pourrait facilement être implémenté de manière
> > portable. C'est ce qui est en train de naitre entre Ada et C++ (voir
> > les papier de Adacore). Pourquoi ne pas imaginer un binding et des Api
> > standards.
> > C'est comme l'interfaçage avec les bibliothèques dynamiques (DLL ou
> > autres) notamment pour faciliter la construction de plugins.
>
> Ceci est un effort de normalisation à l'échelle de l'ensemble de la
> communauté des langages. Vaste projet !
> Et les langages interprétés ?
>
Je suis d'accord c'est un vaste projet mais ce serait un vaste
progrès. En plus je ne pense pas que cela soit tellement compliqué
puisque cela existe déjà, mais seulement de manière artisanale.
>
>
> > Je pourrais alors imaginer une application totalement portable à
> > priori (c'est à dire sans se soucier des extensions ou particularités
> > des compilateurs) qui serait constituée d'éléments rigides en langage
> > compilable en code natif et d'éléments interprétés. Cela existe déjà,
> > oui je sais, mais quel travail pour assurer la portabilité. Entre le
> > choix des options de compilation, le choix de compilateurs, la
> > construction des makes et les instructions pour les précompilateurs
> > dont le volume est parfois plus important que la bibliothèque elle
> > même; on se demande comment tout cela peut marcher, cela tient du
> > miracle; en tout cas je ne mettrais pas ce genre de logiciel dans
> > n'importe quelle application.
>
> Tu as tout dit. Ce n'est pas viable dans tous les contextes, loin de là.
>
>
L'universalité n'est pas à notre portée, c'est sur. Mais .... on a le
droit de rêver.
>
> > Pour que cet interfaçage soit réalisable il faut que chaque langage
> > évolue vers la conformité à un standard (je n'ose même plus parler de
> > norme) et fournisse des directives pour le compilateur genre "pragma"
> > en Ada qui permettent de générer des interfaces standards.
>
> Il faudrait déjà un format de "CU" standards, c'est le minimum et ça, ce
> n'est déjà pas donné avant que tout le monde se mette d'accord...
>
>
>
> > En fait cela existe (IDL) mais n'est utilisé que pour des applications
> > de type base de données distribuées.
>
> Ca peut être utilisé à autre chose. Le problème c'est qu'il n'y a pas de
> l'IDL pour tout le monde.
>
>
>
> > Pour la généricité celle fournie par chaque langage peut être utilisée
> > à l'intérieur de chaque module.
> > Et on pourrait envisager de réaliser des traits de généricité dans les
> > langages interprétés (peut-être que cela existe ?).
>
> Excessivement coûteux en performance, en général.
Oui, mais dans le cas d'un langage interprété qui appelle des
bibliothèques compilées, la performance du langage n'est pas le plus
important.
La réalisation d'IHM est souvent prise en charge par des outils
graphiques et le choix de ces outils doit satisfaire les besoins
fonctionnels de l'application. Mais comme toujours le choix d'un outil
rend l'application captive d'une technologie et souvent d'un langage
de programmation.
> > La difficulté vient avec la composition de l'application. Le choix des
> > composant doit être judicieux et doit répondre aussi à des exigences
> > non fonctionnelles qui peuvent être faciles à exprimer et difficiles à
> > satisfaire en tout cas à vérifier. Tel composant me donne t-il les
> > performances que j'attends ? est-il multi-thread ? ...etc...est-il
> > pérenne ?
>
> Il faudrait des description formelles sur la description des composants
> mais, pour prendre un exemple que je connais bien, va décrire
> formellement les performances d'un composant (ça encore, on peut y
> arriver) mais surtout va comparer 2 descriptions formelles de
> performances de n composants qui réalisent la même chose : ça relève
> quasiment de l'indécidable...
Beaucoup de chose sont indécidables théoriquement. Il est même parfois
possible de le démontrer sans trop d'efforts. Mais si on restreint le
contexte on peut définir des éléments qui permettent de faire des
choix pas trop idiots même s'ils ne sont pas optimum.
>
>
>
> > Mais une fois les choix individuels faits il faut s'assurer que les
> > composants peuvent fonctionner ensemble : qu'ils sont composables.
>
> Ah oui, et comment on s'y prend concrètement pour s'assurer qu'ils sont
> composables ?
> Ne me dit pas les tests, car il restera toujours des cas importants qui
> n'auront pas été testés.
>
J'ai dit s'assurer, pas démontrer, :-) , d'accord c'est une
pirouette.
Mais c'est le genre de pirouette qu'on fait tous les jours quand on
compile, link puis exécute une application.
La démonstration formelle est encore limitées à des petits ensembles
fonctionnels.
>
>
> > Et ne pas faire de l'inversion d'abstraction du genre utiliser un
> > tableur pour faire une multiplication.
>
> >> Je vais me faire traiter de vieux schnock (à 31 balais) mais notre grand
> >> plaisir à l'école était de refaire tout de AàZ (moteur 3D, protocole
> >> réseau ...), aujourd'hui le plaisir viens d'avoir sus correctement
> >> agencer des éléments pour obtenir un produit.
> >> Heureusement qu'il y a ce mouvement, sinon l'informatique serait restée
> >> à l'age de l'assembleur et du bidouillage et resterais centrée sur la
> >> technique plutôt que sur les besoins utilisateurs.
>
> > A l'école il me semble important d'aller au plus profond possible des
> > choses. Tâter de l'assembleur, du C et des protocole réseau,
> > programmer une carte graphique, gérer les interruptions, piloter un
> > traceur etc... permettent de savoir ce qu'il se passe sous
> > l'abstraction et de se faire une représentation mentale basée sur du
> > concret. Même si le soft a de plus en plus tendance a pénétrer dans le
> > hard, ce n'est qu'une transcription de réalisation. Le code devient
> > pseudo code. Les algorithmes sont fondamentalement les mêmes sauf
> > qu'ils sont optimisés en fonction de leur contexte.
>
> > Cette connaissance même succinte de ce qui se passe sous l'abstraction
> > permet aussi d'éviter l'inversion d'abstraction.
>
> Si tu sais expliquer tout ça à des débutants et qu'ils le comprennent,
> chapeau !
>
Si on veut des concepteurs qui tiennent la route il faut bien.
>
>
> > Mais c'est vrai que se limiter à cela est stupide. En sortie d'école à
> > moins d'entrer chez NVIDIA on ne va pas mettre les mains dans un
> > driver opengl ou directX encore moins dans le firmware. Mais quand on
> > réalise une application temps réel avec du graphique 3D la
> > connaissance du fonctionnement (les algo utilisés) du composant
> > utilisé sera primordiale.
>
> On y revient. Si on n'a pas de description formelle, on est "tout nu".
>
>
J'ai supposé naïvement qu'en formation à l'informatique il y avait des
cours d'algorithmique et qu'on apprenait à mesurer la complexité. Mais
peut-être que tout cela a changé...
>
> >> Je constate juste cette évolution et peut être l'enseignement doit-il
> >> prendre cela en compte (il le fait surement déjà). Un historique des
> >> langages (qui est le sujet originel) dois AMA montrer l'augmentation
> >> dans le niveau d'abstraction mais aussi
>
> ...
>
> plus de détails »
J'espère que les gars qui vont programmer les prochaines générations
de logiciels qui serviront à diriger les avions, contrôler les trains,
gérer les transactions financières, contrôler les centrales
nucléaires, les scanner et bientôt nos voitures ... auront pu
bénéficier d'autre chose qu'un cours java ou PHP....