... et ils ont viré le C

Marc Boyer wrote:

Ecrire un tri de type tri-rapide en ASM pour s'en convaincre.
Rendre le code générique sur le type de données et le critère
de tri pour rire un peu.

Ce ne sera pas très différent de la version C.

Ce qui est fastidieux en asm, amha, c'est plutôt de se passer
d'analyseur d'expressions. Genre :

int i = (a * 5.1) /3 + 2;

Là, ce C économise la frappe !

cedric <rixed@happyleptic.NOSPAM.org> writes:

Eric Deveaud wrote:

commencer par un langage bas niveau est une bétise.

Ne soyez pas si péremptoire. Que le développement en assembleur soit plus
lent qu'en tout autre langage n'implique pas que ce soit plus
difficile. Considérez ceci : la norme d'un langage (même du C, dont la
norme est pourtant concise) est rarement plus courte qu'une liste
d'opcodes,

Cela fait un certain temps qu'une liste d'opcode ne suffit plus pour
programmer en assembleur. Les processeurs ont change depuis les 8008.

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 avait énoncé :

Eric Deveaud wrote:

commencer par un langage bas niveau est une bétise.
Ne soyez pas si péremptoire. Que le développement en assembleur soit plus

lent qu'en tout autre langage n'implique pas que ce soit plus difficile.
Considérez ceci : la norme d'un langage (même du C, dont la norme est
pourtant concise) est rarement plus courte qu'une liste d'opcodes, et fait
appel à des définitions et des notions éthérées plus difficiles à visualiser
que la description de l'action d'une opcode.

Je suis tout à fait d'accord : je n'ai jamais eu de problème avec les
notions basiques d'architecture et d'assembleur, alors que les notions
de haut-niveau, par leur charabia conceptuel, me laissent encore et
toujours perplexe.
Le C est pour moi un bon compromis car il me permet de ne pas trop
m'éloigner du "terre à terre", et une connaissance de base du niveau
en-dessous permet de rapidement dissiper les principaux pièges et
malentendus qui se présentent au débutant, comme vous les citez plus
bas.

Et j'suis aussi d'accord avec le reste du texte que j'ai enlevé.

A+,
Stéphane.

--
Ceci est une signature automatique de MesNews.
Site : http://mesnews.no-ip.com

Stéphane Goujet wrote:

cedric avait énoncé :

Eric Deveaud wrote:

commencer par un langage bas niveau est une bétise.
Ne soyez pas si péremptoire. Que le développement en assembleur soit plus

lent qu'en tout autre langage n'implique pas que ce soit plus difficile.
Considérez ceci : la norme d'un langage (même du C, dont la norme est
pourtant concise) est rarement plus courte qu'une liste d'opcodes, et fait
appel à des définitions et des notions éthérées plus difficiles à visualiser
que la description de l'action d'une opcode.

Je suis tout à fait d'accord : je n'ai jamais eu de problème avec les
notions basiques d'architecture et d'assembleur, alors que les notions
de haut-niveau, par leur charabia conceptuel, me laissent encore et
toujours perplexe.

Parce qu'ils sont là pour résoudre des problèmes d'une complexité
toute différente ?

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...

cedric wrote:

Eric Deveaud wrote:

commencer par un langage bas niveau est une bétise.

Ne soyez pas si péremptoire.

je voulais au contraire être péremptoire ;-)

étant confronté au problème de l'enseignement de la programation à des
débutants complets, des biologistes pour tout dire.
je me heurte à des problèmes non d'acquisition du langage, mais à des
problèmes de conception.

le principal problème que nous rencontrons n'est pas l'acquisition du
vocabulaire lié au langage. nous utilisons, et avons utilisé des
langages divers et varié (scheme, python, perl, C, java).
mais bien la façon de modéliser le problème, le découpage en taches
élémentaires et leur enchainement logique. Une fois cette barrière
franchie, le langage ne présente que des contraintes d'ordre
typographique.

d'ou ma volonté de leur faire faire beaucou de pseudo-code en TP

l'avantage d'un langage qui masque/facilite (au choix) la gestion de la
mémoire permet de s'abstraire plus facilement de l'aspect langage en lui
même.
le deuxieme avantage d'un langage type python (j'exclu perl du fait de
ses variables implicites, qui sont très perturbantes et ne sont que du
sucre syntaxique) est qu'il y a une très grande facilité de passage du
pseudo code aux code lui-même.

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

Quant à perdre un débutant avec la notion de mémoire, à ce que je sache
le concept de variable des langages évolué, voir d'objets, n'est pas
vraiment plus simple (il n'y a qu'à voir le nombre de choses différentes
que regroupent le terme "objet" par exemple - merci la simplicité !).

la notion de variable est en soit peu évidente pour des non
informaticiens au début. les matheux sont un peu rebuté par le terme
même de variable, il y a antinomie entre le sens varaible en info et en
math.

