Guile Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Bad news from the module/environment front
> Telford> The other thing is that, while speed is nice, it is not the
> Telford> prime importance of a scripting language.
> IMHO it is quite dangerous to make this kind of distinction. Not that
> I think that speed should go before anything else, but we should not
> accept that it does not matter.
It's a priority queue, not a boolean expression. Other things matter
more the speed.
> To me, the main thing is that the architecture is sound, also with
> respect to speed. It does not have to be fast now, but there must
> exist a justifiable belief that it can be made fast eventually.
If this means that we shouldn't go out of our way to make it slow then
I agree, if you are saying that we should have a long term objective to
unseat C and become the only language anyone will ever need -- you have
got to be joking. Guile MIGHT have a slim chance at unseating perl,
unlikely but possible, planning the scheme takeover of the known computing
universe is a little premature at this stage.
> The evaluator/interpreter can be slow only if a compiler exists for
> those in need of speed. Many systems uses such a setup, guile
> currently (almost) has neither.
Most of the time spent writing code is not time spent typing the
words in, it is spent debugging the algorithm and getting the ideas
together. Scheme (and guile) is pretty good for that because you can
toy around with things in a way that will never be possible in C or
and C derivative. I often write a first draft in scheme and a third
or fourth draft in C -- no big deal, usually the C rewrite is very fast
because by then I know WHAT it is I'm supposed to be writing.
I'll agree that a scheme compiler would be nice at times but hardly
an essential thing. Theoretically scheme could compile just as well as
C does but in practice there are a lot of problems (shifting datatypes,
lambda expressions, error checking, caller interface) so I think the
pragmatists amongst us will admit that C compilers will beat scheme
compilers for the foreseeable future. Yes, I know people have quoted
good results for stalin but those are a few special cases and a long
way away from being applicable to the day-to-day needs of most coders.
> Telford> Remember the target audience -- people who have working code
> Telford> to do the guts of their job and want to support scripting or
> Telford> interactive evaluation with minimal effort.
> If we box ourselves in by coding only for the target audience, Guile
> will die a slow but certain death.
Geee, perl started out with a pretty specific target audience
(i.e. combining the abilities of awk and sed for use in text processing)
and put practical usability ahead of most everything else, I guess that
perl must be doomed to a slow but certain death.
> People will start using Guile, hit
> the performance roof and switch to something else, and most people do
> such an exercise only once (even switching to another scheme is a
> non-trivial exercise).
Oh this is just silly. Like I said, rewriting a few critical crunching
routines in C is no trouble when you can bolt-in C code and call it from
your scripting language. People still write in assembler for crying in
a bucket, they don't write whole apps, they just write the routines that
really matter. Is guile going to have its own assembler now too?
> Tcl has been done this road. Tcl7 used a simple implementation basing
> everything on strings, which proved inadequate for the stuff people
> wanted to use tcl for. Only few users would be prepared to use one
> implementation for small scale jobs and another for large scale jobs.
I can't say that I have much experience with Tcl but I know that there are
still people using it. Your reasoning is that every application must
be homogeneously coded and switching language means restarting from the
ground up. This is contrary to everything that guile stands for.
> Telford> GC ... is such an unsolved issue and ... it might be better
> Telford> to admit defeat
> But still others are doing rather well in this respect. Mark/sweep is
> not exactly rocket science anymore, and since (any) GC does take time,
> it makes it all the more important not to create more garbage than
Actually, C can afford to generate garbage without wasting time because it
uses stack storage for auto variables and the stack frame is reset on return.
Also, because the compiler does data optimisation, you can define a dozen
temporary variables for this and that but the only space used is what needs
to be used. Often people use temporary variables just to give a meaningful
name to a sub-expression or to change a type. Doing this in C cost NOTHING
in terms of final code efficiency -- it will generate identical code.
Doing this in scheme is guaranteed to generate garbage and waste time.
Same with numbers, C does its type-checks at compile time and sets the
operation in stone, scheme checks at run-time and changes the type of the
number when it sees fit, scheme will always be slower. Same with checking
how many args there are for a function. In short, an interpretive language
has a ``performance roof'' -- you might as well deal with it.
As I said above, a fast interpreter is nice, generating garbage is bad
because it slows the interpreter down, however these issues have to
be prioritised. Getting the language organised with clearly defined
modules is far more important than a speed issue.
Guile Home |
Main Index |