Sure. There’s been ups and downs in the volume of posts that appeared here. At some point I managed to post once every single day for a year. For the past few months it’s been quiet, at least on zef.me. But I still blog — more on other websites. Little over 1,600 posts in 9 years.

Next year requires a more extensive celebration.

You don’t need a full-blown IDE for web development

and

… you can’t go wrong with TextMate. It’s easy to use, convenient, and extensible. Plus the syntax highlighting blows everything else out of the water.

I wonder. What happened the past few years?

The 90′s and 00′s were the golden age of IDEs. No longer did you have to use plain text editors that did nothing but paint your code in colors. No longer did you have to use a command-line based debugger. No longer did you have to open up a reference manual to see what arguments that one method takes or how it works. No longer did you even have to remember what methods a string object has. No longer did you have to do Find & Replace refactoring.

But today, IDEs got a bad rap.

Since the growing popularity of dynamic languages, people seem to get the idea that IDEs are only required for those bloaty old languages like C# and C++ and oh-my Java. IDEs are, general perception seems to be, bloaty pieces of software. Resource hogs. Slow. Badly designed. Not cool.

So, the current generation of programmers — you, most likely — seems to have moved away from the languages typically associated with IDEs. You use cool languages, like Ruby, Python, PHP and JavaScript. And cool languages don’t need no IDE. You’re pretty happy with your simple, basic text editor.

Your language don’t need no code completion — you can keep the entire API of your application in your head. You don’t need no refactoring — you no longer make design mistakes. You don’t need no debugger — because, there’s no more bugs in your software, and console.log ought to be enough for everybody. You don’t need constant analysis of your code and clearly marked warnings and errors — you’ll find the mistakes you made when it is time. You don’t need integrated API documentation — you know everything there is to know already.

But perhaps there is still a lot of opportunity for doing amazing stuff in the IDE space. Maybe an IDE can be very useful. Cool. Great. Even for dynamic languages.

Yeah — maybe.

The video of my live coding is not always super clear, but I think it gives a good, albeit brief, introduction to my work there anyway. To play with treehugger.js (as I did during the talk), you can use the treehugger.js playground.

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.

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.

• Towards JavaScript Refactoring
• Never Commit to your Master
• Effective Code Editing with Cloud9
• The Time has Come to Add Classes to JavaScript
• Complete Your Code

• 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.

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).

• Official Google Announcement
• Behind the scenes post by Steven Levy
• While We Await The Native App, The Google+ iPhone Mobile Web App Is Pretty Solid

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.)

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.

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.

Starting September 1st I will be employed by Ajax.org, the Amsterdam based company that is developing Cloud 9 IDE — not to be confused with the similarly named Amsterdam-based soccer club.

Why an IDE in “the cloud”?

During the past decade more and more of the stuff we do every day has moved online: e-mail, word processing, spreadsheets, chat, collaboration tools. The obvious next — almost inevitable — step is to move the IDE (Integrated Development Environment) to the cloud as well. Exit Eclipse. Enter Cloud9.

A few (potential) advantages:

• Your code is accessible anywhere, from any computer, but also mobile device: iPhone, iPad. Just point your browser to a URL and off you go.
• No complex tool setup. It’s typically very difficult to properly install your IDE (e.g. Eclipse) with all the plug-ins, web servers etc. A Cloud IDE makes this simpler, just point your browser at a URL and everything just works: testing web servers run in the cloud, deployment is simple etc.
• Real-time collaboration with team members: remember Google Wave? Imagine collaborating on a single code base with many developers. Great for pair programming.

An IDE implemented in Javascript is now possible because Javascript speeds are rapidly improving. If you try out Cloud9 right now you’ll see it is very snappy already. Another often heard criticism is that you cannot use web apps when offline. Cloud9 will soon feature offline support allowing you to work, even without an Internet connection.

Why me?
I have been working for the past 4 years on code analysis tools and compilers. I implemented a language from scratch, covering both the compiler side, as well as the IDE side (error checking, code completion etc.). The group that I’m doing my PhD in has a lot of experience with developing such tools, and I will be leveraging much of that knowledge to build a language infrastructure for Cloud 9, enabling others, as well as Ajax.org itself, to easily build great language support for any programming language, including features like inline error highlighting, code analysis, code outlining, code completion and refactoring. Recently a lot of my work has been in Javascript, so I know the language pretty well — which is useful, because Cloud9 is almost 100% built on Javascript, both on the client and on the server (they use node.js).

