Archive for Work

First Paper Accepted

This morning we got an e-mail saying that our paper entitled “Code Generation by Model Transformation. A Case Study” has been accepted to the International Conference on Model Transformation ‘08. Which means that the first paper I co-wrote will be published! The paper is about the implementation of WebDSL and the two dimensions of modularity that we applied to organize the WebDSL generator and make it extensible.

The paper will be presented in Zurich, Switzerland this July, I’m not sure who of the three of us will be there. We’ll see.

Update: Abstract: The realization of model-driven software development requires effective techniques for implementing code generators. In this paper, we present a case study of code generation by model transformation with Stratego, a high-level transformation language based on the paradigm of rewrite rules with programmable strategies that integrates model-to-model, model-to-code, and code-to-code transformations. The use of concrete object syntax guarantees syntactic correctness of code patterns, and supports the subsequent transformation of generated code. The composability of strategies supports two dimensions of transformation modularity. Vertical modularity is achieved by designing a generator as a pipeline of model-to-model transformations that gradually transforms a high-level input model to an implementation. Horizontal modularity is achieved by supporting the definition of plugins which implement all aspects of a language feature. We discuss the application of these techniques in the implementation of WebDSL, a domain-specific language for dynamic web applications with a rich data model.

Superlanguages

Imagine a language that can be both generic and domain specific. A language that is extensible is every way imaginable. You can define your own syntax. You can extend the type system. It would be a kind of, a kind of… superlanguage!

In short this is what XMF is. And yes, as I typed that name I mistyped it as XML, but do not worry, it has nothing to do with XML, thank god. You can download a free book on the XMF superlanguage. I’m reading it now. It’s not just for fun for me, it’s work — it’s an alternative approach to building DSLs which needs to be investigated. That’s what we, scientists do.

That, and make the world a better place. With super languages for instance.

“Don’t Model Everything”

From different directions I received links to Steve Yegge’s post “Portrait of a N00b” and although the length of it certainly qualifies it not to be read by me, at a certain point you just give in.

Now Yegge’s post is long, read it during your lunch break or something. This is my 100-words-or-less summary: new programmers are metadata obsessed and as you grow older (10+ years or more programming experience) you start to see that metadata (such as comments and excessive modeling) is not the answer to all problems in life.

The picture of Heidi Klum at the right is completely unrelated to this post by the way, except for the fact she’s also a model (and often objectified) — and not everything nor everyone has to be a model. There’s some random wisdom for ya.

Anyway. Some quotes I find relevent to my work:

And Haskell, OCaml and their ilk are part of a 45-year-old static-typing movement within academia to try to force people to model everything. Programmers hate that. These languages will never, ever enjoy any substantial commercial success, for the exact same reason the Semantic Web is a failure. You can’t force people to provide metadata for everything they do. They’ll hate you.

One very real technical problem with the forced-modeling approaches that static type systems are often “wrong”. It may be hard to imagine, because by a certain definition they can’t be “wrong”: the code (or data) is programmatically checked to conform to whatever constraints are imposed by the type system. So the code or data always matches the type model. But the type system is “wrong” whenever it cannot match the intended computational model. Every time want to use multiple inheritance or mixins in Java’s type system, Java is “wrong”, because it can’t do what you want. You have to take the most natural design and corrupt it to fit Java’s view of the world.

[…]

Java has been overrun by metadata-addicted n00bs. You can’t go to a bookstore or visit a forum or (at some companies) even go to the bathroom without hearing from them. You can’t actually model everything; it’s formally impossible and pragmatically a dead-end. But they try. And they tell their peers (just like our metadata-addicted logical data modelers) that you have to model everything or you’re a Bad Citizen.

I feel I should respond to this, because it seems to be a direct attack at the work that we are doing. Are we the part of the “static-typing movement within academia”?

We do like static typing. WebDSL is fully typechecked. And we do force you to model everything. I’m not so sure this the kind of modeling that Yegge refers to here though. In my view there are two kinds of modeling:

  1. Modeling as a means to organize the software (directories, libraries, modules, classes, methods) — this is what I think Yegge refers to
  2. Semantic modeling (in WebDSL: entities, pages, actions, access control rules) — this is what we try to do

