Re: What's the best language to start with

[ian@rsd.bel.alcatel.be (Ian Ward)]

In article 87ee6fce@timpent.airshields.com, "Tim Behrendsen" <tim@airshields.com> () writes:
>Szu-Wen Huang <huang@mnsinc.com> wrote in article
><4u7grn$eb0@news1.mnsinc.com>...
>> Tim Behrendsen (tim@airshields.com) wrote:
>> : Maybe I'm weird, but I just don't see assembly as being harder
>> : than a HLL, and in fact, it seems to me that it's much easier.
>> : The number of fundamental things to learn is *very* small, and
>> : I would think that being able to show a problem in terms of the
>> : "array of memory" being manipulated would just make it infinitely
>> : easier than having to wrestle with all the abstract nonsense.

Assembler is easy to understand, it has very simple instructions,
this is what makes it so useless at expressing solutions. One needs
so much of it to do anything. Besides all the small solutions have
already been done.

Besides, the second best female software woman I know, who works
for Oracle (in support ???? duh.) got a first class honours degree
in computing/combined science without knowing what Hex was, and I'd
trust her code with my life (but not Oracle's.) Simply because, her
course did not require it. If she had the brains to be able to deal
with abstract concepts, then she could do the design work, and the
simple algorithms could be left to someone else. 

[That was not what I thought of this at the time mind, I thought
she was a stupid bitch, but then in that same year I remember
defending Basic _and_ assembler against Pascal, simply because
I had not come across a problem that I could not solve (and
remember the complete solution months afterward) in my head. 
I wish I go back then, playing around for four hours a day in 
college, and then drinking ten pints of lager (56p a pint.)
Wall to wall vomitting, best days of your life.]

>> 
>> I know what you're trying to say, but you neglect what the subject
>> is trying to teach.  I don't need my students to learn how to print
>> out a string calling interrupt this function that, or that the
>> instruction *after* a branch is always executed (in some pipelined
>> RISCs), or you cannot divide by the ZZX register.  These will all
>> be useless in a few years, perhaps even a few months.  I need my
>> students to learn when and why quicksort is more efficient than
>> bubblesort, and telling them to use assembly sidetracks that effort.
>
>Let me bring it back full-circle where we started.  The reason
>I mention assembly in the first place was the number of graduates
>coming to me for a job that were failing the test I give
>*abysmally*, particularly in the areas of creating an algorithm
>for a problem they've never seen before, and doing logical
>operations.
>

There are two fundamental points here which until recently I had
not sussed, and which seem to be fighting each other in this thread.

1. Algorithmic problem solving. 
Tim here suggests that assembler should be used to teach students
how to become software engineers, because the simple structure 
of the assembly language is easy to understand. Students will 
be able to follow it, etc. Additionally, people studying this, if
(and only if) they become good programmers using this method, then
they are the type of people who can work things out for themselves.

2. Software engineering.
There are two things here, one is abstraction, and the other is
best fit solution from multiple points of reference. (The second,
I like because it works for me, I always used to call this 
abstraction, but the whole of the rest of the software engineering
community, in fact, do not seem to.)

I take no credit for this observation, it is blatantly plagiarised.

Abstraction, the software design technique of placing a model for
your design which is as wide as possible, (such as designing your
car control system to be actually a system which can handle all
vehicles up to say, 14 wheels, and then restraining your
implementation to a four wheeled vehicle, by parameters) is part
of the whole series of modern developments in software engineering,
which have been created or refined since early languages were 
created. It is in these fields that languages such as Ada95 and C++
have advantages over their earlier counterparts.

Plagiarism over.

We see modern languages providing the means to implement,
efficiently (or not), modern design techniques (such as, but not
limited to, abstraction) which are the solutions to the increasing
varying types of problems that software people now face. These
varying different approaches to problem solving are mirrored in
modern languages, and by learning (using in the way they were
intended.) languages of sufficiently different front end, the
methodology rubs off and affects the users thinking. (Of course
the methodology shall not rub off, if the programmer writes the
new language in the same way as he would have his old language.
This is why I always feel you must love the language. This accounts
for the experiences of people achieving better solutions in their
preferred language, even though it may not be the best language to
solve the problem. It also explains why people hate some languages,
which of course, they don't, they just resent having to use it.)

In contrast :

  Modern assembler does nothing more clever at the programmer
  interface than it did twenty years ago, even though they are
  miles more efficient than they ever were.

  In my opinion, the main improvements in processor technology
  have come in the internal way they get their speed. There are,
  I guess, two exceptions to this, that really affect the
  programmer, the ability to connect them together, that is
  multiprocessing... and the useful test and set instructions.

-------------------------- ~ ----------------------------

In an interesting post a couple of weeks ago, Robert Dewar,
in reply to a post about somebody who said that learning 
5 or 6 assemblers 'just for fun' that this kind of experience
was not valuable. This fits in with my pet theory on the
subject, because all assemblers are basically the same, and
they implement clever techniques below the programmer interface,
but nothing innovative at it.

Tim seems to be of the school that teaching CS should be done
in assembler because they don't have to put up with loads
of abstractions (read modern methods.) Peter on the other
hand basically is disagreeing with him, on the grounds that
with exception of new device drivers, all the easy stuff (the
stuff that is so easy it can be done in assembler just with
simple jumps, adds etc.) has been done. Modern methods have
evolved to cope with problems that could not be solved, or at
the very least old methods provided unreliable or slowly
developing solutions.
I do not think problems will converge in there similarity either,
by their very nature, the nature of new problems will diverge as
ways are found to solve existing ones.

I have to agree with Peter in this case. I do not think that
assembler is a very useful grounding for programmers, even 
though Z80 was basically my first language. I think I would
have been a better programmer had this not been the case.

Just how much speed do we need anyway? Even if hand written
assembler was faster than compiled code, which it is not, these
things need to be put into perspective. A modern high end
desktop PC will be faster than an old Cray One (400Mhz. I think)
in _less_ than two years.

>
>I chalked this up to the lack of the fundamentals being taught,
>and the students having their brains filled up so much with
>abstractions that they don't understand how to solve problems
>anymore.

It was probably just lack of what you consider to be fundamental,
however, with the very few exceptions, straight assembler will 
almost totally unused, anywhere, twenty years from now. 

Furthermore, if students were told that computers implemented,
at ground level, say, strings, and all these students'
interfaces provided strings, then they would think the bottom
level was their provided interface. There is no reason why they
need to even know assembler, these days, ten or twenty years
from now, there will be even less of a case.

>
>This is why I think assembly is the better way to teach
>algorithms; it's just you and the algorithm.  It forces them
>to really think about the problem, because they don't have any
>"training wheels" to protect them from the problem.
>

Very few people have good problem solving abilities, I agree
but a lot of this minority have developed this ability themselves,
or inherited it from their parents (or a bit of both.)

Out of these, almost nobody has derived sound software engineering
methods from first principles. They have to be taught.

>Whatever were doing now is *not working*, let me tell you.

Perhaps if you tested people differently, and employed the
people who could understand sound abstract concepts, then the
solutions your company provides would be designed better
originally, rather than having lots of clever bits of algorithmic
code to save the inexperienced design these hackers you have
employed have made. Then you may see more success, and not
feel the situation is so hopeless. :-) Inexperienced (or 
people with narrow experience) but talented
problem solvers, in my experience, often cause more damage
than they should, because they are more likely to just say,
"I can see how to do it!" and start coding. Yet all these 
problems, where it is possible to humanly achieve a viable 
solution using this technique are drying up. Unfortunately,
these problem solvers, having relied on their wits since the
day they first started to think, are the last people to step
back and think, "Is there another way of doing this?"

In the rare cases where they do, they, (like ex boy racers
turned thirty, with children,) still retain their speed but
become the safest people on the road, because they have seen
the behaviour of the vehicle beyonds its limits, and they
know not only when it is safe to speed, but also when it
is not. 

>
>-- Tim Behrendsen (tim@airshields.com)


I think Peter is on the right track here.

Best regards,
Ian.
---
Ian Ward's opinions only : ian@rsd.bel.alcatel.be