🚀 go-pugleaf

From article <6774@titan.UUCP>, by rossj@titan.UUCP (Ross Judson):
> I have never worked with Ada.  It appears to be an excellent production
> language; that is quite likely its best use as well.  Trying to introduce
> the concept of packages, declarations, concurrency, exception handling, et
> cetera at the introductory level is foolish.  Remember, we are dealing with
> students who have difficulty understanding the difference between
> pass-by-reference and pass-by-value!

    In Ada, they don't need to worry about how parameters are passed,
    only whether they are "in", "in out", or "out".  As for the rest,
    nobody is asserting that students who have taken an introductory
    course is going to be an Ada expert, any more than a child who has
    had 16 weeks of Interactive English is going to be an English expert.

    But let's look at these Ada concepts: if they can understand what 
    an interface is, then they will have no trouble with the idea of a
    package.  As for declarations, it makes sense to have to obtain
    (or create, if you prefer) an object first.  Exception handling
    is simply "What to do if something goes wrong in this environment";
    nothing un-intuitive about that.  With a properly-written text (and 
    I grant you that there are not many Ada texts which don't assume 
    previous knowledge of another language), these concepts are OK. 
    As you mention above, there are some things about programming
    languages which are difficult to learn, such as the difference
    between pass-by-reference and pass-by-value in Pascal.  The reason
    for this is that pass-by-reference forces you to keep two different
    environments in your head at the same time, whereas pass-by-value
    is clean and modular, thus easily understood.  Similarly, specifying
    "in", "in out", or "out" is clean and modular, thus easily understood. 
     
> o	Ease of use and programming (advanced user interface).  

    Great for a Hypercard system designed to be used by non-experts;
    but we are training professionals here, not unsophisticated users.

> o	The teaching of reuse _early_.  

    Which I strongly endorse, and which Ada strongly supports.

> o	Beginning Smalltalk programmers are isolated from the hard "machine
> 	realities".  They don't have to worry about storage, data types,
> 	garbage collection, or any of the other nonsense that their lives
> 	will be concerned with when they hit the real world :-).  They can
> 	focus on _concepts_, and think in _abstractions_.  

     Now HERE is where the real problems come in.  The time to focus
     on concepts and think in abstractions is when you are writing
     your package specifications.  But do we really want students 
     to only write specs, with the impression that implementation 
     is just a trivial thing, free from all that nasty mental work?  

     If we want to simplify the student's life, we can provide underlying
     abstractions for the student to use; for example, implementing the
     five basic operations of relational algebra is relatively easy if
     you have a generic B+ tree at your disposal, properly documented
     with respect to time and space requirements.  But PLEASE, let's not
     have students thinking they can just go out and simply write a spec 
     for Ackermann's function!!!  Nor, IMHO, should they harbor ideas
     that will cause them to wonder why anyone would ever worry about 
     any time vs. space tradeoffs!  Indeed, these questions are at the
     very heart of what software people do, and are therefore properly 
     placed right in the center of one's introduction to computer science. 


     Bill Wolfe, wtwolfe@hubcap.clemson.edu