DSLs imperativos contra declarativos

      The difference is really in the intention. Imperative DSLs usually specify what to do, and declarative DSLs specify what you want done.
      — An imperative DSL specifies a list of steps to execute (to output text using a templating DSL, for example). With this style, you specify what should happen.
      — A declarative DSL is a specification of a goal. This specification is then executed by the supporting infraestructure. With this style, you specify the intended result.

Building Domain Specific Languages in Boo
Ayende Rahien
Manning

Interfaces elocuentes versus DSL

Fluent interfaces are usually useful only during the development process. A fluent interface is probably a good choice if you intend to use it while you write the code, because you won't have to switch between two languages and can take advantage of the IDE tooling. In contrast, if you want to allow modifications outside development (for example, in production), a DSL tends to be a much better choice.

Building Domain Specific Languages in Boo
Ayende Rahien
Manning

La claridad es más importante que la brevedad

But while code may be unambiguous to a computer, it can certainly be incomprensible to people. Understanding code can be a big problem. You tend to write the code once, and read it many more times. Clarity is much more important than brevity. By ensuring that our code is readable, clear, and concise, we make an investment that will benefit us both in the inmediate future (producing software that is simpler and easier to change) and in the long term (providing easier maintainability and a clearer path for extensibility and growth).

Building Domain Specific Languages in Boo
Ayende Rahien
Manning

IQuackFu

If it walks like a duck and it quacks like a duck, then it must be an IQuackFu.

Building Domain Specific Languages in Boo
Ayende Rahien
Manning

El próximo podría ser un psicópata

It's considered polite to express intent in code in a manner that will make sense to the next developer who works with your code, particularly because that poor person may be you. A good suggestion that I take to heart is to assume that the next developer to touch your code will be an axe murderer who knows where you live and has a short fuse.

Building Domain Specific Languages in Boo
Ayende Rahien
Manning