Mais ça ne simplifie pas le code, puisqu'il devient plus gros, verticalement...
Pas sur ...
C'est pourtant chose manifeste : la réécriture en deux tests occupe au moins une ligne de plus, sauf à l'écrire dans un style trop dense pour être honnête.
Mais ça ne simplifie pas le code, puisqu'il devient plus gros,
verticalement...
Pas sur ...
C'est pourtant chose manifeste : la réécriture en deux tests occupe au
moins une ligne de plus, sauf à l'écrire dans un style trop dense pour
être honnête.
Mais ça ne simplifie pas le code, puisqu'il devient plus gros, verticalement...
Pas sur ...
C'est pourtant chose manifeste : la réécriture en deux tests occupe au moins une ligne de plus, sauf à l'écrire dans un style trop dense pour être honnête.
mips
On 23 Apr 2004 12:33:41 GMT Miod Vallat wrote:
/* If it's empty, make a page more of that size chunks */ if( page_dir[j]==NULL ) { if( malloc_free_chunks(j)==NULL ) return 0; }
Ce qui est beaucoup plus lisible et qui est moins sujet a erreur lors d'une evolution de code.
Non, car c'est un couple d'opération qui a une sémantique symbolique.
La logique ici, c'est «j'ai besoin d'un bloc». Et l'existence d'un bloc s'exprime sous la forme «j'en ai déjà un, ou je parviens à en créer un», qui correspond au code initial.
C'est bien ce que je critique, la logique symbolique doit etre decomposee pour etre plus lisible.
/* look for a page */ if (page_dir[j] == NULL) { /* It's empty, try to make a page */ if (malloc_free_chunks(j) == NULL) return(NULL); /* failed page alloc */ }
Le fait que le test && soit une évaluation booléenne paresseuse est une«feature», mais justement parce que c'est la façon humaine naturelle de procéder.
Ca confirme que je ne suis pas humain :)
Il y en a toujours pour penser que coder de facon illisible (donc comme un goret) ca fait "31337" ("elite" en langage elite de goret). Mais bon si ca leur fait plaisir on va pas gacher leur bonheur :)
Ah, c'est sûr que, en Ruby, on ne laisse pas au programmeur la responsabilité de gérer la mémoire, ce serait trop dangereux.
Ah, moi je voyais plutot ca du cote feignant : pourquoi faire quelque chose soi-meme quand le language peut le faire de facon transparente. Et en plus ca simplifie le code, que demande le peuple ? (a part le SMP sous openbsd, un arbre des ports correct sous freebsd, des chemises presentables pour netbsd ;)
mips
On 23 Apr 2004 12:33:41 GMT
Miod Vallat <miod@online.fr> wrote:
/* If it's empty, make a page more of that size chunks */
if( page_dir[j]==NULL ) {
if( malloc_free_chunks(j)==NULL )
return 0;
}
Ce qui est beaucoup plus lisible et qui est moins sujet a erreur
lors d'une evolution de code.
Non, car c'est un couple d'opération qui a une sémantique
symbolique.
La logique ici, c'est «j'ai besoin d'un bloc». Et l'existence d'un
bloc s'exprime sous la forme «j'en ai déjà un, ou je parviens à en
créer un», qui correspond au code initial.
C'est bien ce que je critique, la logique symbolique doit etre
decomposee pour etre plus lisible.
/* look for a page */
if (page_dir[j] == NULL) {
/* It's empty, try to make a page */
if (malloc_free_chunks(j) == NULL)
return(NULL); /* failed page alloc */
}
Le fait que le test && soit une évaluation booléenne paresseuse est
une«feature», mais justement parce que c'est la façon humaine
naturelle de procéder.
Ca confirme que je ne suis pas humain :)
Il y en a toujours pour penser que coder de facon illisible (donc
comme un goret) ca fait "31337" ("elite" en langage elite de
goret). Mais bon si ca leur fait plaisir on va pas gacher leur
bonheur :)
Ah, c'est sûr que, en Ruby, on ne laisse pas au programmeur la
responsabilité de gérer la mémoire, ce serait trop dangereux.
Ah, moi je voyais plutot ca du cote feignant : pourquoi faire quelque
chose soi-meme quand le language peut le faire de facon transparente.
Et en plus ca simplifie le code, que demande le peuple ? (a part le
SMP sous openbsd, un arbre des ports correct sous freebsd, des
chemises presentables pour netbsd ;)
/* If it's empty, make a page more of that size chunks */ if( page_dir[j]==NULL ) { if( malloc_free_chunks(j)==NULL ) return 0; }
Ce qui est beaucoup plus lisible et qui est moins sujet a erreur lors d'une evolution de code.
Non, car c'est un couple d'opération qui a une sémantique symbolique.
La logique ici, c'est «j'ai besoin d'un bloc». Et l'existence d'un bloc s'exprime sous la forme «j'en ai déjà un, ou je parviens à en créer un», qui correspond au code initial.
C'est bien ce que je critique, la logique symbolique doit etre decomposee pour etre plus lisible.
/* look for a page */ if (page_dir[j] == NULL) { /* It's empty, try to make a page */ if (malloc_free_chunks(j) == NULL) return(NULL); /* failed page alloc */ }
Le fait que le test && soit une évaluation booléenne paresseuse est une«feature», mais justement parce que c'est la façon humaine naturelle de procéder.
Ca confirme que je ne suis pas humain :)
Il y en a toujours pour penser que coder de facon illisible (donc comme un goret) ca fait "31337" ("elite" en langage elite de goret). Mais bon si ca leur fait plaisir on va pas gacher leur bonheur :)
Ah, c'est sûr que, en Ruby, on ne laisse pas au programmeur la responsabilité de gérer la mémoire, ce serait trop dangereux.
Ah, moi je voyais plutot ca du cote feignant : pourquoi faire quelque chose soi-meme quand le language peut le faire de facon transparente. Et en plus ca simplifie le code, que demande le peuple ? (a part le SMP sous openbsd, un arbre des ports correct sous freebsd, des chemises presentables pour netbsd ;)
mips
mips
On 23 Apr 2004 15:29:21 GMT Miod Vallat wrote:
Ah, moi je voyais plutot ca du cote feignant : pourquoi faire quelque chose soi-meme quand le language peut le faire de facon transparente. Et en plus ca simplifie le code, que demande le peuple ? (a part le
Mais ça ne simplifie pas le code, puisqu'il devient plus gros, verticalement...
Pas sur ...
mips
On 23 Apr 2004 15:29:21 GMT
Miod Vallat <miod@online.fr> wrote:
Ah, moi je voyais plutot ca du cote feignant : pourquoi faire
quelque chose soi-meme quand le language peut le faire de facon
transparente. Et en plus ca simplifie le code, que demande le
peuple ? (a part le
Mais ça ne simplifie pas le code, puisqu'il devient plus gros,
verticalement...
Ah, moi je voyais plutot ca du cote feignant : pourquoi faire quelque chose soi-meme quand le language peut le faire de facon transparente. Et en plus ca simplifie le code, que demande le peuple ? (a part le
Mais ça ne simplifie pas le code, puisqu'il devient plus gros, verticalement...
Pas sur ...
mips
mips
On 23 Apr 2004 15:50:52 GMT Miod Vallat wrote:
Mais ça ne simplifie pas le code, puisqu'il devient plus gros, verticalement...
Pas sur ...
C'est pourtant chose manifeste : la réécriture en deux tests occupe au moins une ligne de plus, sauf à l'écrire dans un style trop dense pourêtre honnête.
Hmm, la simplification du code concernait ruby :)
Sinon entre lisibilite et taille du source mon choix est vite fait ...
mips
On 23 Apr 2004 15:50:52 GMT
Miod Vallat <miod@online.fr> wrote:
Mais ça ne simplifie pas le code, puisqu'il devient plus gros,
verticalement...
Pas sur ...
C'est pourtant chose manifeste : la réécriture en deux tests occupe
au moins une ligne de plus, sauf à l'écrire dans un style trop dense
pourêtre honnête.
Hmm, la simplification du code concernait ruby :)
Sinon entre lisibilite et taille du source mon choix est vite fait ...
Mais ça ne simplifie pas le code, puisqu'il devient plus gros, verticalement...
Pas sur ...
C'est pourtant chose manifeste : la réécriture en deux tests occupe au moins une ligne de plus, sauf à l'écrire dans un style trop dense pourêtre honnête.
Hmm, la simplification du code concernait ruby :)
Sinon entre lisibilite et taille du source mon choix est vite fait ...
mips
espie
In article , mips wrote:
On 23 Apr 2004 15:50:52 GMT Miod Vallat wrote:
Mais ça ne simplifie pas le code, puisqu'il devient plus gros, verticalement...
Pas sur ...
C'est pourtant chose manifeste : la réécriture en deux tests occupe au moins une ligne de plus, sauf à l'écrire dans un style trop dense pourêtre honnête.
Hmm, la simplification du code concernait ruby :)
Bof, l'evaluation paresseuse des && et des || en C et en shell est idiomatique. Quelqu'un qui trebuche sur une ligne de code comme celle donnee en exergue ne connait tout simplement pas bien le langage. C'est encore plus marque en shell, mais les constructions du type:
if (!j_essaie_ce_truc_ci() && !j_essaie_ce_truc_la()) { return CA_N_A_PAS_MARCHE; }
c'est extremement frequent et naturel comme logique.
In article <20040423190107.3839cc57.anti@spam.gov>,
mips <mips@cyberspace.org> wrote:
On 23 Apr 2004 15:50:52 GMT
Miod Vallat <miod@online.fr> wrote:
Mais ça ne simplifie pas le code, puisqu'il devient plus gros,
verticalement...
Pas sur ...
C'est pourtant chose manifeste : la réécriture en deux tests occupe
au moins une ligne de plus, sauf à l'écrire dans un style trop dense
pourêtre honnête.
Hmm, la simplification du code concernait ruby :)
Bof, l'evaluation paresseuse des && et des || en C et en shell est
idiomatique. Quelqu'un qui trebuche sur une ligne de code comme
celle donnee en exergue ne connait tout simplement pas bien le
langage. C'est encore plus marque en shell, mais les constructions
du type:
if (!j_essaie_ce_truc_ci() && !j_essaie_ce_truc_la()) {
return CA_N_A_PAS_MARCHE;
}
c'est extremement frequent et naturel comme logique.
Mais ça ne simplifie pas le code, puisqu'il devient plus gros, verticalement...
Pas sur ...
C'est pourtant chose manifeste : la réécriture en deux tests occupe au moins une ligne de plus, sauf à l'écrire dans un style trop dense pourêtre honnête.
Hmm, la simplification du code concernait ruby :)
Bof, l'evaluation paresseuse des && et des || en C et en shell est idiomatique. Quelqu'un qui trebuche sur une ligne de code comme celle donnee en exergue ne connait tout simplement pas bien le langage. C'est encore plus marque en shell, mais les constructions du type:
if (!j_essaie_ce_truc_ci() && !j_essaie_ce_truc_la()) { return CA_N_A_PAS_MARCHE; }
c'est extremement frequent et naturel comme logique.
Cyrille Szymanski
On 2004-04-23, Marc Espie wrote:
Bof, l'evaluation paresseuse des && et des || en C et en shell est idiomatique. Quelqu'un qui trebuche sur une ligne de code comme celle donnee en exergue ne connait tout simplement pas bien le langage.
Hum, le C offre tellement de "possibilités" de ce genre que je me demande si un jour on peut dire qu'on connaît le langage (ou qu'on est condamnés à juste pouvoir dire qu'on le connaît mieux que la moyenne...) et cela ne justifie pas forcément qu'on s'en serve.
Le tout c'est qu'on ne passe pas trois plombes à déchiffrer dix lignes de code, et ça c'est une question d'entraînement, donc d'habitude, pas de connaissance du langage.
Peut-être que ce code n'est pas fait pour être lu par des ignares ?
-- cns
On 2004-04-23, Marc Espie <espie@tetto.gentiane.org> wrote:
Bof, l'evaluation paresseuse des && et des || en C et en shell est
idiomatique. Quelqu'un qui trebuche sur une ligne de code comme
celle donnee en exergue ne connait tout simplement pas bien le
langage.
Hum, le C offre tellement de "possibilités" de ce genre que je me demande
si un jour on peut dire qu'on connaît le langage (ou qu'on est condamnés à
juste pouvoir dire qu'on le connaît mieux que la moyenne...) et cela ne
justifie pas forcément qu'on s'en serve.
Le tout c'est qu'on ne passe pas trois plombes à déchiffrer dix lignes
de code, et ça c'est une question d'entraînement, donc d'habitude,
pas de connaissance du langage.
Peut-être que ce code n'est pas fait pour être lu par des ignares ?
Bof, l'evaluation paresseuse des && et des || en C et en shell est idiomatique. Quelqu'un qui trebuche sur une ligne de code comme celle donnee en exergue ne connait tout simplement pas bien le langage.
Hum, le C offre tellement de "possibilités" de ce genre que je me demande si un jour on peut dire qu'on connaît le langage (ou qu'on est condamnés à juste pouvoir dire qu'on le connaît mieux que la moyenne...) et cela ne justifie pas forcément qu'on s'en serve.
Le tout c'est qu'on ne passe pas trois plombes à déchiffrer dix lignes de code, et ça c'est une question d'entraînement, donc d'habitude, pas de connaissance du langage.
Peut-être que ce code n'est pas fait pour être lu par des ignares ?
-- cns
Miod Vallat
Hum, le C offre tellement de "possibilités" de ce genre que je me demande si un jour on peut dire qu'on connaît le langage (ou qu'on est condamnés à juste pouvoir dire qu'on le connaît mieux que la moyenne...) et cela ne justifie pas forcément qu'on s'en serve.
C'est une impression provoquée par le manque d'expérience. C est plutôt simple et non-ambigû, en fait. Au bout de quelques années d'expérience, on ne remarque même plus des constructions pareilles (et pas qu'en C, d'ailleurs).
Le tout c'est qu'on ne passe pas trois plombes à déchiffrer dix lignes de code, et ça c'est une question d'entraînement, donc d'habitude, pas de connaissance du langage.
Oui.
Peut-être que ce code n'est pas fait pour être lu par des ignares ?
Un volontaire pour ressortir l'anecdote du /* You are not expected to understand this. */ présent dans les sources d'UNIX, il y a longtemps... ?
Hum, le C offre tellement de "possibilités" de ce genre que je me demande
si un jour on peut dire qu'on connaît le langage (ou qu'on est condamnés à
juste pouvoir dire qu'on le connaît mieux que la moyenne...) et cela ne
justifie pas forcément qu'on s'en serve.
C'est une impression provoquée par le manque d'expérience. C est plutôt
simple et non-ambigû, en fait. Au bout de quelques années d'expérience,
on ne remarque même plus des constructions pareilles (et pas qu'en C,
d'ailleurs).
Le tout c'est qu'on ne passe pas trois plombes à déchiffrer dix lignes
de code, et ça c'est une question d'entraînement, donc d'habitude,
pas de connaissance du langage.
Oui.
Peut-être que ce code n'est pas fait pour être lu par des ignares ?
Un volontaire pour ressortir l'anecdote du
/* You are not expected to understand this. */
présent dans les sources d'UNIX, il y a longtemps... ?
Hum, le C offre tellement de "possibilités" de ce genre que je me demande si un jour on peut dire qu'on connaît le langage (ou qu'on est condamnés à juste pouvoir dire qu'on le connaît mieux que la moyenne...) et cela ne justifie pas forcément qu'on s'en serve.
C'est une impression provoquée par le manque d'expérience. C est plutôt simple et non-ambigû, en fait. Au bout de quelques années d'expérience, on ne remarque même plus des constructions pareilles (et pas qu'en C, d'ailleurs).
Le tout c'est qu'on ne passe pas trois plombes à déchiffrer dix lignes de code, et ça c'est une question d'entraînement, donc d'habitude, pas de connaissance du langage.
Oui.
Peut-être que ce code n'est pas fait pour être lu par des ignares ?
Un volontaire pour ressortir l'anecdote du /* You are not expected to understand this. */ présent dans les sources d'UNIX, il y a longtemps... ?
Benoit Izac
Bonjour,
le 23/04/2004 à 22:55, Miod Vallat a écrit dans le message <408982b2$0$503$ :
Un volontaire pour ressortir l'anecdote du /* You are not expected to understand this. */ présent dans les sources d'UNIX, il y a longtemps... ?
google : <http://cm.bell-labs.com/cm/cs/who/dmr/odd.html>
/* * Switch to stack of the new process and set up * his segmentation registers. */ retu(rp->p_addr); sureg(); /* * If the new process paused because it was * swapped out, set the stack level to the last call * to savu(u_ssav). This means that the return * which is executed immediately after the call to aretu * actually returns from the last routine which did * the savu. * * You are not expected to understand this. */ if(rp->p_flag&SSWAP) { rp->p_flag =& ~SSWAP; aretu(u.u_ssav); } /* * The value returned here has many subtle implications. * See the newproc comments. */ return(1);
-- Benoit Izac
Bonjour,
le 23/04/2004 à 22:55, Miod Vallat a écrit
dans le message <408982b2$0$503$636a15ce@news.free.fr> :
Un volontaire pour ressortir l'anecdote du
/* You are not expected to understand this. */
présent dans les sources d'UNIX, il y a longtemps... ?
google :
<http://cm.bell-labs.com/cm/cs/who/dmr/odd.html>
/*
* Switch to stack of the new process and set up
* his segmentation registers.
*/
retu(rp->p_addr);
sureg();
/*
* If the new process paused because it was
* swapped out, set the stack level to the last call
* to savu(u_ssav). This means that the return
* which is executed immediately after the call to aretu
* actually returns from the last routine which did
* the savu.
*
* You are not expected to understand this.
*/
if(rp->p_flag&SSWAP) {
rp->p_flag =& ~SSWAP;
aretu(u.u_ssav);
}
/*
* The value returned here has many subtle implications.
* See the newproc comments.
*/
return(1);
le 23/04/2004 à 22:55, Miod Vallat a écrit dans le message <408982b2$0$503$ :
Un volontaire pour ressortir l'anecdote du /* You are not expected to understand this. */ présent dans les sources d'UNIX, il y a longtemps... ?
google : <http://cm.bell-labs.com/cm/cs/who/dmr/odd.html>
/* * Switch to stack of the new process and set up * his segmentation registers. */ retu(rp->p_addr); sureg(); /* * If the new process paused because it was * swapped out, set the stack level to the last call * to savu(u_ssav). This means that the return * which is executed immediately after the call to aretu * actually returns from the last routine which did * the savu. * * You are not expected to understand this. */ if(rp->p_flag&SSWAP) { rp->p_flag =& ~SSWAP; aretu(u.u_ssav); } /* * The value returned here has many subtle implications. * See the newproc comments. */ return(1);
-- Benoit Izac
Thierry Thomas
Vendredi 23 avril 2004 à 19:29 GMT, Cyrille Szymanski a écrit :
Peut-être que ce code n'est pas fait pour être lu par des ignares ?
C'est une impression provoquée par le manque d'expérience. C est plutôt simple et non-ambigû, en fait.
Je remercie la syntaxe du C d'être celle qu'elle est, sans ça l'ioccc n'aurait jamais vu le jour.
main(l ,a,n,d)char**a;{ for(d=atoi(a[1])/10*80- atoi(a[2])/5-596;n="@NKA CLCCGZAAQBEAADAFaISADJABBA^ SNLGAQABDAXIMBAACTBATAHDBAN ZcEMMCCCCAAhEIJFAEAAABAfHJE TBdFLDAANEfDNBPHdBcBBBEA_AL H E L L O, W O R L D! " [l++-3];)for(;n-->64;) putchar(!d+++33^ l&1);}
Pour Paris, 48°N, 2°E
./a.out 49 2
-- cns
On 2004-04-23, Miod Vallat <miod@online.fr> wrote:
C'est une impression provoquée par le manque d'expérience. C est plutôt
simple et non-ambigû, en fait.
Je remercie la syntaxe du C d'être celle qu'elle est, sans ça l'ioccc
n'aurait jamais vu le jour.
main(l
,a,n,d)char**a;{
for(d=atoi(a[1])/10*80-
atoi(a[2])/5-596;n="@NKA
CLCCGZAAQBEAADAFaISADJABBA^
SNLGAQABDAXIMBAACTBATAHDBAN
ZcEMMCCCCAAhEIJFAEAAABAfHJE
TBdFLDAANEfDNBPHdBcBBBEA_AL
H E L L O, W O R L D! "
[l++-3];)for(;n-->64;)
putchar(!d+++33^
l&1);}
C'est une impression provoquée par le manque d'expérience. C est plutôt simple et non-ambigû, en fait.
Je remercie la syntaxe du C d'être celle qu'elle est, sans ça l'ioccc n'aurait jamais vu le jour.
main(l ,a,n,d)char**a;{ for(d=atoi(a[1])/10*80- atoi(a[2])/5-596;n="@NKA CLCCGZAAQBEAADAFaISADJABBA^ SNLGAQABDAXIMBAACTBATAHDBAN ZcEMMCCCCAAhEIJFAEAAABAfHJE TBdFLDAANEfDNBPHdBcBBBEA_AL H E L L O, W O R L D! " [l++-3];)for(;n-->64;) putchar(!d+++33^ l&1);}
