C'est incroyable, la Fac d'orleans vient de passer au LMD et ils ont viré
le C des programmes.
Ils ont conservé le Caml pour les 2eme années
Et ont remplacé Pascal (1ere année) et C (2eme année) par je Java sur
les deux années.
En troisieme on aura directement droit au C++.
Je trouve ca injuste. Et dire que j'etais vraiment content de faire du C,
d'autant plus que je tourne uniquement sous Linux et que sous Linux le C
est tres abondant ... je devrais donc apprendre le C a coté : une masse
de travail supplémentaire ... Quel desastre ... vous voyez un bon coté
des choses dans cette histoire, moi je suis un tantinet deprimé la ...
--
ASPO Infogérance - http://aspo.rktmb.org/activites/infogerance
Unofficial FAQ fcolc - http://faq.fcolc.eu.org/
Linux User Group sur Orléans et alentours.
Tél: + 33 2 38 76 43 65 (France)
Je t'invite si tu as du temps à fréquenter le forum c++, à lire les "Design Pattern"
Voilà, justement. J'ai essayé, j'ai eu des problèmes :-)
A+, Stéphane.
-- Ceci est une signature automatique de MesNews. Site : http://mesnews.no-ip.com
Jean-Marc Bourguet
Marc Boyer writes:
Jean-Marc Bourguet wrote:
Quel relativisme? Je défends simplement la thèse qu'il vaut mieux commencer l'enseignement par le niveau d'abstraction le plus élevé utilisé et descendre que l'inverse. Parce que ce niveau est plus simple et qu'il sera plus utilisé que les autres.
Tiens, juste pour compliquer un peu les choses, moi je suis pour un niveau d'abstraction moyen pour commencer: variables, conditions, boucles, fonctions, récursivité, puis on part ensuite dans les deux directions.
Il me semble que c'est justement le niveau le plus haut utilise fourni par le langage (si du moins tu enleve les fonctions). Le reste (routines, structures, modules) permet de batir dans le langage d'autres niveaux d'abstraction.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Jean-Marc Bourguet wrote:
Quel relativisme? Je défends simplement la thèse qu'il vaut
mieux commencer l'enseignement par le niveau d'abstraction
le plus élevé utilisé et descendre que l'inverse. Parce que
ce niveau est plus simple et qu'il sera plus utilisé que les
autres.
Tiens, juste pour compliquer un peu les choses, moi je
suis pour un niveau d'abstraction moyen pour commencer:
variables, conditions, boucles, fonctions, récursivité,
puis on part ensuite dans les deux directions.
Il me semble que c'est justement le niveau le plus haut utilise fourni
par le langage (si du moins tu enleve les fonctions). Le reste
(routines, structures, modules) permet de batir dans le langage
d'autres niveaux d'abstraction.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Quel relativisme? Je défends simplement la thèse qu'il vaut mieux commencer l'enseignement par le niveau d'abstraction le plus élevé utilisé et descendre que l'inverse. Parce que ce niveau est plus simple et qu'il sera plus utilisé que les autres.
Tiens, juste pour compliquer un peu les choses, moi je suis pour un niveau d'abstraction moyen pour commencer: variables, conditions, boucles, fonctions, récursivité, puis on part ensuite dans les deux directions.
Il me semble que c'est justement le niveau le plus haut utilise fourni par le langage (si du moins tu enleve les fonctions). Le reste (routines, structures, modules) permet de batir dans le langage d'autres niveaux d'abstraction.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Marc Boyer
Jean-Marc Bourguet wrote:
Marc Boyer writes:
Tiens, juste pour compliquer un peu les choses, moi je suis pour un niveau d'abstraction moyen pour commencer: variables, conditions, boucles, fonctions, récursivité, puis on part ensuite dans les deux directions.
Il me semble que c'est justement le niveau le plus haut utilise fourni par le langage (si du moins tu enleve les fonctions). Le reste (routines, structures, modules) permet de batir dans le langage d'autres niveaux d'abstraction.
Ben non, pour moi, ça, c'est l'algorithmique. Après, on passe à la programmation: modules, tests unitaires, allocation dynamique, droits d'acces (public/private), objet, polymorphisme, généricité, programmation par contrat...
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Jean-Marc Bourguet wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Tiens, juste pour compliquer un peu les choses, moi je
suis pour un niveau d'abstraction moyen pour commencer:
variables, conditions, boucles, fonctions, récursivité,
puis on part ensuite dans les deux directions.
Il me semble que c'est justement le niveau le plus haut utilise fourni
par le langage (si du moins tu enleve les fonctions). Le reste
(routines, structures, modules) permet de batir dans le langage
d'autres niveaux d'abstraction.
Ben non, pour moi, ça, c'est l'algorithmique. Après, on
passe à la programmation: modules, tests unitaires,
allocation dynamique, droits d'acces (public/private),
objet, polymorphisme, généricité, programmation par
contrat...
Marc Boyer
--
La contractualisation de la recherche, c'est me donner de l'argent pour
faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce
que je sais faire, je le fais sans moyens...
Tiens, juste pour compliquer un peu les choses, moi je suis pour un niveau d'abstraction moyen pour commencer: variables, conditions, boucles, fonctions, récursivité, puis on part ensuite dans les deux directions.
Il me semble que c'est justement le niveau le plus haut utilise fourni par le langage (si du moins tu enleve les fonctions). Le reste (routines, structures, modules) permet de batir dans le langage d'autres niveaux d'abstraction.
Ben non, pour moi, ça, c'est l'algorithmique. Après, on passe à la programmation: modules, tests unitaires, allocation dynamique, droits d'acces (public/private), objet, polymorphisme, généricité, programmation par contrat...
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Marc Boyer
Stéphane Goujet wrote:
Le 29/09/2004, Marc Boyer a supposé :
Je t'invite si tu as du temps à fréquenter le forum c++, à lire les "Design Pattern"
Voilà, justement. J'ai essayé, j'ai eu des problèmes :-)
Problèmes avec quoi. A comprendre les difficultés que prétendent résoudrent ces pattern ou les solutions ? Pour moi, un informaticien en 2004 qui n'arrive pas à lire les "Designe Pattern", ça me semble dommage.
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Stéphane Goujet wrote:
Le 29/09/2004, Marc Boyer a supposé :
Je t'invite si tu as du temps à fréquenter le forum c++,
à lire les "Design Pattern"
Voilà, justement. J'ai essayé, j'ai eu des problèmes :-)
Problèmes avec quoi. A comprendre les difficultés que
prétendent résoudrent ces pattern ou les solutions ?
Pour moi, un informaticien en 2004 qui n'arrive pas
à lire les "Designe Pattern", ça me semble dommage.
Marc Boyer
--
La contractualisation de la recherche, c'est me donner de l'argent pour
faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce
que je sais faire, je le fais sans moyens...
Je t'invite si tu as du temps à fréquenter le forum c++, à lire les "Design Pattern"
Voilà, justement. J'ai essayé, j'ai eu des problèmes :-)
Problèmes avec quoi. A comprendre les difficultés que prétendent résoudrent ces pattern ou les solutions ? Pour moi, un informaticien en 2004 qui n'arrive pas à lire les "Designe Pattern", ça me semble dommage.
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Jean-Marc Bourguet
cedric writes:
Mais à mon tour de vous renvoyer la question : quel est le langage le plus abstrait ?
Je parle de niveau d'abstraction, pas de langages. Le choix du langage m'est assez indifferent tant qu'il ne force pas un melange de niveaux, ce que font le C et l'assembleur en pratique. Du pseudo-code peut meme fonctionner.
C++ ? Certainement pas. Haskell ? Erlang ? Faut-il choisir un langage déclaratif ? full-objet ? Perl ]:) ?
C++ n'est pas un si mauvais choix; sa maitrise necessite le melange de niveau mais un tel melange n'est necessaire pour s'en servir comme support d'un premier cours.
Haskell c'est plutot l'utilisation d'autres abstractions que d'abstraction de plus haut niveau (a part l'aspect manipulation de fonction), je preferais un langage fonctionnel plus classique et pas "pur", scheme me semble un bon choix.
Erlang, je connais pas assez pour commenter.
Les langages logiques (prolog, mercury) sont de plus haut niveau, mais trop "langage de niche" pour servir.
full-object, c'est quoi? Si c'est ce que je pense, c'est trop contraint et le resultat d'une pensee dogmatique (bizarrement je ne pense pas ca des pur fonctionnel).
Perl, no comment.
J'aurais a choisir maintenant, j'hesiterais entre Ada, scheme et aldor (que je ne connais malheureusement pas assez bien). C++ serait acceptable et peut-etre plus facile a faire passer.
Comment ne pas penser que des étudiants qui n'apprendraient qu'Erlang ou Perl ou untel n'auraient pas une vision partielle du domaine ?
Je vais me repeter: l'enseignement doit aborder plusieurs langages.
Avec l'asm au moins, ils ont vu la base sur laquelle les autres se développent. Personne ne dis qu'il ne faut apprendre QUE l'asm, mais à mon avis c'est un module obligatoire, suivi d'un module sur les compilateurs et les OS ; ensuite, roulez jeunesse.
Je vais me repeter: Si un cursus ne présente pas au moins un langage impératif, un langage orienté-objet, un langage fonctionnel classique, un langage fonctionnel pur moderne, un langage logique, un assembleur, il manque des choses.
Mais l'assembleur je le met avec le cours de structure des ordinateurs, mais dans le cours d'introduction.
Je ne suis certainement pas d'accord. Le niveau description le plus bas ayant parfois une utilité pour le programmeur est celui juste au dessous, où les ALU et les pipelines et les délais d'accès aux mémoires ont une existence.
Oui, à condition d'avoir envie de maltraiter les mouches...
Je descend jusqu'a ce niveau quand je m'occupe de performance.
Je vais porter plainte pour diffamation. Je ne suis pas zoophile :-)
Il y avait aussi accessoirement une idée à laquelle je m'opposais implicitement, la description des processeurs registre + mémoire + exécution séquentielle n'est plus pertinente depuis une dizaine d'année pour réfléchir sur les performances.
Certes, il faudrait dire au passage que des processeurs existent qui exécutent plusieurs instructions comme elles viennent ; mais il ne faudrait pas non plus donner l'idée que le vieux shéma registres+mémoire+unité d'exécution n'est qu'une vieille fadaise.
Ce n'est pas une fadaise, c'est une abstraction tout aussi pertinente que celles du dessus ou du dessous.
Les derniers processeurs top-moumoutes sont toujours décris en ces termes là.
Ah bon?
Vous relativisez toujours trop. :)
Je vais trop vite qu'il faille appliquer la relativite a mes pensees?:-)
Ce jeu d'instructions n'a survécu que parce que la compatibilité avec le passé est une obligation.
Ah bon, pourquoi une obligation ? pour qui ?
Les concepteurs de processeurs. Ca coute des millions a Intel et AMD.
Au fait, le systeme registres+mémoire+unité d'exécution est aussi une contrainte pour eux. J'en connais qui pretendent qu'elle nous coute un facteur dix en puissance de calcul -- je ne suis pas tout a fait convaincu -- et qui ont en tete des architectures tellement differentes qu'on ne saurait compiler aucun des langages cites pour elles (a part peut-etre les langages fonctionnels purs, ce doit etre pour ca que je les considere mieux que les langages pur objet).
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
cedric <rixed@happyleptic.NOSPAM.org> writes:
Mais à mon tour de vous renvoyer la question : quel est le langage
le plus abstrait ?
Je parle de niveau d'abstraction, pas de langages. Le choix du
langage m'est assez indifferent tant qu'il ne force pas un melange de
niveaux, ce que font le C et l'assembleur en pratique. Du pseudo-code
peut meme fonctionner.
C++ ? Certainement pas. Haskell ? Erlang ? Faut-il choisir un
langage déclaratif ? full-objet ? Perl ]:) ?
C++ n'est pas un si mauvais choix; sa maitrise necessite le melange de
niveau mais un tel melange n'est necessaire pour s'en servir comme
support d'un premier cours.
Haskell c'est plutot l'utilisation d'autres abstractions que
d'abstraction de plus haut niveau (a part l'aspect manipulation de
fonction), je preferais un langage fonctionnel plus classique et pas
"pur", scheme me semble un bon choix.
Erlang, je connais pas assez pour commenter.
Les langages logiques (prolog, mercury) sont de plus haut niveau, mais
trop "langage de niche" pour servir.
full-object, c'est quoi? Si c'est ce que je pense, c'est trop
contraint et le resultat d'une pensee dogmatique (bizarrement je ne
pense pas ca des pur fonctionnel).
Perl, no comment.
J'aurais a choisir maintenant, j'hesiterais entre Ada, scheme et aldor
(que je ne connais malheureusement pas assez bien). C++ serait
acceptable et peut-etre plus facile a faire passer.
Comment ne pas penser que des étudiants qui n'apprendraient
qu'Erlang ou Perl ou untel n'auraient pas une vision partielle du
domaine ?
Je vais me repeter: l'enseignement doit aborder plusieurs langages.
Avec l'asm au moins, ils ont vu la base sur laquelle les
autres se développent. Personne ne dis qu'il ne faut apprendre QUE
l'asm, mais à mon avis c'est un module obligatoire, suivi d'un
module sur les compilateurs et les OS ; ensuite, roulez jeunesse.
Je vais me repeter: Si un cursus ne présente pas au moins un langage
impératif, un langage orienté-objet, un langage fonctionnel classique,
un langage fonctionnel pur moderne, un langage logique, un assembleur,
il manque des choses.
Mais l'assembleur je le met avec le cours de structure des
ordinateurs, mais dans le cours d'introduction.
Je ne suis certainement pas d'accord. Le niveau description le
plus bas ayant parfois une utilité pour le programmeur est celui
juste au dessous, où les ALU et les pipelines et les délais
d'accès aux mémoires ont une existence.
Oui, à condition d'avoir envie de maltraiter les mouches...
Je descend jusqu'a ce niveau quand je m'occupe de performance.
Je vais porter plainte pour diffamation. Je ne suis pas zoophile :-)
Il y avait aussi accessoirement une idée à laquelle je
m'opposais implicitement, la description des processeurs
registre + mémoire + exécution séquentielle n'est plus
pertinente depuis une dizaine d'année pour réfléchir sur les
performances.
Certes, il faudrait dire au passage que des processeurs existent qui
exécutent plusieurs instructions comme elles viennent ; mais il ne
faudrait pas non plus donner l'idée que le vieux shéma
registres+mémoire+unité d'exécution n'est qu'une vieille fadaise.
Ce n'est pas une fadaise, c'est une abstraction tout aussi pertinente
que celles du dessus ou du dessous.
Les derniers processeurs top-moumoutes sont toujours décris
en ces termes là.
Ah bon?
Vous relativisez toujours trop. :)
Je vais trop vite qu'il faille appliquer la relativite a mes pensees?:-)
Ce jeu d'instructions n'a survécu que parce que la compatibilité
avec le passé est une obligation.
Ah bon, pourquoi une obligation ? pour qui ?
Les concepteurs de processeurs. Ca coute des millions a Intel et AMD.
Au fait, le systeme registres+mémoire+unité d'exécution est aussi une
contrainte pour eux. J'en connais qui pretendent qu'elle nous coute
un facteur dix en puissance de calcul -- je ne suis pas tout a fait
convaincu -- et qui ont en tete des architectures tellement
differentes qu'on ne saurait compiler aucun des langages cites pour
elles (a part peut-etre les langages fonctionnels purs, ce doit etre
pour ca que je les considere mieux que les langages pur objet).
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Mais à mon tour de vous renvoyer la question : quel est le langage le plus abstrait ?
Je parle de niveau d'abstraction, pas de langages. Le choix du langage m'est assez indifferent tant qu'il ne force pas un melange de niveaux, ce que font le C et l'assembleur en pratique. Du pseudo-code peut meme fonctionner.
C++ ? Certainement pas. Haskell ? Erlang ? Faut-il choisir un langage déclaratif ? full-objet ? Perl ]:) ?
C++ n'est pas un si mauvais choix; sa maitrise necessite le melange de niveau mais un tel melange n'est necessaire pour s'en servir comme support d'un premier cours.
Haskell c'est plutot l'utilisation d'autres abstractions que d'abstraction de plus haut niveau (a part l'aspect manipulation de fonction), je preferais un langage fonctionnel plus classique et pas "pur", scheme me semble un bon choix.
Erlang, je connais pas assez pour commenter.
Les langages logiques (prolog, mercury) sont de plus haut niveau, mais trop "langage de niche" pour servir.
full-object, c'est quoi? Si c'est ce que je pense, c'est trop contraint et le resultat d'une pensee dogmatique (bizarrement je ne pense pas ca des pur fonctionnel).
Perl, no comment.
J'aurais a choisir maintenant, j'hesiterais entre Ada, scheme et aldor (que je ne connais malheureusement pas assez bien). C++ serait acceptable et peut-etre plus facile a faire passer.
Comment ne pas penser que des étudiants qui n'apprendraient qu'Erlang ou Perl ou untel n'auraient pas une vision partielle du domaine ?
Je vais me repeter: l'enseignement doit aborder plusieurs langages.
Avec l'asm au moins, ils ont vu la base sur laquelle les autres se développent. Personne ne dis qu'il ne faut apprendre QUE l'asm, mais à mon avis c'est un module obligatoire, suivi d'un module sur les compilateurs et les OS ; ensuite, roulez jeunesse.
Je vais me repeter: Si un cursus ne présente pas au moins un langage impératif, un langage orienté-objet, un langage fonctionnel classique, un langage fonctionnel pur moderne, un langage logique, un assembleur, il manque des choses.
Mais l'assembleur je le met avec le cours de structure des ordinateurs, mais dans le cours d'introduction.
Je ne suis certainement pas d'accord. Le niveau description le plus bas ayant parfois une utilité pour le programmeur est celui juste au dessous, où les ALU et les pipelines et les délais d'accès aux mémoires ont une existence.
Oui, à condition d'avoir envie de maltraiter les mouches...
Je descend jusqu'a ce niveau quand je m'occupe de performance.
Je vais porter plainte pour diffamation. Je ne suis pas zoophile :-)
Il y avait aussi accessoirement une idée à laquelle je m'opposais implicitement, la description des processeurs registre + mémoire + exécution séquentielle n'est plus pertinente depuis une dizaine d'année pour réfléchir sur les performances.
Certes, il faudrait dire au passage que des processeurs existent qui exécutent plusieurs instructions comme elles viennent ; mais il ne faudrait pas non plus donner l'idée que le vieux shéma registres+mémoire+unité d'exécution n'est qu'une vieille fadaise.
Ce n'est pas une fadaise, c'est une abstraction tout aussi pertinente que celles du dessus ou du dessous.
Les derniers processeurs top-moumoutes sont toujours décris en ces termes là.
Ah bon?
Vous relativisez toujours trop. :)
Je vais trop vite qu'il faille appliquer la relativite a mes pensees?:-)
Ce jeu d'instructions n'a survécu que parce que la compatibilité avec le passé est une obligation.
Ah bon, pourquoi une obligation ? pour qui ?
Les concepteurs de processeurs. Ca coute des millions a Intel et AMD.
Au fait, le systeme registres+mémoire+unité d'exécution est aussi une contrainte pour eux. J'en connais qui pretendent qu'elle nous coute un facteur dix en puissance de calcul -- je ne suis pas tout a fait convaincu -- et qui ont en tete des architectures tellement differentes qu'on ne saurait compiler aucun des langages cites pour elles (a part peut-etre les langages fonctionnels purs, ce doit etre pour ca que je les considere mieux que les langages pur objet).
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Stéphane Goujet
Il se trouve que Marc Boyer a formulé :
à lire les "Design Pattern" Voilà, justement. J'ai essayé, j'ai eu des problèmes :-)
Problèmes avec quoi. A comprendre les difficultés que
prétendent résoudrent ces pattern ou les solutions ?
Je dirais plutôt les difficultés à résoudre, dans la mesure où on essaye de résoudre ou de simplifier des problèmes qui ne m'étaient jamais apparus comme tels. Quant aux solutions, je les trouve lourdingues et absconses, mais c'est mon problème à moi avec les langages objet en général et le C++ en particulier : je trouve que, tout en masquant quantité de choses et paradoxalement, parce ces choses sont masquées, le C++ complexifie et obscurcit les programmes. Je crois tout simplement que je ne fait pas partie du public visé et interressé par ce genre d'ouvrage (j'ai aussi essayé d'ingurgiter "Effective C++").
Pour moi, un informaticien en 2004 qui n'arrive pas à lire les "Designe Pattern", ça me semble dommage.
Erreur, je ne suis pas un "doigts carrés". Cela m'est néanmoins apparu dommage d'être insensible à la beauté supposée de la chose. Mais (dans mon cas), il n'y a guère à discuter sur cela : ce n'est qu'une question de goût, d'inclination, et peut-être de capacités. EOT ?
A+, Stéphane.
-- Ceci est une signature automatique de MesNews. Site : http://mesnews.no-ip.com
Il se trouve que Marc Boyer a formulé :
à lire les "Design Pattern"
Voilà, justement. J'ai essayé, j'ai eu des problèmes :-)
Problèmes avec quoi. A comprendre les difficultés que
prétendent résoudrent ces pattern ou les solutions ?
Je dirais plutôt les difficultés à résoudre, dans la mesure où on
essaye de résoudre ou de simplifier des problèmes qui ne m'étaient
jamais apparus comme tels. Quant aux solutions, je les trouve
lourdingues et absconses, mais c'est mon problème à moi avec les
langages objet en général et le C++ en particulier : je trouve que,
tout en masquant quantité de choses et paradoxalement, parce ces choses
sont masquées, le C++ complexifie et obscurcit les programmes.
Je crois tout simplement que je ne fait pas partie du public visé et
interressé par ce genre d'ouvrage (j'ai aussi essayé d'ingurgiter
"Effective C++").
Pour moi, un informaticien en 2004 qui n'arrive pas
à lire les "Designe Pattern", ça me semble dommage.
Erreur, je ne suis pas un "doigts carrés".
Cela m'est néanmoins apparu dommage d'être insensible à la beauté
supposée de la chose. Mais (dans mon cas), il n'y a guère à discuter
sur cela : ce n'est qu'une question de goût, d'inclination, et
peut-être de capacités. EOT ?
A+,
Stéphane.
--
Ceci est une signature automatique de MesNews.
Site : http://mesnews.no-ip.com
à lire les "Design Pattern" Voilà, justement. J'ai essayé, j'ai eu des problèmes :-)
Problèmes avec quoi. A comprendre les difficultés que
prétendent résoudrent ces pattern ou les solutions ?
Je dirais plutôt les difficultés à résoudre, dans la mesure où on essaye de résoudre ou de simplifier des problèmes qui ne m'étaient jamais apparus comme tels. Quant aux solutions, je les trouve lourdingues et absconses, mais c'est mon problème à moi avec les langages objet en général et le C++ en particulier : je trouve que, tout en masquant quantité de choses et paradoxalement, parce ces choses sont masquées, le C++ complexifie et obscurcit les programmes. Je crois tout simplement que je ne fait pas partie du public visé et interressé par ce genre d'ouvrage (j'ai aussi essayé d'ingurgiter "Effective C++").
Pour moi, un informaticien en 2004 qui n'arrive pas à lire les "Designe Pattern", ça me semble dommage.
Erreur, je ne suis pas un "doigts carrés". Cela m'est néanmoins apparu dommage d'être insensible à la beauté supposée de la chose. Mais (dans mon cas), il n'y a guère à discuter sur cela : ce n'est qu'une question de goût, d'inclination, et peut-être de capacités. EOT ?
A+, Stéphane.
-- Ceci est une signature automatique de MesNews. Site : http://mesnews.no-ip.com
Marc Boyer
Stéphane Goujet wrote:
Il se trouve que Marc Boyer a formulé :
à lire les "Design Pattern" Voilà, justement. J'ai essayé, j'ai eu des problèmes :-)
Problèmes avec quoi. A comprendre les difficultés que
prétendent résoudrent ces pattern ou les solutions ?
Je dirais plutôt les difficultés à résoudre, dans la mesure où on essaye de résoudre ou de simplifier des problèmes qui ne m'étaient jamais apparus comme tels.
C'est en effet rédibitoire. Si on est pas d'accord sur les hypothèses, le reste se passe mal.
Quant aux solutions, je les trouve lourdingues et absconses, mais c'est mon problème à moi avec les langages objet en général et le C++ en particulier : je trouve que, tout en masquant quantité de choses et paradoxalement, parce ces choses sont masquées, le C++ complexifie et obscurcit les programmes.
C'est en effet une question que je me pose avec C++: la complexité introduite est-elle assez faible face à la complexité maîtrisée. En gros, le remède n'est-il pas pire que le mal.
Pour moi, un informaticien en 2004 qui n'arrive pas à lire les "Designe Pattern", ça me semble dommage.
Erreur, je ne suis pas un "doigts carrés".
D'ou ton manque d'intérêt pour les outils des doigts carrés.
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Stéphane Goujet wrote:
Il se trouve que Marc Boyer a formulé :
à lire les "Design Pattern"
Voilà, justement. J'ai essayé, j'ai eu des problèmes :-)
Problèmes avec quoi. A comprendre les difficultés que
prétendent résoudrent ces pattern ou les solutions ?
Je dirais plutôt les difficultés à résoudre, dans la mesure où on
essaye de résoudre ou de simplifier des problèmes qui ne m'étaient
jamais apparus comme tels.
C'est en effet rédibitoire. Si on est pas d'accord sur les
hypothèses, le reste se passe mal.
Quant aux solutions, je les trouve
lourdingues et absconses, mais c'est mon problème à moi avec les
langages objet en général et le C++ en particulier : je trouve que,
tout en masquant quantité de choses et paradoxalement, parce ces choses
sont masquées, le C++ complexifie et obscurcit les programmes.
C'est en effet une question que je me pose avec C++: la
complexité introduite est-elle assez faible face à la
complexité maîtrisée.
En gros, le remède n'est-il pas pire que le mal.
Pour moi, un informaticien en 2004 qui n'arrive pas
à lire les "Designe Pattern", ça me semble dommage.
Erreur, je ne suis pas un "doigts carrés".
D'ou ton manque d'intérêt pour les outils des doigts carrés.
Marc Boyer
--
La contractualisation de la recherche, c'est me donner de l'argent pour
faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce
que je sais faire, je le fais sans moyens...
à lire les "Design Pattern" Voilà, justement. J'ai essayé, j'ai eu des problèmes :-)
Problèmes avec quoi. A comprendre les difficultés que
prétendent résoudrent ces pattern ou les solutions ?
Je dirais plutôt les difficultés à résoudre, dans la mesure où on essaye de résoudre ou de simplifier des problèmes qui ne m'étaient jamais apparus comme tels.
C'est en effet rédibitoire. Si on est pas d'accord sur les hypothèses, le reste se passe mal.
Quant aux solutions, je les trouve lourdingues et absconses, mais c'est mon problème à moi avec les langages objet en général et le C++ en particulier : je trouve que, tout en masquant quantité de choses et paradoxalement, parce ces choses sont masquées, le C++ complexifie et obscurcit les programmes.
C'est en effet une question que je me pose avec C++: la complexité introduite est-elle assez faible face à la complexité maîtrisée. En gros, le remède n'est-il pas pire que le mal.
Pour moi, un informaticien en 2004 qui n'arrive pas à lire les "Designe Pattern", ça me semble dommage.
Erreur, je ne suis pas un "doigts carrés".
D'ou ton manque d'intérêt pour les outils des doigts carrés.
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
K. Ahausse
"Marc Boyer" a écrit dans le message de news:cjgg6g$19j$
cedric wrote:
Exception ? On reparle de l'assembleur ?? :-D
Non, car l'assembleur ne permet pas de libérer les ressources en ordre inverse d'aquisition lors d'une exception.
Y'a comme un bug, là.
Il faudrait qu'un langage générer une séquence de codeops qu'un assembleur "ne permettrait pas" ?
Si ce n'est pas une ânerie j'aimerais bien en savoir plus, car pour moi un pan entier de la science s'écroule :-)
"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le message
de news:cjgg6g$19j$2@news.cict.fr...
cedric wrote:
Exception ? On reparle de l'assembleur ?? :-D
Non, car l'assembleur ne permet pas de libérer les
ressources en ordre inverse d'aquisition lors d'une
exception.
Y'a comme un bug, là.
Il faudrait qu'un langage générer une séquence de codeops qu'un assembleur
"ne permettrait pas" ?
Si ce n'est pas une ânerie j'aimerais bien en savoir plus, car pour moi un
pan entier de la science s'écroule :-)
"Marc Boyer" a écrit dans le message de news:cjgg6g$19j$
cedric wrote:
Exception ? On reparle de l'assembleur ?? :-D
Non, car l'assembleur ne permet pas de libérer les ressources en ordre inverse d'aquisition lors d'une exception.
Y'a comme un bug, là.
Il faudrait qu'un langage générer une séquence de codeops qu'un assembleur "ne permettrait pas" ?
Si ce n'est pas une ânerie j'aimerais bien en savoir plus, car pour moi un pan entier de la science s'écroule :-)
Marc Boyer
K. Ahausse wrote:
"Marc Boyer" a écrit dans le message de news:cjgg6g$19j$
cedric wrote:
Exception ? On reparle de l'assembleur ?? :-D
Non, car l'assembleur ne permet pas de libérer les ressources en ordre inverse d'aquisition lors d'une exception.
Y'a comme un bug, là.
Il faudrait qu'un langage générer une séquence de codeops qu'un assembleur "ne permettrait pas" ?
J'aurais du dire l'écriture en assembleur oblige le programmeur qui désire libérer les ressources en ordre inverse d'acquisition en cas d'exception à un code tellement lourd qu'il ne le fait jamais dans la pratique.
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
K. Ahausse wrote:
"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le message
de news:cjgg6g$19j$2@news.cict.fr...
cedric wrote:
Exception ? On reparle de l'assembleur ?? :-D
Non, car l'assembleur ne permet pas de libérer les
ressources en ordre inverse d'aquisition lors d'une
exception.
Y'a comme un bug, là.
Il faudrait qu'un langage générer une séquence de codeops qu'un assembleur
"ne permettrait pas" ?
J'aurais du dire l'écriture en assembleur oblige le programmeur
qui désire libérer les ressources en ordre inverse d'acquisition
en cas d'exception à un code tellement lourd qu'il ne le fait jamais
dans la pratique.
Marc Boyer
--
La contractualisation de la recherche, c'est me donner de l'argent pour
faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce
que je sais faire, je le fais sans moyens...
"Marc Boyer" a écrit dans le message de news:cjgg6g$19j$
cedric wrote:
Exception ? On reparle de l'assembleur ?? :-D
Non, car l'assembleur ne permet pas de libérer les ressources en ordre inverse d'aquisition lors d'une exception.
Y'a comme un bug, là.
Il faudrait qu'un langage générer une séquence de codeops qu'un assembleur "ne permettrait pas" ?
J'aurais du dire l'écriture en assembleur oblige le programmeur qui désire libérer les ressources en ordre inverse d'acquisition en cas d'exception à un code tellement lourd qu'il ne le fait jamais dans la pratique.
Marc Boyer -- La contractualisation de la recherche, c'est me donner de l'argent pour faire ce que je ne sais pas faire, que je fais donc mal, pendant que ce que je sais faire, je le fais sans moyens...
Gabriel Dos Reis
"Charlie Gordon" writes:
| "Vincent Lefevre" <vincent+ wrote in message | news:20040929134001$ | > | > Je conseillerais plutôt la VO, car dans la VF, il y a des erreurs de | > traduction gênantes (genre byte -> octet). | > | En quoi est-ce une erreur ? | | http://fr.wikipedia.org/wiki/Byte
Ne crois pas tout ce que tu lis sur le web.
-- Gaby
"Charlie Gordon" <news@chqrlie.org> writes:
| "Vincent Lefevre" <vincent+news@vinc17.org> wrote in message
| news:20040929134001$5890@vinc17.org...
| >
| > Je conseillerais plutôt la VO, car dans la VF, il y a des erreurs de
| > traduction gênantes (genre byte -> octet).
| >
| En quoi est-ce une erreur ?
|
| http://fr.wikipedia.org/wiki/Byte
| "Vincent Lefevre" <vincent+ wrote in message | news:20040929134001$ | > | > Je conseillerais plutôt la VO, car dans la VF, il y a des erreurs de | > traduction gênantes (genre byte -> octet). | > | En quoi est-ce une erreur ? | | http://fr.wikipedia.org/wiki/Byte
