Reblog

In this article PragDave draws a line about when it’s time to stop enhancing and wasting time trying to make a DSL read like english (or another spoken language). Spoken languages are imperfect and redundant and this is their strength. The impedence mismatch is clear: programming languages need predictability and writability instead. Fluent interfaces (as from the definition of Martin Fowler) should not be used as a technique to make a DSL read like english, but a programming language more clean and concise in a specific business context.

I think that tools like RSpec or Cucumber didn’t cross that line yet. True, authors of those tools put effort to create a DSL similar to a spoken language but I think the approach is still very pragmatic in nature. What I disagree with these days is the tendency to believe you always have to use tools like Cucumber (or Fitnesse/JBehave you name it) to create acceptances and scenarios even in the case there is no “business customer” reading and editing them. That’s a mistake in my opinion: as a programmer I don’t need the level of sophistication in readability that Cucumber offers because at the same they increase my programming effort. Again, there is a tradeoff you need to consider when you assume all projects should have a complete suite of acceptances. I’m still not at the point to consider acceptances a “scam” thought :) My rule of thumb at this point is: “if it’s taking too long and is getting way too complicated, it means there is something wrong”. Creation and maintenance of acceptances, unit tests, both TDD or test after, should always be an easy and straightforward task.