Thursday, 30 April 2009

If Only it Were That Simple

Simplicity is a holy grail touted as an ideal for which to strive. Keep it simple stupid, KISS, is sacred doctrine. Yet is the world a simple place? Are the problems you are solving simple? Are Java or C++ simple languages? In fact, do simple things ever stay simple? After all, C evolved into C++, and Java too evolved to support generics and enumerations, and those clearly didn't make the languages simpler. Consider too why it is that a simple mind is not a good thing despite the fact that simplicity is such a good thing. The reason is simple: extremes are typically not optimal. In the end, there needs to be a delicate balance between simplicity and complexity. I certainly don't want my garden to be simple!


Consider for example a Turing machine. With an optimally simple set of symbols, i.e., only zeros and ones, it's effectively impossible to come up with a simpler computational model. So why don't we all flock to this simplicity? Because it's a mirage. The expression of our solution isn't helped by the simplicity of the Turing machine, rather it's hurt by the lack of expressiveness. It's for this very reason that I bristle when I hear people say that EMF is too complex. I'll argue that it's neither too simple nor too complex, it's a higher level abstraction and it's just right. If you can do better, make my day sunny.


So many people are so used to solving their problems with rocks and pointed sticks that the mere thought of more sophisticated technology scares them away. This situation is particularly ironic because these same people are typically working on foisting some synthesized technology of their own on their unsuspecting end users. Of course everything they produce is simple, right? It's always the other guy who produces complexity. After all, I understand my stuff, so therefore it's simple, right?


Here is what I consider to be the gist of rocks and pointy sticks argument. Why would I need to build a big fire with my pointy sticks, and smelt my rocks to render metal, just so I can make a better rock or pointy stick? It's such a complicated process and it's so much extra work given that I can just smack my problems with rocks and poke them with pointy sticks already. Well, guess what folks, some of us have seen a way to move beyond the stone age caves, but feel free to hang out in yours, if that's where you feel most comfortable.



I totally agree with Michael Scharf's blog about the problem of How to Explain EMF? How do you describe something that's both a floor wax and a dessert topping? It's just not that simple. The responses to his blog were very interesting too, and while there is underlying truth in them, they typically also miss the point a bit. Consider for example that given an XML Schema, or simply annotated Java interfaces, EMF will generate a fully functional Eclipse IDE or RCP application. You don't have to know much of anything about Eclipse, and poof, there you go, a running application. That's pretty simple. It takes about a minute. But then you start to dissect it and realize oh my goodness, there's a lot going on here and gosh but it all seems so complicated. That's right because it's a complicated problem, yet would it have been simpler to have spent the months it would have taken to learn how to get all that working from scratch? No it would not! But feel free to hang out in your cave chipping stones and sharpening sticks if that gives you a sense of purpose.


Even with modeling's layered architecture, people complain that all the layers are confusing. Granted very little of modeling is well documented, the marketing message is poor, and the web organization leaves much to be desired, but please people, is there an alternative to layered architecture? Don't forget too that EMF has a book. I think this really is Michael's fundamental point, i.e., poor marketing. Rather than polishing the technology, which as developers is what we (and most of all I) like best, we need to address this marketing problem with a higher level of priority.


There's even the premise that modeling is good but EMF, not so much. The argument is actually stronger than that: EMF stifles modeling and harms the ecosystem. I think the important point being missed here is the extreme value of "the one model to bind them all," i.e., Ecore/EMOF. The modeling ecosystem is rife with other meta models---gosh but I dislike using the word meta. For example, there's UML, BPMN, XML Schema, and so on. This reality is not the hallmark of a constrained ecosystem. In each case, the value of the model is enhanced by the fact that Ecore/EMOF is the underlying meta meta model---gosh, two metas in a row, I should be shot.


Here's a fundamental assertion I'm sure will never be proven wrong: if you tried to replace Ecore/EMOF and the rest of EMF's core with something better, you'd merely end up with another EMF; only if you're lucky (people care about what you've done) and highly skilled (you've learned from EMF's successes and mistakes) might it actually be relevant and a bit better. In any case, feel free to build another ecosystem if you're feeling lucky and skillful. Don't forget to take sociology into account; you're likely better off in an established ecosystem.


No doubt it's true that I'm way too steeped in this technology to understand the perspective of someone looking at it for the first time, but surely there have been plenty of people looking at it for the first time that just a few of them might have tried to help out the next guy with their fresh insights; kudos to Michael on that front! E.g., these are the five things that took me weeks to grasp and would have been nice to have realized up front. Ultimately, simplicity like beauty is in the eye of the beholder. May you always see simplicity where others see complexity so you can lead the way forward.

