THELOP is the first incarnation of LanguageOrientedProgramming. It is a working title for a project in progress.  There was little interest in LOP and THELOP here during the last year, so I think about moving most of the content to a separate wiki, where it won't matter to create a few hundred pages about these topics:

	* http://www.wikiservice.at/thelop/wiki.cgi

Please tell me whether you want me to keep the pages of CategoryThelop here in this wiki, delete them or reduce them to a minimum. -- HelmutLeitner [Sep 30, 2002]

----

You have written several pages about LOP which are all very low level.  A large proportion of them seem to assume that you already know the terminology of LOP and how/why you might use the technique.  I (NatPryce) have difficulty understanding these pages and seeing how to apply LOP to the activity of problem solving and thinking about programming.
	* The story is this: I had offered a friend THELOP for the API design of a noncommercial project (a free multilingual dictionary on the Internet) but was late. I stumbled over WikiWikiWeb and was immediately attracted. I intended to put some pages (rules and vocabulary) into this system, experiment with it and keep my promise at the same time. But this system has dynamics of its own and enforces a complete transformation...

I think what is needed is a concrete, practical LopCaseStudy, taking us from the beginning of a ''real'' LOP project through the steps one takes to complete the project.  The ExtremeProgramming people did this with much success.
	* I'm sorry, I can't offer you a case study. I will give some background information in ThelopProgramming and I offer cooperation if someone wants to do such a case study.

----

In particular I'd be interested in a LopCaseStudy that describes:
	* How LOP affects the analysis and design phases of a project.  How are domain concepts modelled using LOP, and how are they mapped to implementation constructs?

In addition, I'd  be interested in descriptions of:
	* How the vocabulary is documented and enforced.
	* How code from different sources is integrated -- what if they have different vocabularies?
	* How multiple programmers coordinate to build a LOP language and maintain the consitency of the LopVocabulary.
	* Concrete measurements of how much overhead is involved in creating and maintaining the vocabulary and how it affects new team-members who are brought into the project after the vocabulary as been built up.
('''Copied to ThelopProgramming''', will be deleted here sooner or later)

----

The ThelopLanguage defines ThelopWord''''''s and gives ThelopRule''''''s to ease the formation of ThelopSentence''''''s. ThelopSentence''''''s are used as function names and are therefore also called ThelopName''''''s. So the terms ThelopSentence and ThelopName are equivalent.

THELOP is very much like a natural language. There are strict rules and there are rules that may be violated occasionally. There may be even rules that are somewhat contradictory. There are even forms of slang. THELOP is created for the communication between the writer and the reader of a source which may be one and the same person. It may be the thing for the IdiotProgrammer.

----

''Do you have an example program?''

You can look at the small THELOP example on the LanguageOrientedProgramming page to get a first impression, but I will build example pages like ThelopWordExample''''''s, ThelopNameExample''''''s, ThelopExample''''''s and perhaps ThelopForCee, ThelopForJava, ThelopForBasic (and for any other language asked for) if there is need or interest.

''Your example seems nothing more than C code using a naming convention. I see nothing warranting a new paradigm much less a language build on that paradigm? Can you give use some BNF for ThelopLanguage? Something besides abstract ideas? What is it parallel to? A paradigm (like OO), a language, or some naming convention you think works well for any language? Why is it called Language Oriented Programming?''

Below the surface of a naming convention (Are Spanish or English *just* naming conventions?) there is OO thinking and a number of philosophical and technical principles. Nothing warrants 2000 natural or 200 programming languages (or whatever the real numbers are), so I don't feel a need to warrant the ThelopLanguage. LOP is a paradigm, a way of thinking and more. THELOP is a naming convention, a language and more. Both work together to exploit the unused potential of function and variable names. I don't intend to give a BNF because this would restrict the "natural language" component of THELOP (I may change my mind if you give me a BNF of English).

It is called Language Oriented Programming because just as OOP concentrates on objects, LOP concentrates on language. OOP and LOP may be combined, because they operate on different levels. A LOP rule like "words and names must be used consistently" should be natural in all areas of software development, but it isn't (look at the 3500+ Java classes, the 1500+ function Win32 API or even the C standard library or everyday programming). If THELOP were just a naming convention, we could theoretically just change the names within these APIs. If you tried, you would find that this simple solution is not feasible, you would have to redesign these APIs to be able to give consistent names. You would have to simplify the interfaces, make them more object oriented, add functions for completeness (because obvious gaps open up) and more. Isn't that interesting? How is it possible that a naming process (invisible to the translation and execution of a program) creates powerful feedback to change overall design?

