04/15/09 :: [MOP] Language Design [permalink]
I started to look at Mgrammar and I did not see the light: the approach to parse a given grammar in relation to the production of an output is fragmented, so unlike xtext, it seems that you are pretty much on your own to create the metamodel behind your grammar. I need a bit more time to come to a definite conclusion but it looks that xtext is a lot smarter in the way you can attach a true metamodel to your syntax. Of course xtext has an M3 layer. It seems in effect that Oslo has no real M3 backbone, you can define any output you want and then build an engine that can consume it.
Serendipitously, Jonathan Allen publish a news on InfoQ about Andrej Bauer's essay, On programming language design. Something caught my eye, I think this is an oxymoron:
A language must support the programmer’s laziness by providing lots of useful libraries, and by making it possible to express ideas directly and succinctly.
Look around, developers have become scripters, there is a gazillion APIs poorly or smartly designed. These APIs change rapidly and trap business logic with more force than a black hole's attraction. The whole idea behind MOP is to create a programming model that is API-less. APIs are used in the implementation of the engine(s) implementing the programming model.
Then Andrej made my day:
Many languages are advertised as “simple” because in them everything is expressed with just a couple of basic concepts. Lisp and scheme programmers proudly represent all sorts of data with conses and lists. Fortran programmers implement linked lists and trees with arrays. In Java and Python “everything is an object”, more or less. It is good to have a simple language, but it is not good to sacrifice its expressiveness to the point where most of the time the programmer has to encode the concepts that he really needs indirectly with those available in the language.
Precisely, how many times have I heard, I love this language everything "IS-A Process", "IS-A Resource", "IS-An Object"... this is precisely what MOP is about, it is about aligning the expressivity of the language to the concepts the developer needs to manipulate to construct the solution. MOP is not a "problem side" approach, it only focuses on the people constructing the solution.