20
Jan 12

Dr. Zef

Last week Wednesday I successfully defended my PhD thesis. Therefore, I am now officially a doctor. I was a little nervous, because you don’t know in advance what questions will be be asked during the defense. However, it was a very nice, friendly defense.

You can download my thesis as PDF, though I must warn you: it’s a page turner!

Domain-Specific Languages (DSLs) are programming language aimed at a particular problem domain, e.g. banking, database querying or website page lay-outs. Through the use of high-level concepts, a DSL raises the level of abstraction and expressive power of the programmer, and reduces the size of programs.

This dissertation covers various aspects of the design and implementations of such DSLs. Throughout the project, two DSLs were developed: WebDSL, a language for rapid web application development, and mobl, a DSL for mobile application development. Using these two case studies, the dissertation explores the design space, as well as techniques developed to implement the compiler and IDE for such DSLs.

The general design principle applied is syntactic integration and separation of concerns. Rather than using a number of DSLs to build a single application, our approach is to develop a single, integrated DSL that can be used to develop the entire application, while still enabling clear separation of concerns. The result of this integration is static verification — the ability to instantly be notified when your program is inconsistent, without having to run it.

The dissertation covers five aspects of DSL design and implementation: (1) Verification, the ability to verify applications written using the DSL; (2) Coverage, how to ensure that a DSL enables its user to express what he needs to express; (3) Abstractions, the use as well as the definition of abstractions in a DSL; (4) Code generation, techniques for efficiently generating executable code from a DSL; (5) Portability, the ability to generate code from a DSL that is runnable on multiple platforms.


29
Dec 11

Reality Distortion through Text

One of Steve Jobs’ most amazing traits was the ability to “invoke” a reality distortion field. He did it many a time. He went on stage, pitched his new product and even though you didn’t need it at all — you’d feel deep inside that in fact you really did. You had to have it.

According to his biography, Steve did this in many aspects of his life. Not just on stage, but also during meetings and even with his disease. In the later case that did not work out so well.

I always wondered — what is the essence of this distortion field? Could I do that, or is it Steve-specific? Does it require you hearing him, seeing him, or could he do the same thing through text? Yeah. Would it be possible to convince somebody of about anything as long as you would pitch it the right way in text, online? Is it about the pitch, or is it more than that? Can you somehow perfect a writing style that does that?

Since then I made an attempt or two, of really working on pitching an idea just right. Perfecting it in every possible way. Attempting to describe it in such a way that you simply could not disagree. And I think, at times, I did pretty well. But then I found out the reality of an online audience.

They don’t read this far. TL;DR.


28
Nov 11

Blog Activity

Although it’s quiet here, I’ve been putting down a fair amount of words on the Cloud9 IDE company blog recently. For your reading pleasure:


04
Sep 11

Everything “In The Cloud”

Here’s what I use my computer for:

  • Browsing the web
  • Email
  • Twitter, Facebook, …
  • Listening to music
  • Watching video
  • Chat/call/skype
  • Developing software

I realized that all of these take place “in the cloud” (distributed on multiple servers across on the internet) today. There’s very little vital data that I still store locally on my harddrive.

Browsing the web, email, twitter, Facebook is all online, all this data is in the cloud. I do most of my music listening on Spotify, which also stores my playlists, and have my iTunes Music directory backed-up on Dropbox. Recently I have been uploading almost all my documents to Google Docs as well as some video content (which I can now stream from my Docs account). Chatting and calling is also all online, using Skype, IRC and Google Talk.

Last Thursday I started my job at Cloud9 IDE, Inc. who build the Cloud9 IDE — which, you guessed it, enables you to develop software in the cloud.

I think I can truthfully say that if my laptop breaks down right now, it really wouldn’t matter. I wouldn’t lose any important data.

None.


04
Jul 11

Plus

Don’t want to show off or anything, but I’m on Google+ so follow/encircle me if you like!


29
Jun 11

State of Code

In case you hadn’t noticed: I have launched a new site: StateOfCode.com. Another site? Indeed.

Whenever I write on zef.me I feel it has to be personal somehow. It’s all about me, right? Hence the name :-) I’m not going to report on “news”. I’m not going to do interviews. Who would participate in an interview for somebody’s personal blog?

And yet, I’d like to do those things. I feel there is a lot of interesting stuff going on in my field of interest: programming languages, frameworks and other developer tools — stuff we can never learn enough about. I have found that simply e-mailing a person involved in such a project, asking them questions is a great way to extract this information: “You seem to be passionate about x can you let us share in your enthusiasm?”

It turns out most people are actually friendly and want to answer your questions — they would like to share their interest.

This, combined with the latest “programmer’s news” is what I aim StateOfCode.com to become. It makes it possible to get other people to help me out on the site some day (anybody interested?). And since the site has been online barely two weeks, and already had about 6,000 visitors — it looks like a promising endeavor.

So far I’ve published two interviews. One with Bruno Jouhier on streamline.js , and another with Manuel Simoni (of the great Axis of Eval blog) on Lisp. There’s another interesting one queued to be published next week, and a few more people have agreed to participate. But there is room for opinion pieces as well, Are Web Apps And Insult to Users got a fair amount of response.

Anyway. It’s a new project and I’m enjoying it. Want to help out? Write posts, have tips? Know people I should talk to? Email me or contact me on twitter.

Be sure to follow @stateofcode on twitter as well (or me, new posts are pushed to both twitter accounts).


29
Jun 11

+


19
Jun 11

Bye Bye File System

I don’t want to deal with files and directories anymore.

A few weeks ago I bought IA Writer for Mac (thanks Stephan!) — the most basic text editor one could imagine. Its goal is to facilitate distraction-free writing. Before being turned into a Mac app, it was a successful application on the iPad.

