

Great Presentation on MetaProgramming. Talks about pg/ycombinator/lisp/ruby. [video] - luccastera
http://mwrc2008.confreaks.com/03bowkett.html
The speaker summarizes Paul Graham's theories on Lisp and startups with the following statement:<p>"Skilled programmers can write better programmers than they can hire"<p>I really enjoyed watching the whole video. Very interesting stuff. Highly recommended.
======
Jesin
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.

------
bobp
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?

~~~
ken
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.

------
icey
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.

------
Hexstream
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.

~~~
icey
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.

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

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

good talk.

~~~
astine
You know John Carmack? I wrote him.

~~~
icky
Did he write back? ;)

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

~~~
0x44
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.

~~~
tokipin
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

------
pkrumins
fizzbuzz, oh my!

------
pkrumins
Jessica Alba and monkeys!

