... et ils ont viré le C

cedric

29/09/2004 à 18:51

Jean-Marc Bourguet wrote:

Mais l'assembleur ce n'est jamais qu'une abstraction aussi, (...)
equations de Maxwell et la physique quantique (...) abstraction plus faible.

Elle est bien bonne.

Personne ici avant cela n'était entré dans la discussion de savoir quel
niveau d'abstraction rendait le mieux compte de "ce qui se passe
vraiment" ; la réponse étant bien évidente : aucun, par définition.

La question qui était posé, c'est de choisir un langage d'enseignement
parmi les langages qui permettent de controler un ordinateur.
L'assembleur (doublé d'un rapide coup d'oeil sur le format de codage des
instructions par le CPU) est le plus bas niveau que l'on puisse
concevoir. On n'a pas prétendu qu'on pouvait psychanalyser l'électron
avec, juste que c'était le premier langage qui permettait d'entrer des
ordres pour la machine ; par construction. Si les i386 récents, à force
de contorsions stupides, en arrivent a posséder un jeux d'instructions
officiel et un jeux d'instruction ésotérique, ca ne fait que révéler la
grande confusion mentale qui règne chez ce constructeur, rien de plus.

Cessez donc de souffler ce relativisme décourageant.

:-p

Johann Dantant

29/09/2004 à 19:00

"Marc Boyer" a écrit dans le message
de news:cjemh6$7gs$

Johann Dantant wrote:
(...)

Le premier but d'une école devrait être d'enseigner un savoir faire. De
mon

expérience un savoir faire en programmation ça passe par une progression
logique, depuis la machine vers le haut niveau, point barre.

Pourquoi ne pas commencer alors à Turing, puis le lamda-calcul
typé (équivalence de Church au passage si on a 2mn), puis le
reste n'est que mise en pratique ?

Pourquoi verser immédiatement dans la caricature ? Bien sûr qu'il n'est pas
forcément indispensable de commencer à la Pascaline et aux métiers Jacquart
pour enseigner l'informatique (même si une bonne culture générale est
souvent un gage d'awareness comme dirant Van Damme). Sérieusement, quand on
voit débarquer des stagiaires qui n'ont aucune, mais absolument aucune idée
de ce que le nombre de bits du type int a comme impact sur leur code, on
croit rêver ! Quand après 3 ans de formation Java il faut leur expliquer
pourquoi la valeur 0x1234 qu'ils envoient au gars en face est interprétée
par lui comme étant 0x3412, on ne rêve plus, on pleure... Par contre, on
leur a bien appris à mettre 1234 en UTF-8 dans un fichier XML, c'est vrai...

Parmi tous les
collègues et stagiaires que j'ai eu et que j'ai encore, seuls ceux qui
ont

suivi cette logique ont de réelles compétences utilisables pour faire
autre

chose que des camemberts ou des histogrammes.

Sérieux ? T'es sur qu'ils ont tous commencé la prog par l'ASM ?

Pas forcément l'assembleur. Mais au minimum par de bonnes notions d'algèbre
booléenne, par des notions fondamentales d'architecture, par des TPs de
maths ou de physique bien ciblés (récursivité, calculs matriciels, tri...).
Le langage importe peu, personnellement j'ai commencé par le Pascal puis le
C puis enfin l'assembleur, mais cela ne me semble vraiment pas
déterminant... Le point important à mon avis est que l'étudiant touche du
doigt se qui se passe physiquement dans la machine quand il écrit telle
ligne de code plutôt que telle autre. On peut espérer que ça lui plus tard
d'écrire en Java une fonction qui fait out of memory exception en moins de
temps qu'il n'en faut pour essayer de l'arrêter...

(...)

Quel est le critère de "bonne méthode pédagogique" ? Pour moi,
c'est celle qui permet de faire entre de manière durable un max
d'information en un min de temps à un max d'élèves.

C'est un non sens. Les élèves sont là pour acquérir un savoir faire, pas
pour digérer une encyclopédie ou une somme d'information. Je préfère 100
fois un gars qui a une bonne méthode de travail même si ses connaissances
sont réduites, à un gars qui a survolé tous les domaines dans sa formation
mais qui s'avère incapable d'approfondir quoique ce soit dès qu'il n'est
plus encadré.

Et le C est d'expérience un bon moyen de perdre du temps
et des élèves en route.

Le C est d'expérience une bonne école de rigueur et d'humilité dont ceux qui
réchappent savent lire un livre pour y trouver des informations, et
comprendre et mettre en oeuvre ces informations. C'est certain que ça peut
prendre du temps, ce n'est peut-être pas accessible à tout le monde, mais ce
n'est pas en allant au plus vite qu'on travaille sur le long terme.

(...)

Plus sérieusement, il y a des choses qui sont *jolies* dans
un code et qu'on laisse tomber parce que non maintenables (genre
un i |= ~1 vu récemment ici).

Ca c'est pas joli, pas beau, je suis d'accord. Ce qui est joli et beau c'est
de faire plus court tout en faisant plus simple et plus lisible...

Naivement j'espérais que la contractualisation de la recherche c'était
de

donner de l'argent sur des résultats et non sur des objectifs...
Qu'est-ce

que je suis naïf...

Disons que la meilleure idée peut donner la pire mise en pratique
si on ne fait pas attention à ce qu'on fait.

J'imagine que tu sais ce que tu dis...

J.D.
--
C'est tout bête mais avec OE 4 je n'arrive plus à envoyer de
mails (...) alors que j'arrive à me connecter sur le net, à
envoyer des mails,... Please please sauvez-moi...
-+- JC in GNU : Docteur, quand je fais ca, je n'y arrive pas ! -+-

"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le message
de news:cjemh6$7gs$1@news.cict.fr...

