F# has a few mechanisms for doing programming in a style one might call "language-oriented".

First, the syntax niceties (function calls don t need parentheses, can define own infix operators, ...) make it so that many user-defined libraries have the appearance of embedded DSLs.

Second, the F# "quotations" mechanism can enable you to quote code and then run it with an alternative semantics/evaluation engine.

Third, F# "computation expressions" (aka workflows, monads, ...) also provide a way to provide a type of alternative semantics for certain blocks of code.

All of these kinda fall into the EDSL category.

Language oriented program (LOP) can be used to describe any of the following.

Creating an external language (DSL)

This is perhaps the most common use of LOP, and is where you have a specific domain - such as UPS shipping packages via transit types through routes, etc. Rather than try to encode all of these domain-specific entities inside of program code, you rather create a separate programming language for just that domain. So you can encode your problem in a separate, external language.

Creating an internal language

Sometimes you want your program code to look less like code and map more closely to the problem domain. That is, have the code read more naturally . A fluent interface is an example of this: Fluent Interface. Also, F# has Active Patterns which support this quite well.

I wrote a blog post on LOP a while back that provides some code examples.

In Object Oriented Programming, you try to model a problem using Objects. You can then connect those Objects together to perform functions...and in the end solve the original problem.

In Language Oriented Programming, rather than use an existing Object Oriented or Functional Programming Language, you design a new Domain Specific Language that is best suited to efficiently solve your problem.

The term language Oriented Programming may be overloaded in that it might have different meanings to different people.

But in terms of how I ve used it, it means that you create a DSL(http://en.wikipedia.org/wiki/Domain_Specific_Language) before you start to solve your problem.

Once your DSL is created you would then write your program in terms of the DSL.

The idea being that your DSL is more suited to expressing the problem than a General purpose language would be.

Some examples would be the make file syntax or Ruby on Rails ActiveRecord class.

I haven t directly used language oriented programming in real-world situations (creating an actual language), but it is useful to think about and helps design better domain-driven objects.

In a sense, any real-world development in Lisp or Scheme can be considered "language-oriented," since you are developing the "language" of your application and its abstract tree as you code along. Cucumber is another real-world example I ve heard about.

Please note that there are some problems to this approach (and any domain-driven approach) in real-world development. One major problem that I ve dealt with before is mismatch between the logic that makes sense in the domain and the logic that makes sense in software. Domain (business) logic can be extremely convoluted and senseless - and causes domain models to break down.

An easy example of a domain-specific language, mentioned here, is SQL. Also: UNIX shell scripts.

Of course, if you are doing a lot of basic ops and have a lot of overlap with the underlying language, it is probably overengineering.