Teaching python (programming) to children

[David Bolen]

Cliff Wells <logiplexsoftware at earthlink.net> writes:

> Not knowing Ada makes me reluctant to disagree, but I wonder how a language 
> so strict that writing sloppy code is difficult can be a very flexible 
> language.  Usually those things are mutually exclusive. Training-wheels on a 
> bicycle are a common comparison... safety over flexibility.  Maybe this is 
> why you need inline Fortran/C/Assembly in your Ada code - to get around the 
> restrictions of the language.

Generally it works out because in the areas that Ada is strict, it
also contains a wide variety of declarative capability in order to
provide the needed flexibility.  Although I don't think I'd be as
confident to say that sloppy code can't be written in Ada, since it's
easier to write neater code with built-in language features, I do
expect that in general code is less sloppy.

As one example, while Ada's type system is strict and includes
features such as range and value checking (both compile and runtime)
to lock down a wide variety of coding errors, it also permits enough
declarative information to be encoded in the source to give the
compiler enough information to perform those checks while still
permitting the application to accomplish its goals without trying to
defeat the protection.  You work with the type safety system rather
than against it.

In Ada, you don't tend to just define variables as integers, or
floating point, but rather with appropriate ranges, as subtypes of
other existing types, etc...  Enumerations are hard types and not just
substitutes for integer values.  The compiler and runtime enforce type
rules, but it's a nice synergy with the more flexible declarations.

To be honest, I see a lot of similarity of the strong typing between
Ada and Python - it's just that Python pushes everything dynamic and
at runtime, while Ada contains lots of language features for static or
compile time type handling.  Both of them contrast with something like
C/C++ where many types - particularly numeric - are coerced and
converted automatically all the time behind the covers and without any
explicit source support for such conversion.

I don't think the training wheels is a good analogy, since those are
quite inflexible and externally imposed.  In effect, it's an imposed
limitation (for safety) but without any changes to the bicycle itself
to let you define the world such that the safety is in context.
Unfortunately, I can't come up with a counter analogy at the moment.

> True, I don't know jack about Ada.  I don't know jack because I've never 
> known anyone (other than yourself) who claims to use it.  This doesn't make 
> it a bad language, just an impractical one.  (...)

I don't think that can be a blanket statement - as with any language
it may be better suited to some venues than others.  I'm sure in many
circles most of the languages discussed here (including Python itself)
could be considered impractical, and in some of those areas (e.g.,
embedded systems) Ada is more likely to shine.  And I'm not sure that
practicality in a language is a prime requisite for its use in a
learning environment.

> I think Ada had its chance and failed to claim enough interest to make it 
> relevant today.  

Even were it not in use at all (which it is, although certainly not as
prevalent in the open source areas), I think Ada as a language is
still relevant for those interested in languages (which is sort of
on-topic for this learning thread).  It contains a lot of interesting
language features (its type system, packages, tasking model for
example).  And much as Pascal might have been used in introductory
classes a while back, I would think that Ada could serve the same
purpose while not being subject to Pascal's limitations.

Clearly though, Ada is not in use to the extent of something like
C/C++, and that makes it harder to try to introduce in environments
where people are unfamiliar with it.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/