If you look for quick examples of common ThelopWord
's then you have found the right page. This should look familiar:
File Str Chr Dialog System Timer Point Rect Image Text Window Menu Font Bit Pixel Button Line Object Parent
Set Get Cpy Cvt Find Ins Del Clear Add Equ Cmp Sort Ins Open Read Write Close Draw Print Create Free Sort Is
Dim Height Width Size Pos Ind Count Name Limit Day Month Year Color Status
First Next Last All Fast Upper Lower Hi Lo Min Max Hor Ver Cur
But be careful! The ThelopLanguage
is a MetaLanguage
and not a simple subset of the English language. So the words are tuned for building ThelopName
's. Each word has an exact definition given in it's ThelopWordSignature
. The word's meaning may deviate slightly from common English usage and will usually carry additional information. Understanding will be easier, accepting this will be more difficult for an English native speaker.
So, I ask again. Why all the abbreviations if you want to make this usable by normal people? Or even programmers. Use MeaningfulNames. -- SunirShah
Among the 70 words above there are about 20 abbreviations. A usable ThelopVocabulary?
of about 300 words will contain about 40 abbreviations. So I would not use "all the" to describe the situation. There are a number of reasons for these abbreviations.
Some of the abbreviated words are long and THELOP has a heart for the LazyProgrammer
(this includes me):
Other word originate from the standard C library:
Str (strcpy, strstr, strlen)
Cpy (strcpy, memcpy)
Cmp (strcmp, memcmp)
There were times when I thought that APIs look more pleasing and readable when there is some symmetry in length:
And there were times when I thought that the most important and common words deserve to be three letter words:
Cvt(instead of Convert)
Cmp(instead of Compare)
So the ThelopLanguage
developed and changed over time. It does not try to be a formal language and does not pretend to be "true" English. This will become more visible if we walk on to WordSignature
Having trouble coming up with a name? Need a naming system like THELOP or Hungarian to help? Stop. Your objects are probably too complex. Reduce the scope of your objects until each object is doing just one thing. If you do this enough, you stop having too many names in one name space and it stops becoming difficult to come up with clear, short, unique names.
Programming problems are often like liquids. It is easy to shape them, but you can't change their volume. If you try to reduce one dimension you will inevitably increase others. Many small objects (current Java: 3500 classes) create problems of their own and consistent naming of methods across object borders is still not guaranteed. What really counts is to reduce the surface of a programming problem (a liquid). Obviously cubes and spheres have the high symmetry and balance of dimensions that is missing in programming paradigms. LanguageOrientedProgramming tries to introduce such symmetry in various forms.
I am having trouble coming up with a name? Need a naming system like THELOP or Hungarian to help? Stop. My objects are probably too complex. Not only that but the shades of meaning between the objects are too subtle to be conveyed in any reasonable length name. I tried refactoring. I tried beating my head on the ground. Some solutions to some problems are just ugly.
I once even had aproblem that was so bad that in the end I took the embedded comments out because they were misleading too. The only thing that made sense was the 500 word comment before the function and raw C code, with variable names like t.
Having said that, for coding the solution to the right problem Thelop is great I am pretty sure that a lot of people do things like it already. Devloping a standard dictionary might help but the abbreviations seem to go too far.
- Ver is not good for Vertical because of Version.
- Cvt I dont like would prefer Chg if you really wanted three chars.
- Hor is not enough for horizontal
- Vert is not good for Vertical because of Vertex.
Will the bsll og dtring ever stop unravelling to get standard that works outside of one problem domain. I guess not which is why I use my own Thelop.
Everything you say seems to make sense. But don't judge quickly and don't judge based on your personal habits. I'm sure that you use abbreviations too. Decisions have to be made. The word Version is rare, it doesn't hurt to write it in full length. If you do 2D-problems (e.g. image processing), you may have dozens of functions with Hor/Ver-modifiers and it would be a PITA to write them in full length. Sometimes I may be wrong, but I invested a lot of time and used and refactored THELOP for many years.
"Some of the abbreviated words are long and THELOP has a heart for the LazyProgrammer
What about having a heart for the lazy reader
? Maintaining a program is an order of magnitude more expensive than writing it. Maintenance is usually done by programmers who didn't write the code and are not familiar with the code or project. Therefore it is important to write code to be easy to read, rather than easy to write. For example, names should be unambiguous. Abbreviations introduce ambiguity. Addressing ambiguity through a dictionary of abbreviations and their meanings doesn't help someone who has to read the code since they have to constantly refer to document other than the source code. Furthermore, a separate document is likely to become out of sync with the code, especially when it is being maintained or modified under tight deadlines. --NatPryce
I'd argure that URL is an acronym, not an abbreviation. Acronyms are OK if they are standard jargon in the primary subject domain of the code. Abreviations are more troublesome, because they are generally not related to the domain (there may be some exceptions): they are related to lazyness. Omitting vowels is also bad. -- DaveWhipp
- We are talking on a very theoretical level. If we would look at certain code sample, we would surely agree on what is good and what is bad practise. You may argue that "Application" is better than "App" or that "UniformResourceLocator" is better than "Url", but these abbreviations do not create the maintenance problems. To have the unabbreviated words in function "ShowPage" doesn't mean that nothing is abbreviated: perhaps what it really means is "BrowserOpenUrlWindow" and the information that an external browser is activated, that a window is opened, that an url string has to be passed as an parameter has been abbreviated to *nothing*. In a THELOP controlled environment you could e.g. be sure that a simple text search for the word "Browser" would give you all places where browser functionality is defined or used. And you might do a cross project and perhaps even a cross language search over your complete source pool. That's what really helps you to maintain a project or reuse the work of your fellow programmers.
You are comparing two completely different concepts: abreviation and abstraction.
It goes without saying that action caused by calling a function is always defined by its implementation. The name of the function should reflect that action, so both Show
Page and OpenURLInBrowserWindow are good names for a function (although I'd prefer Show
Page or ShowURL because it hides how
the function is implemented and highlights
the function does). Both names provide an abstraction to the reader and are easy to read, and so don't unnecessarily impede the work of the maintenance programmer.
However, the use of abbreviations is a completely orthogonal issue to abstraction, and the naming of abstractions. Abbreviations adversely affect how easily one can read a name, whether or not that name is a good description of abstraction. For example, would you rather maintain code with functions called Shw
Pg or OpnURLInBrsrWndw. or code with functions called Show
Page or OpenURLInBrowserWindow?
See also: ThelopNameExample