Language Oriented Programming

Language Oriented Programming just got a face-lift (Nov, 2004). SergeyDmitriev has published and article titled Language Oriented Programming: The Next Programming Paradigm. See http://www.onboard.jetbrains.com/articles/04/10/lop/. His argument is that LOP will be the next programming paradigm after OOP (oh boy, the NextBigThing).

It seems pretty compelling to me (but then again, I'm the editor of the article, and an employee of JetBrains). We're looking for feedback, discussion, and especially criticism. I'm sure the wikizens have an opinion on this. What say ye?

I was going to respond on LambdaTheUltimate, where there's currently a forum discussion on this topic, but Wiki lets me link more easily...

First off, there's a large amount of prior research in this direction, and not just in the Lisp world. I think it's worth taking a look at:

MlLanguage (ML initially stood for "MetaLanguage", and was designed to make construction of compilers and DSLs easy). There's a good presentation on how to write a DSL in Ocaml in a day at http://www.venge.net/graydon/talks/mkc/html/index.html.
RebolLanguage. Rebol was initially supposed to be a universal data-exchange language. EverythingIsa dialect in Rebol, allowing you to adjust the language on the fly. There's native BNF (BackusNaurForm) support, and execution can alter the parsing of subsequent tokens (this fact makes Rebol impossible to compile, but also makes it ideal for DSLs). From the sample Rebol code I've seen, it looks a bit easier than the LanguageOrientedProgramming examples in the article.
Preprocessors + combinator libraries in HaskellLanguage. The two that come to mind are HaskellDb and WASH. HaskellDb is a replacement for SQL that lets you write RelationalAlgebra expressions directly in Haskell. WASH is a webapp framework that's kind of like ActiveServerPages for Haskell, except it tends to integrate a bit better because Haskell code is already declarative. There's also Fudgets, a GUI library in pure-functional style.
D-expressions in DylanLanguage. There's a paper on this by JonathanBachrach?, and it's the implementation strategy in FunctionalDeveloper?. This is a way to tap into the AbstractSyntaxTree of parsed Dylan code fragments, except it actually works at a slightly higher level (the skeleton syntax tree). It then provides a GenericFunction interface to manipulate code fragments. Basically all of Dylan syntax is represented as D-expressions in FunctionalDeveloper?, which is an elegant approach that unfortunately leads to impenetrable error messages when using that IDE. DSLs like the Dylan User Interface Manager are done using Dylan macros.
DavidMoon's ideas on defsyntax (http://www.archub.org/arcsug.txt). I'm not sure I think this is a terribly great approach; BNF already provides a good mechanism for defining syntax, and providing an ad-hoc alternative just seems like a needless fragmentation.
The internals of ParrotCode. Parrot is written in CeeLanguage, but it's C that's heavily preprocessed by various PerlLanguage scripts. As a result, there's a DSL to define PMCs, to define opcodes, to define JIT operations, and so on. DanSugalski? gave a presentation about the use of DSLs in Parrot at some recent convention.

As for whether LanguageOrientedProgramming is a good idea, I see two big StumblingBlocksForDomainSpecificLanguages (content moved there, hope you don't mind.)

Previously, discussion of LOP on this wiki was based on HelmutLeitner's interpretation of it. See http://www.wikiservice.at/thelop/wiki.cgi?LanguageOrientedProgramming for information about that. The 'new' LOP is technically derived from the same source, which was an article titled Language Oriented Programming by MartinWard? (http://www.dur.ac.uk/martin.ward/martin/papers/middle-out-t.pdf). However, Helmut took a very different approach to it, so his LOP is not the same as SergeyDmitriev's LOP.

Xactium has some interesting technology that realizes this vision (their whole tool is defined using itself). A book can be freely downloaded from their website (http://www.xactium.com/). It seems that this technology has migrated over to this other website (http://www.ceteva.com/). There you can find everything formerly located at Xactium's site and much more.

The early access to Meta-Programming System is started in June 2005 at http://www.jetbrains.com/mps.

Would the opposite be "attribute-based" programming, such as a BusinessRulesMetabase?

Not necessarily. The definition at the top of BusinessRulesMetabase states, "[r]ather than coding BusinessRules in a generic language Java, C++ etc.[, p]ut them in a high level language/database explicitly for the purpose of storing and enforcing business rules." I would interpret a high level language for storing (and representing) and enforcing business rules as being something that could conceivably employ LanguageOrientedProgramming.

If it's a language, I wouldn't call it a "___base". I dissagree with that definition.

Didn't this used to be called 'metalinguistic abstraction'? Why did it need a new name? -- BryanEdds

Hi Bryan, I see 'metalinguistic abstraction' is an abstract concept that doesn't tell you how to construct the language. It also assumes, from what I read that an application specific language is the results. My concept is more concrete by providing a dictionary and rules, so you can see it as an specific implementation of the 'metalinguistic abstraction'. On the other hand, it has a more general forcus as a cross-application meta-language, with a special focus on reusable libraries and modules. -- HelmutLeitner

The article about language oriented programming is full of nonsense and tautology. First, programming has always been "language oriented" so the article title and concept is meaningless. That is how you program: you use a computer programming language. The title "language oriented programming" is redundant, since programming has always been oriented around programming languages. Second, in the article he says he never thinks of programs as a list of things to do (set of instructions). This is complete nonsense. What is the first thing that comes to mind when you want to build an input form on a website: first I want the user to input his data, then I want to collect the data, then I want to store it in a database. These are all very procedural ways of thinking, and this model works well.

CategoryMetaprogramming