Raytracer.el: a raytracer in Emacs Lisp | Hacker News Reader

Raytracer.el: a raytracer in Emacs Lisp

github.com

94 pointskruhft53 comments

Another neat pair of raytacers that shows the performance boost from vectorization:

http://www.excamera.com/sphinx/article-ray.html

I've also written a GPU tracer using the same style of calculation, and it just blows anything done on the CPU out of the water. It gets about 10fps with 100 spheres on a mid range Mac Pro.

This one is great if you want to understand ray tracing. It explains everything step by step in a way that's easy to comprehend.

That code is so beatiful: clear, easily understandable. I don't think I've ever seen any C++ code which even comes close to this in readability. And it just flows.

Really, LISP gets way too little credit (and use) than it deserves.

Lisp gets nothing but loving praise from most people who've really looked into it. To me, it's a really good indicator of someone's quality as a programmer - someone who treats programming as just a job will probably never run into it in any meaningful way, but a true hacker will eventually encounter it and be able to appreciate its elegance.

Wanting something like lisp to gain mainstream popularity would be a naive wish - your average web developer wouldn't be able to appreciate it, and over time lisp would change to become more like PhP. No offense meant to such people of course, not everyone needs to have that kind of passion, and someone needs to do web development - God knows it won't be me!

> over time lisp would change to become more like PhP.

A lot of things are so wrong in this statement.

First of all, PHP isn't bad. Don't get me wrong I don't like it (I also don't like Go but that's another story) but it has become so much better. Several of my colleagues use it (that's not the only language they use though) and believe me they are quite passionate about programming. Actually there is some zen in being able to use any tool life throws at you to solve some practical problems.

Second, you are comparing family of languages to the one particular language. This doesn't do justice to both.

Third, if the comparison with PHP was another way to say that Lisp would become worse then here is another thought. It won't. Every mainstream language I know is becoming better in a sense of better defaults and FP features. Java has got lambdas. JS ES6 is going to have TCO and strict mode which fixes a lot of old vague behaviour. Yes, there are a lot of crazy stuff in those languages because their features weren't well thought out back in the day and now it's impossible to fix everything without breaking the core semantics and behaviour. Basically you can fix some things but you can't evolve one language into another.

Getting back to Lisp now. It doesn't need fixing. It has very basic and clear core which doesn't need to be fixed and a lot of advanced language features can be built upon it (and actually was built and are being built). Taking in account both that languages are becoming better with time and that Lisp has awesome core I don't see at all how's popularity can make it worse.

I'd suggest reading some PLT books or taking some related courses. It helps to get the whole picture. You won't love Lisp less (probably the opposite) but you'll accept other languages more. :)

I have to add I'd prefer something Lispish over anything else any day of the week. I'm looking into Clojure(ClojureScript). It's not as elegant as original Lisps and Schemes but it's tradeoffs come from real world use cases (running on top of JVM and JS). Even with them it's an awesome language.

You're putting words in my mouth. I never said PHP was bad - it's reasonably good for common use cases on the web.

I'm just saying that if hypothetically lisp became super popular, it would inevitably change to fit the work flow of the mainstream. Maybe not directly (i.e. through the spec changing) but definitely indirectly, through changes in common practice, libraries etcetera, as well as the general culture of relatively CS-literate, experienced hackers surrounding it.

Of course, I'm not worried about this happening - what's happening instead is that lisp features are finding their way into other languages (a process that has been going on since the 70s).

I'm just saying that if hypothetically lisp became super popular, it would inevitably change to fit the work flow of the mainstream.

Being a functional language designed for metaprogramming, it is expected that it be extended: just by defining a new function, one defines LISP on the fly. That's the core idea of LISP! (:-))

Sorry. I've reread my answer. It was kinda offensive.

I don't see anything bad in Lisp becoming good for common use (on the web or wherever else) and I don't agree with your hypothesis. Lisp would just become more diverse in terms of libraries ecosystem and community. It will keep it's spirit and a core of really experienced users.

