What Is Programming

This page offers a very short sketch of what I think that programming is all about.

The experience of programming starts with implementing algorithms using the basic commands of a programming language. But that's not really programming. It's just the inevitable lowest level of the craft. Adding colors to a canvas doesn't make an artist. Adding commands to a source doesn't make a programmer. There must be an higher overall structure or order to make programs functionally and aestetically working.

Structure comes into programming by the creation of building blocks: basically data structures and functions, but there are other names in use too - objects, methods, components, modules and many more. Often these granules - to invent a new term - are packaged as libraries and executable. They are created for a special application and maintained with considerable effort. This effort makes more sense if you reuse them for other programming tasks.

Reuse comes into programming because everyone wants that the expensive developments to become easier, faster and cheaper. But reuse is tricky, it doesn't come free. You have to put additional effort into the granules to convert them to error-free and easy-to-use tools. The problem is that you can't measure the quality of what you do at the time of production. You will only find out over the years, when reuse has happened over and over again. It would help if there were a "Theory of Reuse" or at least a "Theory of API design" but there is none. Currently the place of such a theory is taken by "do OO programming and everything will be well". That's not enough.

Existing systems have lots of features but lack simplicity. The MS Windows Win32 API is documented in 5-Volumes (about 4000 pages). The Java Runtime library 1.2 contains about 3500 classes and about 10 times as many methods (in fact no-one knows their number). While this may be impressive, it doesn't make these systems easy to (re-)use. Future systems will become even larger, and we will experience that producers will create more and more features at an increasing rate. But it won't make better systems.

APIs can be made simpler and easier to use. It's not difficult and it's not in the interest of the large corporations, but it can be done. We just have to add an additional level of abstraction by the creation and use of a meta language. If we use a meta language consisting - just like a natural language - of words and syntax, then many thousand function names can be expressed with a few hundred words and they can be made consistent. We gain an order of magnitude in simplicity.

The basic observation is: even identical functions named "abc" and "DrawLine" differ in quality, in readability, in consistency with their function and in the expectations produced in the mind of the programmer - and therefore in their quality for reuse. If you fully exploit this quality difference you will work with the meaning of words like "Draw" and "Line" and do LanguageOrientedProgramming. This may look simple, but it isn't trivial. It is not about changing the names of functions, it is about making functionality and names meet. It has similar depth and potential like the growth of a natural language.

While LanguageOrientedProgramming is a general concept, it has to be implemented in a concrete form. The implementation chosen here is called Thelop (THE Language Of Programmers). That's why this wiki is named ThelopWiki. But just as there a many natural languages like English or Spanish, there will be a number of "meta languages for programmers". It's inevitable. Thelop is just the first step.

When you first see a meta language you won't understand a word. If you think you understand, you even may be mistaken, because a large number of these words are normal English words. The meaning of the words may be different in subtle ways. There are hidden rules that you neither see nor appreciate.

When you start to think in a meta language, you aren't working in a programming language anymore, you are beyond it. Your language will describe the problem at the level of abstraction that you like, unbound by technical constraints.

-- HelmutLeitner

© ThelopWiki Community zuletzt geändert am November 15, 2004