vladimir piskarev's blog

Musings on the Eclipse Handly project and software development in general

Month: February, 2014

Handly Creation Review successful

It’s hard to find the words to convey what you feel when your first Eclipse project is being created before your very eyes. Thus, I shall restrain myself to simply expressing appreciation to all of you who have been interested in the proposal (or even took time to read my commentary on it and spread the word). Special thanks (in alphabetical order) to Doug, Marcel, Sven and Wayne; without your help and support, it would not be possible for the project to reach this phase within a relatively short time.

I hope that Handly will nicely fit the “Incubators Stream” of its parent Technology Project, as defined in the Project Charter (“incubation of small-scale, innovative platform and tools projects”). Being a small-scale project, it’s unlikely that its community is going to be particularly large. However, I do hope that its community will be friendly, diverse and vibrant. It’s an explicit goal for the project that we shall try to achieve.

We’re eager to make the initial contribution available to the community as soon as technically and legally possible. After that, please join in the development effort, participate in feature planning and design discussions, begin using this thing and provide valuable feedback, or simply ask questions. Remember, you are always welcome here. Thank you!


A quote from “Hints for Computer System Design” by Butler W. Lampson

Designing a computer system is very different from designing an algorithm:

  • The external interface (that is, the requirement) is less precisely defined, more complex, and more subject to change.
  • The system has much more internal structure, and hence many internal interfaces.
  • The measure of success is much less clear.

The designer usually finds himself floundering in a sea of possibilities, unclear about how one choice will limit his freedom to make other choices, or affect the size and performance of the entire system. There probably isn’t a ‘best’ way to build the system, or even any major part of it; much more important is to avoid choosing a terrible way, and to have clear division of responsibilities among the parts.

Welcome to my blog

This should have probably been my opening post. A personal weblog often contains an introductory entry about what inspired its creation; its intended focus; its author and his interests; etc. However, in the first post, it has been more important to me to talk about the Eclipse Handly proposal, which I find very exciting and which actually inspired me to start blogging for the first time in my life. The Handly project and open source in general will remain the primary focus of this site, but this is a personal blog after all and I reserve the right to publish occasional reflections of me under an appropriate category in a lame attempt to amuse the reader.

I was thinking of the question — should I introduce my humble self in the hope of facilitating socialization and if I should, then how? My current status is presented on the About page. I might add that I’m a big fan of Beethoven, though I enjoy Trout Mask Replica too. Still, I wanted to convey something that not only could characterize my personality in some respects, but also was more fitting to the intended focus of this blog.

Finally, I thought that a better way to introduce myself might be to reflect on my personal heroes in computer science and their powerful ideas that have informed my interests and, in large part, my thinking. I already mentioned Alan Kay when I was musing on scalability. Now is the turn of another hero, also of Xerox PARC fame. His name is Gregor Kiczales.

Gregor is, of course, widely known for aspect-oriented programming and AspectJ (actually, he coined the term “crosscutting”), but it’s his fantastic, though perhaps slightly less known work on the metaobject protocol approach and its unsurpassed manifestation in Common Lisp Object System (CLOS) that, to me, is even more important. I can only repeat the Alan Kay’s recommendation for the profound book “The Art of the Metaobject Protocol” by Gregor Kiczales, Jim des Rivières and Daniel G. Bobrow. That book must have been one of the most significant revelations in my life. It thoroughly introduces the concepts of metaobject protocol design, but to me, the most remarkable has been the very idea of “opening languages up” for achieving that exquisite blend of elegance and efficiency, beauty and practicality. If you read it, you will never be the same again.

How to run open-source projects well — education of a project lead

Ultimately, I believe that the only way to really learn something is by doing, but education is quite important too. I have never run an open-source project before, though I’m not entirely uneducated in that area. Besides watching how other Eclipse projects are run and making minor contributions occasionally, I’ve read the excellent book “Innovation Happens Elsewhere” by Ron Goldman and Richard P. Gabriel. The authors are highly regarded, to say the least, and the book, although quite lengthy, is an essential read. Actually, I’ve read it twice. I’ve enjoyed reading the influential “The Cathedral and the Bazaar” by Eric Raymond. I’ve also read the Development Resources available on the Eclipse Wiki.

Have I missed something essential to that education end? What resources would you recommend to an aspiring Eclipse project lead?

On scalability and why it’s so important

I’m not going to say anything really new here. Rather, it’s a way to summarize thoughts on that, quite important to me, matter.

I have a deep interest in object-oriented programming; more in the original idea than in any specific implementation (though I find Smalltalk to be an execution par excellence) or methodology (however helpful design patterns can be). I was immensely impressed by Alan Kay’s talk at OOPSLA 97. Here’s the link. I continue to enjoy it every time I’m reading it. It’s influential, to say the least. Without doubt, Alan is one of the most important thinkers of our time, probably of all time.

Of course, the central idea underlying object-oriented programming is how we can deal with large-scale structures effectively. It’s all about scalability. As Alan Kay excellently put it: “As size and complexity increase, architecture always dominates materials”. When ARPANET was being designed in the sixties, its designers thought deeply about scalability of “the intergalactic network” — the result is, of course, the Internet as we know it — probably, the largest structure ever made by the human.

Now, many seem to be concerned more about performance than scalability. Some may even believe it’s the same thing. It’s hard to say why this syndrome is so deeply embedded in our nature, as programmers. Indeed, system programmers may be thought of as “high priests of a low cult”. The cult is, of course, optimization. But the irony is that staying in the “pink plane”, strongly focused on optimization, we are often optimizing something that can’t be optimized very much. While such optimization can bring tangible tactical benefits, it can also bring much less tangible, but strategic losses (skewed design, closed options, hard to maintain inflated code base, etc.). In contrast, thoroughly thinking about scalability is strategically important, though perhaps less perceivable tactically. When a first Smalltalk took a while to compute “3 plus 4”, Alan could not care less. He knew about the Moore’s law and designed for scalability, not for performance per se. The rest is history.