Johann Dantant wrote:
(...)

Le premier but d'une école devrait être d'enseigner un savoir faire. De
mon

expérience un savoir faire en programmation ça passe par une progression
logique, depuis la machine vers le haut niveau, point barre.

Pourquoi ne pas commencer alors à Turing, puis le lamda-calcul
typé (équivalence de Church au passage si on a 2mn), puis le
reste n'est que mise en pratique ?

Pourquoi verser immédiatement dans la caricature ? Bien sûr qu'il n'est pas
forcément indispensable de commencer à la Pascaline et aux métiers Jacquart
pour enseigner l'informatique (même si une bonne culture générale est
souvent un gage d'awareness comme dirant Van Damme). Sérieusement, quand on
voit débarquer des stagiaires qui n'ont aucune, mais absolument aucune idée
de ce que le nombre de bits du type int a comme impact sur leur code, on
croit rêver ! Quand après 3 ans de formation Java il faut leur expliquer
pourquoi la valeur 0x1234 qu'ils envoient au gars en face est interprétée
par lui comme étant 0x3412, on ne rêve plus, on pleure... Par contre, on
leur a bien appris à mettre 1234 en UTF-8 dans un fichier XML, c'est vrai...

Parmi tous les
collègues et stagiaires que j'ai eu et que j'ai encore, seuls ceux qui
ont

suivi cette logique ont de réelles compétences utilisables pour faire
autre

chose que des camemberts ou des histogrammes.

Sérieux ? T'es sur qu'ils ont tous commencé la prog par l'ASM ?

Pas forcément l'assembleur. Mais au minimum par de bonnes notions d'algèbre
booléenne, par des notions fondamentales d'architecture, par des TPs de
maths ou de physique bien ciblés (récursivité, calculs matriciels, tri...).
Le langage importe peu, personnellement j'ai commencé par le Pascal puis le
C puis enfin l'assembleur, mais cela ne me semble vraiment pas
déterminant... Le point important à mon avis est que l'étudiant touche du
doigt se qui se passe physiquement dans la machine quand il écrit telle
ligne de code plutôt que telle autre. On peut espérer que ça lui plus tard
d'écrire en Java une fonction qui fait out of memory exception en moins de
temps qu'il n'en faut pour essayer de l'arrêter...

(...)

Quel est le critère de "bonne méthode pédagogique" ? Pour moi,
c'est celle qui permet de faire entre de manière durable un max
d'information en un min de temps à un max d'élèves.

C'est un non sens. Les élèves sont là pour acquérir un savoir faire, pas
pour digérer une encyclopédie ou une somme d'information. Je préfère 100
fois un gars qui a une bonne méthode de travail même si ses connaissances
sont réduites, à un gars qui a survolé tous les domaines dans sa formation
mais qui s'avère incapable d'approfondir quoique ce soit dès qu'il n'est
plus encadré.

Et le C est d'expérience un bon moyen de perdre du temps
et des élèves en route.

Le C est d'expérience une bonne école de rigueur et d'humilité dont ceux qui
réchappent savent lire un livre pour y trouver des informations, et
comprendre et mettre en oeuvre ces informations. C'est certain que ça peut
prendre du temps, ce n'est peut-être pas accessible à tout le monde, mais ce
n'est pas en allant au plus vite qu'on travaille sur le long terme.

(...)

Plus sérieusement, il y a des choses qui sont *jolies* dans
un code et qu'on laisse tomber parce que non maintenables (genre
un i |= ~1 vu récemment ici).

Ca c'est pas joli, pas beau, je suis d'accord. Ce qui est joli et beau c'est
de faire plus court tout en faisant plus simple et plus lisible...

Naivement j'espérais que la contractualisation de la recherche c'était
de

donner de l'argent sur des résultats et non sur des objectifs...
Qu'est-ce

que je suis naïf...

Disons que la meilleure idée peut donner la pire mise en pratique
si on ne fait pas attention à ce qu'on fait.

J'imagine que tu sais ce que tu dis...

J.D.
--
C'est tout bête mais avec OE 4 je n'arrive plus à envoyer de
mails (...) alors que j'arrive à me connecter sur le net, à
envoyer des mails,... Please please sauvez-moi...
-+- JC in GNU : Docteur, quand je fais ca, je n'y arrive pas ! -+-

Vous avez filtré cet utilisateur ! Consultez son message

"Marc Boyer" a écrit dans le message
de news:cjemh6$7gs$

Johann Dantant wrote:
(...)

Le premier but d'une école devrait être d'enseigner un savoir faire. De
mon

expérience un savoir faire en programmation ça passe par une progression
logique, depuis la machine vers le haut niveau, point barre.

Pourquoi ne pas commencer alors à Turing, puis le lamda-calcul
typé (équivalence de Church au passage si on a 2mn), puis le
reste n'est que mise en pratique ?

Pourquoi verser immédiatement dans la caricature ? Bien sûr qu'il n'est pas
forcément indispensable de commencer à la Pascaline et aux métiers Jacquart
pour enseigner l'informatique (même si une bonne culture générale est
souvent un gage d'awareness comme dirant Van Damme). Sérieusement, quand on
voit débarquer des stagiaires qui n'ont aucune, mais absolument aucune idée
de ce que le nombre de bits du type int a comme impact sur leur code, on
croit rêver ! Quand après 3 ans de formation Java il faut leur expliquer
pourquoi la valeur 0x1234 qu'ils envoient au gars en face est interprétée
par lui comme étant 0x3412, on ne rêve plus, on pleure... Par contre, on
leur a bien appris à mettre 1234 en UTF-8 dans un fichier XML, c'est vrai...

Parmi tous les
collègues et stagiaires que j'ai eu et que j'ai encore, seuls ceux qui
ont

