:: Re: [Dng] [OT] Debian problems with…
Page principale
Supprimer ce message
Répondre à ce message
Auteur: T.J. Duchene
Date:  
À: Hendrik Boom, dng
Nouveaux-sujets: [Dng] Default configuration for Devuan PulseAudio
Sujet: Re: [Dng] [OT] Debian problems with Jesse - was simple backgrounds

On 03/03/2015 09:07 PM, Hendrik Boom wrote:
> As time passed, they kept finding new uses for their scripting
> language. Occasionally they would realize and existing module needed
> major new functinoality, and it was easier to write the new version in
> Scheme than to modify the old. Over two years or so, they ended up
> replacing their C code, piece by piece, with Scheme code. In the end
> they had a system that was mostly written in Scheme, was more
> reliable, did more, ran faster, and was only about 30000 lines of Scheme.


When I say this, please do not think that I am making remarks against
your experience or observations, but I just "don't get it".

I don't see how that can be the case. The version of Scheme that you
mention is specifically implemented on top of C, so your remarks cannot
be entirely true, nor make any sense to me at all. Scheme can't be more
reliable, do more, or run faster, especially if it implemented on top of
C or even converted into system object code by the very same C compiler.

The entire statement is "non sequitur."

I will that any specific compiler, even a C compiler, can be total and
utter crap, if it is badly implemented. I will also agree that
individuals' programming skills can be massively lacking. It is
possible that they were more skilled with Scheme than C, but that does
not make Scheme superior to C by any objective standard.

> It was really a win for the high-level, garbage-collected language.
>


I've used enough GC languages to know the problems that they try to
solve. It's a good idea to try, really, and it is a fantastic debugging
tool when testing code.

But that is all it is good for.

No one has ever created a fail-proof GC design. When the GC model fails,
it makes fixing your code difficult, sometimes even impossible to
correct without a patch for the entire runtime, not to mention you may
need to recompile everything regardless after you get it.

When someone can design a GC language that solves leaks and buffer
overflows 100% of the time, I'll give them all the praise they deserve.

Until then, the only things that GC does for you is waste memory,
processor time, and force you to reboot the entire system more
frequently in order to clear the exhausted resources.

Have a great evening!
t.j.