nous sommes d'accord en ce qui concerne l'objet.

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 ??

Eric

--
Alcotest> OUi, mais aussi pour la création des 2 autres ducon,
Expliquez moi, pourquoi voulez vous créer deux autres ducon ?
Vous vous sentez seul ?
-+- FF in Guide du Neuneu sur Usenet - Les deux font l'impair -+-

"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le message
de news:cjdvnk$2ht$1@news.cict.fr...

In article <415A7DDC.8000705@yahoo.NoSpam.fr>, Max M wrote:

Prendre des débutants complets et commencer avec le C ?
Bonne chance.

C'est ce que j'ai fait et pas le seul ;et je trouve cela tres sain

Le fait que certains en réchappent ne signifie pas que ce soit une
bonne méthode pédagogique.

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. 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.

Maintenant, tu as certainement raison de considérer que c'est une mauvaise
méthode pédagogique, mais personnellement je préfères une mauvaise méthode
pédagogique qui forme des gens compétents et efficaces qu'une bonne méthode
pédagogique qui m'amène des brouettes de débutants inemployables en l'état.
Il suffit de repenser à la méthode actuelle d'apprentissage de la lecture
qui donne de si bon résultats dans les écoles primaires. Une amie qui se
destine à être institutrice (enfin, ex-amie, forcément on est fâché
maintenant...) me soutient que c'est une bonne méthode pédagogique.
D'accord. Mais une autre amie prof en 6ème me confirme que c'est une
mauvaise méthode d'apprentissage, puisqu'ils sont nuls en arrivant... Alors
?

(...)

Quand à la beauté, je ne trouve pas ça un argument: on forme
des développeurs, pas des artistes.

Non non, franchement, sincèrement, il ne faut surtout pas dire ça... J'ai
aussi assuré (oh, pas longtemps, j'en ai eu vite marre) quelques cours en
école d'ingénieur. Une fois passé de l'autre côté de la barrière, j'ai pu
confronter (un peu) mes points de vue avec mes anciens professeurs, et
effectivement eux comme toi ne voient que les arguments techniques et
pédagogiques. C'est à mon sens une erreur fatale. Un développeur c'est avant
tout un créateur, au même titre qu'un designer de voiture ou un modiste.
Comme le designer ou comme le modiste il a entre les mains un cahier des
charges, des méthodes de travailles précises et des critères d'évaluation
strictes, mais comme le designer ou le modiste il doit aimer, chercher à
faire beau, à la fois pour lui (il est avant tout fier de ce qu'il fait et
heureux de ne pas être immédiatement remplaçable par une machine à pisser du
code) et pour le projet lui-même. Lisibilité du code, performances globales,
rapidité de codage, ambiance dans l'équipe, de ma petite expérience tout le
monde gagne à travailler avec des artistes...

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...

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...

Johann Dantant
--
Ceci est un message en texte brut.
-+-JFS in : Guide du Neuneu d'Usenet - Le con, le brut et le néant -+-

Marc Boyer a émis l'idée suivante :

Je suis tout à fait d'accord : je n'ai jamais eu de problème avec les
notions basiques d'architecture et d'assembleur, alors que les notions
de haut-niveau, par leur charabia conceptuel, me laissent encore et
toujours perplexe.
Parce qu'ils sont là pour résoudre des problèmes d'une complexité

toute différente ?

Si l'on considère le C et l'assembleur, je suis d'accord. Par contre
s'il s'agit du C vis-à-vis de langages de plus haut-niveau
objet-abstrait-machin-concept-chose, alors il me semble(*) que l'on
peut traiter des problèmes de même complexité avec une complexité de
programmation similaire.

A+,
Stéphane.
(*) Je ne suis pas spécialiste non plus, donc prière de ne pas se
répandre en contre-exemples :-)

--
Ceci est une signature automatique de MesNews.
Site : http://mesnews.no-ip.com

Johann Dantant wrote:

"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le message
de news:cjdvnk$2ht$1@news.cict.fr...

In article <415A7DDC.8000705@yahoo.NoSpam.fr>, Max M wrote:

Prendre des débutants complets et commencer avec le C ?
Bonne chance.

C'est ce que j'ai fait et pas le seul ;et je trouve cela tres sain

Le fait que certains en réchappent ne signifie pas que ce soit une
bonne méthode pédagogique.

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 ?

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 ?

Maintenant, tu as certainement raison de considérer que c'est une mauvaise
méthode pédagogique, mais personnellement je préfères une mauvaise méthode
pédagogique qui forme des gens compétents et efficaces qu'une bonne méthode
pédagogique qui m'amène des brouettes de débutants inemployables en l'état.

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.
Et le C est d'expérience un bon moyen de perdre du temps
et des élèves en route.

