D'après ce que j'ai lu sur les ng, je sais qu'il y a quelques
fr(ançais|ancophones) qui participent aux différents BSD. J'aimerais
savoir en quoi cela consiste? Je commence à vraiment apprécier ces OS,
d'autant que je me rends compte que j'ai vraiment perdu mon temps avec
certains OS qui me faisaient croire, à tort, que mon PC était un peu à
bout de souffle, que mon graveur était trop vieux, qu'il était temps
d'overclocker mon processeur. Là, j'ai vraiment la haine.
J'ai en ce moment OpenBSD et FreeBSD installés, et ce qui m'amuse le
plus, c'est d'underclocker mon proc jq 233Mhz (je peux pas aller en
dessous dans le BIOS), et voir que ça ne rame pas plus. En fait ça ne
rame pas.. Je m'y suis repris à plusieurs fois, je n'y croyais pas
trop.
Vu la chaleur qu'il fait, ça va bien me faire gagner quelques degrés ?
Le C est le langage à connaitre pour bosser sous UNIX, mais c'est aussi un des pires langages pour apprendre. Le Pascal est bien pour apprendre la programmation procédurale, je trouve.
Je ne suis pas tout a fait d'accord, des le moment ou on comprend le concept des pointeurs et que l'on code dans un style correct le C est largement potable. Bien sur si on code a la "guru"/"perl" forcement ca devient un peu le caca.
D'ailleurs en parlant de "un des pires languages pour apprendre" perl a une bonne tete de gagnant :)
Sinon pour l'assembleur, faut surtout eviter le 80x86, les autres sont comprehensibles.
Bof pas pire que le 68000 d'apres mes souvenirs, par contre j'ai bien aime celui du Z80 qui est peut-etre aussi la raison pour laquelle on trouve encore ce processeur sur des systemes embarques.
mips
Le C est le langage à connaitre pour bosser sous UNIX, mais c'est
aussi un des pires langages pour apprendre. Le Pascal est bien pour
apprendre la programmation procédurale, je trouve.
Je ne suis pas tout a fait d'accord, des le moment ou on comprend le
concept des pointeurs et que l'on code dans un style correct le C est
largement potable.
Bien sur si on code a la "guru"/"perl" forcement ca devient un peu le
caca.
D'ailleurs en parlant de "un des pires languages pour apprendre" perl
a une bonne tete de gagnant :)
Sinon pour l'assembleur, faut surtout eviter le 80x86, les autres
sont comprehensibles.
Bof pas pire que le 68000 d'apres mes souvenirs, par contre j'ai bien
aime celui du Z80 qui est peut-etre aussi la raison pour laquelle on
trouve encore ce processeur sur des systemes embarques.
Le C est le langage à connaitre pour bosser sous UNIX, mais c'est aussi un des pires langages pour apprendre. Le Pascal est bien pour apprendre la programmation procédurale, je trouve.
Je ne suis pas tout a fait d'accord, des le moment ou on comprend le concept des pointeurs et que l'on code dans un style correct le C est largement potable. Bien sur si on code a la "guru"/"perl" forcement ca devient un peu le caca.
D'ailleurs en parlant de "un des pires languages pour apprendre" perl a une bonne tete de gagnant :)
Sinon pour l'assembleur, faut surtout eviter le 80x86, les autres sont comprehensibles.
Bof pas pire que le 68000 d'apres mes souvenirs, par contre j'ai bien aime celui du Z80 qui est peut-etre aussi la raison pour laquelle on trouve encore ce processeur sur des systemes embarques.
mips
manu
mips wrote:
Le C est le langage à connaitre pour bosser sous UNIX, mais c'est aussi un des pires langages pour apprendre. Le Pascal est bien pour apprendre la programmation procédurale, je trouve. Je ne suis pas tout a fait d'accord, des le moment ou on comprend le
concept des pointeurs et que l'on code dans un style correct le C est largement potable.
Ben le C, il a quand même des défauts. Rien que ca, c'est atroce: char* toto, tata; et tata n'est pas un char*
Sinon pour l'assembleur, faut surtout eviter le 80x86, les autres sont comprehensibles. Bof pas pire que le 68000 d'apres mes souvenirs,
Tu dois mal te souvenir alors. sur 68000 tu as 8 registres de données et 8 registres d'adresses chacun identiques aux autres. Sur le 8086, tu as tel registre qui peut servir de compteur pour telle instruction de chaine mais pas les autres, c'est horrible.
par contre j'ai bien aime celui du Z80 qui est peut-etre aussi la raison pour laquelle on trouve encore ce processeur sur des systemes embarques.
Tu traines dans les soirées technosadomasochistes?
-- Emmanuel Dreyfus
mips <mips@cyberspace.org> wrote:
Le C est le langage à connaitre pour bosser sous UNIX, mais c'est
aussi un des pires langages pour apprendre. Le Pascal est bien pour
apprendre la programmation procédurale, je trouve.
Je ne suis pas tout a fait d'accord, des le moment ou on comprend le
concept des pointeurs et que l'on code dans un style correct le C est
largement potable.
Ben le C, il a quand même des défauts. Rien que ca, c'est atroce:
char* toto, tata;
et tata n'est pas un char*
Sinon pour l'assembleur, faut surtout eviter le 80x86, les autres
sont comprehensibles.
Bof pas pire que le 68000 d'apres mes souvenirs,
Tu dois mal te souvenir alors. sur 68000 tu as 8 registres de données et
8 registres d'adresses chacun identiques aux autres. Sur le 8086, tu as
tel registre qui peut servir de compteur pour telle instruction de
chaine mais pas les autres, c'est horrible.
par contre j'ai bien
aime celui du Z80 qui est peut-etre aussi la raison pour laquelle on
trouve encore ce processeur sur des systemes embarques.
Tu traines dans les soirées technosadomasochistes?
Le C est le langage à connaitre pour bosser sous UNIX, mais c'est aussi un des pires langages pour apprendre. Le Pascal est bien pour apprendre la programmation procédurale, je trouve. Je ne suis pas tout a fait d'accord, des le moment ou on comprend le
concept des pointeurs et que l'on code dans un style correct le C est largement potable.
Ben le C, il a quand même des défauts. Rien que ca, c'est atroce: char* toto, tata; et tata n'est pas un char*
Sinon pour l'assembleur, faut surtout eviter le 80x86, les autres sont comprehensibles. Bof pas pire que le 68000 d'apres mes souvenirs,
Tu dois mal te souvenir alors. sur 68000 tu as 8 registres de données et 8 registres d'adresses chacun identiques aux autres. Sur le 8086, tu as tel registre qui peut servir de compteur pour telle instruction de chaine mais pas les autres, c'est horrible.
par contre j'ai bien aime celui du Z80 qui est peut-etre aussi la raison pour laquelle on trouve encore ce processeur sur des systemes embarques.
Tu traines dans les soirées technosadomasochistes?
-- Emmanuel Dreyfus
Laurent Lefevre
Le Lun, 30 jui 2003 at 19:31 GMT Emmanuel Dreyfus a écrit:
Laurent Lefevre wrote:
Mais avant de coder, il y a peut être, une étape importante que tout le monde oublie, faire des spécifications formelles.
Je ne sais pas si ca marche très bien au niveau système d'exploitation. Trop près du hard, on subit souvent des comportements qui ne sont pas si conformes que caz à leurs spécification. (C'est une question, pas un troll).
Ben non, tu t'abstrait du langage, ce qu'il y a en dessous, tu t'en fout. Tu peut faire des spécifs pour des OS, je l'ai fait pour une antiquité, une surcouche à µxinu79, un µ unix 16 bits.
Après, tu te heurtes à ceux qui ne font aucune spécif, mais c'est un autre problème.
Tu raisonnes avec des années d'habitudes, de réflexes ;)
Un autre exemple, l'intégralité du métro de Lille à été spécifié par la méthode B.
-- Laurent
Le Lun, 30 jui 2003 at 19:31 GMT Emmanuel Dreyfus a écrit:
Mais avant de coder, il y a peut être, une étape importante que tout
le monde oublie, faire des spécifications formelles.
Je ne sais pas si ca marche très bien au niveau système d'exploitation.
Trop près du hard, on subit souvent des comportements qui ne sont pas si
conformes que caz à leurs spécification. (C'est une question, pas un
troll).
Ben non, tu t'abstrait du langage, ce qu'il y a en dessous, tu t'en
fout. Tu peut faire des spécifs pour des OS, je l'ai fait pour une
antiquité, une surcouche à µxinu79, un µ unix 16 bits.
Après, tu te heurtes à ceux qui ne font aucune spécif, mais c'est un
autre problème.
Tu raisonnes avec des années d'habitudes, de réflexes ;)
Un autre exemple, l'intégralité du métro de Lille à été spécifié par
la méthode B.
Le Lun, 30 jui 2003 at 19:31 GMT Emmanuel Dreyfus a écrit:
Laurent Lefevre wrote:
Mais avant de coder, il y a peut être, une étape importante que tout le monde oublie, faire des spécifications formelles.
Je ne sais pas si ca marche très bien au niveau système d'exploitation. Trop près du hard, on subit souvent des comportements qui ne sont pas si conformes que caz à leurs spécification. (C'est une question, pas un troll).
Ben non, tu t'abstrait du langage, ce qu'il y a en dessous, tu t'en fout. Tu peut faire des spécifs pour des OS, je l'ai fait pour une antiquité, une surcouche à µxinu79, un µ unix 16 bits.
Après, tu te heurtes à ceux qui ne font aucune spécif, mais c'est un autre problème.
Tu raisonnes avec des années d'habitudes, de réflexes ;)
Un autre exemple, l'intégralité du métro de Lille à été spécifié par la méthode B.
-- Laurent
espie
In article <3effec95$0$24677$, Étienne Labaume wrote:
Le Sun, 29 Jun 2003 15:26:48 +0200, Emmanuel nous disait:
Pour répondre sérieusement à ce vulgaire troll, le veritable but de ces articles est de susciter des vocations. Coder c'est bien, faire coder les autres, c'est mieux: ca fait plus de code au final.
Tiens, j'aimerais bien avoir avoir l'avis des uns et des autres là-dessus: Pour bien apprendre à développer, par quel langage commencer, quel cheminement suivre ? J'ai envie de tout reprendre à zéro.
Le langage n'a pas tellement d'importance. Il faut surtout apprendre a eviter de reinventer la roue, et a lire le code ecrit par d'autres. 95% de l'activite de developpement, dans tous les projets, consiste a comprendre du code ecrit par d'autres et a ajouter des choses.
Dans ce contexte, toute source de code de qualite, correspondant plus ou moins a ses aspirations du moment, est a prendre...
... et le langage qui va avec, mais qui est accessoire.
In article <3effec95$0$24677$626a54ce@news.free.fr>,
Étienne Labaume <hornbblower@yahoo.fr> wrote:
Le Sun, 29 Jun 2003 15:26:48 +0200, Emmanuel nous disait:
Pour répondre sérieusement à ce vulgaire troll, le veritable but de ces
articles est de susciter des vocations. Coder c'est bien, faire coder
les autres, c'est mieux: ca fait plus de code au final.
Tiens, j'aimerais bien avoir avoir l'avis des uns et des autres
là-dessus: Pour bien apprendre à développer, par quel langage commencer,
quel cheminement suivre ? J'ai envie de tout reprendre à zéro.
Le langage n'a pas tellement d'importance. Il faut surtout apprendre a
eviter de reinventer la roue, et a lire le code ecrit par d'autres.
95% de l'activite de developpement, dans tous les projets, consiste a
comprendre du code ecrit par d'autres et a ajouter des choses.
Dans ce contexte, toute source de code de qualite, correspondant plus ou
moins a ses aspirations du moment, est a prendre...
... et le langage qui va avec, mais qui est accessoire.
In article <3effec95$0$24677$, Étienne Labaume wrote:
Le Sun, 29 Jun 2003 15:26:48 +0200, Emmanuel nous disait:
Pour répondre sérieusement à ce vulgaire troll, le veritable but de ces articles est de susciter des vocations. Coder c'est bien, faire coder les autres, c'est mieux: ca fait plus de code au final.
Tiens, j'aimerais bien avoir avoir l'avis des uns et des autres là-dessus: Pour bien apprendre à développer, par quel langage commencer, quel cheminement suivre ? J'ai envie de tout reprendre à zéro.
Le langage n'a pas tellement d'importance. Il faut surtout apprendre a eviter de reinventer la roue, et a lire le code ecrit par d'autres. 95% de l'activite de developpement, dans tous les projets, consiste a comprendre du code ecrit par d'autres et a ajouter des choses.
Dans ce contexte, toute source de code de qualite, correspondant plus ou moins a ses aspirations du moment, est a prendre...
... et le langage qui va avec, mais qui est accessoire.
manu
Laurent Lefevre wrote:
Un autre exemple, l'intégralité du métro de Lille à été spécifié par la méthode B.
La ligne 14 à Paris a aussi été spécifié formellement. Mais autant pour les OS je veux bien suivre, autant là j'ai du mal.
Les bouts de la machine virtuelle Java qui touchent à la sécurité ont aussi été traités à la méthode formelle. Ca n'a pas empeché un groupe de chercheurs de casser cette sécurité issue des preuves formelles, simplement en chauffant la RAM: http://www.cs.princeton.edu/~sudhakar/papers/memerr.pdf
Vu comme l'electronique délire quand on la chauffe un peu trop, j'ai pas tellement plus confiance en un metro spécifié en methode B, qu'en un metro conduit par un être humain pas prouvé du tout.
Un autre exemple, l'intégralité du métro de Lille à été spécifié par
la méthode B.
La ligne 14 à Paris a aussi été spécifié formellement. Mais autant pour
les OS je veux bien suivre, autant là j'ai du mal.
Les bouts de la machine virtuelle Java qui touchent à la sécurité ont
aussi été traités à la méthode formelle. Ca n'a pas empeché un groupe de
chercheurs de casser cette sécurité issue des preuves formelles,
simplement en chauffant la RAM:
http://www.cs.princeton.edu/~sudhakar/papers/memerr.pdf
Vu comme l'electronique délire quand on la chauffe un peu trop, j'ai pas
tellement plus confiance en un metro spécifié en methode B, qu'en un
metro conduit par un être humain pas prouvé du tout.
Un autre exemple, l'intégralité du métro de Lille à été spécifié par la méthode B.
La ligne 14 à Paris a aussi été spécifié formellement. Mais autant pour les OS je veux bien suivre, autant là j'ai du mal.
Les bouts de la machine virtuelle Java qui touchent à la sécurité ont aussi été traités à la méthode formelle. Ca n'a pas empeché un groupe de chercheurs de casser cette sécurité issue des preuves formelles, simplement en chauffant la RAM: http://www.cs.princeton.edu/~sudhakar/papers/memerr.pdf
Vu comme l'electronique délire quand on la chauffe un peu trop, j'ai pas tellement plus confiance en un metro spécifié en methode B, qu'en un metro conduit par un être humain pas prouvé du tout.
-- Emmanuel Dreyfus
manu
Erwan David wrote:
Vu que mon boulot est de dévlopper en embarqué, je peux assurer que la phase de spec fait gagner énormément de temps. On n'a quasiment pas besoin de debug. Par contre quand on tombe sur un bug c'est soit un trivial soit un très coriace...
Et tu tombes jamais sur un bug materiel?
-- Emmanuel Dreyfus
Erwan David <erwan@rail.eu.org> wrote:
Vu que mon boulot est de dévlopper en embarqué, je peux assurer que la
phase de spec fait gagner énormément de temps. On n'a quasiment pas
besoin de debug.
Par contre quand on tombe sur un bug c'est soit un trivial soit un
très coriace...
Vu que mon boulot est de dévlopper en embarqué, je peux assurer que la phase de spec fait gagner énormément de temps. On n'a quasiment pas besoin de debug. Par contre quand on tombe sur un bug c'est soit un trivial soit un très coriace...
Et tu tombes jamais sur un bug materiel?
-- Emmanuel Dreyfus
Erwan David
(Marc Espie) écrivait :
Le langage n'a pas tellement d'importance. Il faut surtout apprendre a eviter de reinventer la roue, et a lire le code ecrit par d'autres. 95% de l'activite de developpement, dans tous les projets, consiste a comprendre du code ecrit par d'autres et a ajouter des choses.
Sauf dans le monde du logiciel propriétaire où on passe son temps à réineventer la roue sans avoir le droit de regarder le code du voisin...) (mais bon faut bien bouffer hein).
-- Monde de merde
espie@tetto.gentiane.org (Marc Espie) écrivait :
Le langage n'a pas tellement d'importance. Il faut surtout apprendre a
eviter de reinventer la roue, et a lire le code ecrit par d'autres.
95% de l'activite de developpement, dans tous les projets, consiste a
comprendre du code ecrit par d'autres et a ajouter des choses.
Sauf dans le monde du logiciel propriétaire où on passe son temps à
réineventer la roue sans avoir le droit de regarder le code du
voisin...)
(mais bon faut bien bouffer hein).
Le langage n'a pas tellement d'importance. Il faut surtout apprendre a eviter de reinventer la roue, et a lire le code ecrit par d'autres. 95% de l'activite de developpement, dans tous les projets, consiste a comprendre du code ecrit par d'autres et a ajouter des choses.
Sauf dans le monde du logiciel propriétaire où on passe son temps à réineventer la roue sans avoir le droit de regarder le code du voisin...) (mais bon faut bien bouffer hein).
-- Monde de merde
Arnaud Launay
Le Mon, 30 Jun 2003 22:19:16 +0200, Emmanuel Dreyfus écrivit:
Vu comme l'electronique délire quand on la chauffe un peu trop, j'ai pas tellement plus confiance en un metro spécifié en methode B, qu'en un metro conduit par un être humain pas prouvé du tout.
L'avantage, c'est que le premier ne fait pas grève pour un oui pour un non, lui.
Arnaud. -- BOFH excuse: The lines are all busy (busied out, that is %why let them in to begin with?).
Le Mon, 30 Jun 2003 22:19:16 +0200, Emmanuel Dreyfus écrivit:
Vu comme l'electronique délire quand on la chauffe un peu trop, j'ai pas
tellement plus confiance en un metro spécifié en methode B, qu'en un
metro conduit par un être humain pas prouvé du tout.
L'avantage, c'est que le premier ne fait pas grève pour un oui
pour un non, lui.
Arnaud.
--
BOFH excuse:
The lines are all busy (busied out, that is %why let them in to begin with?).
Le Mon, 30 Jun 2003 22:19:16 +0200, Emmanuel Dreyfus écrivit:
Vu comme l'electronique délire quand on la chauffe un peu trop, j'ai pas tellement plus confiance en un metro spécifié en methode B, qu'en un metro conduit par un être humain pas prouvé du tout.
L'avantage, c'est que le premier ne fait pas grève pour un oui pour un non, lui.
Arnaud. -- BOFH excuse: The lines are all busy (busied out, that is %why let them in to begin with?).
manu
Laurent Lefevre wrote:
Le problème, c'est que ce n'est pas rentré dans lees moeurs. Qu'est ce qui t'empèche de faire des spécifs en rentrant les données thermiques d'un CI ?
Ben le problème c'est que dès que tu touches à l'electronique, tu n'es plus dans un monde mathematique mais dans un monde physique. Le circuit a 99,9...9% de chances de se comporter conformement à sa spécification, mais il te reste un 0,0....1% de chances que ca fasse autre chose.
Donc autant spécifier pour reduire le nombre de bugs, je veux bien, autant spécifier pour dire que c'est sûr et faire un metro qui marche sans pilote, j'ai pas tellement confiance.
Le problème, c'est que ce n'est pas rentré dans lees moeurs. Qu'est ce
qui t'empèche de faire des spécifs en rentrant les données thermiques
d'un CI ?
Ben le problème c'est que dès que tu touches à l'electronique, tu n'es
plus dans un monde mathematique mais dans un monde physique. Le circuit
a 99,9...9% de chances de se comporter conformement à sa spécification,
mais il te reste un 0,0....1% de chances que ca fasse autre chose.
Donc autant spécifier pour reduire le nombre de bugs, je veux bien,
autant spécifier pour dire que c'est sûr et faire un metro qui marche
sans pilote, j'ai pas tellement confiance.
Le problème, c'est que ce n'est pas rentré dans lees moeurs. Qu'est ce qui t'empèche de faire des spécifs en rentrant les données thermiques d'un CI ?
Ben le problème c'est que dès que tu touches à l'electronique, tu n'es plus dans un monde mathematique mais dans un monde physique. Le circuit a 99,9...9% de chances de se comporter conformement à sa spécification, mais il te reste un 0,0....1% de chances que ca fasse autre chose.
Donc autant spécifier pour reduire le nombre de bugs, je veux bien, autant spécifier pour dire que c'est sûr et faire un metro qui marche sans pilote, j'ai pas tellement confiance.
-- Emmanuel Dreyfus
Nathan De La Pierre
According to Emmanuel Dreyfus :
mips wrote:
Le C est le langage à connaitre pour bosser sous UNIX, mais c'est aussi un des pires langages pour apprendre. Le Pascal est bien pour apprendre la programmation procédurale, je trouve. Je ne suis pas tout a fait d'accord, des le moment ou on comprend le
concept des pointeurs et que l'on code dans un style correct le C est largement potable.
Ben le C, il a quand même des défauts. Rien que ca, c'est atroce: char* toto, tata; et tata n'est pas un char*
T'abuse la, que le C soit critique pour des declarations telles: char (*(x[3])())[5] on comprends tout a fait mais pour des declaration pareils char foo, *bar; c'est quand meme de la paresse intellectuelle.
Sinon pour l'assembleur, faut surtout eviter le 80x86, les autres sont comprehensibles. Bof pas pire que le 68000 d'apres mes souvenirs,
Tu dois mal te souvenir alors. sur 68000 tu as 8 registres de données et 8 registres d'adresses chacun identiques aux autres. Sur le 8086, tu as tel registre qui peut servir de compteur pour telle instruction de chaine mais pas les autres, c'est horrible.
par contre j'ai bien aime celui du Z80 qui est peut-etre aussi la raison pour laquelle on trouve encore ce processeur sur des systemes embarques.
Tu traines dans les soirées technosadomasochistes?
-- Emmanuel Dreyfus
According to Emmanuel Dreyfus <manu@netbsd.org>:
mips <mips@cyberspace.org> wrote:
Le C est le langage à connaitre pour bosser sous UNIX, mais c'est
aussi un des pires langages pour apprendre. Le Pascal est bien pour
apprendre la programmation procédurale, je trouve.
Je ne suis pas tout a fait d'accord, des le moment ou on comprend le
concept des pointeurs et que l'on code dans un style correct le C est
largement potable.
Ben le C, il a quand même des défauts. Rien que ca, c'est atroce:
char* toto, tata;
et tata n'est pas un char*
T'abuse la, que le C soit critique pour des declarations telles:
char (*(x[3])())[5] on comprends tout a fait mais pour des
declaration pareils char foo, *bar; c'est quand meme de la
paresse intellectuelle.
Sinon pour l'assembleur, faut surtout eviter le 80x86, les autres
sont comprehensibles.
Bof pas pire que le 68000 d'apres mes souvenirs,
Tu dois mal te souvenir alors. sur 68000 tu as 8 registres de données et
8 registres d'adresses chacun identiques aux autres. Sur le 8086, tu as
tel registre qui peut servir de compteur pour telle instruction de
chaine mais pas les autres, c'est horrible.
par contre j'ai bien
aime celui du Z80 qui est peut-etre aussi la raison pour laquelle on
trouve encore ce processeur sur des systemes embarques.
Tu traines dans les soirées technosadomasochistes?
Le C est le langage à connaitre pour bosser sous UNIX, mais c'est aussi un des pires langages pour apprendre. Le Pascal est bien pour apprendre la programmation procédurale, je trouve. Je ne suis pas tout a fait d'accord, des le moment ou on comprend le
concept des pointeurs et que l'on code dans un style correct le C est largement potable.
Ben le C, il a quand même des défauts. Rien que ca, c'est atroce: char* toto, tata; et tata n'est pas un char*
T'abuse la, que le C soit critique pour des declarations telles: char (*(x[3])())[5] on comprends tout a fait mais pour des declaration pareils char foo, *bar; c'est quand meme de la paresse intellectuelle.
Sinon pour l'assembleur, faut surtout eviter le 80x86, les autres sont comprehensibles. Bof pas pire que le 68000 d'apres mes souvenirs,
Tu dois mal te souvenir alors. sur 68000 tu as 8 registres de données et 8 registres d'adresses chacun identiques aux autres. Sur le 8086, tu as tel registre qui peut servir de compteur pour telle instruction de chaine mais pas les autres, c'est horrible.
par contre j'ai bien aime celui du Z80 qui est peut-etre aussi la raison pour laquelle on trouve encore ce processeur sur des systemes embarques.
Tu traines dans les soirées technosadomasochistes?
