Rich Kilmer: Ruby's Best Feature | Hacker News Reader

Rich Kilmer: Ruby's Best Feature

richkilmer.blogs.com

40 pointsluccastera17 comments

"syntax-driven development"

Interesting methodology I'd never considered. Great read, thanks for posting.

I have often tried to make DSLs for projects, but I have generally always tried to design the DSL from the start... I had (sadly) never considered just writing as if your DSL already existed, then go back and actually implement it.

This is great, because what you write initially is basically what you need to implement your DSL via TDD. In this case the code written in the DSL represents your unit tests for the code implementing the DSL.

Now I just need a project I can try this on. Not sure why I never tried it that way before. Seems like a much better approach than 'designing' a DSL in a top-down manner.

http://www.infoq.com/presentations/agile-dsl-development-in-...

I thought Ruby and Python were roughly isomorphic. Is there anything drastically different about Ruby's syntax? I wish he'd given an example.

BTW, if I recall correctly, this is what PG calls "wishful thinking"-oriented development in On Lisp (actual words may differ, but "wishful" should be in there)

I thought Ruby and Python were roughly isomorphic.

Outside of the trivial matter of Turing equivalence, Ruby and Python strike me as being dissimilar on all but the most superficial level, both as languages and as cultures.

Ruby aids and abets designing your own syntax, functional programming, anonymous classes, and extremely late binding. Python either explicitly rejects such things or makes them more difficult.

Meanwhile, Python shows evidence of having paid attention to ideas invented since Lisp and Smalltalk were the new kids on the block, including things like generators and list comprehensions.

JM2C, I am not an expert in either language.

Ruby aids and abets designing your own syntax

But... how? Can you give an example?

And by isomorphic, I mean that, given a finite number of "utilities" one could translate line for line a Ruby program into a Python program, and still get, maybe not a fully Pythonic program, but close enough. I thought, using this metric, C < Python, Ruby < Lisp

I have found a remarkable proof that Ruby aids and abets writing your own domain-specific languages, but the margin is too small to write it out.

Actually, I have found this to be true and you will also find the OP makes this exact point. Google ruby and DSL and you will find hundreds of examples. While argumentum ad popularum is a fallacy, I think we have are safe in saying Ruby encourages this. Whether the resulting DSLs are any good is another question.

I don't think this is true. I have a strong feeling that Ruby allows certain things that would require whole-program rewriting to redo in Python, and certainly the reverse is true.

Generators from Python and the various metaprogramming callbacks from Ruby come to mind. Certainly you can translate from one to the other, but I don't think the resulting rewriting will be entirely local.

"Wishful thinking" is a great technique to produce clear and concise code. I use it whenever possible. It's absolutely recommendable!

I don't recall if PG used the term, but Gerald Sussman uses it in the SICP video lectures.

It's a sign that it's probably a comfortable conceptual boundary in explaining what you're trying to do.

Python's design favors having a simple syntax over a flexible one, whereas Ruby's seems to favor the reverse (though not quite to the same extent as Perl). They're in the same niche, and generally good for the same things, but they feel quite different.

I have only a small amount of experience with Ruby (I already know Python well, and think my time is better spent learning other things), but this seems like a reflection of their design trade-offs.

I'm very curious as to why Ruby was used instead of something like Erlang which was explicitly (roughly) designed for the situation he describes.

Well, according to the article it's because it is easy to generate DSLs with, which Erlang is not. Am I missing anything?

Erlang = easy to parallelize computer operations.

Ruby = easy to parallelize development.

In a situation where you have plenty of money (like DARPA) and therefore plenty of hardware, people are the bottleneck. This article is about diminishing the people bottleneck, which is the actual 'situation he describes'.

Hmmm, you mean Haskell? Erlang is not designed for that kind of job, it's far from appropriate for that kind of work.

Ruby scales? I thought the entire tech community had already taken Twitter as a lone example and proof that Ruby doesn't scale.

Edit: I was being ironical here.

Ruby != Rails

Ruby and Rails shouldn't be constants.

Reply on news.ycombinator.com