En primer lugar, sus observaciones sobre Oslo:
What is clear is that now Oslo is only about "modeling", SOA and Composite Applications are simply areas where Oslo can be applied. That's a bit different from the original announcement on the project in the fall of 2007 and pieces like "Dublin" seem to have fallen off Oslo which is now only 3 elements: a metadata repository, quadrant and the M language.Dubray parte de una premisa con la cual juzga Oslo:Metamodel Oriented Programming (MOP):
MOP is an approach which seeks to create a programming model independent of architecture such that architects can architect and developers can build the solution in an architecture independent way. This is in line with projects like Microsoft Volta which talked about "Architecture Refactoring" concepts. Incidentally Volta has disappeared from the face of the earth, what a shame. MOP is not about creating a single programming model, but again, rather an approach to separate architecture(s) from programming model(s). I, of course, focus on SOA and Composite Apps, but as a good software engineer, I believe that anything I do is so general MOP can be applied to anything...Dubray, basado en las conjeturas que permite extraer la todavía difusa información sobre Oslo, sostiene que el proyecto no logra establecer una separación clara entre el nivel de abstracción de modelado y la programación:
If you build something like Oslo you start with a programming model like .Net RIA Services or anything you want that tries to do the same thing and then you build Oslo to make it easy(ier) to build something like .Net RIA Services. In case you have not noticed MOP has already happened, all the annotations in Java or C# is MOP layered on top of OO. But MOP layered on top of OO does not provide a clean separation between Architecture and Programming Models. This is the mission that Oslo should set itself up with. So starting with an "app" is, of course, a traditional Microsoft approach. But this is the wrong level. This is actually catastrophic to start at this level, it ensures they will never deliver something at the MOP level. What our industry needs today is not a better way to write code snippets or string templates, it needs a way to express business logic in a sustainable way, i.e. outside a given architecture.Sobre M:
"M lets developers build out domain-specific languages (DSLs) relatively easily" is no longer the problem, Microsoft has DSL tools for that, the question that the Oslo team should ask itself is does M stands for Model or Metamodel?Douglas Purdy, mencionado por Dubray, acaba de contestarle. En todo caso, postula M como una herramienta para trabajar a nivel de metamodelos y meta-metamodelos. Diferenciando M de las DSL tools de VS:
The current DSL tools (the DSL Toolkit) are for visual DSLs, not for textual DSLs. We want an architecture that supports both both textual and visual DSLs operating over the same model. Speaking of model, M is for model and metamodel and metametamodel. Since my Smalltalk days, I have grown tired of using the meta prefix, as it often confuses more than helps the conversation with developers.También en su contestación está implícito el rumbo zigzagueante de Oslo desde su inicio al contestar aceerca de la relación entre Oslo y FTA.
Está abierta una discusión...Más allá del punto de vista sobre Oslo, otras aristas del pensamiento de Dubray merecen ser seguidas. En otro momento.
No hay comentarios.:
Publicar un comentario