The first one you could argue is not always absolutely necessary. Your software works just as well when you dump everything in one directory and one namespace or even class (why else would there be such a thing as a God class?). The second kind of modeling is what we attempt to do. The win in this kind of modeling is that we can write software that actually “understands” these models and can do clever things with it.

You should really avoid abusing models for means they were not intended for, as Yegge points out. Often you can achieve a lot with clever tricks, but what should really be done is extending the meta-model. Meta-wha!? Extending the programming language, essentially. In Java this is not really possible, of course. The compilers we build for our modeling languages (such as WebDSL), however, are designed to be (relatively) easy to extend so that if you cannot model something, it is easy to extend the language to add construct that make modeling of it possible, or at least simpler.

The third point from Yegge’s quote is about how you cannot model everything. That is probably true, so in the future we will work on “back doors” within our modeling languages to lower-level languages such as Java. So that if there is something you cannot model, and it is really not worth extending the language to add a modeling mechanism for this, you can just quickly hack it in Java, or whatever the target language may be.

Google Scholar’s Killer Feature: BibTeX Exports

For my research I use Google Scholar quite a bit. It works reasonably well, although I would like more control over the results I get (like ordering them by date published). Last week, however, I found the killer feature:

As many, I use LaTeX to write papers and BibTeX for keeping track of papers I cite. The annoying thing is it is often hard to get the information about papers (title, authors, conference, years etc.) in BibTeX format. Now, it turns out Google Scholar offers this as a feature, it’s hidden, but it’s there. Go to your preferences and check the “Show links to import citations into BibTeX” radio button as shown above. Then, with every article result in Google Scholar you find:

I know, this is the kind of thing I get excited about these days. You can laugh, but I at least still appreciate the smaller things in life.

Compiling…

I got some time for blogging again. Why? Because I’m doing some development of our WebDSL compiler again, or rather, debugging. And as compiling this thing takes like 2 minutes, I got more time to write. Great way of keeping posts short.


(source)

Ok, the two minutes have passed.

Phew… First Paper Submitted

After a few weeks of hard work our first paper is finished. We submitted it to the International Conference on Model Transformations ‘08. In March we’ll hear if it is accepted or not. I won’t go into details about what we wrote about exactly (not quite sure what I can say and what not), but it’s a paper about how the WebDSL generator is constructed.

Did you notice that link just now? I linked to webdsl.org, that means that we launched the first alpha! The reason I didn’t post about it before is partly lack of time, but mostly because I don’t feel it’s ready for prime time yet. It really is an alpha. We have some performance issues (the site can be quite slow, especially when you’re logged in) and the behaviour of WebDSL models can sometimes seem unpredicatable if you’re not that familiar with it. Plus, there’s hardly any documentation. Oh, and installing it works mostly, as long as you use the Nix package manager to do so, which — I am very aware — is not nearly mainstream (but also not that hard to install). I was working on whipping up some debian packages, but had some trouble on the way. Either way, if you feel like trying it, go ahead. This week WebDSL is taught as an example DSL for the program transformation course that is taught here. I’m sure documentation will improve then and we’ll most likely find loads of bugs.

Assembly Language of the Web

I was watching this video interview with Dion Almaer of Google and it reminded me of a view that I have, and that I think is shared within the WebDSL team. It might be controversial, maybe it’s not. The view is that we see (X)HTML, CSS and Javascript as the assembly languages of the web. I feel that, although coding HTML, CSS and Javascript was fun for a while — we can do better. What you’d want is a higher-level language (be it WebDSL or GWT or whatever else) that abstracts from those low-level languages. I think there are better languages to be designed that can be compiled to a combination of those three.

GWT is the most mainstream implementation of this. You feed it Java code and it produces HTML and Javascript. We do the same in WebDSL (although we did not base it on Java). Web development is hard, and frankly, annoying because you have to deal with differences in browser implementations, browser versions and so on. All stuff you don’t care about. The solution is to abstract from that, and come up with a language + compiler that generates the browser-dependent code for you so you can focus on the problem at hand rather than spending 2 hours fixing the lack of support for CSS’s a:hover in IE 5.5 (or whatever, I don’t know zip about CSS).