Steven Kelly sobre DSL´s y plataformas

Steven Kelly, de Metacase, abre una más que interesante discusión clarificadora en el terreno de las vías de contrucción de software, una que tiene que ver con las factorías de software. Esto vale un pormenorizado seguimiento, que no cabe por tiempo en una sola nota. Por lo tanto, ahora sólo quisiera destacar una o dos afirmaciones suyas a propósito de afirmaciones de Jezz Santos, que refuerzan mi impresión sobre las SF:

The task when creating a DSM language is thus to achieve the raise in the level of abstraction away from the bits and bytes of the implementation, and to offer a smooth, impedance-free mapping between the problem domain and the language. For both of those, we need to focus on the problem domain (the domain expert view) not the solution domain (the implementation in code).

(...) Let's look at a couple of other people's perspectives. First up, Microsoft's Jezz Santos:

If you understand the difference between problem domain and solution domain in software design, you will know that [software] factories are all about the solution domain. We are so far away from modeling problem domain and turning it into software just yet - forget it for now. It has proven impractical at this time, it is too big a step at this point, we need to evolve to that later.

If that really is the Microsoft party line then I'm seriously disappointed. Maybe Microsoft are "so far away" from a real raise in the level of abstraction, but others most certainly have proved that it's practical. Pushing out that kind of poor advice is a disservice to Microsoft's customers, dragging their modeling languages down to near the level of the code. Failing to raise the level of abstraction much was the key reason why Ordina only achieved a productivity increase of less than 20%, despite spending man-years on extending Microsoft's DSL Tools.

Maybe Microsoft are so focused on selling their platforms and frameworks that they are misled into thinking those are primary, and the customers' actual problems and needs are secondary? From a neutral point of view I'd have thought it would be self evident that problems come first, and solutions are dependent on the problems. There can be many different solutions, built with different technologies, that all solve the same problem. Only a technology vendor would take the technology as primary, and declare that all customer problems must be expressed in terms of that technology to be valid.

Kelly pone la discusión sobre construcción de software en buenas bases. Servirá, así como el material que se deriva de sus comentarios, para abrir aquí algunas líneas de pensamiento. Será en días y posts próximos...