suivi cette logique ont de réelles compétences utilisables pour faire
autre

chose que des camemberts ou des histogrammes.

Sérieux ? T'es sur qu'ils ont tous commencé la prog par l'ASM ?

Pas forcément l'assembleur. Mais au minimum par de bonnes notions d'algèbre
booléenne, par des notions fondamentales d'architecture, par des TPs de
maths ou de physique bien ciblés (récursivité, calculs matriciels, tri...).
Le langage importe peu, personnellement j'ai commencé par le Pascal puis le
C puis enfin l'assembleur, mais cela ne me semble vraiment pas
déterminant... Le point important à mon avis est que l'étudiant touche du
doigt se qui se passe physiquement dans la machine quand il écrit telle
ligne de code plutôt que telle autre. On peut espérer que ça lui plus tard
d'écrire en Java une fonction qui fait out of memory exception en moins de
temps qu'il n'en faut pour essayer de l'arrêter...

(...)

Quel est le critère de "bonne méthode pédagogique" ? Pour moi,
c'est celle qui permet de faire entre de manière durable un max
d'information en un min de temps à un max d'élèves.

C'est un non sens. Les élèves sont là pour acquérir un savoir faire, pas
pour digérer une encyclopédie ou une somme d'information. Je préfère 100
fois un gars qui a une bonne méthode de travail même si ses connaissances
sont réduites, à un gars qui a survolé tous les domaines dans sa formation
mais qui s'avère incapable d'approfondir quoique ce soit dès qu'il n'est
plus encadré.

Et le C est d'expérience un bon moyen de perdre du temps
et des élèves en route.

Le C est d'expérience une bonne école de rigueur et d'humilité dont ceux qui
réchappent savent lire un livre pour y trouver des informations, et
comprendre et mettre en oeuvre ces informations. C'est certain que ça peut
prendre du temps, ce n'est peut-être pas accessible à tout le monde, mais ce
n'est pas en allant au plus vite qu'on travaille sur le long terme.

(...)

Plus sérieusement, il y a des choses qui sont *jolies* dans
un code et qu'on laisse tomber parce que non maintenables (genre
un i |= ~1 vu récemment ici).

Ca c'est pas joli, pas beau, je suis d'accord. Ce qui est joli et beau c'est
de faire plus court tout en faisant plus simple et plus lisible...

Naivement j'espérais que la contractualisation de la recherche c'était
de

donner de l'argent sur des résultats et non sur des objectifs...
Qu'est-ce

que je suis naïf...

Disons que la meilleure idée peut donner la pire mise en pratique
si on ne fait pas attention à ce qu'on fait.

J'imagine que tu sais ce que tu dis...

J.D.
--
C'est tout bête mais avec OE 4 je n'arrive plus à envoyer de
mails (...) alors que j'arrive à me connecter sur le net, à
envoyer des mails,... Please please sauvez-moi...
-+- JC in GNU : Docteur, quand je fais ca, je n'y arrive pas ! -+-

James Kanze

29/09/2004 à 20:05

Trognon Patrice writes:

|> James Kanze wrote:

|> > Benoît Dejean writes:

|> > |> et après tout Java, soit disant disant "code once run
|> > |> everywhere" ...

|> > C'est bien connu, Java, c'est du « write once, debug everywhere ».

|> > Enfin, c'est quand même plus portable que le C++. Au moins, quand
|> > j'ai une GUI à réaliser. (Et si je n'ai pas de GUI, je ne me sers
|> > pas de Java:-).)

|> Ben la portabilité tu peux l'avoir en C++ aussi (et en C). Le tout
|> étant de savoir ce que tu écris.

Je crois m'y connaître en ce qui concerne la portabilité et en C et en
C++. Je crois aussi que tu as raté l'émoticon. Écrire un GUI portable en
C ou en C++, c'est du boulot. Strictement parlant, si on s'en tient à la
norme, c'est même impossible. (Mais si on s'en tient à la norme en C++,
on n'est pas portable.) Dans la pratique, évidemment, qui dit GUI dit
limitation de la portabilité -- quelque soit le langage, une application
avec GUI ne va pas tourner sur le petit processeur embarqué avec tout
juste 256 octets de RAM. Dans la pratique, écrire une application avec
un GUI en C ou en C++, ça veut dire commencer par trouver une
bibliothèque plus ou moins portable.

|> Perso auteur d'un jeu en C++/opengl, plus de 20000 lignes de code,
|> codé entièrement sur windows, le portage sur linux m'a pris une
|> seule journée.

Oui, mais tu as sans doute investi pas mal du temps lorsque tu
l'écrivais pour Windows, pour s'assurer de la portabilité. Déjà, tu as
dû chercher la bibliothèque, parce que opengl n'est pas standard ni avec
C++ ni avec C.

|> Ce que je veux dire, c'est que le problème est de savoir ce que
|> l'on veut :
|> 1) soit on laisse la programmation aux spécialistes, et alors
|> le portage ne leur pose pas trop de problème.
|> 2) soit on essaye de mettre la programmation à la portée de plus
|> de monde.

|> Dans le cas 1), les codeurs en question savent ce qu'ils font.
|> Dans le cas 2), les codeurs on l'impression de savoir ce qu'ils font
|> car le language utilisé leur masque beaucoup de chose.

|> Au bilan on a quoi d'après vous ?

|> Regardez le nombre de projets Java qui donnent des usines à gaz à
|> l'arrivée.

Il y en avait dans le temps. Il n'y en a plus autant que ça. Parce que
l'utilisation du Java s'est restreint à une niche particulière.

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Trognon Patrice <trognon.patrice@wanadoo.fr> writes:

|> James Kanze wrote:

