I thought the example of using a DSL to get as close to the mindset of the customer as possible was a good concrete example.

I think it was also pointed out that even with this DSL, there was still communication errors. However, it seemed easier to fix the misunderstandings because there was a DSL there to fall back on.

> I thought the example of using a DSL to get as close to the mindset of the customer as possible was a good concrete example.

No, "concrete" means that it's something real and tangible. Not just "a DSL" and "a customer", but "a language for the control of a nuclear power plant" and "General Electric" or something like that. Well, a specific company name is not so important, but the industry and what the language's scope was seem extremely relevant to me.

Without actually providing an example, you have no idea what level of abstraction they're working at, and what kinds of benefits and limitations the DSL may have.

I can't remember the exact DSL, unfortunately. But as an example, consider the following pseudo-code:

  for($i = 0; i < 100; $i++) {
    $product = mysql_query("query_string");
    // do something with product
  }

or the far more readable:

  Products.find_all.each do |product|
    product.do_something
  end

Of course, this is only the difference between an ORM and database code, but I think you can imagine the difference if you also encode your clients' vocabulary in your models.

The "fun" bits of client work are when do_something has a non-obvious but critically necessary side effect for products with even-numbered SKUs issued in 1997 from the Chilean subsidiary, and this fact is either a) known to one guy who retired last year or b) so blindingly obvious that it never needed to get written down anywhere.