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.
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.
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.
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 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.
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.
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'.
Interesting methodology I'd never considered. Great read, thanks for posting.