|> > Benoît Dejean <bnet@ifrance.com> writes:

|> > |> et après tout Java, soit disant disant "code once run
|> > |> everywhere" ...

|> > C'est bien connu, Java, c'est du « write once, debug everywhere ».

|> > Enfin, c'est quand même plus portable que le C++. Au moins, quand
|> > j'ai une GUI à réaliser. (Et si je n'ai pas de GUI, je ne me sers
|> > pas de Java:-).)

|> Ben la portabilité tu peux l'avoir en C++ aussi (et en C). Le tout
|> étant de savoir ce que tu écris.

Je crois m'y connaître en ce qui concerne la portabilité et en C et en
C++. Je crois aussi que tu as raté l'émoticon. Écrire un GUI portable en
C ou en C++, c'est du boulot. Strictement parlant, si on s'en tient à la
norme, c'est même impossible. (Mais si on s'en tient à la norme en C++,
on n'est pas portable.) Dans la pratique, évidemment, qui dit GUI dit
limitation de la portabilité -- quelque soit le langage, une application
avec GUI ne va pas tourner sur le petit processeur embarqué avec tout
juste 256 octets de RAM. Dans la pratique, écrire une application avec
un GUI en C ou en C++, ça veut dire commencer par trouver une
bibliothèque plus ou moins portable.

|> Perso auteur d'un jeu en C++/opengl, plus de 20000 lignes de code,
|> codé entièrement sur windows, le portage sur linux m'a pris une
|> seule journée.

Oui, mais tu as sans doute investi pas mal du temps lorsque tu
l'écrivais pour Windows, pour s'assurer de la portabilité. Déjà, tu as
dû chercher la bibliothèque, parce que opengl n'est pas standard ni avec
C++ ni avec C.

|> Ce que je veux dire, c'est que le problème est de savoir ce que
|> l'on veut :
|> 1) soit on laisse la programmation aux spécialistes, et alors
|> le portage ne leur pose pas trop de problème.
|> 2) soit on essaye de mettre la programmation à la portée de plus
|> de monde.

|> Dans le cas 1), les codeurs en question savent ce qu'ils font.
|> Dans le cas 2), les codeurs on l'impression de savoir ce qu'ils font
|> car le language utilisé leur masque beaucoup de chose.

|> Au bilan on a quoi d'après vous ?

|> Regardez le nombre de projets Java qui donnent des usines à gaz à
|> l'arrivée.

Il y en avait dans le temps. Il n'y en a plus autant que ça. Parce que
l'utilisation du Java s'est restreint à une niche particulière.

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Vous avez filtré cet utilisateur ! Consultez son message

Trognon Patrice writes:

|> James Kanze wrote:

|> > Benoît Dejean writes:

|> > |> et après tout Java, soit disant disant "code once run
|> > |> everywhere" ...

|> > C'est bien connu, Java, c'est du « write once, debug everywhere ».

|> > Enfin, c'est quand même plus portable que le C++. Au moins, quand
|> > j'ai une GUI à réaliser. (Et si je n'ai pas de GUI, je ne me sers
|> > pas de Java:-).)

|> Ben la portabilité tu peux l'avoir en C++ aussi (et en C). Le tout
|> étant de savoir ce que tu écris.

Je crois m'y connaître en ce qui concerne la portabilité et en C et en
C++. Je crois aussi que tu as raté l'émoticon. Écrire un GUI portable en
C ou en C++, c'est du boulot. Strictement parlant, si on s'en tient à la
norme, c'est même impossible. (Mais si on s'en tient à la norme en C++,
on n'est pas portable.) Dans la pratique, évidemment, qui dit GUI dit
limitation de la portabilité -- quelque soit le langage, une application
avec GUI ne va pas tourner sur le petit processeur embarqué avec tout
juste 256 octets de RAM. Dans la pratique, écrire une application avec
un GUI en C ou en C++, ça veut dire commencer par trouver une
bibliothèque plus ou moins portable.

|> Perso auteur d'un jeu en C++/opengl, plus de 20000 lignes de code,
|> codé entièrement sur windows, le portage sur linux m'a pris une
|> seule journée.

Oui, mais tu as sans doute investi pas mal du temps lorsque tu
l'écrivais pour Windows, pour s'assurer de la portabilité. Déjà, tu as
dû chercher la bibliothèque, parce que opengl n'est pas standard ni avec
C++ ni avec C.

|> Ce que je veux dire, c'est que le problème est de savoir ce que
|> l'on veut :
|> 1) soit on laisse la programmation aux spécialistes, et alors
|> le portage ne leur pose pas trop de problème.
|> 2) soit on essaye de mettre la programmation à la portée de plus
|> de monde.

|> Dans le cas 1), les codeurs en question savent ce qu'ils font.
|> Dans le cas 2), les codeurs on l'impression de savoir ce qu'ils font
|> car le language utilisé leur masque beaucoup de chose.

|> Au bilan on a quoi d'après vous ?

|> Regardez le nombre de projets Java qui donnent des usines à gaz à
|> l'arrivée.

Il y en avait dans le temps. Il n'y en a plus autant que ça. Parce que
l'utilisation du Java s'est restreint à une niche particulière.

--
James Kanze
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34

Jean-Marc Bourguet

29/09/2004 à 20:59

cedric writes:

Jean-Marc Bourguet wrote:
Mais l'assembleur ce n'est jamais qu'une abstraction
aussi, (...) equations de Maxwell et la physique
quantique (...) abstraction plus faible.

Elle est bien bonne.

Personne ici avant cela n'était entré dans la discussion
de savoir quel niveau d'abstraction rendait le mieux
compte de "ce qui se passe vraiment" ; la réponse étant
bien évidente : aucun, par définition.

