You know, I couldn't understand that Lisp code snippet he presented either. He converted this Ruby:
code == data
to this:
(eq (code (data)))
What? OK, let's translate that to syntax non-Lispers can understand. That means:
eq(code(data()))
What? Maybe he was trying to write
(eq . (code . (data)))
Which is just a horrible, never-used way of writing
(eq code data)
which in that other syntax would be written
eq(code, data)
Yet another person bashing Lisp as impossible to understand without making any effort whatsoever to learn what the extremely minimal syntax means.
Another thing. He says that Perl and Lisp have a lot of power, but nothing in the way of simplicity. I take issue with that. Whereas Perl is overcomplex, Lisp is about the simplest you can get. He seems to think that "simple" means something along the lines of "understandable by people experienced in commonly-used programming languages". To that, I says pleh, and also blub.
Is Giles saying that with the help of Rubinius you can do Lisp-style code generation in Ruby? I don't know much about Rubinius but this doesn't sound right. Lisp macros let you manipulate the program's AST in compile time very easily because the AST is made of sexp's, just like the program code itself. This is due to the peculiar Lisp syntax. Lisp code generation seems quite different from the monkey patching techniques demonstrated in the presentation. Am I missing something?
I didn't take that to be his main point, but yes, I think so. Though I think it would be more accurate to say "Lisp lets you manipulate the program's AST trivially because the AST is the code".
This is basically Greenspun's 10th Law again. There's no magic in Lisp that's computationally impossible in another language, but it might be simpler to just write a Lisp in that language first. Rubinius did something even tougher: they wrote a Ruby. The advantage of this is that it's backwards-compatible with all their existing code, while upgrading to sexps would not be.
I think the monkeypatching corresponds to only the front half of Lisp macros. The macroexpand part comes from making the monkeypatches log Ruby code, and then running the log.
It was amazing when they showed a shot of the audience. A quick count revealed 17 macs, and 1 machine that I don't think was a mac, although it may have been a black macbook.
I didn't realize macbooks had become so pervasive in the ruby world.
A quick disclaimer: I'm really a Lisp / Scheme noob, but I'm learning them both for academic purposes.
That being said, at first the parens bugged me a little bit, but as I got to developing more applications, the more I really grew to LOVE the parens. To me, they introduce a certain purity to the programs that I write; it's like every s-expr is a single thought and every function is a train of thinking. Beyond that, an additional benefit that I've found is that I can hold MUCH more of a program in my head when they're organized this way. I think it has to do with the chunking theory of memory - I don't have to remember the particulars of each chunk; just what each chunk did.
Anyways, it's a big enough attraction to me now that I regret not having them available in my day-to-day languages.
That's what his example was. Instead of saving 12 hours of generated music, he's logging the data that generated it as instructions on how to generate it.
that's still more data than just saving the seed. though maybe he was talking about saving basic things (seed,etc) and when you want to reconstruct them into audio, you basically generate a program instead of an mp3. not really much different than just saving the basics, except it's more shareable and takes up more space
but it didn't sound like that. it really sounded like it never occurred to him to just store the random seed(s) because he said when you hear a great piece in randomly-generated music, it's gone forever, even though the seed is a fundamental and controllable aspect of that
[edit]he said it would generate a log of code which would point back to the generating/generated code. i can't really tell what he was effectively storing though. to reproduce the music well, the seed would have to be in there somewhere, unless it's only in charge of choosing a few discrete items
Sure, as long as you had exactly the same PRNG on every computer where you were going to read the logs, and as long as there was no other input (e.g., human input). Depending on how the music generation worked, it also might make seeking an O(time) operation.
Plus then he couldn't grep his music, which is the really cool part.
Another thing. He says that Perl and Lisp have a lot of power, but nothing in the way of simplicity. I take issue with that. Whereas Perl is overcomplex, Lisp is about the simplest you can get. He seems to think that "simple" means something along the lines of "understandable by people experienced in commonly-used programming languages". To that, I says pleh, and also blub.