Language Oriented Programming

The problem:

The typical experience in programming is, that we have to invent the wheel all the time, and that APIs are typically inconsistent, incomplete and of low quality.

The wrong solution (of the industry):

Let's create new APIs and new languages to keep the developers updating, upgrading and buying our products.

The real solution:

Let's make as independent as possible from current hype and language wars. Let's stick with the tools we have, think about how to optimize API design and how to build libraries that will serve us for a long time. So we can maximize reuse and productivity.

(the page content is currently refactored)

Does anyone else use the concept of language oriented programming (LOP)? If someone does, I would be interested to share ideas. If no one does, I will claim temporary "ownership" of this page and use it to explain the concept of LOP as I developed it. -- HelmutLeitner

LOP is:

• a reuse technology
• a way of OO thinking
• a programming style
• a metalanguage, a system of names (esp. for naming functions/methods)
• LOP is evolutionary in the sense of PiecemealGrowth?
• LOP is final in the sense of DoItRightTheFirstTime? (done right, you should hardly ever have to change a function signature).

• a programming language
• a silver bullet solving all problems
• the effort of a renowned university or corporation (so you have to think yourself to judge whether its good or bad)
• a product someone will try to sell to you

• reduce the gap between OO and procedural programming
• reduce the gap between different programming languages
• reduce the complexity of software development (aims at one order of magnitude)
• invite the software community to develop a common language

• force the programmer to use a certain metalanguage (develop our own, if you like)
• intend to produce or use any hype

• we would build growing libaries for a growing number of programming languages that are consistent, easy to use and have a minimum penalty for using them or switching the language.
• we would grow a common dictionary of words and meanings that would allow us to have really selfdocumenting function names.
• the libaries for the different programming languages would have a large amount of overlapping concepts and similar or identical functions.

• programming is an art that is homed at individuals
• LOP works to empower these individuals
• software development is not primarily about building technical systems, but a way to understand and model the world
• Philosophy: SmallIsBeautiful?, OpenSource?, OpenKnowledge?

A small LOP glossary:

* A word , the basic building block of LOP APIs (function names). Typically words stand for for objects (like String or Window), actions (like Get or Rename), properties (attributes like Size or Color) and modifiers (like All or Fast). * A word has a signature connected with a context-free meaning and two parameter lists: function arguments and return parameters. Any list may also contain only a single element or may be empty. * A LOP sentence corresponds to a function name and consists of words. If done right, the word signatures add up - left to right - to build the function signature. * Only words from a dictionary may be freely used as a part of new function names. New words are either created within the LOP dictionary or within the project dictionary. * Currently there is only one LOP implementation: Thelop (THE Language Of Programmers). A LOP implementation like Thelop should define its dictionary and the grammar to form sentences (should sound familiar). A programmer, knowing the dictonary and the grammar, should be able to derive from a function name everything he needs to know to use it.

A short, informal introduction to Thelop grammar:

• The basic pattern for Thelop function names is:
• ObjectActionObject (the second Object is optional)
• The basic pattern may be followed by another "ActionObject" clause
• Words before the action denote input parameters
• Words after the action Get denote output parameters
• Words after the action Ret denote return parameters
• The second object may be replaced by a property
• Any word may be followed by modifiers

Helmut: Have you read ThinkingForth?? ForthLanguage? itself seems very, very suited for this, although it's somewhat closer to what you(?) refer to as the Ward approach below. Highly recommend. --AdamBerger?

• Adam, I read ThinkingForth? about 20 years ago and I used Forth for some time on an Apple II and I learned a lot from it. The idea of small reusable building blocks that form a language of their own may pretty much be an echo of this experience. On the other hand, Forth neither has consistency in its language nor are "Forth words" (=function names, =LOP sentence) built from "semantic words" like LOP strives for. In fact I recently revisited Forth (WinForth32?) and was again impressed by the simplicity and performance, but the tendency to keep words short instead of consistent IMO cripples the potential of Forth. -- hl