> It has very basic and clear core which doesn't need to be fixed

If that core doesn't evaluate (car nil) -> nil, it's broken to me.

(car nil) -> nil doesn't seem obvious to me. It implies that (equal nil (cons nil nil)) i.e. (equal nil '(nil)).

Now I'm not a very experienced lisp programmer, but I don't see why those two would be equivalent. FWIW, at least on SBCL, (car nil) does evaluate to nil.

Unlike NULL (a void* of value 0), nil is an interesting construct in that it's a special cons cell, an element of two pointers, where each cell points to itself. Or that's one way to think of it.

>it's a really good indicator of someone's quality as a programmer

I would request that you please reconsider this position. It's demonstrably false, because there are great and famous programmers we could think of who have no particular opinion on lisp.

The condescension toward web developers is also not solid ground. There are geniuses and passionate people who take all kinds of different life paths, or don't go to college, or whatever artificial litmus test we think of.

I try to really be careful of personal biases like this during interviews because it's easy for them to creep in. So if I find myself wanting to ask "tell me about lisp", I try to catch it and instead ask directly about what I want to know. For example, "what work have you done that shows your quality as a programmer?", or "can you explain what makes you passionate about code?"

I'm not condescending towards web developers - see also my other comments here. I tried explicitly to make it clear that I wasn't, yet I kind of feel like people are taking the liberty to read things in my comment that just aren't there. If you want me to give a tl;dr: it was a comparison based mostly on statistics; it's not that doing web development makes you a bad programmer, or that bad programmers are particularly driven to web development; it's that because the barrier to entry in web development is relatively low and there's a lot of web developers, the average web developer is going to be worse than the average lisper, because there's far fewer lispers and lisp is an obscure language that for the most part only passionate programmers would be interested in.

I stand by knowing lisp being a good indicator of programmer quality, but it's pretty one-sided: knowing lisp is a very good indicator that one is a reasonably good programmer, but not knowing lisp isn't really an indicator of anything; the vast, vast majority of people don't know lisp, after all.

College is the same way of course: having been to college is a reasonable indicator of competence (though not as good as knowing lisp inside-out), but not having gone to college is not an indicator of incompetence - yet nobody would doubt that a college as a whole is an indicator of competence, because if they did, college degrees would be worthless - which they aren't.

I'm glad to hear you weren't intending to do so, but unfortunately the inference of condescension is just as important as the implication, and I'm sure not all web developers would love the comment.

Regarding correlations, I understand your logic. My point is that correlations, or generalizations about large groups of people usually do more harm than good.

Forget the morality of it; In most real life situations it's simply more productive to use other metrics. For example, some companies use having a college degree as a coursely grained filter, when other approaches can be just as time efficient, and more productive because they don't incorrectly screen out the negatively correlated candidates.

Of course I don't mean general indicators are inherently bad or useless, just that they are often given too much weight against people, especially when better information is available.

It turns out ~99% of violent murders are committed by men. Luckily, most people don't hold this against me personally.

and over time lisp would change to become more like PhP.

While it is true that PHP suffers from "the neighbor's kid" syndrome and design inconsistencies, PHP programs can be very elegant, fast and simple in the hands of an experienced Greybeard UNIX programmer. I think PHP gets a lot of bad rap, but it doesn't necessarily mean that PHP itself is a priory a bad language. Yes it has had, and still does have its fair share of iconsistencies, but in the right hands it could be programmed just like Bourne shell. Or AWK. Or C... Or LISP! Completely functionally. No objects.

I've had employers laugh at me in an interview when I mentioned that my favorite language is Scheme.

Why would you pick a language which runs virtual assembler on a virtual processor on a virtual machine? That is terrible for performance, even with just-in-time compiler technology. I can understand why employers would look unfavorably at that.

One of the principal reasons why I sympathize with ANSI common LISP is that when I'm done writing it in a REPL, I can compile it into an ELF binary executable, for performance.

