Great Presentation on MetaProgramming. Talks about pg/ycombinator/lisp/ruby. [video] | Hacker News Reader

ruby. [video]

mwrc2008.confreaks.com

30 pointsluccastera19 comments

The speaker summarizes Paul Graham's theories on Lisp and startups with the following statement:

"Skilled programmers can write better programmers than they can hire"

I really enjoyed watching the whole video. Very interesting stuff. Highly recommended.

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.

Pretty awesome how tons of really smart people just won't get over their fear of parentheses even when they know the power that's behind them.

As peculiar and different as lisp is, the difficulty of learning it is highly overrated.

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.

Yes, parentheses are beautiful. I don't actually like to look at code without them anymore.

And how exactly is the fear of parenthesis 'pretty awesome'?

http://en.wikipedia.org/wiki/Sarcasm

...oh... Sorry. That looked sort of serious though.

"great programmers can write better programmers than they can hire"

good talk.

You know John Carmack? I wrote him.

Did he write back? ;)

that example with the audio generation could be done by keeping track of the random seed

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.

fizzbuzz, oh my!

Jessica Alba and monkeys!

Reply on news.ycombinator.com