• "The first step on the road to truth is to call things by their proper names." -- Ancient Chinese Saying (from a post by DonOlson?)

• A proper name is one that is understood. It is the result of a community effort in the form of a continuous evolution of a language or of multiple languages.

... LANGUAGE ORIENTED PROGRAMMING which is a novel way of organising the development of a large software system, leading to a different structure for the finished product. The approach starts by developing a formally specified, domain-oriented, very high-level language which is designed to be well-suited to developing "this kind of program". The development process then splits into two independent stages: (1) Implement the system using this "middle level" language, and (2) Implement a compiler or translator or interpreter for the language, using existing technology. The approach is claimed to have advantages for domain analysis, rapid prototyping, maintenance, portability, user-enhanceable systems, ... --- The Ward approach is different from LOP:

• Ward uses a domain specific language that works like a programming language. The goal of LOP is a general language that works like a natural language.
• Ward uses a translator. LOP doesn't need a translator.
• Ward's method is for large, domain specific projects. LOP is for projects of any size.

The goal of language oriented programming is the creation of a new language that consists of words and rules. The rules help to form sentences from the words. Each sentence is used as a function (method, subroutine) name and is meant to describe the function *completely*.

Of course, many people will say that this is impossible or trivial. I will try to show that it's possible, not trivial and that there is a lot to gain.

As a careful person I will not risk everything in one game. So the general idea of LanguageOrientedProgramming and the current implementation of ThelopLanguage? are separated.

LOP and THELOP have nothing to do with the creation of a new programming language. They work on top of any programming language by exploiting the unused potential of function and (much less important) variable naming. They lead to OO programming and OO thinking even if the host language is procedural. So there is a certain overlap between OOP and LOP. On the other hand there are also conflicts.

Q: Any relationship between LOP and Fuzzy Logic?

A: I'm not aware of such a relationship, but I don't know enough about Fuzzy Logic to deny any.

Another A: Offhand, it looks like >NO<. LOP seems to be about syntax and grammar. Fuzzy Logic is about different levels of certainty / confidence / probability between strictly true and false. Like... "Is he tall?" Well, at 6'4" he's somewhat tall, as judged by most people --> not exactly an unambiguous "true." -- JeffGrigg?

It seems from that, fuzzy logic is about applying logic to objects and to relationships between objects which have not yet been defined.

So the ItDepends? answer to the question "Is he tall?" is "It's to soon to tell" leading to "When will we know?", which then focuses on the real problem, which is "How tall is He?" and "what is tall?" If on the other hand you supply the answer "I can't tell you" it might lead to "Compared to What?", which then focuses on problems such as "How tall is (something really) tall?" (like a Redwood tree), or "Do you mean compared to us?" It is this normal thinking process that leads us out of the fuzziness into real logic. And we do this by using language and (Questions/Answers), Questions about the Names we use, and what they mean, and Questions about the processes by which we determine that meaning and express that meaning to others.

One idea of LOP is "ease of learning". The APIs we are using are growing fast in size and complexity. A standard C API may offer a few hundred functions. The current Windows API offers a few thousand functions. Tomorrow we will have to work with ten thousand functions or more. The problem is not only the shear size of these APIs but also their inconsistency.

Lets talk about a future 50.000 function API. If we were able to coin "words" and "rules" to build "sentences" to name these functions we might be able to cope with this complexity. A vocabulary of 500-1000 words could do the job. The ThelopLanguage? implements this basic idea of LOP.

(An alternate approach to addressing the "large API" issue is to make the API object oriented instead of procedural. This is MicroSoft?'s approach; they're using COM. -- JeffGrigg?)

Is this "just" a better naming scheme for function and variable names, or is there more to it?

• It *is* just a better naming scheme, but there is *much* more to it. Just as a natural language influences the thoughts of it's users, the ThelopLanguage? influences the way of programming and how one thinks about programming problems.

