5 ms·

ruby. [video]

30 points by luccastera 19y ago

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.

Hexstream 19y ago
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 19y ago
  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 19y ago
    Yes, parentheses are beautiful. I don't actually like to look at code without them anymore.
- PieSquared 19y ago
  And how exactly is the fear of parenthesis 'pretty awesome'?
  - Hexstream 19y ago
    http://en.wikipedia.org/wiki/Sarcasm http://en.wikipedia.org/wiki/Sarcasm
    - PieSquared 19y ago
      ...oh... Sorry. That looked sort of serious though.
bsaunder 19y ago
"great programmers can write better programmers than they can hire" good talk.
- astine 19y ago
  You know John Carmack? I wrote him.
  - icky 19y ago
    Did he write back? ;)
icey 19y ago
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.
tokipin 19y ago
that example with the audio generation could be done by keeping track of the random seed
- 0x44 19y ago
  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 19y ago
    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
- ken 19y ago
  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.
bobp 19y ago
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 19y ago
  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.
pkrumins 19y ago
fizzbuzz, oh my!
pkrumins 19y ago
Jessica Alba and monkeys!
- deleted 19y ago
  [deleted]
Jesin 19y ago
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.

30 points by luccastera 19y ago

Hexstream 19y ago

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 19y ago
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 19y ago
  Yes, parentheses are beautiful. I don't actually like to look at code without them anymore.
PieSquared 19y ago
And how exactly is the fear of parenthesis 'pretty awesome'?
- Hexstream 19y ago
  http://en.wikipedia.org/wiki/Sarcasm http://en.wikipedia.org/wiki/Sarcasm
  - PieSquared 19y ago
    ...oh... Sorry. That looked sort of serious though.

bsaunder 19y ago

"great programmers can write better programmers than they can hire" good talk.

astine 19y ago
You know John Carmack? I wrote him.
- icky 19y ago
  Did he write back? ;)

icey 19y ago

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.

tokipin 19y ago

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

0x44 19y ago
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 19y ago
  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
ken 19y ago
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.

bobp 19y ago

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 19y ago
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.

pkrumins 19y ago

fizzbuzz, oh my!

pkrumins 19y ago

Jessica Alba and monkeys!

deleted 19y ago
[deleted]

Jesin 19y ago

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.