La question est de savoir par où commencer l'enseignement.
Johann veut "une progression logique, depuis la machine vers
le haut niveau", j'ai simplement poussé au bout sa logique
de progression logique des composants vers les composés.
J'ai exagéré à peine, on tient bien compte d'effets
quantiques lors de la fabrication de circuits intégrés.

La question qui était posé, c'est de choisir un langage
d'enseignement parmi les langages qui permettent de
controler un ordinateur.

L'enseignement doit aborder plusieurs langages. 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. Dans quel ordre et dans
quelle profondeur, c'est la vraie question. Le C a un
problème en tant que premier langage, c'est qu'il force à
mélanger deux niveaux d'abstraction. L'assembleur en a un
autre: c'est devenu un niveau non pertinent et donc pour en
profiter il faut aussi toucher au niveau du dessous, celui
ou on touche a l'architecture du processeur -- c'est
pourquoi je ne l'enseignerais que dans le cadre d'un cours
d'architecture des ordinateurs.

L'assembleur (doublé d'un rapide coup d'oeil sur le format
de codage des instructions par le CPU) est le plus bas
niveau que l'on puisse concevoir.

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.

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. Les processeurs ont au moins 3 niveaux de
mémoire avec des temps d'accès différents et exécute
plusieurs instructions simultanément, parfois dans le
désordre par rapport à un schéma linéaire. Ce modèle est
maintenant aussi artificiel que les machines abstraites
utilisées dans les normes des langages de programmation.

On n'a pas prétendu qu'on pouvait psychanalyser l'électron
avec, juste que c'était le premier langage qui permettait
d'entrer des ordres pour la machine ; par construction.

Ce jeu d'instructions n'a survécu que parce que la
compatibilité avec le passé est une obligation.

Cessez donc de souffler ce relativisme décourageant.

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.

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:

Jean-Marc Bourguet wrote:

Mais l'assembleur ce n'est jamais qu'une abstraction
aussi, (...) equations de Maxwell et la physique
quantique (...) abstraction plus faible.

Elle est bien bonne.

Personne ici avant cela n'était entré dans la discussion
de savoir quel niveau d'abstraction rendait le mieux
compte de "ce qui se passe vraiment" ; la réponse étant
bien évidente : aucun, par définition.

La question est de savoir par où commencer l'enseignement.
Johann veut "une progression logique, depuis la machine vers
le haut niveau", j'ai simplement poussé au bout sa logique
de progression logique des composants vers les composés.
J'ai exagéré à peine, on tient bien compte d'effets
quantiques lors de la fabrication de circuits intégrés.

La question qui était posé, c'est de choisir un langage
d'enseignement parmi les langages qui permettent de
controler un ordinateur.

L'enseignement doit aborder plusieurs langages. 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. Dans quel ordre et dans
quelle profondeur, c'est la vraie question. Le C a un
problème en tant que premier langage, c'est qu'il force à
mélanger deux niveaux d'abstraction. L'assembleur en a un
autre: c'est devenu un niveau non pertinent et donc pour en
profiter il faut aussi toucher au niveau du dessous, celui
ou on touche a l'architecture du processeur -- c'est
pourquoi je ne l'enseignerais que dans le cadre d'un cours
d'architecture des ordinateurs.

L'assembleur (doublé d'un rapide coup d'oeil sur le format
de codage des instructions par le CPU) est le plus bas
niveau que l'on puisse concevoir.

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.

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. Les processeurs ont au moins 3 niveaux de
mémoire avec des temps d'accès différents et exécute
plusieurs instructions simultanément, parfois dans le
désordre par rapport à un schéma linéaire. Ce modèle est
maintenant aussi artificiel que les machines abstraites
utilisées dans les normes des langages de programmation.

On n'a pas prétendu qu'on pouvait psychanalyser l'électron
avec, juste que c'était le premier langage qui permettait
d'entrer des ordres pour la machine ; par construction.

Ce jeu d'instructions n'a survécu que parce que la
compatibilité avec le passé est une obligation.

Cessez donc de souffler ce relativisme décourageant.

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.

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

Vous avez filtré cet utilisateur ! Consultez son message

cedric writes:

Jean-Marc Bourguet wrote:
Mais l'assembleur ce n'est jamais qu'une abstraction
aussi, (...) equations de Maxwell et la physique
quantique (...) abstraction plus faible.

Elle est bien bonne.

Personne ici avant cela n'était entré dans la discussion
de savoir quel niveau d'abstraction rendait le mieux
compte de "ce qui se passe vraiment" ; la réponse étant
bien évidente : aucun, par définition.

La question est de savoir par où commencer l'enseignement.
Johann veut "une progression logique, depuis la machine vers
le haut niveau", j'ai simplement poussé au bout sa logique
de progression logique des composants vers les composés.
J'ai exagéré à peine, on tient bien compte d'effets
quantiques lors de la fabrication de circuits intégrés.

La question qui était posé, c'est de choisir un langage
d'enseignement parmi les langages qui permettent de
controler un ordinateur.

L'enseignement doit aborder plusieurs langages. 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. Dans quel ordre et dans
quelle profondeur, c'est la vraie question. Le C a un
problème en tant que premier langage, c'est qu'il force à
mélanger deux niveaux d'abstraction. L'assembleur en a un
autre: c'est devenu un niveau non pertinent et donc pour en
profiter il faut aussi toucher au niveau du dessous, celui
ou on touche a l'architecture du processeur -- c'est
pourquoi je ne l'enseignerais que dans le cadre d'un cours
d'architecture des ordinateurs.