Initially, the focus will be on dynamic languages, starting with Javascript, but rapidly adding other languages as well — hopefully resulting in an infrastructure that anybody can use to build Cloud9 support for their language of choice. I have done some preliminary work on this with treehugger.js, a language processing library written in Javascript. Treehugger.js intends to be the jQuery of AST transformations, borrowing a lot of ideas from Stratego/XT and the ATerm library (both of which I have been using for the past years, and represent the state of the art in program transformation and analysis tools). I’d like to look into other options as well, such as attribute grammars — anything to simplify language analysis, helping the developer to do their job more efficiently.

There are some Javascript analysis tools already (including Zeon.js, DoctorJS, JSShaper and of course JSLint, the latter already being integrated in Cloud9). We have to see if we can integrate, collaborate or borrow ideas from these tools for Cloud9.

What about mobl?
Ajax.org is interested in mobl. We have yet to see what role it will play in the company as well as in Cloud9. There are several options there. All I can say is: don’t worry, mobl is not dead :)

Weren’t you moving to Poland?
Indeed I am! I will be working on site in Amsterdam for the first few weeks and then move to Poland (Poznań to be exact) and work remotely. Ajax.org has more employees distributed around the world and this will become even more the case in the future. This shouldn’t be a problem, as they are developing a product to make this easier after all.

Anyway. This is still a couple of months ahead. First I have a PhD thesis to finish up.

I’m not much of a gamer. Generally I find it somewhat of a waste of time. Yet, millions of people do not seem to agree. Online RPGs such as World of Warcraft have tens, if not hundreds of thousands of players. They spend hours a day walking around in a virtual world, completing virtual quests, collecting virtual items and fighting virtual enemies. I always wondered why people would do this. Is the interesting angle the social component? It’s kind of cool that you’re not alone exploring this world, there are others as well that you can interact with, team up with and trade with.

I found the whole Aralon experience oddly satisfying. You kill bad guys, help people with their problems, earn money with which you can buy weapons and these thing. You get more experienced and learn new skills along the way. It’s almost like leading a small second life, except more quantifiable and more fast paced.

Still, I find a bit of a shame that you have to sit inside behind a computer screen to play this. I’m aware of LARPs (Life-Action Role-Playing Games), but I find those a bit extreme. Not everybody wants te dress up as a warlord of some kind. I definitely don’t want to.

What if we could turn this into a casual, augmented reality, location-based game, played on our mobile phones?

Rather than virtually running around in a virtual world, you physically run around in the real world. Your neighborhood, your city, other cities, other countries even when on holiday. Based on your actual location you would receive virtual quests on your phone. “You see a boy crying on X street, he lost his dog. Can you find it for him?” Accept. Walking around the block you see on your phone the dog is nearby. You pick it up (virtually of course, you don’t know where the creep has been), return to the boy’s location, return it to him and get some reward in return.

You “see” a runner nearby, challenging you to a run around the block. You accept, win and earn some more money. Using these rewards you can go to the (virtual) merchant around the corner to get a cool looking t-shirt that other players can see on their phone when they’re nearby. Or a set of electric binoculars to temporarily see farther away (allowing you to see, and pick up items that are farther away from you). Quests could involve nearby players involving actual real-life interaction.

The advantage over pure-virtual RPGs? You actually get exercise walking around your town. You actually meet real people. Real stores and restaurants could offer real discounts in exchange for some quest. It can be used for education as well. For instance, a zoo may develop quests to teach players actual things about actual animals requiring them to walk around the zoo, observing animal behavior, answering multiple-choice questions, earning them a special “animal observer level 1 achievement” that every other nearby players and friends can see. Companies may hand out virtual stickers you can make part of your virtual image. Cities and towns can develop tour guides as bots and quests. Virtual items may be traded with other players.

I think such a game may be a very interesting competitor to many location-based services like foursquare, where you check-in and earn badges — and that’s it. Actually turning it into a real game would be much more engaging I would think.

Technically such a game is not very difficult to develop. The server maintains a database of players, their items, ongoing quests and their locations; bots and some representation of their quests and instances of those bots all over the world; items that lie around, with associated value and uses. It’s essentially just a big database of locatable things and some algorithms to ensure there is something to do wherever there are players. A mobile client then simply asks “give me a list of nearby things” and enables the interaction with those things.