Il suffit de repenser à la méthode actuelle d'apprentissage de la lecture
qui donne de si bon résultats dans les écoles primaires. Une amie qui se
destine à être institutrice (enfin, ex-amie, forcément on est fâché
maintenant...) me soutient que c'est une bonne méthode pédagogique.
D'accord. Mais une autre amie prof en 6ème me confirme que c'est une
mauvaise méthode d'apprentissage, puisqu'ils sont nuls en arrivant... Alors
?

Je n'ai pas d'avis sur ces deux méthodes.

Quand à la beauté, je ne trouve pas ça un argument: on forme
des développeurs, pas des artistes.

Non non, franchement, sincèrement, il ne faut surtout pas dire ça... J'ai
aussi assuré (oh, pas longtemps, j'en ai eu vite marre) quelques cours en
école d'ingénieur. Une fois passé de l'autre côté de la barrière, j'ai pu
confronter (un peu) mes points de vue avec mes anciens professeurs, et
effectivement eux comme toi ne voient que les arguments techniques et
pédagogiques. C'est à mon sens une erreur fatale. Un développeur c'est avant
tout un créateur, au même titre qu'un designer de voiture ou un modiste.
Comme le designer ou comme le modiste il a entre les mains un cahier des
charges, des méthodes de travailles précises et des critères d'évaluation
strictes, mais comme le designer ou le modiste il doit aimer, chercher à
faire beau, à la fois pour lui (il est avant tout fier de ce qu'il fait et
heureux de ne pas être immédiatement remplaçable par une machine à pisser du
code) et pour le projet lui-même. Lisibilité du code, performances globales,
rapidité de codage, ambiance dans l'équipe, de ma petite expérience tout le
monde gagne à travailler avec des artistes...

T'as déjà jeté un coup d'oeil sur l'ioccc ? C'est beau, non ?

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).
De même, les tests unitaires, c'est rarement beau.

Après, oui, j'ai grossi le trait. Il y a un aspect "beauté"
du code bien conçu, en effet.

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...

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.

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:

Marc Boyer a émis l'idée suivante :
Si l'on considère le C et l'assembleur, je suis d'accord. Par contre
s'il s'agit du C vis-à-vis de langages de plus haut-niveau
objet-abstrait-machin-concept-chose, alors il me semble(*) que l'on
peut traiter des problèmes de même complexité avec une complexité de
programmation similaire.

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

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.

(*) Je ne suis pas spécialiste non plus, donc prière de ne pas se
répandre en contre-exemples :-)

Ben, il faut pas mal d'expérience ou de lectures pour
toucher du doigt les problèmes dont les "choses-abstraites-
machin-choses" sont les solutions.

--
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...

"Johann Dantant" <news-dot-jd@pro-dash-active-dot-fr.INVALID> writes:

"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le message
de news:cjdvnk$2ht$1@news.cict.fr...

In article <415A7DDC.8000705@yahoo.NoSpam.fr>, Max M wrote:

Prendre des débutants complets et commencer avec le C ?
Bonne chance.

C'est ce que j'ai fait et pas le seul ;et je trouve cela tres
sain

Le fait que certains en réchappent ne signifie pas que ce soit
une bonne méthode pédagogique.

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.

Mais l'assembleur ce n'est jamais qu'une abstraction aussi, pour bien
comprendre ce qui se passe il faut connaitre l'architecture et la
micro-architecture du processeur (regarde c'est le meme assembleur
pour les 486 et les pentiums, pourtant l'implementation est
completement differente). Oh, mais ce n'est qu'une abstraction pour
un ensemble de machine d'etats et de circuits combinatoires ayant des
fonctions complexes du genre ALU. Mais cette vision n'est elle meme
qu'une abstraction: tout ce qu'on a ce n'est que des portes logiques
et des elements sequentiels de base. Mais non, il n'y a que des
transistors et des connections. Mais ta modelisation des transistors
n'est qu'un modele bien simplifie, il faut utiliser les modeles de
spice avec une centaine de parametres et modeliser les connections
avec leurs composantes R, L et C. Mais non, il faut appliquer les
equations de Maxwell et la physique quantique parce qu'il peut y avoir
des phenomenes de diaphonie et de migration d'electons d'un conducteur
a l'autre. Desole, je prefere commencer par l'abstraction la plus
elevee et ensuite voir comment ca peut etre implemente sur base
d'abstraction plus faible.

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.

Je n'ai jamais ecrit qu'il ne fallait pas considerer les niveaux
inferieurs (c'est malheureusement une tendance certaine parmis les
universitaires). Mais commencer par le dessus est beaucoup plus
simple que par le dessous. Parce que le dessus est concu pour etre
plus simple. Oui il faut parfois savoir comment ca peut etre fait
pour l'utiliser efficacement, mais il faut aussi savoir que ca peut
etre fait autrement et que certains reflexes qui etaient bons
deviennent nuisibles quand on change le dessous. Et c'est aussi un
avantage d'utiliser des abstractions, il est beaucoup plus facile de
les adapter qu'une conception qui melange les niveaux.

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