Thelop Programming

This is a page intended for describing and discussing practical aspects of using the ThelopLanguage in software projects. -- HelmutLeitner

Questions:

How is TheLOP applicable (or even of interest) to the general programming world?

There are a number of ways. Apply LOP principles: look at your vocabulary, make the words consistent, make naming consistent, make thinking consistent, make APIs complete. Think of words as objects and use as few as possible. Look into the different types of VirtualOrder and exploit them. Improve APIs to work as the programmers which use them expect. Organize CodeHarvesting. Explore new directions of LOP I missed to see or understand. Compare your conventions and results to Thelop. Note that you can go as may steps as you like, you do not depend on any product or tool.
Or: use the Thelop words and rules as they are. Extend as necessary. Discuss problems and influence the direction Thelop is moving.

It seems to me that a project would have to maintain a large "dictionary" that defines all the allowable "words" (acronyms seems the better description of the code I've seen so far) and their meanings. In any sizeable project in which there are a large number of concepts -- objects, methods, classes etc. -- this data dictionary will become huge and take a long time to learn.

A "typical" dictionary might contain about 300 ThelopWord's and perhaps 50-200 additional words. Most of these words are pretty obvious objects (like File, Window, Text), properties (Color, Width, Height), data types (Double, Long, String) or units (Inch, Cm, Hour). Lets assume about 30-40 printed pages. An evening should be enough to get an overview and remember 90% of them.

How can new programmers get up to speed with LOP code without constantly flipping through the project dictionary every time they want to create a new function?

ThelopProgramming may be 90% using APIs and 10% designing APIs. Using an existing THELOP API should be easier because of its consistency. New programmers rarely design APIs, perhaps they implement them. Anyway, if they create names someone with THELOP experience should check them regularly (weekly at first) and initiate change, if needed. Remember that we don't talk about the body of the functions, only about the API.

How can you be sure that multiple programmers do not use the same names for different concepts without bogging them down in bureaucracy?

This is not a question of bureaucracy, but of giving API quality more priority than IfItWorksItIsOk. If anyone finds a name that is inconsistent he has the right to ask for change. In case of doubt there should be a "language referee". A new concept and its name should be discussed, not just introduced be someone.

Basically, how does LOP scale beyond a single programmer?

The size of the team is not the problem. LOP is easy to use (1-2 orders of magnitude easier than mastering C++) and easy to teach, it reduces the amount of documentation and communication. But LOP is a reuse technology aiming at a very high code and API quality. It will pay off, but at first it is an investment. You must have an environment that really wants this quality. You can't add LOP to a DeathMarch.

What is the largest team that you have worked on who used LOP?

The largest team that used LOP up to now had 4 members.

(Copied from ThelopLanguage, asked by NatPryce, slightly rephrased)

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?

I'm sorry, I can't offer you such a LopCaseStudy?. I also wouldn't know how to quantify this. LOP is in effect OO thinking combined with a strong sense for consistency. There is no need to change analysis or design methods, but there may be always a way to improve analysis or design by finding the best possible abstractions or the cleanest modularisation. LOP as a language talks about real world problems and real world objects, implementation objects or constructs live a level deeper.

How is the vocabulary documented and enforced?

The vocabulary description was made available as a MS Word document. There were also word list files that were produced and used by utilities that checked e.g. the project vocabulary.

How is code from different sources integrated -- what if they have different vocabularies?

If you integrate a lot of different libraries or sources, it may result in a complicated and inconsistent situation. There is no easy solution, but LOP may show you a way out. You may chose to hide an API completely by some form of wrapper functions or facade classes. Sometimes only certain aspects are unified. LOP works for long term (and cross project) reuse, so usually the situation improves step by step.

How are multiple programmers coordinated to build a LOP language and maintain the consistency of the LopVocabulary??

The vocabulary is documented and kept up to date. If you have a larger team one member should act as "language coordinator". Important decisions should be discussion in group meetings.

I'd be interested in 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 has been built up.

The overhead of a vocabulary is small, but we have not measured it. I remember a small OCR subproject (about 8 man months) in which only a few words like "Ocr" or "Glyph" were added. I would expect that the ratio (new_words/man_month) is in the range 0.5-2 if you use the current ThelopLanguage as a starting point. So its not a big thing.

New programmers rarely design APIs

What is your definition of API? Does this imply that LOP only applies to external interface design and not internal method calls? All programmers should be defining lots of method calls, i.e. follow some of the basic refactoring principles and keep each function short and to the point. Does this mean LOP does not apply within a program?

I assumed new=inexperienced, which may be wrong. Here in Austria (and in Europe in general) it is common that programmers stay for 5, 10 or more years.
It is still a problem to make programmer productive as fast as possible, but teaching them good C, C++, Java or BASIC style seems much more a problem than adding a LopLanguage.
API is "everything that's externally visible", but there are more and less important functions and interfaces. Producing lots of small functions may be a way to structure code, but if these functions are not built for reuse, it makes reduced sense. Producing lots of small functions for reuse can only be done intuitively (and without documentation) by using a common language and certain naming patterns. That's what LOP and THELOP are all about.

CategoryThelop