Re: is Ada still being used for teaching at universities?

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

On 28.03.11 14:19, Dmitry A. Kazakov wrote:
> On Mon, 28 Mar 2011 12:25:30 +0200, Yannick Duch�ne (Hibou57) wrote:

>> Yes, Ada is not formal in the mathematical sense.

(Mathematics, like Ada, is not formal in the mathematical sense.
That's not a hindrance, though, to either practising  mathematics
or to teaching it.)

> A programming language must be formal in terms of the science of
> programming, which does not exist.

Trying to strive for the science of programming is possible. Doing so,
then, there is even more reason to try teaching the parts of programming
that would be considered essential, after finding these parts in a
scientific way.

What are the essential parts of programming, and how to find them,
scientifically?

Begin science by observation. Evaluation of programming can find
parts that programmers have been using productively for many years.
For example, one might find procedures for measuring the effectiveness
of certain ways to define a module's (type's) interface, given a
programming situation (to be defined in a minute).

Compare programming situations by varying the parameters of these
"situational experiments".  Declare that effectiveness means that
the outcome is technically working and is understandable by
most humans concerned, now, in the history, and in the future, without
too much effort.

Continuing the module example with further definitions, a programming
situation consists of (a) human programmers and (b) a problem to be
solved.  A module can be defined in terms of data, subroutines,
and visibility.  Then, which module is effective, technically?
And on the human side of the situation, given a PL, how does
the module's definition using the PL influence the complexity
of understanding it (the human side of modules) when compared to
doing the same using another PL?

The latter question assumes the importance of understanding
which I find plausible when trying to turn to the science of
programming.  (Assuming that efficiency, not mere functioning,
is what motivates the subjects of the experiment, too.)

Include reasoning from the psychology of thought.
(By which I mean down-to-earth topics, such as
- human pattern matching as part of the process of human understanding,
our perception matching patterns that move ("operational") or that
stand still ("denotational")
- reading comprehension, including overload resolution of program text
- ...)

Evaluating the different outcomes of programming situations,
one might then arrive at a suggestion, namely to pick parts of
programming for teaching (or language design)  that are both ubiquitous
and that have a justifiable learning curve.  Found by scientific
investigation.  "Ubiquitous parts of programming" should not mean
that everyone uses X all the time; frequency of X alone could be a
consequence of a flaw in language design (thinking of C's int).
This can be checked by the scientific method of comparing.
Justification of the learning curve must include comparison with
other solutions (e.g. other languages), too.

Drawing upon programming literature for scientific evaluation
the subject "Best Practice" is a source of information about
possible choices of what is essential in programming.
Essentials define a goal and following it we are led to the human
prerequisites of ever arriving at or near it.  These would be the
facts that one must know, the skills that one must acquire, in order
to approach the essentials of programming.  Like: procedure call,
modular arithmetic, objects in memory, ...

Experiment:  Leave out a fact or a skill and observe the programming
situation. The experiment can be performed as a retrospect, or by
comparing languages that do or do not have the "fact" (hence require
no knowledge of it).

Eventually, the result of observation and reasoning will be a formalism
of just the features of programming languages that are  considered
essential.
The formalism is not just technical, it refers to programming
situations as well.