Archives
-
If the Chief-Architect doesn't decide... who does?
Yesterday I read this great article about VS.NET's technical roadmap, posted by Rico Mariani. Rico is the Chief Architect of Visual Studio, and he explains what that title means as follows:
I am the Chief Architect but I'm also *only* the Chief Architect, I don't make the final decisions about what goes in the product, not even combined with the other architects. Jointly we come up with the long term technology roadmap, it indicates key problems that need to be solved for the long-term health of the product among other things, but these things cannot usually be mapped directly in to features in a particular release. So, while it's true that I have a significant effect on what we do, it is inadvisable to take any of what I write as some kind of commitment to deliver particular features; rather I talk about examples of things that we might do that are in line with the roadmap.
-
Baby-sitter Framework 2.0: Change tracking in the EF v2, it's still your problem
More than 1.5 year ago (!) I wrote an article about why change tracking of changes of an entity should really be inside an entity object. Change tracking is the concern of the O/R mapper and the entity object, not the developer using the entity object and the O/R mapper. Imagine using an entity object a .NET application and you are in charge of taking care of what changes happened inside the entity object when it was used by some routine so you can decide which routine to call: the InsertNewEntity() routine or the UpdateExistingEntity() routine. Isn't that the concern of the framework you're using? I.o.w.: why do you need to baby-sit the changes of an entity and make sure these changes are propagated along the same path over which the entity travels?
-
Designing a language is hard, and M won't change that
I was a bit surprised about the large scale of the positive hype around 'M' in Oslo. Fortunately, Roger Alsing wrote a 'Back to reality' post about M which stood out as a single critical remark against the sea of positivism. I like it when someone chooses to be the more sceptical voice in the crowd: this way an outsider gets a better chance to see the whole picture instead of just one side. This post is written in that light, to give my two cents in line with what Roger said and to give some more background in what I think he meant.
What's the idea of 'M', the codename for the textual language in Oslo? It's supposed to make it easy to write DSLs. A DSL is a 'Domain Specific Language', which in short is a name for a language (in any shape or form!) to express behavior, data structures, data and what have you, for a specific, narrow, well defined domain. So if you want your application to have a custom set of rules, definable by the user, a DSL might be a good mechanism to formulate these rules in. Make no mistake about what a DSL is though: a grid, form, text in a textfile, can be a representation of a DSL. It's a concept, not a physical toolkit.