Evidemment, cela pose le problème qu'une même personne doit maîtriser tous les tenants et aboutissants du compilateur LISP. L'intérêt d'utiliser directement LISP, c'est de gagner du temps à ne pas réinventer la roue à chaque fois (ou beaucoup moins) et d'avoir un code plus lisible à la fin.
Le combat du "je suis plus rapide" ne s'applique pas aux langages de haut niveau : leur intérêt réside dans le gain de temps, de maintenance, ....
Un programme bien conçu qui ferait 100000 lignes de Lisp ou de Prolog ou de Caml ou autre n'est en fait pas possible à écrire en C. Il faudrait des dizaines de millions de lignes de code, le code ne serait pas maintenable,...
Tu as lu le contraire où dans mes reply ? je dis juste que ces langages ne sont pas comparables sur un même terrain.
Le pire c'est que l'un des textes que j'ai cité dit exactement la même chose que ce que tu dis. Je le re-cite, parce que ça a l'air de passer mal dans les oreilles.
> So what have we learned? We confirmed what we pretty much knew: you
> can write a C program in CL, at which point the relative speed of your
> C and CL versions will depend on the relative quality of the code
> generation. It's worthwhile to know the specifics of your
> implementation (for instance, it seems that a substantial amount of
> the last-mile speed up for this benchmark on CMUCL came from figuring
> out ftruncate could be fast inside a macro, but not inside an inline
> function).
> What would be even more interesting to me would be an example more
> like what I feel I experience anecdotally --- that I write programs
> that are a bit slower than C (maybe 25% to 50%), but they're much more
> flexible, more abstract, cleaner, easily modifiable, and so on. I
> don't really feel like the CL version of almabench we currently have
> shows any of the benefits of CL.
[^] # Re: pourquoi le lip
Posté par taratatatata . En réponse à la dépêche Sortie de SBCL 1.0. Évalué à 2.
Le combat du "je suis plus rapide" ne s'applique pas aux langages de haut niveau : leur intérêt réside dans le gain de temps, de maintenance, ....
Un programme bien conçu qui ferait 100000 lignes de Lisp ou de Prolog ou de Caml ou autre n'est en fait pas possible à écrire en C. Il faudrait des dizaines de millions de lignes de code, le code ne serait pas maintenable,...
Tu as lu le contraire où dans mes reply ? je dis juste que ces langages ne sont pas comparables sur un même terrain.
Le pire c'est que l'un des textes que j'ai cité dit exactement la même chose que ce que tu dis. Je le re-cite, parce que ça a l'air de passer mal dans les oreilles.
> So what have we learned? We confirmed what we pretty much knew: you
> can write a C program in CL, at which point the relative speed of your
> C and CL versions will depend on the relative quality of the code
> generation. It's worthwhile to know the specifics of your
> implementation (for instance, it seems that a substantial amount of
> the last-mile speed up for this benchmark on CMUCL came from figuring
> out ftruncate could be fast inside a macro, but not inside an inline
> function).
> What would be even more interesting to me would be an example more
> like what I feel I experience anecdotally --- that I write programs
> that are a bit slower than C (maybe 25% to 50%), but they're much more
> flexible, more abstract, cleaner, easily modifiable, and so on. I
> don't really feel like the CL version of almabench we currently have
> shows any of the benefits of CL.