[plt-scheme] xxx chooses MzScheme as preferred language

From: Edmund Dengler (edmundd at eSentire.com)
Date: Wed May 31 22:21:15 EDT 2006


Actually, I see efficiency as a very important requirement for practical
systems, and lack of efficiency has been the number one reason why we have
not chosen a number of languages I would have liked to program in (the
second issue is usually support for rich interactions such as database
support, etc). I would really prefer to use a Scheme-like language with
good libraries, which MzScheme would seem to fit the bill. However, when I
have tried MzScheme for a number of projects, and have had to choose
another language based on efficiency reasons:

- the garbage collector taking up 40% of the running time of the system
  due to lack of regional memory allocation/deallocation,

- overall slowness compared to languages such as Perl when regular
  expressions are used (I had one task which executed about an order of
  magnitude faster and consumed a lot less memory when I recoded it as a
  series of transformations based on converting the string to a list,
  running a transformer, and converting it back into a string, in
  contrast to using pregexp),

- just overall slowness compared to languages such as Perl when
  writing straightforwadrd implementations,

- amount of memory consumed because of cons and other
  default representations when compared to other languages

Note that this issue has arisen in other contexts with other languages:
lack of proper record types in Erlang means the cpu spends an inordinate
amount of time matching tuple structures, Erlang's lack of a compact
string, Python's global lock kills any kind of threading approach,
Haskell's default lazy evaluation means non-expert code can quickly bloat
memory, and so on.

Many of these issues are usually tied to efficiency not being considered a
priority, and when you get to large practical engineering problems such as
we face, it just makes a toy language that we cannot use. While Perl may
be quite ugly to program in, and not be nice (in my opinion - I realize
other people have their own thoughts) for programming in the large (proper
thread support anybody?), and C very low level for a lot of tasks, when
you have to move and analyze large amounts of bytes, you may end up not
having any choices.

We still use MzScheme for some tasks, but it would be nice if it would be
competitive for major projects.


On Wed, 31 May 2006, Prabhakar Ragde wrote:

> Matthias Felleisen wrote:
> > When I see the performance combined with the expressive power of
> > MrEd/MzScheme, I will buy it.
> In the first lecture of the first-year HtDP-based course I teach, I have
> a slide full of goals beyond "get it working" and "make it fast" --
> goals like readability, extendability, maintainability, and so on.
> Obviously there are times when speed is the bottleneck and the deciding
> factor. But I suspect we computer scientists tend to make it an issue
> when it is not, simply because it is easier to compare hard numbers than
> the more vague and softer qualities associated with the broader goals I
> mentioned. Does it matter if a given task completes in 10 microseconds
> instead of 50, if a human has to then respond to the result? It would be
> nice to have a path to follow, if speed becomes the deciding factor,
> that does not leave the Scheme universe. But I neither expect nor demand
> that PLT Scheme should provide that path. What it is doing is far more
> important. --PR
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme

Posted on the users mailing list.