L'assembleur (doublé d'un rapide coup d'oeil sur le format
de codage des instructions par le CPU) est le plus bas
niveau que l'on puisse concevoir.

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.

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. Les processeurs ont au moins 3 niveaux de
mémoire avec des temps d'accès différents et exécute
plusieurs instructions simultanément, parfois dans le
désordre par rapport à un schéma linéaire. Ce modèle est
maintenant aussi artificiel que les machines abstraites
utilisées dans les normes des langages de programmation.

On n'a pas prétendu qu'on pouvait psychanalyser l'électron
avec, juste que c'était le premier langage qui permettait
d'entrer des ordres pour la machine ; par construction.

Ce jeu d'instructions n'a survécu que parce que la
compatibilité avec le passé est une obligation.

Cessez donc de souffler ce relativisme décourageant.

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.

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

Misterjack

29/09/2004 à 21:04

Salut !

Misterjack wrote:
L'intérêt d'apprendre le C c'est de comprendre ce que l'on fait et de ne
pas travailler "en aveugle".

scanf("%d",&i);
scanf("%s", prenom);

C'est clair qu'une fois qu'on a compris tout ce que font ces
lignes, on a compris beaucoup de choses.
Mais bon nombre de débutant font ça "en aveugle" (pendant quelques
mois en tout cas).

Je voulais dire que savoir vaguement comment fonctionne un processeur et
son environnement immédiat est utile. Ca permet de ne pas rester comme
un couillon devant un problème complexe qui y est lié.

Commencer par le C permet à l'étudiant de
savoir ce qu'il fait et l'aidera à résoudre beaucoup plus facilement ses
problèmes, et à passer plus facilement à d'autres langages ou plateformes.

A condition qu'il réussisse à le faire.

Si certains n'y arrivent pas c'est soit qu'ils ont des difficultés
certaines, soit qu'ils ne sont pas motivés pour y arriver, soit qu'ils
ne bossent pas. C'est pas insurmontable quand même !

Etre obligé de comprendre le hardware avant de savoir programmer
en C me semble un argument défavorable pour le C.

Je pense le contraire, mais bon, chacun son avis, hein ! :D

Avant de programmer, en C ou en assembleur, il me semble
nécessaire de savoir écrire un algorithme.

Oui. C'est nécessaire avec tous les langages, et c'est à mon sens le
seul vrai intérêt des cours d'informatique à l'université en plus des
méthodes.

Résultat après 3 ans : une maîtrise correcte du C, une autonomie en C++
et Java. Et ceux qui bossent vriament le truc ont rapidement un très bon
niveau.

Et si on avait commencé par autre chose ?

On voit arriver la génération "langages haut niveau". Le résultat est
déplorable : ils savent appeler des fonctions toutes faites, savent
utiliser des composants téléchargés sur internet, savent utiliser des
générateurs de code. Mais en conditions réelles, on a des gens
incapables de créer. C'est très triste. C'est en partie ce qui me fait
militer pour donner une approche plus "hard" à la programmation. Il y a
15 ans les programmeurs maitrisaient la machine et le développeemnt.
Aujourd'hui ce n'est plus forcément vrai.
On a des utilisateurs de langages de programmation, pas des programmeurs.

Non, AMHA le principal problème c'est de faire un code
maintenable, et la question n'est plus de savoir ce qu'on
fait que de savoir le partager de manière péreine.

L'un n'empêche pas l'autre.

Marcel Dassault disait : "Un bel avion vole bien". A méditer.

Et Airbus a fait le Belouga ;-)

Bah, le Belouga il est marrant, fait bien son boulot, mais on peut pas
dire qu'il vole très bien :)))))

@Tchao !
--
Mister Jack (MJ)
"Linux c'est pas pour les manchots !"

Salut !

Misterjack wrote:

L'intérêt d'apprendre le C c'est de comprendre ce que l'on fait et de ne
pas travailler "en aveugle".

scanf("%d",&i);
scanf("%s", prenom);

C'est clair qu'une fois qu'on a compris tout ce que font ces
lignes, on a compris beaucoup de choses.
Mais bon nombre de débutant font ça "en aveugle" (pendant quelques
mois en tout cas).

Je voulais dire que savoir vaguement comment fonctionne un processeur et
son environnement immédiat est utile. Ca permet de ne pas rester comme
un couillon devant un problème complexe qui y est lié.

Commencer par le C permet à l'étudiant de
savoir ce qu'il fait et l'aidera à résoudre beaucoup plus facilement ses
problèmes, et à passer plus facilement à d'autres langages ou plateformes.

A condition qu'il réussisse à le faire.

Si certains n'y arrivent pas c'est soit qu'ils ont des difficultés
certaines, soit qu'ils ne sont pas motivés pour y arriver, soit qu'ils
ne bossent pas. C'est pas insurmontable quand même !

Etre obligé de comprendre le hardware avant de savoir programmer
en C me semble un argument défavorable pour le C.

Je pense le contraire, mais bon, chacun son avis, hein ! :D

Avant de programmer, en C ou en assembleur, il me semble
nécessaire de savoir écrire un algorithme.

Oui. C'est nécessaire avec tous les langages, et c'est à mon sens le
seul vrai intérêt des cours d'informatique à l'université en plus des
méthodes.

Résultat après 3 ans : une maîtrise correcte du C, une autonomie en C++
et Java. Et ceux qui bossent vriament le truc ont rapidement un très bon
niveau.

Et si on avait commencé par autre chose ?

On voit arriver la génération "langages haut niveau". Le résultat est
déplorable : ils savent appeler des fonctions toutes faites, savent
utiliser des composants téléchargés sur internet, savent utiliser des
générateurs de code. Mais en conditions réelles, on a des gens
incapables de créer. C'est très triste. C'est en partie ce qui me fait
militer pour donner une approche plus "hard" à la programmation. Il y a
15 ans les programmeurs maitrisaient la machine et le développeemnt.
Aujourd'hui ce n'est plus forcément vrai.
On a des utilisateurs de langages de programmation, pas des programmeurs.