----

I'm ''extremely'' skeptical of the benefits of ThelopLanguage as an analysis, design or implementation aid. As I read it, all it offers is an Orwellian NewSpeak to replace a more natural style of naming with semantics appropriate to the entities that are being modeled rather than externally imposed. There is a haiku-like attractiveness to the overly strict constraints it would impose, but just as you would probably not want to write an entire novel in (iterated) haiku form, I wouldn't want to write programs using ThelopLanguage as a self-imposed constraint.
-- LaurentBossavit
	* There is no long term replacement for consistency. Any benefits can only come from order (what you call overly strictness). So what you can do is (1) nothing (2) use THELOP (3) create your own and better language.
	* I would doubt that common programs are like novels. They contain too much "structure" and too little "language". They are no fun to read and to maintain. ThelopName''''''s are readable, because they contain the complete meaning of a call. So good THELOP programs or functions should read like stories. Programmers and readers should have fun.

Hmm. IMHO a well-written novel is precisely like a well-written program. Internal consistency, smooth flow, balanced parts, are some common characteristics. There might be more interesting ones; I would go so far as to liken polymorphism to punning (a.k.a. polysemy).

The goals of a programmer are akin to those of a writer. We need to accurately and completely communicate some meaning. This is a hard task; to achieve it, we rely on the flexibility of the language. A flexible enough language will display some degree of interplay with the meanings it can communicate - what you say and how you say it are intricately related.
	* I hate to discuss what a creative writer does. Surely he works with the imagination of the reader and speaks "between the lines". A programmer has to be precise. That's one difference. Another is "reuse". A writer will not reuse sentences or larger units of his work. A programmer should. So there are just as many differences as similarities. This discussion leads us nowhere.

