As a side-note, one recurring pattern I like on Wiki is to have a separate discussion page for a topic. Helmut might want to cut the discussion portion out of this LanguageOrientedProgramming and (at least for now) and paste it to LanguageOrientedProgrammingDiscussion. That will let him use the LanguageOrientedProgramming page to clearly articulate LOP.
-- JohnPassaniti
ThankYou for your suggestion. As a newcomer I appreciate any helpful hint. I left some of the questions on LanguageOrientedProgramming because they seemed to push me in the right direction. But anyone is invited to change this arbitrary separation.
I am very surprised how this developed. Being new to the WikiWikiWeb (4 days) I had no high expectations. Now I'm very impressed how open-minded, tolerant, curious, respectful, warm and pushing this community is. I feel at home!
Questions:
- How does this differ from the programming style of the ForthLanguage or LispLanguage in which one builds high-level domain specific languages out of the primitive mechanisms provided by the base language?
- On one hand: yes, there is a similar spirit. On the other hand: isn't all programming "building high-level from low-level"? So if we all do this, nothing is said about the quality we achieve. All good programmers strive for readability and consistency, but there is usually a job waiting to be done. LanguageOrientedProgramming and the ThelopLanguage make these (and other) ideas the number one issue.
- Yes, all programming is about building high-level constructs from low-level constructs, but Forth and LISP emphasise programming as the task of building high level languages from low-level constructs, and tailoring the resulting languages to the problem domain so that they are extremely expressive in the terms of that domain.
- What are the minimal capabilities for the underlying language to be a suitable substrate for Thelop?
- There are no fixed minimal capabilities but a ThelopHostLanguage should allow names consisting of about 30 characters. Most ThelopName's are shorter. Typical ThelopName's are built from 3-6 ThelopWord's consisting of 3-5 characters each. I have not done statistics but >90% of all ThelopName's should be in the range of 8 to 20 characters.
- Have you ever seen Smalltalk? Why are you reinventing something that's been working well since the 70's?
- I know Smalltalk only a little. THELOP is not a programming language, therefore THELOP is not in the position to reinvent Smalltalk. THELOP works on top of e.g. BASIC or other programming languages, improves readability and leads to OO thinking. It may be that Smalltalk implements a lot of LOP principles and needs THELOP less than other languages do. But I'm just scratching the surface of LOP, so may be it is too early for you to judge.
- Is this just a naming convention for making procedural code more object-oriented. How does it differ from the strict conventions used by Gtk+ or other object-oriented C libraries?
- "Making procedural code more object oriented" is usually a good thing. This may also be a valid first step for PP people. But to stop there would mean to leave 80% of LOP's potential untouched.
- What is the other 80% of LOP's potential. What does it achieve?
- It reduces the complexity of an API because it maximizes abstraction and symmetry. It reduces the need for documentation, because primarily words are documented. It increases learnability because it is easier to learn e.g. 300 words than 1000+ functions or classes. It improves API design because badly designed APIs can't be named consistently. LOP offers new perspectives and viewpoints to old and well known landscapes.
- In what way is LOP more than just another form of HungarianNotation?
- LOP isn't much interested in variable names, it just assumes that it is trivial for the programmer to find a good, readable solution. If it should turn out be be a problem for someone, I'm sure that the principles of LOP could supply some help. Perhaps using the ThelopNamingOracle? page.
- In what way is LOP more than a form of HungarianNotation for function names? Variables are important. Why doesn't LOP address them? If programmers can find a good, readable solution for variables, why not let them do so for functions as well?
- Perhaps I have simplified too much. We are not only talking about naming variables and functions but about finding the correct structures and order principles that they *can be named* in a consistent, complete and *simple* way. Doing this for functions is much more difficult than for variables. It forces to change the shape and the granularity of APIs. Yes, THELOP allows to name any existing function, but usually this is only an eye-opener and a starting point for the real work of optimizing an API. If a programmer has learned to do this then variable names are trivial. You need not learn to go if you are able to run.
- If THELOP isn't a programming language, than what is it and how is it an instance of LOP?
- The ThelopLanguage is not an instance of LOP, it is an instance of a LopLanguage. It tries to implement the principles of LOP.
- Can you tersely state what LOP is just as one can tersely state what OOP, Procedural, Structured, or Functional Programming is?
- If you didn't know OOP you wouldn't understand a single explaining sentence containing words like "encapsulation" or "inheritance", at least not in their full meaning. What does it tell you, that LOP is about consistency, orthogonality, language expectations, ...? These words have to be filled with their full LOP meaning.
- All we're asking for is an abstract. Won't you please try?
- Why does this sound like little more than the result of someone falling in love with their own naming conventions?
What's with the abbreviations in the example on the LanguageOrientedProgramming page? How is that more natural than using the full word? Str vs. String? Dim vs. um, Size? How does that fit into LOP? -- SunirShah
LOP demands unambigous words and sentences. THELOP implements this on top of ThelopHostLanguage's (like on this "c-like" language in the example). There is a tradition in C to use "str" in functions (strstr, strlen, strchr ...) that work with strings. I'm pretty sure that most C programmer would feel comfortable with functions like StrFindStr, StrFindChr or StrClear. So - at this point - the word String (in C) remains still available for building a string object.
If the language X offers a String data type, fine. Change the word "Str" in the example above to "String". Other changes will be needed. No principle of LOP is violated. Readability doesn't suffer. THELOP tries to be language independent and to create a host language independent, reusable vocabulary but not by enforcing the change of built in names, types or grown habits.
In C there are a "sizeof" operator and a "size_t" data type that produce and hold the low-level memory size of data elements measured in C-bytes. Following the principles of LOP the word "Size" must not be reused for something quite different like the number of elements in an array or collection. So ThelopForCee? uses the word "Dim" for this purpose. If a language (e.g. Java) doesn't support the idea of a low-level memory size then we may still use and need the word "Size" to express similar ideas (e.g. FileByNameGetSize or ObjectGetSizeFlat). But as there is a built in "array.length" and a tradition to use the word "Length" for the number of elements ThelopForJava? will adapt to this practise.
THELOP tries to keep names short. But abbreviations only make sense for the most common words. It seems to make sense to abbreviate "Delete" to "Del" (or "Insert" to "Ins") because these words are used so often. It pays off. But it doesn't make sense to abbreviate "ScannerGetResolutionMax" to "ScGetResMax".
It never makes sense to abbreviate a word, especially because you're lazy. Learn how to type. Not only is it harder to read, but it's harder to write. "How, did he abbreviate this? Or that? Which abbreviation? How do you spell that abbreviation?"
You may get away with "slang," though. For instance "max" is slang for "maximum." Slang abbreviations mostly come from mathematics.
C has those stupid names because linkers used to have a six character external identifier limit. Crippling your SystemOfNames by C's legacy support of linkers from the 1960's is not useful. Using "dim" is not better than using "length," which is clear. -- SunirShah
See also: LanguageOrientedProgramming ThelopLanguage
CategoryThelop
Language Oriented Programming Discussion