Re: Suggestions for topics in an Ada course?

[Brian Drummond <brian_drummond@btconnect.com>]

On Mon, 12 Nov 2007 06:39:20 -0500, "Peter C. Chapin"
<pchapin@sover.net> wrote:

>wilson wrote:
>
>> That first language, as someone commented earlier, sets up all kinds of
>> pathways (ruts?) in the brain that are very hard to modify.
>> 
>> This is not to discourage you from trying.  God knows we need more
>> people like you.  It is just a note about possible difficulties along
>> the way.
>
>Thanks for the warning. I know people are influenced, for better or
>worse, by what they already know. How could it be otherwise? Part of my
>job as an educator is to figure out how to teach people new things
>despite their previous bias. One can't work in this field without
>believing that it is possible.

Perhaps the way is to contrive half a dozen realistic examples where
errors go unnoticed (except by the bad guys!), and to show how a type
system will (a) stop some errors at compilation
(b) eliminate others altogether (for array size n, iterate over
array'range instead over 0 to n ... *)
(c) catch others via exceptions instead of propagating incorrect results

(yes, the C prototypes will have bugs built in; bonus points for finding
them!)

Create essentially the same console input system in both languages and
challenge them to break it...

>Steve's suggestion of looking at tasking is good. That is a nice feature
>of Ada and also, as he said, a topic of current interest with a certain
>glamor. I'll have to think about that some more.

This was the first thing that struck me (coming to Ada from VHDL which
is probably equally misunderstood, but where parallelism is even more
simply expressed). There is a lot of grief and woe about the difficulty
of exploiting multiple cores and how long it will take to develop the
tools to catch up...

there's a wonderful little example in Grady Booch/Doug Bryan (Software
Engineering with Ada) - ch 14 - on matrix manipulation with tasks. The
actual algorithm could be anything massively parallel; prime numbers?
searches? shading triangles? just create an array of tasks (dynamically
sized to no. of cores?) and iterate over it twice; once to feed it
inputs, once to collect the finished work.

Compare and contrast with fork/join etc...

IMO C++ has done us one big favour.

I was put off Ada for about 20 years becuse of rumours about its size
and complexity... with the acceptance of C++, that argument is no longer
valid.

- Brian