raganwald
(This is a snapshot of my old weblog. New posts and selected republished essays can be found at raganwald.com.)

Friday, September 22, 2006
  People want holes, not drills, and especially not drill bits


DSLs are a hard way to sell your language. They haven't worked for Lisp yet. Before you can sell Ruby based on DSLs, you need to tell people why they need DSLs.


My sales background tells me that people want holes, not drills, and especially not drill bits. For that reason, you have to sell the holes themselves, not the technology for making them.

It's a mistake to 'sell' DSLs, just as it's a mistake to sell metaprogramming. Wherever programmers hang out, you'll find people arguing the merits of high signal-to-noise techniques like DSLs. It's fun and instructive to have this debate, but it isn't selling. It's coffee-shop banter about drill bits, and whether diamond tips are worth the price, and are all carpenters equal or are some better than others, and should all drills have safeties so any monkey can make holes, and can you do concurrent drilling with a drill press framework?

Lots of people love the way Ruby on Rails makes certain things declarative and makes their code smaller than whatever else they used to use. They love the holes, and that's as it should be. DSLs and metaprogramming are implementation details for framework builders, not selling features for framework users.

At least, not up front. Later, after they've gotten hooked on drilling holes, they'll be interested in drill technology. :-)
 

Comments on “People want holes, not drills, and especially not drill bits:
"DSLs and metaprogramming are implementation details for framework builders, not selling features for framework users."

I do not fully agree. As Joel Spolsky said, most abstractions leak. It is therefore crucial to be able to look behind the scenes. This is a lot easier of your DSL is a compiler rather than an interpreter and, in particular, if it compiles to the very language you are already familiar with. Languages that make this possible have a distinct advantage here. (See my longer post on the topic.)
 
most abstractions leak. It is therefore crucial to be able to look behind the scenes.

It seems you're saying that you have to understand the drill to make the holes. I quite agree with that statement. So perhaps DSLs are not just implementation features for framework builders.

Of course, the bulk of my very short post is about convincing people to try drilling holes. During this "selling" phase, before the user has tried to make their own holes, I believe we need to emphasize the holes and not the drill bits.

As I noted with a wink, users will have plenty of time and motivation to come to grips with the details after they're hooked.
 
When I wast proposing selling DSLs, I didn't mean selling posibility of making DSLs.
You're completely right - nobody's going to buy that.

What we need to sell is complete DSLs. Make people code Ruby when what they actually want is to code in their problem domain. Do you want to control compilation ? Use Rake (which is far better than make/ant). That's Ruby. Do you want to code a website ? Use Ruby on Rails (which is far better than all other web frameworks).

Ruby makes it possible to make good DSLs. It's hard to sell DSLability, but it's pretty easy to sell DSLs, and it will sell Ruby just as a side effect.
 
What we need to sell is complete DSLs.
...
Ruby makes it possible to make good DSLs. It's hard to sell DSLability, but it's pretty easy to sell DSLs, and it will sell Ruby just as a side effect.

Excellent point.

Slightly off-topic: why is it that there are popular DSLs implemented in Ruby, but not Lisp?
 
Matt: "Slightly off-topic: why is it that there are popular DSLs implemented in Ruby, but not Lisp?"

Maybe because Lisp generally does not look very inviting to the people who look for simple and intuitive looking solutions to simple problems? See David Wheeler's take on this.
 
Reginald: "During this "selling" phase, before the user has tried to make their own holes, I believe we need to emphasize the holes and not the drill bits."

Yes, when selling to DSL users, which I agree is the majority. But there is also the sale to would be DSL creators. They reinforce the drive of the platform. Ruby lowers the barrier of entry for creating DSLs in a good way, I think. (I am writing one in Java right now so I can tell.)
 
Matt: I think the main reason is that there is no single good standard implementation of Lisp.

Rake needed Ruby metaprogramming, but it also needed access to all standard Unix functions like globing, timestamp checks etc. Rails needed Ruby metaprogramming, but also SQL support, HTTP support, sockets etc.

Neither Common Lisp nor Scheme are very strong here. They tend to leave such "details" to implementations, and in the end you cannot write portable non-trivial Common Lisp/Scheme programs. Maybe if they all got behind a single implementation (some Scheme or some Common Lisp or Arc or Goo or even RLisp), and implemented a standard library that doesn't feel 1980ish, Lisp would be able to come back.

That, and the parenthesis ;-)
 




<< Home
Reg Braithwaite


Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

Books
What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

Share
rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

Beauty
IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

Work
The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Management
Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

Notation
The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Opinion
Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

Whimsey
The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

History
06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /