There does not now, nor will there ever, exist a programming language in which it is least bit hard to write bad programs.What does it say about evaluating programming languages?
For example, one can make a program highly unreadable by using nested blocks or using procedures with too many parameters. Similarly, low cohesion within a module or high coupling between different modules of a program can make it difficult to understand and modify. Unrestricted use of pointers can result in intractable bugs.
Thus, Flon's axiom suggest that energy should be directed in the direction of educating programmers rather than attempting to find perfect language or even formally defining structured programming.
Do we agree with it?
We agree with Flon's axiom per se but not with its consequences. That is, while it is true that it is possible to write bad programs in all the languages, it does not mean that we should not attempt to find a perfect language or define structured programming. If we had not done so, high level languages would not have evolved, since we can surely write all programs in assembly level language.
Moreover, we should also find ways to design constructs so that probability of their misuse is decreased if not entirely eliminated. For example, in Java, one cannot use pointers at the user's level, even though they are used internally to the language. This way misuse of pointer decreases.
All computing languages or computers can compute anything in theory but nothing of practical interest is easy.What does it say about comparing programming languages?
This means that no language is perfect. In other words, while all languages have capabilities of Turing's machine, each have their own inadequacies as well.
What does Turing's tar-pit say about arguments on language features?
It says that each language has limitations, thus making it difficult to get any interesting work done, by it. For example, restrictions in Pascal, as written by Kernighan, are as following:
The language is inadequate but circumscribed, because there is no way to escape its limitations. There are no casts to disable the type-checking when necessary. There is no way to replace the defective run-time environment with a sensible one, unless one controls the compiler that defines the "standard procedures". The language is closed.
People who use Pascal for serious programming fall into a fatal trap. Because the language is impotent, it must be extended. But, each group extends Pascal in its own direction, to make it look like whatever language they really want. Extensions for separate compilation, FORTRAN-like COMMON, string data types, internal static variables, initialization, octal numbers, bit operators, etc., all add to the utility of the language for one group but destroy its portability to others.
Is there any way out of Turing's Tar-pit?
The ways out of Turing's Tar-pit are as following :
These approaches will ease the task of getting specific work done.
Space is another measure of execution efficiency. Neither the program should take up large space nor consume large run-time storage. Excess storage requirement incurs expensive hardware cost. Nevertheless, often, time and space are contrary of each other -- one is sacrificed for the other. Good compiler should balance between both efficiencies.
Compiler should detect all errors as well as possible errors (warnings) in program due to inadvertence of programmers, and report meaningfully to the programmers. No errors should be leniently forgiven. Good compiler should help programmers discovering the bugs in their programs.
This might sound like this feature is directly against the portabilty criterion above, and it is! However, when carefully used, it increase programming efficiency. For example, due to marketing reason, 2 similar but with slight different programs are needed. With pragmas, programmers need not to maintain 2 copies of source codes. This makes upgrade to the program easy and consistent.
It can be useful in improving execution efficiency by avoiding the overhead of run-time configuration. The "dead" code that due to a specific executing environment can be omitted in the target executable, which improves the translation efficiency.
They compare the big and badly organized team of programmers with the big beast caught in the tar pit. No matter how big and strong is the beast and how much it struggles - it will eventually drown.
Brooks and Frederick suggested the small and well organized team of highly skilled specialists, and showed the way how this team should work. They say that if their advises are followed, then there is the possibility to build the bridge across the tar-pit.
We cannot be absolutly sure if the software companies do follow the Brooks' and Frederick's advises, and how those companies choose the programming languages and tools for their projects. But it seems to be true that there is the way out of tar-pits. The indication of it is the considerable amount of good (and big) software products appearing on the maket.