The big challenge would be the development of content. Virtual worlds are large, but the actual world is a lot larger. How do you augment the entire world with items and quests? Initially, an approach could be to develop a large collection of generic quests that can be instantiated on demand in different locations. Boys can lose their dogs all around the world, can they not? People can ask you to deliver messages and runners can challenge you to a duel no matter where you are in the world. Technically, if you log on to the game such quests could be instantiated dynamically if others are not available.

Subsequently, for major cities, companies, sights, zoos and museums, custom quests can gradually be developed. Potentially by these companies, sights and cities themselves.

Maybe it would be possible to crowd-source the writing of quests, run it as an open source project of some kind. Although one would have to come up with a sparse way of giving out rewards to avoid “push this button to earn $10,000.” Another way could be to let players act as quest-givers, letting other players perform real-life quests for them where rewards are taken from the quest-giver’s personal “account”.

It surely would be an interesting experiment, would it not? Has this never been tried?

In addition, a Devnology podcast has been published interviewing me about mobl, WebDSL and model-driven engineering in general. You can listen to that here. It’s about an hour long.

But beyond that, where I can spend a paragraph not really saying anything profound, not backing up my statements with references. Writing for the sake of writing… Know what I’m sayin’?.

Anyway.

Two weeks ago I bought the Motorokr S305 stereo bluetooth headset.

There she is. Isn’t she a beauty, with the drop shadow and everything? Almost looks like an Apple product.

Just for kicks I won’t start with the problem statement, but rather with the conclusion: it’s pretty good, and you should get it, if you can, if you want to. It costs around $50 (I bought it for 45 euros), so not that expensive. It pinches my ear a little bit, but nothing unacceptable. My ears will just have to adjust, I suppose.

What it does is connect to my (i)Phone and play music, sound, make calls. Wirelessly. Bluetooth, you know. Sounds quality is ok for podcasts and audiobooks (which I use it for) and phone calls, not the bestest for super high-quality stereo surround music. Although it does support stereo, did I mention that?

And last but not least. The problem statement. I’m Dutch. I cycle. Over the past year and a half I have killed four Apple headphone cables because I had my phone in my pocket while cycling, the cable just slowly breaks until I lose sound in one ear. First this was covered by warranty. Now I have to pay the $30 something per headphone set myself.

Not good.

Solution: get rid of the cables. Get a bluetooth headset.

Podcaster allows you to subscribe, download and listen to podcasts directly on your phone. No need to sync with your computer anymore. Podcasts can even be downloaded in the background (after you switch to another application it keeps downloading). It really works well.

It costs under $2. Very much recommended.

iTunes link.

So, companies and governments around the world invest in software engineering research. Professors and PhD students are hired to investigate the problems and come up with solutions. The solutions are written up in academic papers and published to academic conferences. Academic conferences are mostly attended by other academics, listening to each other, collaborating, sharing ideas.

So much for the theory.

I myself am part of this system. I’m a PhD student, 3.5 years in. I have published papers, and I have attended conferences. When I submit a paper to a conference about 3-4 people peer review it and, ideally, accept it. It’s then published to conference proceedings, available in book-form, as well as online, typically behind a pay wall (downloading one of my papers individually costs around $10). Therefore, my paper readership is in practice mostly limited to other academics, whose universities pay big bucks to get access to conference proceedings.

When publishing to a conference, you also get to go to go and talk publicly about your paper for about half an hour. There will likely be a few dozen people in the room, half of which are typing away on their laptops.

The thing is, in our group, a lot of us build tools. The target audience of those tools, ideally, is not the academic world, it’s the software engineering world — not people talking or researching it, but the people doing it. That is, while we are writing papers for academics, we don’t really reach our target audience directly. Sure, indirectly, when your ideas are good, they may reach the mainstream one day. But that will likely be a matter of years.

I’m doing work in the programming language space — how many languages you use today came from academia? A few (a recent one is Scala), but most were developed in industry.

Why?

As it turns out building tools that are robust and reliable take a lot of engineering work. Research is only a small part of it, and that’s a problem because you cannot publish engineering work, you’re an academic, you publish research. All the time you spend engineering on your tools, you’re not spending researching and writing papers. Published papers are currency. I must add here that in our group they’re really good about these things, we get a lot of time to do engineering without a professor breathing in our neck yelling “publish, publish!” We are encouraged to build real, useable tools. Still, intrinsic in the system is that for an important part success is measured by publication count. My PhD thesis is to be filled with published papers.

