Getting back to the e4 summit instead of the QE summit, it was incredibly nice to have the opportunity meet with so many like-minded constructive people all focused on a common goal. I have to admit though that I came to the meeting with an expectation, based on a long history of past experience, that it would be a struggle to get past the typical skepticism about the value of formal modeling. People typically feel that formal techniques will constrain or limit them and then look for as many examples as they can think of to justify why they'd be able to accomplish their task more effectively without all those annoying obstacles to their capacity for creative expression. Been there, done that, could write a book about it. Don't look so surprised!
Of course I don't fault people for healthy skepticism given that we live in world rife with hype where style is all too often more important than substance. Can you say Teflon Programming? I can relate so well because I went through that same process myself many years ago, and let me assure you that at that time, there were a heck of a lot more substantial reasons why the final results produced by the generator were less than ideal, not to mention the bloated MOF API. I even found the class diagrams a complete turnoff, even though now I love them in an almost unnatural way. It all smacked way too much of those flow charts you had to do in university which you were supposed to do before you wrote the code, in waterfall fashion, but actually did after the iterated design was correct, and then only because it was required.
It's clear that what I hadn't anticipated was the fact that I was dealing not only with exceptionally bright people but also atypically diligent people. Folks had done their homework before the meetings and had gathered actual data themselves; of course Tom's prototype was a godsend. That guy is truly amazing. He's the epitome of a great community member, with 233843 being just one of an endless stream of examples. We must clone him! Anyway, getting back to the meandering path, when I asked Eric what convinced him of the merits of EMF he explained that he measured the speed of EObject.eGet and found it to be more than twice as fast as HashMap.get and that of course a HashMap, with its plethora of Map.Entry instances and its sparse hash index dwarfs an EObject's footprint. That's not even taking into account the use of bit flags for booleans and enums nor the ability to store primitive values rather than boxed values. Clearly faster and smaller is hard to beat so I shouldn't be surprised. I'm just way more used to having to argue that point rather than having people verify this themselves! It was like a breath of fresh air.
What I thought was especially great about the the summit was the extent to which it genuinely felt like one big team without the usual organizational boundaries. Folks seemed uniformly excited to do new and cool things while embracing existing technologies like EMF to solve the hard problems we face. Just look at the summary of the major issues that need solutions in our drive to model the workbench and the things in it. People were surprised by the breadth of solutions we already have available in the modeling space, i.e., note how most of the issues already have solutions. In fact, even high end solutions important in developing a rich SDK for self-hosted e4 development, such a graphical Ecore editing, are already available. I take great pride in the fact that the modeling community is diverse and hence has so much to bring to the e4 table. By the end of the summit, it got to be a bit of a joke that every modeling problem raised was either already solved or was currently under investigation.
I think we are witnessing the metamorphosis of a new community around e4, and like the metamorphosis of my community tank, it's a beautiful thing!
Posts
No comments:
Post a Comment