Re: a LISP raytracer


Jon Harrop wrote:

> The Scheme implementation wasn't optimised by hand - the compiler does all
> of the optimisation for you. You shouldn't need to apply low level
> optimisations by hand in a high level language.
>
> The Scheme code was available here:
>
> http://www-bcl.cs.nuim.ie/~qobi/ray1.tgz
>
> None of the free Lisp compilers come close to the capabilities of Stalin. It
> is very difficult to write such a compiler.

Hmm..this sounds like a project :)

> OCaml does has camlp4 macros.

Interesting - I'll look into that.

> > Being a Paul Graham fan, I value that feature quite greatly.
>
> You'd be better off listening the to enormous number of computer science
> researchers who've spent the intervening decades coming up with better
> languages.

Perhaps you're right. My languages professor right now is a huge fan
on OCaML, and not so much with LISP. But Paul Graham does offer a more
practical perspective on this, being experienced in modern industry.
His arguments for LISP are usually based on its rapid prototyping
capability, ease of use/reading, macros, etc. - characteristics that
are increasingly important these days. Although he rarely mentions
performance... well, in any case, OCaML's my next learning project.

> > The power to
> > define your own syntax seems very useful to me, even though I have yet
> > to develop the skill necessary to use them effectively.
>
> There is an important trade-off: Lisp macros come at the cost of efficiency
> and program stability.

Well, they can certainly be abused like any language feature, but when
used well they often increase run-time speed and make code a lot easier
to read/write. I looked at Juho Snellman's raytracer code last night,
and his "def" macro is a great example of this. If you're not familiar
with LISP macros and their usage, it may seem very convoluted and
unecessarily complicated. But it's a powerful macro that can be easily
re-used in many situations to improve performance (beyond just 3d
vectors).

>
> > But
> > nonetheless, I do plan on investigating OCaML soon. These days, I'm
> > sort of looking for the ultimate language -- or at least the ultimate
> > languages.
>
> AFAIK, it hasn't been invented yet. :-)
>
> I used LOC as a primitive measure of development time. It is roughly correct
> but the relationship between LOC and time taken is highly non linear. The
> OCaml was far faster to implement that all of the other languages. Having
> said that, I am quite familiar with OCaml (but more familiar with C++). In
> constrast, the Lisp took many people several weeks to come up with.
>

It's not only highly non-linear, but I can imagine, especially with
LISP, that LOC goes down with development time. But more importantly,
how much indication does it give about debugging time?

But then again, I guess that's not really the point of your
comparisons. You're mainly looking at performance vs. programming
effort, in which case LOC is a reasonable ball-park approximation.

> > Anyways, thanks for these comparisons!
>
> Thanks. :-)
>

And thanks again for your time and input!

Um, we should probably end this thread right here cuz it's definitely
going off topic :P

> --
> Dr Jon D Harrop, Flying Frog Consultancy
> http://www.ffconsultancy.com

.

Relevant Pages

  • Re: "Unified model" for beginners
    ... What insult would it be to say "hey, it can do something like what LISP ... languages and implementations, reduce it to that "essential essence" only ... Molecules and atoms (okay, we don't actually "see" atoms, this is a ... "subtraction" and then lots of "HLLism macros" to create all the other ...
    (alt.lang.asm)
  • Re: Lisp and OCaml, why?
    ... > interpreted languages as possible over time, if not to use them at ... > lisp and OCaml though - why would someone use them in preference to ... Strong, static typing catches type errors at compile time, reducing ...
    (comp.programming)
  • Re: Program compression
    ... Haskell, SML, OCaml, Mathematica, F# and Scala all allow real ... problems to be solved much more concisely than with Lisp. ... for simple lists those three languages equal Lisp in conciseness. ... and thus there's no need for concurrent GC. ...
    (comp.programming)
  • Re: Paul Grahams teaching style is bad
    ... > remaining distinctive features of lisp are a good thing. ... > languages have been picking up from lisp for so long was the big deal, ... > and that macros are only marginally important by comparison, ...
    (comp.lang.lisp)
  • Re: Is Lisp a Blub?
    ... collection is not feasible anymore. ... Why would he be looking toward providing Lisp-style macros ... referring to Gregor's move out of Lisp and into other languages with ... It is interesting that many old Lispers move away from Lisp and ...
    (comp.lang.lisp)