To be bluntly frank, I'm losing patience with the topic; I'm still expecting (as I'm sure others are) a concise and accurate statement of how this proposed paradigm isn't either a platitude (''"naming issues matter in writing software"'') or an intricately formal but ultimately futile attempt at a GrandUnifiedTheory, like a seemingly complex knot which disappears when you tug at both ends.

Unless and until that appears, somebody might feel tempted to "refactor" all these pages into the platitude. I already am, though I expect I'll be able to refrain. ;)

-- LaurentBossavit

-----

''ThelopName''''''s are readable, because they contain the complete meaning of a call.'' -- someone

How can anything that is not the body of the function contain the meaning of the function?  The name (hopefully) causes the reader to make a good guess about the meaning of the function, but there's a big difference between a name that implies the functions's meaning and a name that ''is'' the function's meaning.

Let me put it another way.  If it were possible to specify the meaning of a program by the names of its parts, then why would we need to put anything in the parts?  Just list the names, create a program to pick the meaning out of the names, and go home early.

If you can truly specify behavior with names, then you've discovered the holy grail of program specification, which is the ability to specify a program's behavior without giving the program itself.  If you've done that, you just put us all out of work (thank you very much).

I'm sure I don't understand Thelop.  -- WayneConrad

''Don't worry. Let's assume that we target the free JPEG source and reduce the 700+ KByte source to the real minimum of functionality and API complexity, you might end up with something like:''
	* Image I''''''mageCreateFileJpeg(filename)
	* Err I''''''mageWriteFileJpeg(image,filename)
''We need not to talk about all the details of implementation (quantification, transformation, Huffman coding, ...) in the function name, nor do we magically solve any implementation problems. But the function names tell us everything we need to use these functions as black boxes. In other words: the word "peace" is important, it enables us to talk about peace and work towards peace more easily, but having the word doesn't implement a solution.''

I think we agree that the name is not the meaning, but implies the meaning to the reader.  That's good.

If I were to write the above examples in an OOP language, it'd be like this (using Java, but any language with at least one level of namespace above classes will do):

  package jpeg;
  public abstract class Image {
    public void write(File file) throws Image''''''Exception {...}
    public static Image read(File file) throws Image''''''Exception {...}
  }

The Image class resides in the jpeg library, so there's no need to put "'jpeg"  in the class or method names.  The writeToFile and readFromFile methods reside in the Image class, so there's no need to put "image" in the method names.  The File parameters are identified by their type, so there's no need to add "file" to the method names.

Each name makes sense in its local context.  A name should not try to repeat all of its context.  That's too much baggage for a name to carry around.it.

Thelop names seem to carry their entire context around with them.  If I implement a thelop program in an OOP language, do the names get trimmed now that the packages and objects can provide context for the names, or do the names remain encumbered? -- WayneConrad

Wayne, I hope that this will not lead us into discussing subtleties of minor importance. But: although your suggestion seems to be at least equivalent at first sight, IMO it won't work well neither in a Java (OO) nor in a Thelop context. 

First, the class and packages names don't fit. We do not define an image object, we just fill an image from a special image format file. We surely will have many image formats within a general library and others within different projects that have to work together and that are potential targets for CodeHarvesting. So in reality we might better have:
  /* Jpeg.java */
  package com.xcorp.lib.graphics.jpeg;
  public abstract class Jpeg {
    public void write(Image im,File file) throws Image''''''Exception {...}
    public static Image read(File file) throws Image''''''Exception {...}
  }
  /* Png.java */
  package com.xcorp.yproject.png;
  public abstract class Png {
    public void write(Image im,File file) throws Image''''''Exception {...}
    public static Image read(File file) throws Image''''''Exception {...}
  }
Of course this has nothing to do with Thelop, only with the proper organization of the package and class namespaces, although there are many other possibilities like
  package com.xcorp.graphlib.imageformats.jpeg;
  class I''''''mageFormatJpeg
or
  package com.xcorp.imageformats;
  class Jpeg
but these variations are not important. 

One could also combine packages with Thelop names:
  /* Jpeg.java */
  package com.xcorp.lib.graphics.jpeg;
  public abstract class Jpeg {
    public void I''''''mageWriteFileJpeg(Image im,File file) throws Image''''''Exception {...}
    public static Image I''''''mageReadFileJpeg(File file) throws Image''''''Exception {...}
  }
  /* Png.java */
  package com.xcorp.yproject.png;
  public abstract class Png {
    public void I''''''mageWriteFilePng(Image im,File file) throws Image''''''Exception {...}
    public static Image I''''''mageReadFilePng(File file) throws Image''''''Exception {...}
  }

Now lets imagine a situation where one is interested in code use/reuse and CodeHarvesting in the context of a multi library, multi project situation (that's what LOP and THELOP are working for). The questions are: What classes, functions do exist for e.g. Png? Where are they defined? Where and how are they used? How many source changes are needed for changing an API or moving a module including the update of all projects using it? There will be a quite different answers whether you use namespaces or not, and whether you use Thelop or not.

Without going into detail it should be clear that namespaces increase the work for CodeHarvesting. It should also be clear that a name like "write" will not help someone to find the definition and calls of a special "write". You may have tools that help you but they are often restricted to a project or to a special programming language IDE. Even a good tool will not search for "anything that has to do with Jpeg" as will a simple text search utility if you use Thelop names. 

In a way Thelop replaces explicit namespaces by "semantic namespaces". Any Thelop name (e.g. I''''''mageWriteFileJpeg) may be thought to belong to a number of different semantic namespaces built from any subset of ThelopWord''''''s it contains (e.g. [Image,Write] [Jpeg,File], [Write,File], [Jpeg]...). Often there is neither possibility nor need to have a file, class or package structure to hierarchically organize all these semantic namespaces at the same time. Just like  VirtualClass''''''es these semantic namespaces may be distributed among a number of modules or even projects. Name collisions using Thelop are rare, because they can only happen when there is a semantic collision (e.g. two modules doing the same conversion of a Jpeg file to an Image object). Within a project a semantic collision is unacceptable and must be resolved immediately. Within a multi library, multi project source pool a semantic collision could occur during CodeHarvesting and should be resolved. In other (rare) collision situations using Thelop at least doesn't worsen the situation (use explicit namespaces if the programming language supports them).

In short: Thelop needs additional work to think about and use a consistent dictionary of words. Thelop pays back by reduced need for documentation, less context dependence in using function names, an easier and tool-independent way to "query the source pool" and easier CodeHarvesting. Is it worth the effort? For me the answer is "yes", but I agree that for many developers the answer will be "no". It just depends on the situation and the priorities. 

----
See also: LanguageOrientedProgramming ThelopLanguageFaq
----
CategoryThelop CategoryProgrammingLanguage