As you are likely aware, iOS apps don’t expose file systems. When you open an app like IA Writer you can immediately start typing, either in a previously created document or a new one. As a user you don’t have to deal with directories or file names, meaning you don’t have to make two choices:

  1. What am I going to call my document?
  2. Where am I going to put it?

You may think it’s silly, but those two choices seem to considerably reduce my “barrier to entry” when it comes to creating a new document. When I want to create a new document I don’t care what it’s called or where it’s stored, I just want to enter content.

As it turns out, IA Writer for Mac does not mirror this paradigm. I can start typing immediately, but it doesn’t save content automatically and to save it… you guessed it: you have to choose a file name and location to store it. I have found this really reduced my pleasure of using IA writer — it’s not purely about content anymore, I also have to worry about keeping things tidy. Is this file name descriptive enough? Can I really store this in my Documents directory, won’t that pollute it? Stuff I really don’t want to be bothered anymore. I’ve been spoiled. The same thing goes for other applications too: Keynote, Eclipse, graphic editors. The file system is a pain.

It’s not just mobile where the file system has disappeared. The web has largely got rid of it. Google Docs don’t have file names or directory names. Neither do Gmail or calendar. Files and directories are a major distraction.

As far as I’m concerned, the file system is dead. If I’m looking for something, I’ll open an app and search for it. Get those directories and files out of my face.

(This was written in a unsaved IA Writer file.)


17
Jun 11

Ars’s Duke Nukem Forever Review

I’m not a gamer. Nevertheless, like many, I have been fascinated with Duke Nukem Forever as the prototypical example of vaporware. It’s been in the works since 1996 and never seemed to be released. A few days ago, finally, it has been.

Although it looks like it would have been better if it was never released at all.

According to the Ars Technica review it’s a pretty horrible game. Not just bad — but bad:

In the first few moments of Duke Nukem Forever, your character pees in a urinal and then earns an achievement for reaching into a toilet and extracting a piece of human excrement. Why does the game reward you for doing this? I have no idea. It’s not part of a joke or important to the story; the designers of the game apparently feel that you would miss out by not holding some poo in your virtual hand.

But infantile humor is not the worst. The game appears to contain rampantly offensive story elements.

Ars Technica:

Just in case you didn’t feel like the game had adequately rubbed your nose in its horrific depiction of women, Duke arrives at a point where two nude ladies promise to lose their pregnancy weight from bearing their alien children, and they plead with you to let them live. (These are the same characters who performed fellatio on you during the beginning sequences of the game.)

The only way past this section of the game is to kill both women.

That’s just poor, poor taste.


10
Jun 11

Web vs. Native On Mobile: The Never Ending Struggle

It seems to be an everlasting battle: what’s “better”: developing mobile native applications or developing mobile web applications? Sadly, the answer is boring: it depends.

What matters to you as the developer?

Multiple-platform support. Web applications are a cheap way to go. Develop your application once, run on many platforms immediately. You can reuse the same code base on multiple platforms. When going the native route you will likely have to entirely redevelop (and maintain) your application on every platform.

Quick iteration. Iteration can happen quickly on the web: simply deploy a new version and all users get it instantly. Deployment of native applications requires an explicit update action from the user, plus a (possibly lengthy) approval process on some stores (e.g. Apple’s AppStore).

Integration with the OS. Web applications can do less than native applications. Need access to the camera, file system, address book, notifications (or even extend those features)? That’s a no-go for pure web applications (at least, for now). However, you can wrap your web app using PhoneGap to get access to many of those APIs as well, the drawback is that you lose the advantage of being able to iterate quickly, because you have to deploy your applications through app stores.

What matters to your users?

Performance. Web applications are typically slower than native applications. Of course, it is possible to write extremely slow native applications, but assuming good development practices: a native application will always outperform a web app. That’s the way it is, that’s the way it will be. However, on the long term, the performance of native and web apps will converge. The question is: what are your performance requirements? Is a web application fast enough?

Native look and feel. By default, a web application is not going to have a native look-and-feel. You can get quite far in mimicking a native look and feel (e.g. by using similar colors, similar transitions), yet — very likely — your users are going to be able to notice the difference. I have yet to see a web app where I couldn’t notice it was not native. The question is: does it matter? How important is it that the user notices a difference? Take the Gmail mobile web application, for instance. It doesn’t look native, but it looks clean and it works well. Does it bother me it’s not a native application? Not enough not to use it. I prefer it over Apple’s native mail application because I choose functionality over looks.

User experience. The way the user interfaces are laid-out and operated differ slightly from platform to platform. Although iPhone and Android appear to be extremely similar, there are subtle differences in how the user interfaces are organized and operated. Android makes use of the touch screen, as well as three (hardware) buttons: back, menu and search. No such buttons exist on iOS. The back button is typically an on-screen button, but the idea of a pop-up menu is inherently non-iOS-esque. For web applications this is a problem. First of all, a web app cannot take advantage of additional hardware buttons (other than the back button), but beyond that, you will likely not want to redevelop the way your UI is laid-out for every platform. Thus, you have to come up with some sort of greatest-common denominator: pick the user interface elements that all platforms support and use those exclusively. Is that a problem? Depends who you ask.

So…

Even though I develop mobl (a language for mobile web application development) I’ll be honest. As user, if I could choose between a web app and a native app, having the same feature set, I would go for the native one. However, from a developer’s perspective it’s a much more difficult choice. It completely depends on target audience (what do they care about, what devices do they use?) and specific requirements of the application (do I care about performance, do I need OS integration?).

And I haven’t even touched on development models and tools yet.