The code formatting fallacy

Time to stir my category cloud on the right a bit, and publish a post under a category I’ve so far only used once. Hopefully it will become clear what Language Oriented Programming (LOP) has got to do with code formatting after this post.

There are several holy wars on code formatting:

• CamelCase vs underscores. My most popular post is a review of a scientific paper on the subject.
• How long a function should be, on which I wrote a somewhat controversial opinion.
• Functions should only have one return.
• Tabs vs spaces.
• Self documenting code vs comments.
• The order in which to lay out members in a class.

All these wars are about how text should be formatted. The very notion of code being text is so ingrained in programmers, that they often can’t think outside the box. What if the actual problem is code being text?

The problem is that text editors are stupid and don’t know how to work with the underlying graph structure of programs. But with the right tools, the editor could work directly with the graph structure, and give us freedom to use any visual representation we like in the editor. – Sergey Dmitriev, cofounder and CEO of JetBrains Inc.

This is just one of many interesting statements in the must-read article by Sergey introducing LOP. Once you consider the possibility of separating code and it’s representation, most of the code formatting discussions become obsolete.

• Identifiers can contain spaces, or can be represented differently based on preferences. Heck, they could be icons in a diagram.
• Visually separating a piece of code for readability would be possible without having to split into smaller functions.
• Multiple exit points of a function can be visualized in a diagram.

… and you can think of many more.

Modern IDEs like Visual Studio are slowly adopting alternate visualizations for code made possible by using extensions. As useful as some of these extensions are, they inherit the limitations of having to work on top of text.

If the progress on JetBrain’s Meta Programming System (MPS) is any indication of how feasible LOP will be in the future, my guess is we will be hearing a lot more from this paradigm in the years to come. A new actionscript editor, Realaxy, seems to be more than capable of competing with existing editors, and is built entirely on top of MPS.

UPDATE: Markus Voelter announced mbeddr on his blog, the C language made extensible thanks to MPS.

UPDATE: It seems the Realaxy website no longer exists (I don’t know why), thus I linked to the wikipedia article instead.

Like me you might not have time to try out MPS properly, but I can highly recommend subscribing to their blog. New screencasts are appearing at a regular basis, showcasing features ranging from implementing new language keywords to creating a visual editor for a state machine.

Author: Steven Jeuris

I have a PhD in Human-Computer Interaction and am currently working both as a software engineer at iMotions and as a postdoc at the Technical University of Denmark (DTU). This blend of research and development is the type of work which motivates and excites me the most. Currently, I am working on a distributed platform which enables researchers to conduct biometric research 'in the wild' (outside of the lab environment). I have almost 10 years of professional software development experience. Prior to academia, I worked for several years as a professional full-stack software developer at a game development company in Belgium: AIM Productions. I liked the work and colleagues at the company too much to give up entirely for further studies, so I decided to combine the two. In 2009 I started studying for my master in Game and Media Technology at the University of Utrecht in the Netherlands, from which I graduated in 2012. View all posts by Steven Jeuris