Non, AMHA le principal problème c'est de faire un code
maintenable, et la question n'est plus de savoir ce qu'on
fait que de savoir le partager de manière péreine.

L'un n'empêche pas l'autre.

Marcel Dassault disait : "Un bel avion vole bien". A méditer.

Et Airbus a fait le Belouga ;-)

Bah, le Belouga il est marrant, fait bien son boulot, mais on peut pas
dire qu'il vole très bien :)))))

@Tchao !
--
Mister Jack (MJ)
"Linux c'est pas pour les manchots !"

Vous avez filtré cet utilisateur ! Consultez son message

Salut !

Misterjack wrote:
L'intérêt d'apprendre le C c'est de comprendre ce que l'on fait et de ne
pas travailler "en aveugle".

scanf("%d",&i);
scanf("%s", prenom);

C'est clair qu'une fois qu'on a compris tout ce que font ces
lignes, on a compris beaucoup de choses.
Mais bon nombre de débutant font ça "en aveugle" (pendant quelques
mois en tout cas).

Je voulais dire que savoir vaguement comment fonctionne un processeur et
son environnement immédiat est utile. Ca permet de ne pas rester comme
un couillon devant un problème complexe qui y est lié.

Commencer par le C permet à l'étudiant de
savoir ce qu'il fait et l'aidera à résoudre beaucoup plus facilement ses
problèmes, et à passer plus facilement à d'autres langages ou plateformes.

A condition qu'il réussisse à le faire.

Si certains n'y arrivent pas c'est soit qu'ils ont des difficultés
certaines, soit qu'ils ne sont pas motivés pour y arriver, soit qu'ils
ne bossent pas. C'est pas insurmontable quand même !

Etre obligé de comprendre le hardware avant de savoir programmer
en C me semble un argument défavorable pour le C.

Je pense le contraire, mais bon, chacun son avis, hein ! :D

Avant de programmer, en C ou en assembleur, il me semble
nécessaire de savoir écrire un algorithme.

Oui. C'est nécessaire avec tous les langages, et c'est à mon sens le
seul vrai intérêt des cours d'informatique à l'université en plus des
méthodes.

Résultat après 3 ans : une maîtrise correcte du C, une autonomie en C++
et Java. Et ceux qui bossent vriament le truc ont rapidement un très bon
niveau.

Et si on avait commencé par autre chose ?

On voit arriver la génération "langages haut niveau". Le résultat est
déplorable : ils savent appeler des fonctions toutes faites, savent
utiliser des composants téléchargés sur internet, savent utiliser des
générateurs de code. Mais en conditions réelles, on a des gens
incapables de créer. C'est très triste. C'est en partie ce qui me fait
militer pour donner une approche plus "hard" à la programmation. Il y a
15 ans les programmeurs maitrisaient la machine et le développeemnt.
Aujourd'hui ce n'est plus forcément vrai.
On a des utilisateurs de langages de programmation, pas des programmeurs.

Non, AMHA le principal problème c'est de faire un code
maintenable, et la question n'est plus de savoir ce qu'on
fait que de savoir le partager de manière péreine.

L'un n'empêche pas l'autre.

Marcel Dassault disait : "Un bel avion vole bien". A méditer.

Et Airbus a fait le Belouga ;-)

Bah, le Belouga il est marrant, fait bien son boulot, mais on peut pas
dire qu'il vole très bien :)))))

@Tchao !
--
Mister Jack (MJ)
"Linux c'est pas pour les manchots !"

cedric

29/09/2004 à 21:39

Jean-Marc Bourguet wrote:

La question est de savoir par où commencer l'enseignement.
Johann veut "une progression logique, depuis la machine vers
le haut niveau", j'ai simplement poussé au bout sa logique
de progression logique des composants vers les composés.
J'ai exagéré à peine, on tient bien compte d'effets
quantiques lors de la fabrication de circuits intégrés.

Certes, et je ne suis pas contre non plus un petit débordement sur
l'électronique.

Mais à mon tour de vous renvoyer la question : quel est le langage le
plus abstrait ? C++ ? Certainement pas. Haskell ? Erlang ?
Faut-il choisir un langage déclaratif ? full-objet ? Perl ]:) ?

Comment ne pas penser que des étudiants qui n'apprendraient qu'Erlang ou
Perl ou untel n'auraient pas une vision partielle du domaine ? 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 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...

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. Les
derniers processeurs top-moumoutes sont toujours décris en ces termes
là. Vous relativisez toujours trop. :)

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 ?

Jean-Marc Bourguet wrote:

La question est de savoir par où commencer l'enseignement.
Johann veut "une progression logique, depuis la machine vers
le haut niveau", j'ai simplement poussé au bout sa logique
de progression logique des composants vers les composés.
J'ai exagéré à peine, on tient bien compte d'effets
quantiques lors de la fabrication de circuits intégrés.

Certes, et je ne suis pas contre non plus un petit débordement sur
l'électronique.

Mais à mon tour de vous renvoyer la question : quel est le langage le
plus abstrait ? C++ ? Certainement pas. Haskell ? Erlang ?
Faut-il choisir un langage déclaratif ? full-objet ? Perl ]:) ?

Comment ne pas penser que des étudiants qui n'apprendraient qu'Erlang ou
Perl ou untel n'auraient pas une vision partielle du domaine ? 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 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...

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. Les
derniers processeurs top-moumoutes sont toujours décris en ces termes
là. Vous relativisez toujours trop. :)

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 ?

Vous avez filtré cet utilisateur ! Consultez son message

Jean-Marc Bourguet wrote:

La question est de savoir par où commencer l'enseignement.
Johann veut "une progression logique, depuis la machine vers
le haut niveau", j'ai simplement poussé au bout sa logique
de progression logique des composants vers les composés.
J'ai exagéré à peine, on tient bien compte d'effets
quantiques lors de la fabrication de circuits intégrés.

Certes, et je ne suis pas contre non plus un petit débordement sur
l'électronique.

Mais à mon tour de vous renvoyer la question : quel est le langage le
plus abstrait ? C++ ? Certainement pas. Haskell ? Erlang ?
Faut-il choisir un langage déclaratif ? full-objet ? Perl ]:) ?

Comment ne pas penser que des étudiants qui n'apprendraient qu'Erlang ou
Perl ou untel n'auraient pas une vision partielle du domaine ? 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 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...

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. Les
derniers processeurs top-moumoutes sont toujours décris en ces termes
là. Vous relativisez toujours trop. :)

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 ?

cedric

29/09/2004 à 21:53

Marc Boyer wrote:

Je t'invite si tu as du temps à fréquenter le forum c++,
à lire les "Design Pattern" ou "Rumination in C++".

Lire également "practical reusable unix software", par le labo d'AT&T
auquel on doit entre autre le programme dotty. Ce livre relate leur
expérience (dans les années 80) pour développer des softs utiles et
réutilisables. Ils ont atteint la proportion de 50% de réutilisation
dans leur distribution d'outils. Comme quoi le problème peut être pensé
sans en faire une question de langage (ils codent tout en C, utilisent
le Shell comme "langage d'action" et utilisent des ordonnanceurs entre
les deux).

Une lecture qui repose du brouhaha des objets et des patterns.

Par exemple, il faut pas coder longtemps pour réaliser
que les exceptions sont la meilleure solution à ce jour à la
gestion d'erreur. Et que l'OO est la meilleure pour
lier libération des ressources et gestion d'erreur.

Exception ? On reparle de l'assembleur ?? :-D

Taquineries à part, ces mécanismes - objets, exceptions, patterns,
tolérence aux pannes, gestion des ressources... - sont à enseigner
quelque soit le langage.

Misterjack

29/09/2004 à 21:54

Salut !

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.

Bah on va voir ce genre de questions de plus en plus souvent sur les NG
: "Cela fait plusieurs fois que je dévellope des prog sous VB, tout
fonctionne bien, mais au bout d'un moment, j'ai un dépassemet de pile.
??? j'ai lu pas mal de chose concernant la récursivité, mais pas de
solution pour purger cette pile ....."

Des étudiants qui programment du haut niveau sans connaître du tout le
bas niveau ça va être chaud.

@Tchao !
--
Mister Jack (MJ)
"Java m'a tuer"

cedric

29/09/2004 à 22:00

Eric Deveaud wrote:

l'expérience nous a montré que l'acquisition des concepts se faisait
plus facilement via un langage (dit) de haut niveau.

Vous tenez-là un argument-massue.

L'assembleur peur aussi sembler un mauvais investissement du fait qu'il
change de machine en machine. Pourtant, les principes de bases restent
toujours plus ou moins les mêmes

dans ce cas pourquoi ne pas utiliser une machine de turing pour
apprendre la programation ??

Et pourquoi ne pas en concevoir une petite (en pensée!) avec les
étudiants lors du premier cours ? Un peut comme Knuth dans son cours ?

On pourrait réaliser quelques algorithmes avec, résoudre quelques
problèmes. Et une fois qu'ils auraient compris, avec les doigts, les
"principes" d'un algorithme, vous pourriez embrayer sur une vrai machine
et un vrai langage (au hasard, le C) ?

Tiens, c'est pas idiot ca, il faudrait écrire ce petit manuel qui
explique comment fonctionne "La Machine", son petit jeu d'instruction,
et faire quelques petits exercices. On pourrait bien sur coder un
émulateur en C pour se rendre compte visuelement de ce qui se passe. Cet
émulateur, ce serait le projet de fin d'année :-)

Benoît Dejean

29/09/2004 à 22:55

Le Tue, 28 Sep 2004 21:57:14 +0200, James Kanze a écrit :

Benoît Dejean writes:

|> et après tout Java, soit disant disant "code once run everywhere" ...

C'est bien connu, Java, c'est du « write once, debug everywhere ».

héhé

Enfin, c'est quand même plus portable que le C++. Au moins, quand j'ai
une GUI à réaliser. (Et si je n'ai pas de GUI, je ne me sers pas de
Java:-).)

Java c'est portable mais pas porté. Un compilateur C ANSI, tu en
trouveras presque partout. Avec tu peux construire tout ton environnement
: interfaces graphiques, langages interprétés (Perl, Python, Mono, etc).

Et là tu investis dans un ibook flambant neuf. Tu t'empresses d'y
installer GNU/Linux. C'est magique tout compile, tout fonctionne, tu ne
soupçonne même pas que tu as quitté ton PC. Jusqu'au moment où tu veux
faire du Java. Avec la main mise de Sun, à part leur JVM, point de salut.
Seulement leur VM, elle existe pour X86/sparc pour windows, linux,
solaris, ce qui fait doucement rire en terme de portabilité. Bref pas de
Java. Bref, après le bourrage de mou que j'ai subis, je suis assez
surpris.

Et l'histoire de ne s'arrête pas là : déployer un produit Sun sur une
machine Linux/i386, c'est monstrueusement lourdingue. Bref, de ce que je
constate, Java, c'est pas exploitable, si je veux quelque chose de
portable, je reste aux langages classiques et aux interpréteurs libres
écrit en C ANSI.

Bon fini le troll, bon Dieu ce que j'aime le C :)

... et ils ont viré le C

10 réponses

Veuillez sélectionner un problème