Arthur van Dam just created this nice picture, with a clear statement, for me:
It's going to be featured in our discussion of Growing Languages with Metamorphic Syntax Macros, this Tuesday as part of the Software Generation and Configuration course I mentioned before. Thanks Arthur!
Last week I changed the look of my homepage (which is a Wiki) to a style derived from Blogger's Rounders 3 template, which was designed by Douglas Bowman. Of course, I wanted to change the look of my blog as well; what you see now is the result of this. I hope you like it. As you can see, I'm fond of the combination of shades of blue and gray ;) .
The sources of my blog template are available from my Subversion repository. The sources of the Wiki skin for my homepage are there as well. Feel free to use it.
Yesterday, I read the article "Towards a New Model of Abstraction in Software Engineering" by Gregor Kiczales. We are going to discuss this paper tomorrow (Thursday) in our master seminar on software generation and configuration. I'm not really convinced that aspect-oriented programming (as it is currently implemented in AspectJ) is the way to go, but this earlier article is brilliant!
The problem with abstraction is very well described: abstractions cannot hide their implementations. The need for a separation of meta-level interfaces from base interfaces is entirely clear after reading this paper. The papers immediately reminded me of The Law of Leaky Abstractions. The law introduced in this excellent article by Joel Spolsky is cited quite frequently. However, the credits for identifying this problem (and suggesting a solution!) should go to this article by Gregor Kiczales. I think that many of the ideas expressed in his article are still not realized and researched thorough enough.
Another interesting thing to note is that annotations and attributes as they are available in C# and Java are not really that novel. Until now, it was unclear to me where the idea of attributes in C# actually came from. I think other people have this problem as well, since the idea of adding attributes to source code is often described as being truly novel. After reading more about metaobject protocols, it seems that annotations are nothing more than what was already available in the earliest MOP systems. Why has this link never been explained? Or did I miss something?
Next week we're going to OOPSLA and GPCE! I'm going to present our paper Concrete syntax for Objects at OOPSLA. I'm really looking forward to the conference and the talk, although it is a little bit scary to have your first conference talk ever at OOPSLA. I'm going to prepare this talk in the coming week, so get ready for MetaBorg posts ;) .
We're also going to the Software Transformation Systems workshop. I expect that this is going to very be interesting: quite some transformation system researchers will be there.
Today, I gave a lecture on the concept and techniques of component-based software engineering as part of our software engineering course. The lecture is divided in two parts: concepts of component software and the implementation of these concepts in current platforms (Java and .NET). I hope the students liked the lecture; at least I had a lot of fun myself ;). Preparing a lecture from scratch (which was the case) takes a lot of time, but it usually provides some fresh ideas for stuff that we could do for our 'real work'.
For lectures like these, you get to read material that you wouldn't consider if you would only focus on academic stuff (Essential .NET and Component Development for the Java Platform are great books!). About two weeks ago, I gave a lecture on testing tools and techniques. The preparation for this lecture (and today's one as well) provided me with some more insight in the use of reflection for meta-programming. Concerning testing, it's particularly interesting to see how people work around the poor support for implementing tests in current programming languages. In particular, mock objects (EasyMock is impressive) and dynamic proxies were useful to learn more about.
Sean McGrath has posted a nice set of slides (ppt) that he used for his presentation on XML pipelining at XML 2004. Sean is more or less the pipe guy of the XML community, which is an honorable position. Most interesting is his slide (nr 4) on API components versus data-flow components. Unfortunately, I don't know exactly what he said about this slide (I wasn't there), but he must have raised some interesting points.
The last few decades have made clear that data-flow components never go out of fashion. In particular, the only really successful component model is the idea of pipes and filters of Unix. Unix components can easily be composed; they can be implemented in any language and they are suitable for anticipated (e.g. shell scripts) as well ad-hoc (the command line) composition. API-based component models tend to be language, or at least language family, specific. Hence, components relying on such a component model are coupled to a language or platform. As a result, they go out of fashion. This doesn't make API-based component models useless, but components based on such a mechanism just don't last. Over time, components will have to survive in a heterogenous environment, since fashion changes while time passes by. In this way, the Internet is comparable to time. If you want to connect components in an heterogenous environment, then language specific solutions just don't work. Your current environment is the Internet, which is quite heterogenous.
bin
directory of my StrategoXT installation contains 96 executables
and the libexec directory adds 93 tools to that. That's
quite a pile of tools, and this pile is a big problem for new
users: how to learn all these tools? What command-line arguments
do all these tools need?
To make things worse, many of these tools do not only take input and produce output, but they are also generic and need to be specialized with some configuration for a specific programming language. This idea has been explained in the article Grammars as Contracts. The syntax definition of a programming language can be used to configure these generic tools in the typical pipeline of a program transformation. In this way, the grammar is used to specialize these tools to language specific tools. The disadvantage of this approach is that all these tools need to be configured and that this configuration is not just the syntax definition, but for example a parse table, a pretty-print table, an abstract syntax definition, and so on. Users need to know all these file types, tool, and their configuration.
We are all aware of this issue, but for some reason we never really tried to solve this, except by adding more abstract and easy to use tools. In a discussion with Karl Trygve Kalleberg we realized that this really needs to be improved, since StrategoXT users now need to apply far too many tools for generating all the configuration files required for a basic source to source program transformation:
pack-sdf, for collecting a set of SDF modules into
a single syntax definition.
sdf2table, for creating a parse table.
sdf2rtg, for creating an abstract syntax
definition.
rtg2sig, for creating a Stratego signature
(abstract data type declarations for Stratego).
ppgen, for generating a pretty-printer.
Obviously, this situation cannot be explained to new users. They
have to new all these tools and the file types they operate on
(.sdf, .def, .tbl, .rtg, .str, .pp). Having all these
tools and file types is not really a bad thing, but we provide no
mechanism to abstract over these tools and files. Karl
came up with a very practical solution to this problem (he also blogged
about it). We need a single tool: xtar that applies
all these program and produces a single file: an XT archive
(.xtar). This archive can be passed to all the tools
in StrategoXT and they just take out all the configuration files
that they need to do their work. So, the user no longer needs to
know all generators of configuration files and he doesn't need to
know all these file types as well. This is a huge improvement for
new (but also experienced) users. We hope to implement this as
soon as possible! A little bit more information is available
at the Stratego Wiki
The xtar file and tool are a good example of encapsulation: instead of exposing the internal implementation of our tools, we now just expose the concept an XT archive for a language. In this way, we can also change the implementation details more easily, which used to be quite difficult in the past. It is interesting to see that this idea corresponds exactly to widely applied object-oriented design techniques. Why haven't we learned from this earlier! Maybe we should apply more design patterns to our set of command-line tools?
Yesterday Karl Trygve Kalleberg returned from his trip to the LASER Summer School on Software Engineering (Elba!) and Norway. Having Karl in Utrecht is really great. He is (over?)loaded with fresh ideas for improving our software and he's always ready for a good discussion.
Yesterday, he convinced me to start blogging. That wasn't too difficult, since I love weblogs. It's truly amazing how many bright people are communicating their ideas and thoughts in their weblogs. This is not limited to the famous guys in the computer industry and blogging scene (such as Patrick Logan, John Lam and Sean McGrath). Less well-known bloggers write very interesting and well-phrased stuff as well. For example, Zef Hemel (a student at the University of Groningen, The Netherlands) maintains a very good weblog. Almost every day he adds an interesting story, straight from his mind. Isn't that great?
This network of bloggers is incredibly powerful. You are no longer thinking for yourself: the blogging scene is a hive mind that spreads knowledge at a faster pace than ever before (at least for software development). I'm a PhD student specialized in software technology, so I'm part of what you might call the research community. What surprises (and maybe disappoints) me is the limited the number of researchers that are blogging. If blogging is such an excellent medium for spreading knowledge, then why aren't we part of it?