From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,3be76ca884705a45 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news1.google.com!goblin3!goblin.stu.neva.ru!news-transit.tcx.org.uk!feeder.erje.net!newsfeed.utanet.at!newsfeed01.chello.at!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Mon, 28 Mar 2011 19:53:10 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: is Ada still being used for teaching at universities? References: <8dd2a69d-574c-4f12-a644-ae4b2fd89709@r4g2000vbq.googlegroups.com> <4D7FA036.7020401@obry.net> <87ei686vol.fsf@mid.deneb.enyo.de> <1rts6l41zobmz.1cudqx6jeu5qu$.dlg@40tude.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <4d90cb06$0$6771$9b4e6d93@newsspool3.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 28 Mar 2011 19:53:10 CEST NNTP-Posting-Host: 487b0a7e.newsspool3.arcor-online.net X-Trace: DXC=d8IVMLF:dBX=>bdbdS?M0YMcF=Q^Z^V3X4Fo<]lROoRQ8kFZLh>_cHTX3j]=AneNhH\:i^ X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:19517 Date: 2011-03-28T19:53:10+02:00 List-Id: 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.