What’s the result? A bunch of tools are out there that, even if you wanted to, you cannot even download, or if you can, don’t compile, and if they do, are not documented. Abandoned after the paper was published.

But I digress.

Beside publishing papers, I have a blog. Over the past years I published a few blog posts that were related to my work. Some of them ended up on the frontpages of programming reddit and hacker news and many of them were read more times in one day than all my papers together will likely be read over my life time. And the readers are programmers — exactly my target audience. Sure, some of these readers called me names — but I like to think I planted some seeds here and there. I believe that my blogging has done more in terms of “changing the world” than any of my papers (so far, at least).

I’ll give three examples.

1

A year and a half ago I published When Rails Fails, which was a small part of the related work research I did for this paper (have you read it?). My main message was: Ruby on Rails is not very forgiving when you make mistakes, you often get horrible error messages at runtime. Sure, I got half the Rails community taking a dump on my porch, but the blog article raised an issue: you should’t have to put up with this, the bar must be raised. Some people picked it up and were discussing solutions. Not sure if this changed anything, but it’s a start.

2

A year ago I published persistence.js: An Asynchronous Javascript ORM for HTML5/Gears, a post about a little Javascript library that I needed for what eventually would become mobl, but did not yet exist. persistence.js is more of an engineering project than a research project. There were some new-ish ideas, but basically it was just implementing an Object-Relational Mapper in Javascript. Nothing to write a paper about. Although persistence.js didn’t make a splash entrance, slowly but steadily a community grew around it, and today persistence.js it being maintained by about a dozen contributors and it expanded from the browser to the server, where Javascript is rapidly taking off with node.js. Recently I got a thankful e-mail from one the guys behind Readability who use persistence.js in their mobile application. No paper, but impact on the industry? A little, at least.

3

Lately, we have been struggling with mobl, the language for mobile development that launched this January. Interest in mobl is been pretty incredible since I built a reasonable website, started blogging about it, and wrote an InfoQ article. And thus I spent the past few months mostly fixing bugs, adding features and providing support the growing community of users. I gave a few talks about mobl, both in an academic setting and in industry and everywhere the feedback has been overwhelmingly positive. People are impressed with this stuff. Yet, the paper we wrote about mobl and submitted to a big web-related academic conference got rejected. “Where is the research contribution here?” they asked. Mobl is a nice mashup of programming language ideas, yet none of them are truly new. You may not have seen them all before, but that’s likely because they were published in academic papers, and who reads those during breakfast? Not me. The trick, now, is to somehow package the mobl story in such a way that our future reviewers will see it as enough of a research contribution to publish it. We’ll see what happens there.

Yet, I believe, even if mobl for some reason would not be the next big thing (can you imagine? ;)), our real audience will have seen it and thought “that one thing there, that is a really cool feature”. They will look for that feature in future languages and frameworks, because they know it exists — the bar has been raised.

Now that I mention it. If I’m being extremely cynical, for an academic knowing that “that one language had that cool feature” may be a reason not to implement it, because it’s not novel, it’s not a research contribution. But maybe I’m stretching it a bit.

So?

“What’s your point, mate? Set fire to the whole institution they call ‘academic research’?”

Meh. Let’s not do that just yet. I do think, but this depends on the kind of research that you do, that academics should talk to their real audience more. Don’t only submit papers to academic conferences, but industrial conferences as well. Blog. Create screencasts. Somehow negotiate time to build a real, usable, stable tool with a website that uses at least one feature from HTML 4.

And to those who give out research grants: expect more than academic papers, expect usable products and the PR that goes with it.

There’s so much interesting work happening in academia and the people that it affects simply don’t get to see it. It’s a shame.

We can do better than this!

Application development for mobile devices such as smart phones and tablets is popular. Apple’s AppStore (for iPhone, iPod and iPad) has over 350,000 applications and Android’s marketplace is quickly catching up counting over 200,000 applications. Android and iOS are not the only two mobile platforms, however. BlackBerry is a big player in business, as is Nokia. Microsoft recently launched Windows Phone 7, and HP announced new WebOS devices. While choice is great for users, it is a nightmare for us, developers. What platform should we target with our applications?

InfoQ article