[clean-list] GRS vs LTRS

[Vag]

Universality vs Versatility
---------------------------

Notice that people use PLs not for "expressing any computable
function" but for solving real world problems that end users face
with.

Turing equivalency is a absolute PL power, utmost physically reachable
limit. It may be interesting for physicians and philosophers, but has
nothing to do with programmer job or maybe even computer scientist
job.

Let call PL _suitable_ for problem domain if any needed job can be
completed in reasonable time using tolerable means. Let call PL
_versatile_ if it suitable for _most_ (and most popular) problem
domains.

Versatile languages is obviously much less powerful than
Turing-equivalent ones. It may be easily seen on personal experience,
source code analysis and experience of Flow Based Programming.


No glimpses at PLs
------------------

It is very important fact that PL X may be adequately evaluated by
people if and only if that people has mature knowledge of basic
programming techniques in X. Very often difficulties and hitches with
implementing one or another familiar trick on new programming language
characterizes not that language but lack of solid programming
techniques equipment. I suspect that many hypothetic languages was
underestimated and mistakingly rejected with their imaginable weakness
associated with turing incompleteness just because familiar languages
are turing complete.


Programmers Do Not Tie Knots
----------------------------

I have a clingy impression that cycles in data structures are almost
not used even in programming pearls, not to mention common practice.
Is it for my personal ignorance, or for juvenility of functional
programming techniques panoply, or its intrinsic attribute (so it
never be widely used)?

Can somebody suggest any ways to analyse source code that able to
perform queries of this sort on given large code base with relatively
small programming efforts? Then we will have certain and heavily
justified answer with strong evidence.


Engieneering is Restricting
---------------------------

Each added feature increases PL expressiveness and make typical
program patterns concise but it also brings in ways to do mistakes,
add paths to confusion, hoicks learning curve and drastically
complicates automated reasoning. Fully automated reasoning (AR) is
very important because without it tools never be scalable and robust
(take, for instance, CLEAN type system: ask CLEAN programmer, what if
(s)he required to do manual proof of type correctness each time?). We
must take into consideration not currently existing AR tools but
future ones too (CLEAN supposed to will lasting for many years, isn't
it? So ARs for CLEAN programs definitely will come into being, and by
the way, we already have SPARKLE).

More restrictions means more tools, broader application, less errors.

Almost all programs I ever seen may be implemented in functional
programming language with automatic totality checking using techniques
like mentioned in "Total Functional Programming" by David Turner and
"Ensuring Streams Flow" by Alastair Telford and David Turner. As first
step to bring growing CLEAN code base close to future standards it
will be excellent to ban cyclic data structures so programmers can be
sure they are not accidentally let one creep in. Later (when code base
become large) this may become much more expensive.

So we get two CLEAN sub languages -- fully powered one for rare
careful system programming and one for robust application programming
using ARs.