Yesterday I spent several hours thinking about a concept I have been toying with for several days. Every programming language I have ever used, has its own limitations. The past few months I have been reaching those a lot, which is part of the reason why I started this blog. It made me wonder whether a programming language could be created, which can adjust itself at any given time. One important result is that this would allow you to create new keywords for a set of operations that are used regularly, solving the problem for which now only exist workaround solutions. Another cool aspect I realized, is when you start this process from byte level, the programming language itself could be its own compiler at runtime.
As a thought experiment I tried to come up with a basic set of rules, allowing for this required flexibility. If I didn’t make any logic errors, the rules I came up with can be implemented with a surprisingly small implementation, which for now, I’ll attempt to do in C#. When this turns out fruitful, the next step would be to do the same in assembly. The C# implementation, and the assembly implementation, would be able to run the same code.
While thinking of a name for the programming paradigm I had in mind (Read as: I needed to give the newly created solution in Visual Studio a name.), I checked Wikipedia for existing ones, but didn’t find any similar ones at first. Only by a subsequent google search with some keywords I found appropriate I stumbled upon Language Oriented Programming, and I’m really excited about it! The article reflects a lot (and more) of what I was thinking about and does a really good job of explaining it. As a nice ending brainfuck quotation:
Language Oriented Programming will not just be writing programs, but also creating the languages in which to write our programs. – Sergey Dmitriev, cofounder and CEO of JetBrains Inc.
whatheco.de 
Hi Steven Jeuris,
I saw you comment addressed at me on Ten Things I Hate About Object-Oriented Programming and got curious about this new paradigm – the Language Oriented Programming. I read through Sergey Dmitriev’s introduction Language Oriented Programming: The Next Programming Paradigm and I have to admit that my first impressions were that this looks really promising.
Then I got thinking about the solutions I’ve been working through my career. What struck me is that it was a really rare case when, I’ve had to base the solution on a single general purpose technology. On the contrary usually the solutions involved a whole stack of different technologies and different programming languages and different IDEs respectively.
So, my first concern with LOP is that it won’t work in multi-technology scenarios where it’s impossible to use a single general-purpose programming language underneath. For each technology in the stack involved there have to be a different LOP implementation. Of course, we can try with language transformation – e.g. writing in Java and compiling for JavaScript or writing in C# and compiling to ActionScript VM byte-code. IMO, I haven’t seen that working very well – usually it works under certain constraints and the underlying runtime is never used in its full power, just because there are certain idioms tied to the underlying technology and these idioms aren’t always possible to be translated into natural idioms of another language.
The second doubt I have is that it seems to me not very practical to build LOP on top of languages such as Java or C#. It’s quite hard to build DSLs in those two. If you look at language communities, the two languages that tend to foster DSLs are Lisp and FORTH. Lisp is a perfect sample of programming directly to the abstract syntax tree – the simplicity and regularity of its syntax are perfect for basing the LOP paradigm on it.
And my third concern is formality. What we’ll eventually have with LOP would be anImpenetrable Citadel of Concentric Formality – tons of layers of effective formality and a plethora of languages. I got the idea of how you build such language, but I don’t have any idea of how you learn such languages, and to me that is more important – to get back to the program after a while and to understand easily what’s going on there. And again the question of whether designing a new language and using it would take less time than just using the low-level constructs?
But I guess it’s more a matter of having the freedom to easily change and adapt the language to your needs, rather than designing new languages with each new task at hand.
As to the GUI, if you have time you definitely need to read through this paper – Magic Ink – INFORMATION SOFTWARE AND THE GRAPHICAL INTERFACE – especially the last section which lays down the concept of how you can apply the concepts of Programming by Demonstration for the needs of building certain types of GUI.
Vladimir
“So, my first concern with LOP is that it won’t work in multi-technology scenarios where it’s impossible to use a single general-purpose programming language underneath. For each technology in the stack involved there have to be a different LOP implementation. Of course, we can try with language transformation”
To quote Sergey: “A program in LOP is not a set of instructions. I don’t need to explain the solution in terms of a programming language it could be in almost any form.” MPS provides it’s own transformation language to convert models to an intermediate base language, or to any other model (or extended model) you want. The transformation in this sense, is the compilation.
I think using different technologies and languages is exactly why LOP will be useful. It’s obvious some technologies are more useful in some scenarios, but when choosing a technology, you are more or less stuck with it. LOP allows you to adjust and expand it, or just ‘compile’ to it. It’s this flexibility (although perhaps at the moment still partially theoretical) that makes it powerful.
“The second doubt I have is that it seems to me not very practical to build LOP on top of languages such as Java or C#. It’s quite hard to build DSLs in those two.”
As far as I can follow you, you are only mentioning internal DSLs. LOP allows you to create external DSLs (unrelated to any other programming language). For the ‘hard’ argument, again I think Sergey formulates it perfectly. 🙂 “Class libraries are wannabe DSLs! “. More on this can be found on page 5 of the article.
Impenetrable Citadel of Concentric Formality
I didn’t have time to read through your entire paper, so excuse me if I missed something. I quote “Yet again such systems cease to be practical the moment when in order to understand well the components in a layer you’re forced to explore more and more layers to the extend of being forced to get to know the whole system.” This is a valid argument, which you encounter often during development. I’d argue the main reason for not being able to understand a ‘layer’ properly is insufficient documentation, or simply bad design. LOP actually offers a solution there because the editor isn’t limited to the tools for the language it is hosted in (e.g. method completion). Misuse could be prevented. A math language could allow to visualize formulas in a scientific way. More on this is found on page 3 of the article.
Thanks for the article on user interfaces! At the moment I don’t have time to read it all, but I skimmed through it, and it seems interesting. I’m really interested in computer interaction and actually just submitted a proposal as a thesis about it. 🙂