VirtualOrder is an idea of LanguageOrientedProgramming. "virtual" in this context means that the order is primarily introduced by the means of LOP (e.g. correct naming) and is invisible to the compilers or interpreters that analyze and execute our source code. So this VirtualOrder is not "real" like order from OO programming language objects or classes. But on the other hand VirtualOrder in its flavors:
	* VirtualStructure
	* VirtualObject
	* VirtualClass
	* ...
is more general and may also reach into areas that OO programming languages have sometimes difficulties to touch. In this context "virtual" has nothing to do with its meaning in VirtualMethod, VirtualMachine or VirtualReality. It is meant neither positive nor negative, no hype is intended. VirtualOrder may sometimes be a first step to real order, but it may also be a final abstraction.

----

In LanguageOrientedProgramming *any* function *must* be related to an object. It may be an formal (e.g. Java) object, it may be a real world object or it may be a virtual object that exists only in the mind of the software developer. We must name the object type (what OO people would call a class) and there must be an explicit or implicit reference to the object, but this reference may be realized in several different ways.

I suppose, I should give some examples.

----

	'''F''''''ileDel("test.dat")'''
The object of this call is a real world object, a file named "test.dat" living on some storage space. The object reference is its name. There is never a formal object (BASIC, C, JAVA, ...) although we might use one to implement this function. 

''Why is there never a formal object reference?''

In this case File''''''Del would work as a FacadeFunction that shields us from the details of implementation and from the details of the LopHostLanguage. Thus we create THELOP code that may be portable across some programming languages and follow the ideal of LanguageIndependentProgramming.

We might support function calls like
	'''size=F''''''ileNaRetSize("test.dat")'''
	'''F''''''ileNaSetSize("test.dat", 1000)'''
	'''F''''''ileCpy("backup.dat","test.dat")'''
	'''F''''''ileNaCreateString("config.txt", "Default''''''Wiki=h''''''ttp://c2.com/cgi/wiki")'''
and start building a VirtualClass. BTW the Na is a Thelop slang word (short for Name) that is used a modifier and tells us that not the usual object reference (e.g. a file handle) is used but the name of the object instead. -- hl

----

I'm really struggling to understand what is unique about LOP or THELOP (much less what the difference is between LOP and THELOP). Can you get to the essense of why this:

 '''F''''''ileCreate("test.dat")'''
 '''size = F''''''ileNaRetSize("test.dat")'''
 '''F''''''ileNaSetSize("test.dat", 1000)'''

is any better than this?

 file = File.new( "test.dat" )
 size = file.getSize()
 file.setSize( 1000 )
 file.delete()

In my version, your program is (a) less prone to errors (because you do not have to repeatedly type the same string), (b) easier to maintain (you only have to change the name of the file in one place), (c) easier to type (less characters), (d) easier to optimize (since you can dynamically or statically bind the message names), and (e) supports polymorphism. Before we used OO languages, most of us had these big internal vectors of structures (objects) and had no choice but to use public, free-standing functions to operate on those. It was kind of like Structures Oriented Programming. We had no choice but to use naming conventions since you couldn't have a function named ''Size'' that would produce different results based on the object it was invoked on. For example:

  getSize( file );
  getSize( rect );
  getSize( array );

This sort of thing was impossible because there was no overloading based on type. So, we had to be very careful with naming and do something like the following:

  F''''''ileGetSize( pFile );
  R''''''ectGetSize( pRect );
  A''''''rrayGetSize( pArray );

Why would we want to go back to this? What advantage does it provide? -- RobertDiFalco

In fact there isn't much difference, except my examples where meant as separate call examples. But
     F''''''ileNaSetSize("test.dat", 1000)
is better than
     file = File.new( "test.dat" )
     file.setSize( 1000 )
because it expresses one thought in one ThelopSentence (ThelopName), instead of two. But this is not the point. One could build a similar single global procedure in OO and one would not use the file name as reference in my PP example, if the file is accessed multiple times. Both OO and PP could be made isomorphic and conforming to Thelop.


''Please provide an example that has multiple calls to the same file without using its name?''


On the other hand your 

     F''''''ileGetSize( pFile );
     R''''''ectGetSize( pRect );
     A''''''rrayGetSize( pArray );

