Re: What's the best language to start with? [was: Re: Should I learn C or Pascal?]

[rgilbert@unconfigured.xvnews.domain (Bob Gilbert)]

In article <01bb8df1$2e19d420$87ee6fce@timpent.airshields.com>, "Tim Behrendsen" <tim@airshields.com> writes:
> Bob Gilbert <rgilbert@unconfigured.xvnews.domain> wrote in article
> <4v9nei$kjf@zeus.orl.mmc.com>...
> > In article <01bb8c89$9023e3e0$87ee6fce@timpent.airshields.com>, "Tim
> Behrendsen" <tim@airshields.com> writes:
> > > 
> > > And they don't get wrapped up in implementation
> > > details if they write it in C? 
> > 
> > As compared to assembly, I'd say they certainly won't get wrapped
> > up in the details (I'd prefer Ada over C though, C can be a bit 
> > cryptic).  I can write in a HOL and not worry about memory addressing
> > modes (darn, forgot to load that data page pointer!), I don't have
> > to worry about internal data representation (now can't I just shift
> > right to divide by two, even if it is a float?), I don't have to
> > worry about pipeline conflicts (I just read X into register R1, so
> > why can't I test R1 in the very next instruction?), and whole host
> > of other architectural details that obfuscate the lesson to be
> > learned (sort algorithm, or whatever).  And what happens next term
> > when the school replaces the system on which they teach assembly
> > now for some new and different system?  Now your students have to
> > go through the learning curve (of assembly) all over again.  At least
> > HOL's are fairly portable and stable across platforms.

> Well, all that is certainly true if you intentionally go out
> and find the most complex, arcane architecture you can find.
> If you start with a nice, simple one like a 6809 or 68000 or
> something, then implementation details are practially nil.

There aren't many processors being made today that don't employ
many (and many more) of the architectural features I mentioned
above.  

> > > My primary point is
> > > when it's implemented in assembly, and you have to
> > > manually move the bytes from one location to another
> > > rather than have the compiler "carry them for you",
> > > you get a better view feel for not only what the
> > > algorithm is doing, but what the computer itself is
> > > doing.
> > I agree that learning some sort of assembly and implementing
> > a number of programs (algorithms) is a valuable lesson, but it 
> > is a lesson in computer architecture much more so than a 
> > lesson in learning algorithms or problem solving.

> Yes, exactly.  I understand that theoretically computers
> can be defined in terms of any architectural abstraction,
> but that's not the point.  The point is to give the students
> a foundation to build on, and a very simple computer
> architecture is much simpler than complex language syntax.

Apples and oranges.  Learning problem solving and understanding
basic computer architecture are two different things, although
I do agree that understanding the underlying architecture helps
in developing solutions (gives a target to shoot for), it can 
also hinder the process by prejudicing the student's thinking
into terms of the limited set of known targets.

> > > The most important thing a student can learn about
> > > computers is the fundamentally simple nature.  The
> > > mystery of execution *must* be broken down in order for
> > > the student to being to think like a programmer.
> > > Once they can think like a programmer, all the rest
> > > of the knowledge they learn becomes trivial.

> > I think your viewed scope of computer science is tad narrow.
> > I'd like you to show how learning assembly as a first language
> > will help a student better understand the design of a relational 
> > database, or solve any of the class of problems in mapping theory
> > (find the shortest or fastest route from Miami to Seattle), or deal
> > with networking and concurrency issues.  And it seems to me that 
> > one of the largest areas in the study of computer science is language
> > theory and compiler design, and it is hard to teach that if the 
> > student isn't introduced to a HOL early (perhaps first) in their 
> > curriculum.

> Focusing on individual problems is a narrow view of learning.

I was only offering some examples of other rather large and broad subject
areas in the field of computer science for which an understanding of the 
basic architecture (via assembly language) is of limited use, and where 
introduction of a HOL early on or first would be advisable.

> All computer problems have certain things in common; they have an
> input, they have an output, and they have a set of procedures
> in between.  Teaching the student how to think in terms of
> breaking problems into procedures is by far the most difficult
> task in teaching someone to program. 

A very procedural point of view.  Many of the proponents of object
oriented design might have a problem with this view, and demonstrates
my point about allowing the details of implementation to obscure the
higher level problem solving process.

>   Yes, you can pack algorithms
> into their head, but that doesn't mean they are learning why
> the algorithm is way that it is.

Not at all what I am suggesting (blind memorization of algorithms).  
I am suggesting that they look at various problem domains and see 
some of the more classic solutions as examples of how they might
attack a new problem, or as is more often the case, recognize a
problem as belonging to an existing domain for which mature solutions
may already exists, and avoid re-inventing the wheel.  They are
then free to choose, modify, or even invent new, one of the many
available solutions based on the specific architecture they are 
dealing with.

>  I'm reminded of the one guy
> on another thread that said "I learned Quicksort, but I didn't
> really understand it."  This is what happens when you focus on
> packing knowledge, without teaching understanding.

Agreed.  Sorting is a good example of a classic problem domain for
which there exists many mature solutions.  I still fail to see how
implementing one or more of these solutions in assembly vs a HOL
improves the understanding of the problem domain or even the specific
solution (Quicksort, Bubble sort, whatever).

> Let's take the RDB example.  If I take the normal CS graduate,
> sit them down in front of terminal, and say "whip up an SQL
> parser that's comparable in performance to Oracle", would
> they be able to do it based on the knowledge they have learned
> in the normal CS program?  I don't think it's an exaggeration
> to say "hell no."  Why?  Because the haven't been taught The
> Algorithm that will compare to Oracle.  They would have no
> clue where to start.  This is my experience with testing new
> graduates.

> Now what if that same student had gone to the Tim Behrendsen
> Academy of Programming, and solved new problems every day in
> low level programming, and left with a degree in thinking, but
> was relatively light on HLLs and his Bag O' Algorithms was
> heavy on the basics, but light on the specifics of "mapping
> theory" or whatever?

Mapping problems comprise a rather large and broad problem domain
(I gave the example of finding the shortest route between two cities,
but there are many, many problems that fall into this category).
Many mapping problems exist for which solutions still have not been
developed, and many of the solutions that do exist have somewhat
large orders of computational complexity.

>  I think my student would get way
> farther than this standard CS student, because they would
> know how to take complex problems such as SQL optimization
> that hadn't necessarily been seen before, and could make
> a reasonable go of it.  Not that either would be able to
> reproduce a multi-hundred man year product like Oracle. :)

I really rather doubt that Oracle used a bottom up approach in
the design of their database products.

-Bob