Thursday, 16 April 2009

A Truly Good Person

A great many people from the Eclipse community as well as close friends and family have helped me in countless ways over the past months, often in ways they may think small but collectively to me looms large. I want to express my appreciation for everyone's kinds thoughts, kind deeds, and what I'd characterize as goodness of spirit. Larry and I both appreciated it more than you might imagine. Instead of Ed the software engineer, I will pretend for just this one time to be Ed the poet. I'll express my thoughts in the form of a poem, and no, I won't give up my day job. Larry would be proud of that, I believe. He was most certainly a Truly Good Person.


The title of what I'll call the Truly Good Person poem resounds with the truth that underlies contradiction.

Goodness: The Eternally Transient Changing Constant

The goodness of spirit
and the spirit of goodness
are one and the same.

While theologians among us debate,
while rule followers and makers clash,
to all who behold,
it is clear when they look,
that goodness is manifest.
This is clear,
without faith,
without rules,
for there is manifest goodness wherever we look.

Be the manifestation of goodness,
and behold the manifestation of goodness in others.
Be the change that is good,
and behold the goodness of change.
Be the spirit of goodness,
the eternally transient, changing, constant.
Be a truly good person.

It's an important lesson for each of us: be a Truly Good Person for in doing so you will be loved and you will find peace. It's certainly clear to me that my social circle, which includes the Eclipse community, is rife with Truly Good People. You all know who you are and you should know that you are appreciated.

Friday, 10 April 2009

All Good Things

All good things come to an end and Good Friday seems an apt day for endings. Eclipse has a great many contributors, not all of them well recognized. While many work in the foreground to make Eclipse what it is today, many more play important supporting roles in the background. Did you notice one of those background contributors in this picture from a previous blog?


I'll bet that when I said "It's important to keep in mind that although those in the foreground will tend to catch your eye, there's much more going on in the background than you might notice" you didn't take the hint to look more closely. If you had, you'd have seen Larry. As many of you know, he's been home since the beginning of February dying of cancer. He's been my guiding light for the past 27 years, so the girls and I did everything we could to make the end as dignified and comfortable as possible.


Today glioblastoma extinguished that light. Without him I might never have contributed to Eclipse and most certainly I would not have contributed as much. I don't use the word hate lightly, but I hate cancer and I despise glioblastoma for robbing his mind and then his life. Eclipse lost a significant contributor today and I lost something precious beyond measure. Thank goodness fond memories last a lifetime.


Value what you have while you have it because all good things come to an end.

Friday, 3 April 2009

Sharing: The Good Spirit of Open Source

Sharing is a good thing. Every spring one of the good things the garden shares at the very start of the new season is the first snow drops. Their early arrival makes them special.


Open source too is fundamentally about sharing: the sharing of software. Earlier this week, Bjorn blogged about his personal view regarding "open source products." I agree, open source is not about products. It's about sharing what you create for free. Now there's a loaded word. In this case it means free as in freedom, i.e., the freedom to ignore anyone else in the universe who might take issue with what you shared with them for free. Hello? Did you noticed the $0 price tag dudes and dudets?! If you get nothing of value you've gotten exactly what you paid for. Of course everyone is more than free to be irrelevant as well. Ignoring the community is a most excellent way achieve irrelevance. Feel free!

In the end, the value of sharing is greatly enhanced when others partake. I'd like to think that when you share your software, you try---another loaded word; to try is a lie---to ensure that the things you share have "true value." Perhaps I project too much? Providing "true value" takes effort. It's a burden of responsibility not to be taken lightly. Life is a bounty but comes complete with a great many burdens that ought not to be taken lightly. Gardens, on the other hand share their bounty with no sense of obligation, like these crocuses, though the crocuses do anticipate pollinators will share their mobility.


When others use the software you share with them for free, they can help shoulder the burden of responsibility. They might shoulder it in recognition of the benefit received from sharing it for free in the first place. An excellent excellent example of that principle at work is seen in 270870. Achim Demelt shared his time and deep analytical insight to a cast light on a challenging technical problem. It's quite remarkable, and not just in my opinion. When you stop to consider that all the people and organizations in the community---those who have contributed and those who have not---all benefit from individuals like Achim sharing solutions to hard problems, you will have understood the true value of sharing in the context of open source. Social software indeed.