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