Re: Trying to understand chicken limitations

[Marc Feeley]

> On Dec 23, 2019, at 8:36 AM, Lassi Kortela <address@hidden> wrote:
> 
> There's a persistent myth among programmers that interpreters are slow.

I disagree that this is a myth.  Interpreted code is typically anywhere from 5x 
to 100x slower than compiled code depending on the features of the interpreter 
and quality of the compiled code.  The real issue is that developers are 
notoriously bad at predicting where performance matters in their code and in 
particular the impact of the interpreter's “slowness” on the overall 
performance of the application.  If the interpreted code is mainly ordering the 
execution of rather long-running operations that are well implemented in C then 
the slowness of the interpreter will not be observable by the user (for example 
typical shell scripts executed by an interpreter-based shell).

But the performance of code execution by the embedded language matters for some 
applications and usually the developper only knows this late in the development 
process (after the application’s goals have evolved) which is after the 
embedded language implementation has been selected and much code written around 
it.  In such a situation it is usually too expensive to change the embedded 
language implementation, so instead more and more functionality gets 
implemented in the low-level language.

So code execution performance should not be overlooked when selecting an 
embedded language implementation, otherwise the development benefits of the 
high-level language may eventually be lost.

Marc