[MSLUG] Floating point speed of Gambit-C
Mathieu Bouchard
matju at artengine.ca
Sat Dec 8 01:11:59 EST 2007
On Sat, 8 Dec 2007, Houman Zolfaghari wrote:
> 2. We chose scheme for other reasons that where more critical for our task
> when we made this decision. We already had the C++ libraries for the
> numerical aspects. We needed other qualities that I think are specific to
> scheme or functional and logical languages.
I could've sworn that there was some decision like this behind. I'd
suspect that a damn lot of scheme projects are multilanguage and involve
libraries that are written in C++, that one has to reason to translate to
scheme, that would take a long while to translate, or often even that has
to remain written in C++ for some reason (such as existing applications
using a library...). Often the use of Scheme or other language starts when
a project expands to the point that working exclusively in C++ begins to
suck.
Quite a few languages are full of wrappers for C/C++ libraries and often
it's because the normal interpreter/compiler has speed problems, but most
often not, it's just because it's easier to wrap than to rewrite,
especially considering the aspect of applying/translating diffs across two
branches of essentially the same software in different languages, over
several years. Thus for many cases, it doesn't matter how fast Scheme is,
though it's can be a nice bonus.
> In short, I don't necessarily see an all-or-thing war between C++ and
> scheme, quite on the opposite.
All-or-nothing wars are waged by people who have something else than the
interest of the project in mind. It can be caused by fear, but it also can
be a conflict of interest (language fandom or other). That said, every
cross-language interface introduces a cost, which is at least that to
understand the whole system you need to understand two languages and you
need to understand that interface.
_ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
More information about the MSLUG
mailing list