Of course, the funny part is that ELisp is generally considered to be the least elegant of the big 3 Lisps. CL and Scheme are actually a lot nicer.

That's the thing with lisps, you can write your own elegance.

You can write your own elegance in any Turing Complete language. Doesn't mean it'll be easy or pleasant. Beware the Turing tarpit and all that...

It's physically possible to dig a mountain with a spoon too. Lisps aren't about the possibility, but about a culture built on top of a thin set of computation/linguistic building blocks and abstractions they allow.

I consider scheme the nicest but the only thing I'd write in it are exercises for a CS textbook. I like CL, but I wouldn't configure my text editor in it.

Elisp gets undue hate.

Scheme is actually usable for Real Work right now. But while Scheme's ecosystem is more active AFAICT, CL's ecosystem and tooling is far more developed.

>I like CL, but I wouldn't configure my text editor in it.

Why not? As Dynamic Scoping falls out of popularity and the cl packages become increasingly widely used, idiomatic elisp becomes increasingly close to CL, despite RMS's distaste for that language.

One Emacs Lisp aspect that I enjoy for interactive configuration is the lack of packages. When interactive programming with some other languages, there's some cognitive overhead "which package am I in?" depending on how you use the user/repl packages and scratch buffers. Without packages, everything is unambiguous and avoids the issue entirely.

re: dynamic scope, I agree that Emacs' future is with lexical-binding for non-special variables. Chris Wellons recently wrote a great post which has shown up on my radar: http://nullprogram.com/blog/2016/12/22/

Isn't it because you like the lisp syntax, though? I feel that plays a big part of "elegant" for me...

No, it's because I can actually understand the code, without knowing the language. That's just amazing to me. I don't recall ever experiencing such a thing before.

If authors adds a lazy DAG transformation on eval and an ASCII dithered output, you could drop Autodesk Maya for Emacs.

I get the ACSII part, but what would be the purpose/intent of the 'lazy DAG transformation on eval'?

Semi-live re-rendering avoiding too much recomputation.

How do I run this? Opening raytracer.el and doing M-x eval-buffer doesn't seem to work. Guess my Emacs 24.3.1 is too old..

EDIT: Ah, I see. You need emacs-jit from the parent project.

It's built to test the JIT but shouldn't depend on it.

To run:

    Open raytracer.el
    M-x eval-buffer
    M-: (ray-test 256)

Output will be in a buffer as well as in 'image.pbm'

ray-test requires an argument.

D'oh. Can't even read my own code this morning :) Thanks.

It's fine :) How long is this supposed to take?

At 256 I think about a minute or so...

Awesome project. While going over it to figure out how it worked, I looked up the 'cl' package and noticed that it has been deprecated in favor of cl-lib. [1] Also, what license (if any) does this fall under?

[1] https://www.emacswiki.org/emacs/CommonLispForEmacs

I'm assuming you are asking what license cl-lib falls under.

From the top of cl-lib.el in Emacs 25.1:

  ;;; cl-lib.el --- Common Lisp extensions for Emacs  -*- lexical-binding: t -*-
  
  ;; Copyright (C) 1993, 2001-2016 Free Software Foundation, Inc.
  
  ;; Author: Dave Gillespie <daveg@synaptics.com>
  ;; Version: 1.0
  ;; Keywords: extensions
  
  ;; This file is part of GNU Emacs.
  
  ;; GNU Emacs is free software: you can redistribute it and/or modify
  ;; it under the terms of the GNU General Public License as published by
  ;; the Free Software Foundation, either version 3 of the License, or
  ;; (at your option) any later version.
  
  ;; GNU Emacs is distributed in the hope that it will be useful,
  ;; but WITHOUT ANY WARRANTY; without even the implied warranty of
  ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  ;; GNU General Public License for more details.
  
  ;; You should have received a copy of the GNU General Public License
  ;; along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.

Oh no, I meant raytracer.el. Would it fall under the GPL by default? (Does running raytracer.el within GNU Emacs count as extending it?)