“If you think programming is small, that’s why your programs are so big.” Our industry as a whole could benefit if we begin to think more deeply about all aspects of scalability when doing system design. And that’s the main lesson from Alan Curtis Kay, to me.

P.S. Once you start blogging, it’s hard to stop. That’s why I’ve long resisted creating a personal blog. Now it’s frightening to think what will happen when I discover Facebook and Twitter.

On handle-based models and the recent Eclipse Handly proposal

This is going to be quite a special post to me for two reasons. First, I must admit that I’ve never blogged before, so this is my first blog entry ever. Second, it’s about the recent Eclipse Handly proposal that I’m entitled to be the sponsor for. I find the proposed initiative important enough to justify starting a personal blog for the first time in my life. Here’s why.

I’m old-enough to remember the good old days of Eclipse as (just) an IDE platform and a great Java IDE built on top of it. That was how it all started. Then, seemingly, the focus has been gradually changing: RCP, Modeling, Runtime, and now the Internet of Things and M2M draw a lot of attention. That’s all great, but it looks like, somehow, the initial IDE-platform mission was overshadowed by this diversity and has never been realized completely. Now, that’s just an opinion, but many people seem to have similar feelings. See, for example, a recent blog post by Doug Schaefer, the Eclipse CDT project lead. (Doug, and Marcel Bruch, the project lead of Eclipse Code Recommenders, have kindly agreed to become our mentors.)

But how could that IDE-platform mission be more fully realized? That’s not an easy question for sure, but I believe a possible answer may lay in creating a multi-language IDE infrastructure slightly above the level of abstraction offered by the Eclipse core and doing it piecemeal. Simply put, Eclipse needs to become a great multi-language IDE and that goal just cannot be achieved in one go.

And this is exactly where I see the proposed Eclipse Handly project fits in. It aims to become a first piece of the puzzle, addressing language-oriented handle-based models. “Language-oriented handle-based models? That’s mouthful. Isn’t it something that EMF does already?” No, it has nothing to do with Eclipse Modeling effort. But it has to do with the core of a multi-language IDE in a very real sense.

If you have ever looked into the design of Eclipse Java development tools (JDT), or for that matter, CDT or DLTK, you already know that at the tooling’s core lies a handle-based model for the programming language(s) in question: Java Model, CDT model, DLTK model, etc. To a large extent, it’s the handle-based model that makes possible seamless tool integration and unified user experience provided by the IDE.

Unlike the more common object-graph kind of models (such as EMF-based models), handle-based models employ a variation of the handle/body idiom, where clients have direct access only to immutable, equal-by-value ‘handles’ to model elements, while the corresponding element state is stored separately in the internal ‘body’. Such design has a number of properties that makes it an especially nice fit for a large-scale long-lived model of a programming language from the workspace root level down to structural elements inside a source file as required for IDE tools. Here are the main characteristics of a language-oriented handle-based model:

  • ideally suited for presenting in structured viewers
  • scalable due to virtualization made possible by a handle-based design
  • eventually consistent — need not be consistent all the time
  • can refer to non-existing elements — existence can be tested with exists()
  • tolerant to inconsistencies in a source file (syntax errors, etc.)

If you have not come upon handle-based models before and are curious to know more about them, I can recommend the excellent book “Contributing to Eclipse” by Erich Gamma and Kent Beck, especially the pattern stories about the Java Model.

But the question remains: “what does Handly bring to the table?”. Initially, two things — a set of reusable building blocks and a uniform API for language-oriented handle-based models. Three things, actually. I forgot to mention out-of-the-box integration with the Xtext editor.

What does it mean in practical terms? A detailed system overview and an exemplary implementation will follow as part of the initial contribution, but in a nutshell, you should specialize (via inheritance) the system-provided interfaces and abstract classes for model elements specific to your language, override/implement a few methods and provide the necessary model plumbing (using supplied building blocks) such as the model’s cache and the delta processor. Of course it’s not that simple as it may sound from this description, but in the end you’ll get a full-featured handle-based model not unlike the Java Model in its essential qualities (functional and non-functional). And if your language happens to be Xtext-based, you’ll also get an automatic asynchronous reconciling of your model (with corresponding notifications) when typing in the Xtext editor; it’s just a matter of a few bindings in the Xtext UI module for your language. The initial contribution will include an example of a full-featured Handly-based model for a simple Xtext-based language, complete with automated tests, content outline and a CNF-based navigator view.

Furthermore, your Handly-based model will be accessible through a uniform API, which can potentially be leveraged by a multi-language IDE infrastructure in the future (for example, it could be used by a common outline framework).

Now, that’s just a vision and an initial contribution. Making this a real success requires bringing the IDE community together, breaking down the project silos and, last but not least, your help. Spread the word to people you know who might be interested. If you have not yet read the proposal, perhaps it’s a good time to do it now. Please send all feedback to the Eclipse Proposals forum — it’s the official communication channel. The forum topic for the proposal contains a short FAQ that you might find interesting too. If you’re even mildly interested in the proposed area of work, I ask you to join the developer mailing list as soon as the project is created. We are open to everyone’s input. Especially welcomed to contribute and join the ranks of the project’s committers at their earliest convenience are folks with significant experience in handle-based models. Seasoned Eclipse-based language-tooling developers, you are very much invited! It might be an excellent opportunity to come together! I expect a lot of fun down the road!

UPDATE: The project has been created and the initial contribution made available. Please send all feedback through the project’s official communication channels.