Re: Why is Ada a good choice for an ambitious beginner to programming

[Bill Findlay <yaldnifw@blueyonder.co.uk>]

On 22/12/02 23:02, in article au5gnq$f3f$1@bunyip.cc.uq.edu.au, "David
Wright" <davidw@uq.net.au> wrote:

> 
> "Bill Findlay" <yaldnifw@blueyonder.co.uk> wrote >
>> 
>> Actually, if the interest is in learning to program,
>> rather than learning to use a specific toolset,
>> then neither IDEs nor debuggers are necessary,
>> or even particularly useful to a beginner.
>> 
> 
> Hi Bill,
> 
> Of all the extremely useful advice to date (thanks everyone!) this concise
> remark reached out and grabbed me by the throat! If by this you are
> suggesting that 'programming' should mean more than the ability to know and
> use the elements of  'a' language and an IDE, but rather should subsume a
> thorough understanding the central abstractions or constructs (e.g.,
> looping, arrays, recursion, pointers etc)

That is the valid subject matter of beginners' programming courses.

> which characterise the various
> language 'genres' (e.g., logical, imperative, functional, object oriented
> etc), then we are very much on the same wave length.

Well, I don't want to dampen your enthusiasm,
but perhaps you read rather more into my posting than I intended.

To begin with, I'll clarify what I did mean.

Beginners to programming have a great deal of detail to absorb.
They do not need to be burdened by learning merely contingent
factoids, such as how to operate the not-necessarily-intuitive
user interface of an IDE. They do need an effortless text editor,
and a trivial means of invoking a compile-and-run cycle.
A very simple IDE (e.g. AdaGIDE) can provide these facilities
with no harm done. Anything more can easily become a distraction
from the real issues.

As for using a debugger, the not-necessarily-intuitive
user interface argument applies there too, even more strongly.
More importantly, it is almost never necessary (at beginner level anyway)
to use a debugger when learning in a supportive language like Ada 95.
This is because debuggers are mainly useful for gathering circumstantial
evidence to support working hypotheses about obscure errors.
Beginners in Ada 95 will rarely experience the kind of obscure error I have
in mind. Even if they do, they will seldom have the conceptual framework
necessary to develop and exploit debugger-provided evidence.

I would go further and say that resorting to a debugger focuses
attention on the miniutiae of individual statements, when beginners
need to develop skill in seeing the bigger picture - i.e. the overall
program structure, with its pre- and post-conditions and invariants
(not that they need to think in formalistic terms, just that they need
to be aware of their program as a cumulatively logical construction).

In other words, they most need to develop the skill of debugging programs
by critical reading. This is crucial, because it develops the very skills
that will enable them to avoid creating bugs in the future.

> Perhaps I am a perverse recalcitrant but it has always bemused me to read
> well meaning contributors in various newsgroups tell self-teaching newcomers
> to "just choose a language and learn it thoroughly". I would have thought
> that a preliminary step would be to delve broadly but thoroughly into the
> particular 'personalities' of the available generic styles of programming
> (logical, imperative...) before choosing and committing to a specific genre,
> language and IDE.

Merely learning 'a language' is absolutely not a worthwhile goal,
but I have to stop short of agreeing with all you say here.
The comparative study you recommend has its place, but that
place is not in a course for complete beginners.  Very few can read a
theoretical treatment and see through it to its practical ramifications.
The comparative studies you suggest begin to have value for sophomores,
but for only a very few, atypical, beginners.

> I wonder whether this comparative approach means that we have moved beyond
> programming into the domain of computer science. But if that is true, I am
> unaware of any formal courses that have as their principal raison d'etre a
> 'thorough' (not cursory or introductory) exposition of the comparative
> differences and merits of the main styles of programming. I stand to be
> correct here.

Such courses certainly exist in CS curricula.

David Watt's series of programming language books (especially "Programming
Language Concepts and Paradigms", to which I was a contributor) covers the
sort of ground you have in mind.

In the Honours curriculum (read CS major in the US) that I am
most familiar with, a deep comparative study of the fundamental semantics of
programming is a Junior level course, assuming an intuitive familiarity
with the basic ideas that is founded on 2 years of theory and lab classes.

> I detect the mutterings of those who (rightly) propound the educational
> theories of  'active learning', 'constructivism', 'hands on, minds on' etc:
> "To learn how to program, they need to program, they need to code and code
> some more!"

Count me among them. That's not enough, of course.

>Correct. But that's not my point.  First, we (I) need to explore
> the nature of programming and its different styles. This can be done
> 'actively' by thinking 'actively', by reading 'actively' and by actively
> discussing these issues with likeminded searchers.

If you are a beginner in programming, you are an unusual one.
If that approach works for you, great.
I could not recommend it for most of the 400 freshers I used to help teach
"Programming for Beginners" (in Ada 95).

> It seems that for many if not most, learning to code, like the prospect of
> consummation, causes one to be lose patience and rush in; both ventures,
> perhaps, have a certain mindless sex appeal.

Indeed, much of a first course is dedicated to persuading those who are
prepared to listen that programming and coding are not the same thing.
But this is not to say that even the more receptive beginners are ready for
an elaborate meta-discussion about the semantic nuances of concepts they
have only begun to master.

> Bill, do correct me if I have misconstrued what you had intended to say. I
> would also be keen to hear any elaborations you may have.
> 
> Thanks for being there. ;P

You're welcome!

-- 
Bill-Findlay chez blue-yonder.co.uk ("-" => "")