Sorry, here is the license for the project:

https://github.com/burtonsamograd/emacs-jit/blob/master/COPY... (GPL v3)

I see nothing else which overrides this but I could be mistaken.

Thanks!

To run:

    Open raytracer.el
    M-x eval-buffer
    M-: (ray-test 256)

Output will be in a buffer as well as 'image.pbm'.

Here's some additional information on ray tracing:

https://github.com/melling/ComputerGraphics/blob/master/ray_...

Now if we could only embed a flight simulator in to Emacs...

I'd settle for decent performance rendering long lines...

Maybe you can be inspired by the flight sim written in PicoLisp RcSim back in 1991, and still included with the PicoLisp distribution. [1]

  [1] http://picolisp.com/wiki/?rcsim

The whole "web developers can't be talented, passionate, real programmers" narrative is very myopic, tired, and just down right flawed. "Real programmer" machismo, in general, has no place on HN or any community that thrives to be productive and constructive.

Why not? If programming were poorly paid scut work, that would be true. But since it's a very highly compensated ticket to the middle class---surely many will do it without love.

Look at the games industry: worse pay, worse hours---those people must love their vocation.

> Why not?

That's not the question. The question is: why? Why is programming such a special field of endeavor that those who approach it may only virtuously do so by vocation, rather than profession? The only other field I know of where that's true is the priesthood. We are not priests. Nor should we be.

Now, i am no web programmer, but I read that differently. Or at least I saw another truth in it compared to what theauthor meant. To me it seems like web programming is in many ways a "solved problem". Most of the tools for doing a large part of what is web development is already there, and there is a big living ecosystem for web developers.

Lisp is not a part of that, and I doubt it would bring much even if it was. Learning lisp for someone that is fluent in some.pf the big frameworks seems to me like another way of being able to do less with more code and less neat abstractions.

Sure, Lisp has some really cool things, and in many ways it is great for building abstractions in with all the macro facilities, but the path to the same ecosystem (to me) looks too long and too impossible.

We detached this subthread from https://news.ycombinator.com/item?id=13253831 and marked it off-topic.

You misunderstood me. Of course there's plenty of good web developers. It's just that, in my opinion, the average programming language is less elegant than Lisp, and the average programmer is less passionate than the average Lisper.

This says nothing about individual programmers - there's just a lot of web developers (that's why I picked PHP as an example, because in my mind it's the standard example of a "mainstream language"), and many of them aren't particularly passionate about programming, it's just a job to them (which is, as I tried to point out, perfectly OK!). People who know Lisp, on the other hand, are almost exclusively passionate about programming, because there's no real reason to learn Lisp if you're not - it's not known to be particularly employable.

I never tried to make a value judgement of web developers as a group, it was just a matter of statistics. I'm sorry if that wasn't clear.

Your argument has merit, disregard the dissenters, just noise.

The same is true for other great languages. In my view, Erlang, FORTH, Smalltalk. I've yet to meet anyone well-versed in these that didn't turn out to be a good programmer. Moreover, this process is additive. I've met a few people over the years who are well-versed in subsets of the languages I mentioned, that turned out to be masters of the craft and helped me improve tremendously either through them commenting on my work, or me examining their output and their problem-solving approach. If I had one word to describe these persons, it'd be Artists.

In close to 20 years in this domain, I've yet to meet a single person whose primary expertise lies in {C, C++, Javascript, PHP, Java, C#, Python, Ruby}, that has triggered paradigm shifts in me that led to personal growth or re-evaluating programming. If I had one word to describe these persons, it'd be laborers. Of course the second group is also far larger than the first, and includes all the hacks [1], primadonnas [2] and mediocrats [3] one would expect.

[1] http://www.morganstanley.com/profiles/bjarne-stroustrup-mana...

[2] https://en.wikipedia.org/wiki/James_Gosling

[3] https://en.wikipedia.org/wiki/Guido_van_Rossum

Reply on news.ycombinator.com