• There will be examples on pages like ThelopWordExample?'s, ThelopNameExample?s, ThelopExample?'s and ThelopLanguageFaq? but I want to give you at least a smell (assuming a C-like procedural language, no error handling):

If the average C programmer understands this example and feels not far from being able to use some of the functions above without much additional documentation, then LOP and THELOP have done their job.

Can you give us an example of solving a problem using LOP, versus OOP or FP or whatever to show how LOP affects the way one thinks about a programming problem and the design/development of its solution?

• Yes, I will. But not now and here. I first need to introduce some more ideas and terms to be able to draw a better picture of LOP and THELOP. Then I will use the ThelopExample? page to answer your question deeply.

How does Language Oriented Programming let one think about a problem and its solution?

• LOP creates a language for the problem. It reuses the current vocabulary and may extend it consistently. Words and word combinations are used to express objects, properties and actions. Because words are more abstract than objects, we reach a higher level of abstraction. And we are not only talking about OO objects but about *all* types of objects (we are also not bound to use an OO programming language at all).

LOP seems to echo the central theme of the SapirWhorfHypothesis?-- that language shapes thought. Presumably HelmutLeitner is going to present a formalized system for names that somehow opens up the programmer to new or better ways of thinking about the problem. At least, that's what I'm getting from all this so far.

Is that where all this is going? If so, I'm skeptical. While I believe everyone will agree that a clear and consistent naming scheme is not only useful but important, I don't see how it affects thinking. That's the key here, because otherwise, LOP sounds just like yet another policy for names.

--John Passaniti

Thinking is affected by ideas. Ideas are represented by words. Without the idea and the word democracy no one would have wanted it or fought for it. This is quite simple.

LOP introduces things like VirtualOrder? (VirtualStructure?, VirtualObject?, VirtualClass?), FacadeFunction?, LanguageExpectation?, FunctionHyperspace?, FunctionOrthogonality?, LanguageIndependentProgramming?, WordSignature? and SupraConsistency?. If these terms work for you (as they do for me) and are used regularly they will affect your thinking about programming problems.

A LOP implementation like the ThelopLanguage? will work equally well bottom-up or top-down. Bottom-up is easy because one is able to create hundreds of related functions building on each other without a naming problem. Top-down is easy because functions at all levels use the same vocabulary, so top and bottom are guaranteed to meet seemlessly. Very often solving a programming problem starts with writing some PseudoCode? using the ThelopLanguage? that later turns out - as expected - to be final code.

• I am one of the few who has pursued this path of building on semantic clarity. The above paragraph is true. I cannot explain it though, because the first thing that becomes obvious once you have crossed this line is that most languages work against the convenient implementation of function based semantic clarity. For example, when I decided that C++ was the appropriate language for an imbedded system I was writing, I looked at C++ and decided that it was easier to generate the C++ code. So I do not talk C for examples. And C and Lisp appear to be the only 'acceptable' languages around here and on C2.com wiki. A review of language at this level causes questioning of all the conventional languages. I congratulate the author on the brave attempt at throwing light on this important perspective. It is the only viable long term view of software I have seen so far. -- PeterLynch?

LanguageOrientedProgramming is very object oriented, but not in the OO way. LOP is about modelling real world objects and solving real world problems. Everything in LOP is about objects, their creation and transformation. There can be no LopName (ThelopName?) without an object reference. This is much more radical than e.g. Java, that has primitives that are not objects.

Just as natural languages describe the real world, LOP languages have to speak about and model aspects of the real world. Different LopHostLanguage?s offer different environments to achieve this goal. Certain programming language features may come handy or may become obstacles. LOP and THELOP try to cooperate, but there is an analytical and a critical potential. I will leave this for the reader to explore, because I want to avoid wars or pissing contests. This is the reason why I did't comment on HungarianNotation?.

See also: ThelopLanguage?