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)
"Marc Boyer" a écrit dans le message de news:cjh0nn$4je$
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.
J'avais compris ... la fougue de la jeunesse avait dû t'emporter :-) ... et j'ai succomber au plaisir d'étaler ma science au détriment d'un éminent professeur :-)
Même, si je suis pas entièrement de ton avis, il faut reconnaître que l'assembleur pur est ( était, devrais-je dire ) quelques fois rébarbatifs.
"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit dans le message
de news:cjh0nn$4je$1@news.cict.fr...
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.
J'avais compris ... la fougue de la jeunesse avait dû t'emporter :-) ... et
j'ai succomber au plaisir d'étaler ma science au détriment d'un éminent
professeur :-)
Même, si je suis pas entièrement de ton avis, il faut reconnaître que
l'assembleur pur est ( était, devrais-je dire ) quelques fois rébarbatifs.
"Marc Boyer" a écrit dans le message de news:cjh0nn$4je$
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.
J'avais compris ... la fougue de la jeunesse avait dû t'emporter :-) ... et j'ai succomber au plaisir d'étaler ma science au détriment d'un éminent professeur :-)
Même, si je suis pas entièrement de ton avis, il faut reconnaître que l'assembleur pur est ( était, devrais-je dire ) quelques fois rébarbatifs.
Gabriel Dos Reis
cedric writes:
| 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 ]:) ?
Readmymind.
-- Gaby
cedric <rixed@happyleptic.NOSPAM.org> writes:
| 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 ]:) ?
| 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 ]:) ?
| 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.
???
-- Gaby
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
| 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.
| 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.
???
-- Gaby
Jean-Marc Bourguet
Gabriel Dos Reis writes:
| > Par contre, la norme du C dit que "char" doit faire au moins | > 8-bits. Donc, sur les machines où le "byte" fait 4 bits, le | > "char" faiut plusiuers "byte"... | | J'avais voulu l'ecrire mais l'ai oublie. Merci de l'avoir signale.
Le C dit que 1 char fait exactement 1 byte.
L'utilisation de byte au sens de la norme C est parfois en contradiction avec l'usage de certaines plateforme.
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
Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
| > Par contre, la norme du C dit que "char" doit faire au moins
| > 8-bits. Donc, sur les machines où le "byte" fait 4 bits, le
| > "char" faiut plusiuers "byte"...
|
| J'avais voulu l'ecrire mais l'ai oublie. Merci de l'avoir signale.
Le C dit que 1 char fait exactement 1 byte.
L'utilisation de byte au sens de la norme C est parfois en
contradiction avec l'usage de certaines plateforme.
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
| > Par contre, la norme du C dit que "char" doit faire au moins | > 8-bits. Donc, sur les machines où le "byte" fait 4 bits, le | > "char" faiut plusiuers "byte"... | | J'avais voulu l'ecrire mais l'ai oublie. Merci de l'avoir signale.
Le C dit que 1 char fait exactement 1 byte.
L'utilisation de byte au sens de la norme C est parfois en contradiction avec l'usage de certaines plateforme.
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
Jean-Marc Bourguet
Gabriel Dos Reis writes:
Jean-Marc Bourguet writes:
[...]
| Je n'ai jamais ecrit qu'il ne fallait pas considerer les niveaux | inferieurs (c'est malheureusement une tendance certaine parmis les | universitaires).
Yep, il faut d'abord commencer par la théorie des catégories :-)
Tu as du voir par ailleur que je suis d'accord :-)
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
Gabriel Dos Reis <gdr@cs.tamu.edu> writes:
Jean-Marc Bourguet <jm@bourguet.org> writes:
[...]
| Je n'ai jamais ecrit qu'il ne fallait pas considerer les niveaux
| inferieurs (c'est malheureusement une tendance certaine parmis les
| universitaires).
Yep, il faut d'abord commencer par la théorie des catégories :-)
Tu as du voir par ailleur que je suis d'accord :-)
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
| Je n'ai jamais ecrit qu'il ne fallait pas considerer les niveaux | inferieurs (c'est malheureusement une tendance certaine parmis les | universitaires).
Yep, il faut d'abord commencer par la théorie des catégories :-)
Tu as du voir par ailleur que je suis d'accord :-)
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
Gabriel Dos Reis
Marc Boyer writes:
| > 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.
Comment certaines personnes réussissent à écrire des codes inutilement complexes en C++ et s'en plaignent après est un problème intéressant.
-- Gaby
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
| > 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.
Comment certaines personnes réussissent à écrire des codes inutilement
complexes en C++ et s'en plaignent après est un problème intéressant.
| > 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.
Comment certaines personnes réussissent à écrire des codes inutilement complexes en C++ et s'en plaignent après est un problème intéressant.
-- Gaby
Max M
Stephane Zuckerman a écrit:
Bonjour,
On Wed, 29 Sep 2004, Johann Dantant wrote:
Prendre des débutants complets et commencer avec le C ? Bonne chance.
Je suis d'accord (même si c'est ce qui m'est arrivé en IUT). Ou plutôt, tout dépend de la façon dont on l'enseigne. Nous avions commencé par faire de l'algorithmique, puis des applications en C en même temps. En fin d'année nous avons abordés deux langages très différents (VB et C++), afin d'aborder la programmation événementielle d'une part (Visual Basic), et la programmation orientée objet d'autre part. Ceci après "seulement" six mois de C.
En fin de compte, ce qui a été déterminant, c'était la pédagogie. Les enseignants étaient excellents, et ont artificiellement caché les difficultés du C au départ pour nous permettre de nous concentrer sur l'algorithmique .
Je suis d'accord j'ai fait le même parcours mais le prof était excellent...
Bref, les pointeurs, nous les avons vu au bout du deuxième ou troisième mois de formation. Avant, des artifices (du même ordre que ceux utilisés par Java par exemple, en plus limitants) nous permettaient de faire notre boulot, sans vraiment comprendre pourquoi taper "CH20 machaine" me forçait à 19 caractères uniquement.
Par contre, nous avions des cours d'architecture (en gros de l'électronique numérique, des cours de logique formelle, de la prog de micro-code, etc.) en parallèle. Au bout de trois mois, nous en savions assez sur les machines pour pouvoir utiliser les pointeurs sans trop de bourdes.
ne pas oublier le Harware, sinon on arrive a des jeunes qui ont une peur
instinctive de la carté réelle. Je puis vous l'assurer. Faute a une grande abstraction. ? ou ?
Il ya rigoureusement le même pb pour les jeunes électroniciens, Pspice Ok , Fait peur. Il faut les deprogrammer, vaincre les resistances mentales. Certains n'y arrivent jamais, d'autres tres vite. Il y a un "effet de bord induit"par ce type de formation en info eu électronique. Et on rejoint le pb de l'apprentissage de la lecture metionné plus haut. Alors ?
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.
Rudement, bien dit même si ce n'est pas inconciliable.
Stephane Zuckerman a écrit:
Bonjour,
On Wed, 29 Sep 2004, Johann Dantant wrote:
Prendre des débutants complets et commencer avec le C ?
Bonne chance.
Je suis d'accord (même si c'est ce qui m'est arrivé en IUT). Ou
plutôt, tout dépend de la façon dont on l'enseigne. Nous avions commencé
par faire de l'algorithmique, puis des applications en C en même temps. En
fin d'année nous avons abordés deux langages très différents (VB et C++),
afin d'aborder la programmation événementielle d'une part (Visual Basic),
et la programmation orientée objet d'autre part. Ceci après "seulement"
six mois de C.
En fin de compte, ce qui a été déterminant, c'était la pédagogie.
Les enseignants étaient excellents, et ont artificiellement caché les
difficultés du C au départ pour nous permettre de nous concentrer sur
l'algorithmique .
Je suis d'accord j'ai fait le même parcours mais le prof était excellent...
Bref, les pointeurs, nous les avons vu au bout du deuxième ou
troisième mois de formation. Avant, des artifices (du même ordre que ceux
utilisés par Java par exemple, en plus limitants) nous permettaient de
faire notre boulot, sans vraiment comprendre pourquoi taper "CH20
machaine" me forçait à 19 caractères uniquement.
Par contre, nous avions des cours d'architecture (en gros de
l'électronique numérique, des cours de logique formelle, de la prog de
micro-code, etc.) en parallèle. Au bout de trois mois, nous en savions
assez sur les machines pour pouvoir utiliser les pointeurs sans trop de
bourdes.
ne pas oublier le Harware, sinon on arrive a des jeunes qui ont une peur
instinctive de la carté réelle.
Je puis vous l'assurer.
Faute a une grande abstraction. ? ou ?
Il ya rigoureusement le même pb pour les jeunes électroniciens, Pspice Ok ,
Fait peur.
Il faut les deprogrammer, vaincre les resistances mentales.
Certains n'y arrivent jamais, d'autres tres vite.
Il y a un "effet de bord induit"par ce type de formation en info eu
électronique.
Et on rejoint le pb de l'apprentissage de la lecture metionné plus haut.
Alors ?
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.
Rudement, bien dit
même si ce n'est pas inconciliable.
Prendre des débutants complets et commencer avec le C ? Bonne chance.
Je suis d'accord (même si c'est ce qui m'est arrivé en IUT). Ou plutôt, tout dépend de la façon dont on l'enseigne. Nous avions commencé par faire de l'algorithmique, puis des applications en C en même temps. En fin d'année nous avons abordés deux langages très différents (VB et C++), afin d'aborder la programmation événementielle d'une part (Visual Basic), et la programmation orientée objet d'autre part. Ceci après "seulement" six mois de C.
En fin de compte, ce qui a été déterminant, c'était la pédagogie. Les enseignants étaient excellents, et ont artificiellement caché les difficultés du C au départ pour nous permettre de nous concentrer sur l'algorithmique .
Je suis d'accord j'ai fait le même parcours mais le prof était excellent...
Bref, les pointeurs, nous les avons vu au bout du deuxième ou troisième mois de formation. Avant, des artifices (du même ordre que ceux utilisés par Java par exemple, en plus limitants) nous permettaient de faire notre boulot, sans vraiment comprendre pourquoi taper "CH20 machaine" me forçait à 19 caractères uniquement.
Par contre, nous avions des cours d'architecture (en gros de l'électronique numérique, des cours de logique formelle, de la prog de micro-code, etc.) en parallèle. Au bout de trois mois, nous en savions assez sur les machines pour pouvoir utiliser les pointeurs sans trop de bourdes.
ne pas oublier le Harware, sinon on arrive a des jeunes qui ont une peur
instinctive de la carté réelle. Je puis vous l'assurer. Faute a une grande abstraction. ? ou ?
Il ya rigoureusement le même pb pour les jeunes électroniciens, Pspice Ok , Fait peur. Il faut les deprogrammer, vaincre les resistances mentales. Certains n'y arrivent jamais, d'autres tres vite. Il y a un "effet de bord induit"par ce type de formation en info eu électronique. Et on rejoint le pb de l'apprentissage de la lecture metionné plus haut. Alors ?
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.
Rudement, bien dit même si ce n'est pas inconciliable.
Gabriel Dos Reis
Marc Boyer writes:
| In article , Gabriel Dos Reis wrote: | > Marc Boyer writes: | >| 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. | > | > Vraiment ? | | Pour un débutant, oui, il me semble. | Pas toi ?
Non.
Si le débutant en question n'est pas confus, alors c'est un miracle.
-- Gaby
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
| In article <m3mzz7j3ai.fsf@merlin.cs.tamu.edu>, Gabriel Dos Reis wrote:
| > Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
| >| 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.
| >
| > Vraiment ?
|
| Pour un débutant, oui, il me semble.
| Pas toi ?
Non.
Si le débutant en question n'est pas confus, alors c'est un miracle.
| In article , Gabriel Dos Reis wrote: | > Marc Boyer writes: | >| 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. | > | > Vraiment ? | | Pour un débutant, oui, il me semble. | Pas toi ?
Non.
Si le débutant en question n'est pas confus, alors c'est un miracle.
-- Gaby
Marc Boyer
Gabriel Dos Reis wrote:
Marc Boyer writes: | 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 suis allé un peu vite, il manque un deuxième "à ce jour", et une précision sur l'OO avec destructeur systématique.
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 wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
| 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 suis allé un peu vite, il manque un deuxième "à ce jour",
et une précision sur l'OO avec destructeur systématique.
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 writes: | 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 suis allé un peu vite, il manque un deuxième "à ce jour", et une précision sur l'OO avec destructeur systématique.
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...
