[Shootout-list] Re: Ray tracer

[Stephen Weeks]

> > In any case, I've committed a new revision of raytracer.mlton that
> > makes the same algorithmic improvements as in raytracer.mlton-2.  They
> > now run at roughly the same speed.
> 
> Are the only differences stylistic between your code and my code?

There are pretty big stylistic differences, but there must be
something else too, since mine still runs slightly slower.  I haven't
investigated why.

> I think it would be best to use my style as, otherwise, both the
> performance and the LOC of MLton will suffer unrepresentatively if
> we adopt the "fastest under 100 LOC" approach.

Only the LOC will suffer.  The whole point of MLton is that one
doesn't pay for writing the code in a readable style, with lots of
modules, abstract types, higher-order functions, etc.  Yes, I realize
there is a small (10%) slowdown of my program over yours, but that is
very likely due to a minor algorithmic difference, not coding style.

> I appreciate that the shootout is for optimised programs but I think
> that a very short (and yet surprisingly efficient!) implementation
> will be helpful to anyone trying to implement this benchmark in
> their own favourite language.

An understandable program is much better than a short program.  One
reason I rewrote your raytracer program is so that I could understand
it.  All the usual ML features (abstract types, modules, etc.) helped
immensely, and I think would help others to understand the program as
well.

> > Should we use Stephen's style, which is more representative of
> > typical SML code, or should we use my style, which is more
> > representative of the brevity of SML's grammar but arguably less
> > comprehensible? 
>
> One great benefit of the shootout is as a collection of (often
> nontrivial) program implementations in a wide range of languages.  I
> think we should accept some level of 'noblesse oblige' and try to
> display implementations that follow the coding style and practices
> that are typical for the language in question.  So, the short answer
> is "Use Stephen's Style."

I appreciate the implication that I am the one true arbiter of SML
programming style :-), but I will point out that my programming style
is pretty idiomatic and especially high in LOC compared to many SML
programmers.