don't qualify as LopName''''''s (ThelopName''''''s), because they are not consistent with their meaning. In THELOP one would use

     size = F''''''ileRetSize( pFile );
     area = R''''''ectRetArea( pRect );
     dim = A''''''rrayRetDim( pArray );

because size, area and dimension are three totally different properties, that should be represented by different words. At least that's what LOP is teaching when it talks about consistency. -- Helmut

The problem with this is that the following example:

   rect.getSize()   --> (height, width)
   file.getSize()   --> # of bytes
   list.getSize()   --> # of elements
   array.getSize()  --> # of elements
   string.getSize() --> # of characters

...only requires the programmer to master one basic concept -- the concept of ''size''. The meaning of ''getSize'' is not absolute but is relative to the context it was used in. This is just like '''real'' language -- objects are ''modifiers''. So, for example, the term ''strike'' is slightly different in the context of a match than in the context of a hand and face. For a rectangle, ''size'' may be its height and width (a point) while for a file it may be a single integer denoting the number of bytes it contains. Your example is much more complex since each ''Object'' requires a unique and dedicated ''term''. There is no general concept. The user must remember that ''Area'' goes with ''Rect'', ''Size'' only with ''File'', ''Dim'' goes with ''Array'', and further more that ''Dim'' is an abbreviation for ''Dimension'' and ''Ret'' for ''Return''. -- RobertDiFalco

----

"...concept of size...". This is not a concept, it is a (bad) habit. Even a man from the street wouldn't ask "What is the size of IBM?", he would ask "How many people work for IBM?". That's where LOP departs from grown programming habits and seeks for consistency. 

Perhaps this makes the difference clearer:
     poligon.retArea
     poligon.retDim    --> # of points
     poligon.retSize   --> Bytes of flat storage space needed
     poligon.retAreaBoundingRect
It is a question of what it costs and what it buys you. 

The cost is
	* learning a (simple) language of highly reusable words
It buys you
	* less documentation (assuming THELOP is used) because only new words and inconsistencies that violate LanguageExpectation''''''s have to be documented
	* classes may grow with much less interface problems (DoItRightTheFirstTime)
	* Questions like "How do we deal with Area in our multi library, multi project, multi programming language source pool?" are easy to answer by simple text search.
	* more consistent thinking and communication about real world objects
	* ...

But this belongs into ThelopConsistencyDiscussion, where I will put it sooner or later.

----

''...because it expresses one thought in one ThelopSentence (ThelopName)''

Actually, most programming is too complex to try to represent rich interactions in a single sentance. It is better to have abstract, reusable parts that can but composed with one another. I'm still searching for something unique, something deserving of being called a language in LOP and THELOP. What I see is style and convention. Most of which makes programming less intuitive. More back to the old days of abbreviations and cryptic names. JMTC. -- RobertDiFalco

What you mean is that badly-designed programs have many steps that are too
complex to represent in a single sentence. Naming things meaningfully is a good tool to expose the hidden complexity in your software. However, I agree
that the abbreviations make the names more cryptic and LanguageOrientedProgramming would be better without them. -JoshPurinton

----

The more I see of LanguageOrientedProgramming, the less impressed I am. These are just function calls that take strings as arguments.  So? How is this different from what I did in C 20 years ago?  Maybe you want to write programs that can be trivially translated into COBOL, but I don't. -- RalphJohnson

The most important concepts in software engineering are independent of any particular programming language. Giving names a structure so that they have a consistent meaning is a critically important process in the design of any large system built up of interconnected parts. This is particularly difficult in software design where the range of concepts we have to work with is particularly large, and  Helmut's work is quite helpful in this regard. -- JoshPurinton

''It is only a small example. It wasn't meant to impress, but to explain VirtualOrder in a simple way. And no, I'm not interested in COBOL.''

''Should I stop using the WikiWikiWeb to write about LOP and THELOP? I am new to this community, so please tell me.''

Please continue to write about it.  If I read enough of it, I'll start to get what it's about.  I'm afraid that right now I don't understand LOP and THELOP enough to even have an opinion on it, although I suspect it's solving a set of problems I don't have (or am already solving with OOP).  -- WayneConrad

Yes, PLEASE continue. More people need to understand these concepts. I am very grateful for the details you have provided so far and eagerly await more.

----
See LanguageOrientedProgramming, ThelopLanguage

----
CategoryThelop