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

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

[Adam Beneschan]

jsa@alexandria (Jon S Anthony) writes:
>
 >Actually, when people use the side-ways "8" notation, the typical
 >intent is simply that of indicating "arbitrarily large" or (somewhat
 >less so) denumerably infinite (size of naturals - aka Aleph0).  Your
 >"Aleph2" is a denotation for the size of sets the size of the power
 >set of R (the reals) where Aleph1 denotes the size of sets
 >equinumerous with R.  In general you have this whole "backbone" of
 >transfinite numbers constructed (typically) via the power set
 >operation.

As long as we're getting pedantic: Is it really true that Aleph1
denotes the sets equinumerous with R?  What I learned was that Aleph0
denoted the cardinality of N (the natural numbers), but the
designation for the cardinality of R was the letter C (and I think the
designation for the cardinality of the power set of R was the letter
F).  It's natural to ask whether C and Aleph1 are the same (where
Aleph1 is the "successor" cardinality to Aleph0--roughly speaking, the
cardinality of the smallest set that is larger than N); but from what
I've read, it's been shown that the truth of the statement

    C = Aleph1

is independent of the other axioms of set theory.  I asked sci.math
about this several years ago, and I don't really remember what the
answers were (I may have printed them out and stuffed them in my files
at home), but I think they were along the lines of: The axioms of set
theory don't really give you a definition of what a 'set' is, but if
you come up with a suitable definition that satisfies all the axioms,
you may be able to determine from your definition whether C=Aleph1 is
a true statement or not.  However, no one told me whether it was known
whether C=Aleph1 or not in the "usual case" of the real numbers and
integers. 

I believe the question is equivalent to the following: Is there an
infinite subset of R that is not equivalent (equinumerous) to either R
or N?  My impression is that the answer may depend on how you define
the concepts "real number" and "natural number" and how you define the
sets R and N.  I don't know whether there's a definite answer . . .

I'm crossposting this to sci.math; maybe one of them can enlighten us.
(Sorry to all the comp.* readers for the off-topic discussion, but now
I'm curious.)

                                -- Adam

       

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

[Spencer M. Simpson, Jr.]

Adam Beneschan wrote:
> 
> jsa@alexandria (Jon S Anthony) writes:
> >
>  >Actually, when people use the side-ways "8" notation,...
> 
> As long as we're getting pedantic:...
As long as we're getting pedantic, shouldn't this thread have a 
defferent name?

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

[Craig Franck]

"Spencer M. Simpson, Jr." <mapwiz@erols.com> wrote:
>Adam Beneschan wrote:
>> 
>> jsa@alexandria (Jon S Anthony) writes:
>> >
>>  >Actually, when people use the side-ways "8" notation,...
>> 
>> As long as we're getting pedantic:...
>As long as we're getting pedantic, shouldn't this thread have a 
>defferent name?

The problem is that you never know what a thread will evolve into!
Certain threads exist as a kind of dumping ground for idle musings.
I remember pondering "If god exists, is he procedural?". Also, notice
that it has already undergone a name change.

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
The thing I like least about Usenet is that when you make a
fool of yourself, there is always a written transcript.

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

[Jon S Anthony]

In article <52eha1$o7h@krusty.irvine.com> adam@irvine.com (Adam Beneschan) writes:

>  >Actually, when people use the side-ways "8" notation, the typical
>  >intent is simply that of indicating "arbitrarily large" or (somewhat
>  >less so) denumerably infinite (size of naturals - aka Aleph0).  Your
>  >"Aleph2" is a denotation for the size of sets the size of the power
>  >set of R (the reals) where Aleph1 denotes the size of sets
>  >equinumerous with R.  In general you have this whole "backbone" of
>  >transfinite numbers constructed (typically) via the power set
>  >operation.
> 
> As long as we're getting pedantic: Is it really true that Aleph1
> denotes the sets equinumerous with R?

Well, really, that is going too far as it would presume the continuum
hypothesis.  So, you have hoisted me on my own petard.  The Aleph
sequence denotes the ascending ordered sequence of the ordinal _class_
of infinite cardinal numbers.  So, Aleph0 is the smallest, then Aleph1
is least such greater than Aleph0, and so on.  The "and so on" can be
made rigorous.  Now, Aleph0 is not only the least cardinal it is also
the cardinality of N (the naturals) or any other countably infinite
set.

It is also easy to show (after the machinery is set up) that for any
set S

   card(P(S)) = 2^card(S)

So, the card(P(N)) = 2^card(N) = 2^Aleph0.  It also falls right out of
the Shroder-Berstein Thm, that card(R) = 2^Aleph0.  So, the question
is, are there any infinite cardinals between Aleph0 and 2^Aleph0???
If not, then 2^Aleph0 = card(R) = Aleph1.  But this is the Continuum
Hypothesis (CH).  Some have claimed it is true and some have claimed
it is false.  What we do know is that K.Goedel (1939) showed that it
is _consistent_ with standard set theory (Zermelo-Frankel axioms) and
that Paul Cohen (1963) showed that it was _independent_ (both via
formal model theory).  So, it is neither provable nor refutable from
the standard axioms.  So, should it be accepted or not?

Well, that's just not obvious and further you could even argue that it
may not make sense to claim its truth or falsity wrt _standard_ set
theory.

Of course, the situation is even "worse than this", since it is not
any more obvious that for any infinite cardinal number C, there is not
some infinite cardinal between C and 2^C.


> cardinality of the smallest set that is larger than N); but from what
> I've read, it's been shown that the truth of the statement
> 
>     C = Aleph1
> 
> is independent of the other axioms of set theory.  I asked sci.math

Yes, given your defs for C and Aleph1, this is correct.


> theory don't really give you a definition of what a 'set' is, but if
> you come up with a suitable definition that satisfies all the axioms,
> you may be able to determine from your definition whether C=Aleph1 is
> a true statement or not.

The definitions do give a notion of set which is formal.  The axioms
then are specified to produce the/a desired theory of sets.
Interpretation of the axioms provides the semantics (here we are
hinting at formal model theory).  Basically, KG provided a model where
all the standard axioms are true as well as CH, hence CH is consistent
with ZF.  Cohen (with true genius level ingenuity) provided one
showing the standard ones true but CH not, hence CH is _independent_.
This situation is not unlike the independence and consistency of the
so called "fith postulate" of Euclid (two parallel lines never
intersect) and the resolution of that "nut" also involved model
theory.


> However, no one told me whether it was known whether C=Aleph1 or not
> in the "usual case" of the real numbers and integers.

That's probably because it is not known :-), and may be unknowable in
any meaningful sense.


> I believe the question is equivalent to the following: Is there an
> infinite subset of R that is not equivalent (equinumerous) to either R
> or N?

Yes, or simply: is every uncountable set of real numbers equinumerous
to R.


> My impression is that the answer may depend on how you define
> the concepts "real number" and "natural number" and how you define the
> sets R and N.  I don't know whether there's a definite answer . . .

See above...



/Jon

-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

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

[Ilias Kastanas]

In article <JSA.96Sep27200651@alexandria>,
Jon S Anthony <jsa@alexandria> wrote:
>
>In article <52eha1$o7h@krusty.irvine.com> adam@irvine.com (Adam Beneschan) writes:

...

>> However, no one told me whether it was known whether C=Aleph1 or not
>> in the "usual case" of the real numbers and integers.
>
>That's probably because it is not known :-), and may be unknowable in
>any meaningful sense.


	It is known, in a sense, about definable sets of reals:  Cantor
   showed that any closed set is either countable or it has the cardinality
   of the reals.  This can be extended to all Borel sets, and in fact to
   analytic sets (continuous images of Borel sets).  At that point, however,
   independence sets in.  One can proceed by complements and continuous
   images to define higher and higher levels of "projective" sets... but one
   needs more than classical set theory to handle them.  If one adds the
   axiom of Projective Determinacy, then all projective sets satisfy CH,
   like the analytic ones.  Of course, there are lots of _other_ sets of
   reals...

							Ilias

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

[Jon S Anthony]

In article <01bbabe7$4304be40$2bac399d@v-cnadc1> "Dann Corbit" <a-cnadc@microsoft.com> writes:

> It's the successor to the object.
> Dennis probaly loved to play the peano.
> (I'm not really a mathematician,
> my degree is in Numerical Analysis)
> ;-)

Fair enough.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

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

[Richard A. O'Keefe]

"Larry J. Elmore" <ljelmore@montana.campus.mci.net> writes:
>I believe Tim was referring to qualified students actually ready for
>college, Richard. The fact is, remedial programs should NOT be offered by
>colleges--unqualified students should never be admitted in the first
>place!!!

The students we get are the students we get.
We do what we can with them, or we go out of business.

The Liberal government here believes that the best thing it can do
for the country is spend heavily on the 2000 Olympics and cut
education by 10%.  This on top of a state Liberal government that
has had several years of closing schools (including one where the
previous premier's spouse just happened to work...).

>It is true that one can pick up assembly language on one's own, but that
>can be said about almost *everything* in computer science... Actually, I'm
>a great admirer of self-education, but there is great value in traditional
>education (and not only because it's a hell of a lot harder to get a good
>job without that expensive piece of paper called a diploma...).

Hm.  A lot depends on what you mean by "traditional" education.
I don't think giving lectures in Latin will help any more (I don't think
the places that do that teach CS, though I could be wrong).
Someone with an education degree told me last semester that "everyone
knows lectures are a bad idea".

There are a lot of things in CS that can only be picked up with a _lot_ of
background.  I have a hard time with some papers because I have only the
most elementary grasp of category theory.  Assembler is one of those things
that is easy to pick up _without_ a lot of background.  My own personal
view is that education should be about guiding people through their
self-education, helping them get the background to understand the things
they want to understand.

In a country where the government is preaching "The American model" to
universities, and believes that this means "reduce government funding;
offer market-driven teaching;  put up prices to students; have a few
really good universities that do research and maybe shut down or degrade
the rest", my own personal views don't have much influence.

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: Should I learn C or Pascal?

[David Verschoore]

[snip]
> So please, don't trap yourself in the one-or-the-other mindset.  Learn
both.  You 
> will be a better programmer -- and a more valuable employee -- for it.
> 
> Lee Crites
> Computer Mavericks
> 
Bravo!
I would like to point out that a language is a tool.  Any tool used
improperly will give less than expected results.
What makes a good programmer is not necessarily the language but the
technique in which it is used. Lean a 
language well. but more importantly, learn the technique of good
programming practices.  Once you develop your 
personal 'technique', try another language and see how well your
techniques port to the new language.

An artist is more likely able to paint a masterpiece than the man selling
the paints. ;-)

You may want to check out Steve McConnell's book Code Complete as you
learn your target language.
-Dave

Re: Should I learn C or Pascal?

[TRAN PHAN ANH]

Absolutely right.

But Pascal or C was the original question.  Start with C is what I say.  
Better yet, why not C++ then move on to JAVA?

Besides, if you can master C/C++, and JAVA, it will take you 5 min. to learn 
Pascal.  Actually, if one has a solid foundation in programming techniques and
a solid understanding of one or two languages, one can aquire a working 
knowledge of any language in no time.

From my point of view, right now, C/C++, and JAVA on a resume is hotter 
than Pascal.

Anh


In article <01bb73e3.1c6a0060$6bf467ce@dave.iceslimited.com>, "David Verschoore" <dversch@ibm.net> writes:
> [snip]
>> So please, don't trap yourself in the one-or-the-other mindset.  Learn
> both.  You 
>> will be a better programmer -- and a more valuable employee -- for it.
>> 
>> Lee Crites
>> Computer Mavericks
>> 
> Bravo!
> I would like to point out that a language is a tool.  Any tool used
> improperly will give less than expected results.
> What makes a good programmer is not necessarily the language but the
> technique in which it is used. Lean a 
> language well. but more importantly, learn the technique of good
> programming practices.  Once you develop your 
> personal 'technique', try another language and see how well your
> techniques port to the new language.
> 
> An artist is more likely able to paint a masterpiece than the man selling
> the paints. ;-)
> 
> You may want to check out Steve McConnell's book Code Complete as you
> learn your target language.
> -Dave

Re: Should I learn C or Pascal?

[Mark Eissler]

In article <1996Jul20.124025.122789@kuhub.cc.ukans.edu>,
anh@kuhub.cc.ukans.edu (TRAN PHAN ANH) wrote:

> Absolutely right.
> 
> But Pascal or C was the original question.  Start with C is what I say.  
> Better yet, why not C++ then move on to JAVA?
> 
> Besides, if you can master C/C++, and JAVA, it will take you 5 min. to learn 
> Pascal.  Actually, if one has a solid foundation in programming techniques and
> a solid understanding of one or two languages, one can aquire a working 
> knowledge of any language in no time.
> 
> From my point of view, right now, C/C++, and JAVA on a resume is hotter 
> than Pascal.
> 

Yes, but since just about everyone else has said something I'd say follow
this path BASIC -> Pascal -> C -> C++ -> JAVA. 

Jumping from nothing to C is likely to end up with nowhere. Pascal is a
simple language that will teach you certain things that will make it
easier to adapt to or "learn" C. While Pascal may not be used all that
much at a commercial level, it is still an excellent teaching language and
therefore a good place to start. 

Adapting to C is a breeze once you know Pascal. Of course, having had some
passing familarity with the concepts of programming (possibly picked up
from BASIC) will help a great deal. 

Becoming a "programmer" is something that happens in steps, not all at
once. And the learning continues as the languages evolve.

--
Mark Eissler                      |  Still in Toronto.
tequila@interlog.com              |  Still Raining.    http://www.interlog.com/~tequila/ |  Still...

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

[Tim Behrendsen]

Mark Eissler <tequila@interlog.com> wrote in article
<tequila-2007961836190001@tequila.interlog.com>...
> Yes, but since just about everyone else has said something I'd say follow
> this path BASIC -> Pascal -> C -> C++ -> JAVA. 

I think that is fine for the casual programmer.  If you want to be
a professional programmer, I think this is the *best* course, but
not the easiest ...

Assembly -> C [non-GUI] -> C-GUI -> C++

All the rest of the languages are variations on the same theme.
Here's my rationale ...

Assembly:   Learn what's *really* going on.  The most important.

C:          Learn structured programming.  C is close enough
            to assembly that a student can really *see* how the
            compiler translates the code to assembly, and really
            understand what languages are all about.

C-GUI:      Learn the concept of event-driven programming (which
            is all GUI is, stripped of the extraneous stuff).

C++:        Even though I think C++ is brain damaged, it is
            close enough to C that the student can see what OOP
            really is in the context of, again, assembly
            language. Assembly is without the "abstraction
            bias" that other languages have. IMO, the only
            thing OOP brings to the table is the concept of
            assigning methods to areas of memory, AKA objects.
            Non-OOP: Apply methods to memory.  OOP: Execute
            method abstractly bound to memory.  All the rest
            of the concepts of OOP derive from that. Obviously,
            I'm speaking from a "reality" point of view, not from
            the OO abstraction.

My point is there is nothing that is all that complicated
in computer science, if it can be expressed in the fundamental
components of programming, which are move, arithmetic, logicals,
test, and branch (might be something else I'm leaving out). If
a student is ground in these fundamentals, there is nothing else
they can't learn.

-- Tim Behrendsen (tim@airshields.com)

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

[Rick Elbers]

"Tim Behrendsen" <tim@airshields.com> wrote:

>Mark Eissler <tequila@interlog.com> wrote in article
><tequila-2007961836190001@tequila.interlog.com>...
>> Yes, but since just about everyone else has said something I'd say follow
>> this path BASIC -> Pascal -> C -> C++ -> JAVA. 

>I think that is fine for the casual programmer.  If you want to be
>a professional programmer, I think this is the *best* course, but
>not the easiest ...

>Assembly -> C [non-GUI] -> C-GUI -> C++

>All the rest of the languages are variations on the same theme.
>Here's my rationale ...

>Assembly:   Learn what's *really* going on.  The most important.
I fully agree, i did not get the  *concept*( i do not mean just the
use) of pointers and reference down without an understanding of
Assembly. I wonder how other C++ ers do this ....


>C:          Learn structured programming.  C is close enough
>            to assembly that a student can really *see* how the
>            compiler translates the code to assembly, and really
>            understand what languages are all about.

>C-GUI:      Learn the concept of event-driven programming (which
>            is all GUI is, stripped of the extraneous stuff).

>C++:        Even though I think C++ is brain damaged, it is
>            close enough to C that the student can see what OOP
>            really is in the context of, again, assembly
>            language. Assembly is without the "abstraction
>            bias" that other languages have. IMO, the only
>            thing OOP brings to the table is the concept of
>            assigning methods to areas of memory, AKA objects.
>            Non-OOP: Apply methods to memory.  OOP: Execute
>            method abstractly bound to memory.  All the rest
>            of the concepts of OOP derive from that. Obviously,
>            I'm speaking from a "reality" point of view, not from
>            the OO abstraction.

>My point is there is nothing that is all that complicated
>in computer science, if it can be expressed in the fundamental
>components of programming, which are move, arithmetic, logicals,
>test, and branch (might be something else I'm leaving out). If
>a student is ground in these fundamentals, there is nothing else
>they can't learn.
Yep this approach is IMHO the very best approach to understand almost
every *over-mystified* topic (though later on you might just switch
the other way around ..and considers "nothing compared......"). 
But when radically following this lead i think you can as well start
with BASIC to get the hunch ( while all the concepts of
branch,test,arithmic, move and logic are there also ...)

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

Rick Elbers
e-mail: rick.elbers@tip.nl

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

[J. Christian Blanchette]

> >Assembly -> C [non-GUI] -> C-GUI -> C++

This is really crazy!

It's maybe interesting to understand how arguments are passed on the 
stack, but i strongly believe that simple high-level languages must be 
learned first, and more complex one after.  Since there is a performance 
vs. simplicity tradeoff all along, the performance desire (usually for 
graphical applications) makes people learn lower level languages.  I know 
many people, including myself, who made the Basic/C step for 
performances.

C must me learned before C++, that's a point since C++ is a really more 
complex superset.

I see no reason why learning GUI programming before OOP: in my sense 
they're not related at all.  I've never did any GUI app, but the concept 
of multiple entry points is easy to understand, as well as that of 
object-orientedness (which can be found even in C programs, although 
C++/Java are more adequate).

Understanding the machine architecture is one thing, using assembly 
languages is another.  There's no real interest in knowing all the 
mnemonics of a peculiar assembly language for a C coder: knowing how 
stacks work or how system calls are performed is enough to make efficient 
C programs.

Jas.

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

[Robert Dewar]

iJas says

"C must me learned before C++, that's a point since C++ is a really more
complex superset."

This is a mistake. Learning C before C++ makes it hard to understand
what C++ is all about. I still see huge quantities of C++ code clealry
written by C programmers, and it is basically C++ written in C style.

It is much more effective to teach C++ first, at an appropriate level
of abstraction, and then later on you can introduce the low level
features of C++ that are inherited from C, and are occasionally
appropriate for low level code. 

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

[Tim Behrendsen]

J. Christian Blanchette <jblanc@ivic.qc.ca> wrote in article
<31FBC584.4188@ivic.qc.ca>...
> > >Assembly -> C [non-GUI] -> C-GUI -> C++
> 
> This is really crazy!
> 
> It's maybe interesting to understand how arguments are passed on the 
> stack, but i strongly believe that simple high-level languages must be 
> learned first, and more complex one after.  Since there is a performance 
> vs. simplicity tradeoff all along, the performance desire (usually for 
> graphical applications) makes people learn lower level languages.  I know

> many people, including myself, who made the Basic/C step for 
> performances.

The point isn't that your actually going to use it day-to-day, the point is
really understand what's going on in terms of the fundamentals.  People
who program in C who do not understand assembly are dangerous
because they don't truly understand what the compiler is producing.

> I see no reason why learning GUI programming before OOP: in my sense 
> they're not related at all.  I've never did any GUI app, but the concept 
> of multiple entry points is easy to understand, as well as that of 
> object-orientedness (which can be found even in C programs, although 
> C++/Java are more adequate).

I could go either way on this one; I chose GUI first because the student
can
understand event-driven programming without the added baggage of OOP
abstractions.

> Understanding the machine architecture is one thing, using assembly 
> languages is another.  There's no real interest in knowing all the 
> mnemonics of a peculiar assembly language for a C coder: knowing how 
> stacks work or how system calls are performed is enough to make efficient

> C programs.

The point isn't to learn a specific one; I don't that really matters.  The
student needs *something* to play on.  The point is to see what's really
going on, to see the bytes flow in and out of memory locations, to really
experience that it's only a big table of bytes that you're moving around.

The most important thing any student can learn is the stripping away
of the shroud of abstractions, and seeing the simplicity of what's
really underneath.  Once they get that, all the rest of it comes naturally.

-- Tim Behrendsen (tim@airshields.com)

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

[Arra Avakian]

In article <01bb7da2$6c505ac0$96ee6fcf@timhome2>, "Tim Behrendsen" <tim@airshields.com> wrote:
..
>The most important thing any student can learn is the stripping away
>of the shroud of abstractions, and seeing the simplicity of what's
>really underneath.  Once they get that, all the rest of it comes naturally.
>

I can see both sides of this issue: the importance of understanding 
abstractions, and the importance of understanding what is underneath.
I think that a programmer needs to have a model of how a computation occurs in 
order to understand issues such as time and space efficiency of the 
computation. On the other hand, understanding the abstractions presented by 
both language constructs and by APIs is absolutely critical to being able to 
deal with complex systems. A curriculum that does not accomplish the learning 
of computing abstractions fails. Its hard for me to judge the "best" approach 
for someone learning now, when I have had the experience of learning gradually 
over a lifetime.

I learned programming in the summer between my freshman and sophomore years in 
high school (1960!!). I was taught two "languages" that summer: IBM 1620 
assembly language and FORTRAN II. I do recall being mystified and puzzled by 
the concept of how FORTRAN source code could "execute", but could readily 
"grok" how a dumb machine could blindly execute machine code. It wasn't until 
I understood the concepts behind a compiler that the mystery faded and I could 
accept the abstraction of FORTRAN. What is interesting in hindsight was that 
the concept of an assembler did not cause any mystification - its role as a 
translator was "obvious", but the role of a compiler was definitely not 
obvious. The foundation of understanding the concepts of a stored program 
computer was essential for me to understand anything else.

I still to this day need to understand the execution model of an abstraction 
in order to "really" understand it. I guess my character is to be suspicious 
of the mystery, and not be able to take it on "faith".

Arra Avakian
Intermetrics, Inc.
733 Concord Avenue
Cambridge, Massachusetts 02138
USA
(617) 661-1840
arra@inmet.com

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

[Stephen M O'Shaughnessy]

In article <DvD01C.4v0.0.-s@inmet.camb.inmet.com>, arra@inmet.com says...
>
>In article <01bb7da2$6c505ac0$96ee6fcf@timhome2>, "Tim Behrendsen" <tim@airshields.com> 
wrote:
>..
>>The most important thing any student can learn is the stripping away
>>of the shroud of abstractions, and seeing the simplicity of what's
>>really underneath.  Once they get that, all the rest of it comes naturally.
>>
>
>I can see both sides of this issue: the importance of understanding 
>abstractions, and the importance of understanding what is underneath.
>I think that a programmer needs to have a model of how a computation occurs in 
>order to understand issues such as time and space efficiency of the 
>computation. On the other hand, understanding the abstractions presented by 
>both language constructs and by APIs is absolutely critical to being able to 
>deal with complex systems. A curriculum that does not accomplish the learning 
>of computing abstractions fails. Its hard for me to judge the "best" approach 
>for someone learning now, when I have had the experience of learning gradually 
>over a lifetime.
>

As with most hot debates, both sides have equally valid arguments. 
In this I tend toward the  abstract side of the fence.  We learn to 
tie our shoes without knowledge of knot theory.  We learn to read
without a knowledge of grammer. We learn addition, subtraction, multi.
and division without any formal mathmatical proofs.  In fact learning basic 
arithmetic is an abstraction as most school children learn by counting
pennies and dimes.  This prepares us for 90% or more of the problems we
encounter in life.  Likewise with programming.  I believe, once you learn
a language, it will be quite sufficient for 90% of the programming problems
you encounter. (I do not consider assembly as a language. Despite it's title
of assembly *language* it is a code not far enough removed (i.e. abstracted)
from the underlying hardware).

I am not saying that the basic principles are not important.  If one is going
to make a career of programming these principles are crucial.  But I don't
believe one can recognize the underlying principles without the *shroud* of
abstractions to frame them.  

problem: Add two numbers
Q: How?
A: Put them in registers A and R5 then do ADD A,R5
Q: What is a register? 
A: A place to hold data. 
Q: What is data?
A: A collection of 8 bit bytes.
Q: What is a bit/Byte?
A: ...

OR

problem: Add two numbers
Q: How?
A: C := A + B

The original question was where do you start.  I have not learned Pascal so
I can't comment about it's quality as a beginning language.  For me the best
way to start is with Ada.  Programming is solving real world problems with a computer.
That is an abstraction.  The beginning student already understands real world problems.
So first teach them to express these problems with a computer language.  Ada,
with it's strong typing, maps very well to real world objects.  Strong typing
is about abstraction and that enables the hiding of irrelevant details.
This is so important when we are trying to learn something.  (That something
we are trying to learn is how to solve real world problems with a computer, 
not how a computer works).

Ada syntax was designed to be read by a human being.  I have yet to read C
code, my own included, that was quickly and easily decipherable a year
after it was written.  Ada systems catch more errors earlier than other 
language systems.  I know all you old pros who studied under Babbage never make
mistakes.  But for a beginner, it is a nice feature not to have to go through
the whole compile, link, execute process before finding bugs.

Should I learn C or Pascal? 

No. Learn Ada

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

[James Youngman]

In article <DvD01C.4v0.0.-s@inmet.camb.inmet.com>, arra@inmet.com says...
>
>In article <01bb7da2$6c505ac0$96ee6fcf@timhome2>, "Tim Behrendsen" 
<tim@airshields.com> wrote:
>.
>>The most important thing any student can learn is the stripping away
>>of the shroud of abstractions, and seeing the simplicity of what's
>>really underneath.  Once they get that, all the rest of it comes naturally.
>>
>
>I can see both sides of this issue: the importance of understanding 
>abstractions, and the importance of understanding what is underneath.
>I think that a programmer needs to have a model of how a computation occurs in 
>order to understand issues such as time and space efficiency of the 
>computation. 

This IMHO makes Knuth's "The Art Of Computer Programming" indispansable 
even now.  He teaches many algorighms but talks __all the way through__
about the machanics of the machine.  He shows the student the wood and the 
trees simultaneously.

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

[Tim Behrendsen]

Arra Avakian <arra@inmet.com> wrote in article
<DvD01C.4v0.0.-s@inmet.camb.inmet.com>...
> In article <01bb7da2$6c505ac0$96ee6fcf@timhome2>, "Tim Behrendsen"
<tim@airshields.com> wrote:
> ..
> >The most important thing any student can learn is the stripping away
> >of the shroud of abstractions, and seeing the simplicity of what's
> >really underneath.  Once they get that, all the rest of it comes
naturally.
> >
> I can see both sides of this issue: the importance of understanding 
> abstractions, and the importance of understanding what is underneath.
> I think that a programmer needs to have a model of how a computation
occurs in 
> order to understand issues such as time and space efficiency of the 
> computation. On the other hand, understanding the abstractions presented
by 
> both language constructs and by APIs is absolutely critical to being able
to 
> deal with complex systems. A curriculum that does not accomplish the
learning 
> of computing abstractions fails. Its hard for me to judge the "best"
approach 
> for someone learning now, when I have had the experience of learning
gradually 
> over a lifetime.

Let's try a thought experiment.  We take two students; Jane is taught
assembly from day 1 for two years.  John is taught C for two years.
Both are exposed to identical curriculums of algorithmic analysis,
data structures, etc.

Two years later, they switch roles.  Who will learn the other's skills
the easiest?  I say C will be the most obvious thing in the world to
Jane, and within a few weeks she will out-code John by a longshot.
She will instantly see what subroutines, automatic variables,
static variables, pointers, argument passing, call-by-value v.s.
call-by-reference, arrays, you name it, are all about.  She will
already know the concepts; it's just a matter of learning the syntax.
And if she's ever confused, she can always look at the assembly
output.

John will be hopelessly confused at first, because he will have
absolutely no grounding in what the C syntax really means.  He will
have to start completely from scratch.  His C syntactical experience
will be almost useless in learning assembly, because the mechanisms
behind the "magic" have been hidden to him.

-- Tim Behrendsen (tim@airshields.com)

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

[Fergus Henderson]

"Tim Behrendsen" <tim@airshields.com> writes:

>Let's try a thought experiment.  We take two students; Jane is taught
>assembly from day 1 for two years.  John is taught C for two years.
>Both are exposed to identical curriculums of algorithmic analysis,
>data structures, etc.

That's not a realistic thought experiment.  Teaching abstraction,
data structures, etc. is easier in a higher level language,
and so it is unlikely that Jane will have managed to complete
the same curriculum that John can, given the handicap of using
a low-level language.

I've tutored classes using C and Miranda, amoung other languages.
Much of the time tutoring C was spent explaining how to avoid common
traps and pitfalls in C that simply don't occur in Miranda.
In Miranda, the code for a simple quicksort algorithm fits in
about two or three lines.  This makes it much easier for students
to grasp the essential ideas of such algorithms.
I haven't tutored any classes using assembler, but I imagine that
students would get even more distracted by low-level issues (which
are not relevant to learning the algorithms, abstraction techniques,
etc. that the tutorial is trying to teach) than they do in C.

>Jane [...] will
>already know the concepts; it's just a matter of learning the syntax.

It's generally much easier to learn a concept in the first place
if you have some syntax to hang it on.  Assembler doesn't help much
in that respect.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

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

[Tim Behrendsen]

Fergus Henderson <fjh@mundook.cs.mu.OZ.AU> wrote in article
<4u5a11$siv@mulga.cs.mu.OZ.AU>...
> "Tim Behrendsen" <tim@airshields.com> writes:
> 
> >Let's try a thought experiment.  We take two students; Jane is taught
> >assembly from day 1 for two years.  John is taught C for two years.
> >Both are exposed to identical curriculums of algorithmic analysis,
> >data structures, etc.
> 
> That's not a realistic thought experiment.  Teaching abstraction,
> data structures, etc. is easier in a higher level language,
> and so it is unlikely that Jane will have managed to complete
> the same curriculum that John can, given the handicap of using
> a low-level language.

This seems to be a common theme; that programming things in
assembly in necessarily harder than programming in a HLL.

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.

Now, you wouldn't want to *maintain* large systems of assembly,
which is why HLLs have taken over the world, but it seems to
me that assembly per se is just not that hard to use.

-- Tim Behrendsen (tim@airshields.com)

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

[Fergus Henderson]

"Tim Behrendsen" <tim@airshields.com> writes:

>This seems to be a common theme; that programming things in
>assembly in necessarily harder than programming in a HLL.
>
>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.
>
>Now, you wouldn't want to *maintain* large systems of assembly,
>which is why HLLs have taken over the world, but it seems to
>me that assembly per se is just not that hard to use.

N lines of assembler is not much more difficult to understand
or to code than N lines of C.  But if you want the students to
understand say quicksort, it's a lot easier showing them 20 lines
of C than 100 lines of assembler.

Also, we want to get our students into the habit of writing
robust and reusable code, and this is very difficult in assembler.
At least C has malloc()/free(); with assembler, you need to write
the memory management from scratch.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

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

[Tim Behrendsen]

Fergus Henderson <fjh@mundook.cs.mu.OZ.AU> wrote in article
<4u86lc$2gu@mulga.cs.mu.OZ.AU>...
> "Tim Behrendsen" <tim@airshields.com> writes:
> 
> >This seems to be a common theme; that programming things in
> >assembly in necessarily harder than programming in a HLL.
> >
> >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.
> >
> >Now, you wouldn't want to *maintain* large systems of assembly,
> >which is why HLLs have taken over the world, but it seems to
> >me that assembly per se is just not that hard to use.
> 
> N lines of assembler is not much more difficult to understand
> or to code than N lines of C.  But if you want the students to
> understand say quicksort, it's a lot easier showing them 20 lines
> of C than 100 lines of assembler.

Who's talking about showing them?  I would suggest that if
they wrote a quicksort in assembler, they will have a much
better "feel" for the algorithm, than if they wrote it in C.

> Also, we want to get our students into the habit of writing
> robust and reusable code, and this is very difficult in assembler.
> At least C has malloc()/free(); with assembler, you need to write
> the memory management from scratch.

Well, I don't the student has to rewrite all the library
routines!  Nothing precludes you from using them from assembler.

-- Tim Behrendsen (tim@airshields.com)

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

[Thomas Hood]

Tim Behrendsen wrote:
<snip>
> > or to code than N lines of C.  But if you want the students to
> > understand say quicksort, it's a lot easier showing them 20 lines
> > of C than 100 lines of assembler.
> 
> Who's talking about showing them?  I would suggest that if
> they wrote a quicksort in assembler, they will have a much
> better "feel" for the algorithm, than if they wrote it in C.

Nonsense.  They will have a much better feel for how to shift stuff from
one register to another, but will never realize _why_ they are doing it.
Problem solving in anything but the most trivial of cases is the process
of moving from the specific (the problem at hand, for which we have no
solution) to the general (the algorithmic solution, which fits
the problem domain).  Accomplishing this in assembly language is
unnecessary and cruel.  Any HOL has the lexical elements necessary to
encapsulate the concept of a quicksort without the agony of dealing with
assembler.


> 
> > Also, we want to get our students into the habit of writing
> > robust and reusable code, and this is very difficult in assembler.
> > At least C has malloc()/free(); with assembler, you need to write
> > the memory management from scratch.
> 
> Well, I don't the student has to rewrite all the library
> routines!  Nothing precludes you from using them from assembler.

If you are allowing them to use higher level constructs (abstractions)
to accomplish lower level tasks (solve specific problems), then you
are upholding the very concept you are arguing against!

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

-- 
Thomas Hood
Senior Program Manager - Chief Engineer
Former Ada Geek
Neptune Interactive Communications
703.924.9234 x250
thomas@nicom.com
http://thomas.nicom.com

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

[Tim Behrendsen]

Thomas Hood <thomas@nicom.com> wrote in article
<320A65F5.65D9@nicom.com>...
> Tim Behrendsen wrote:
> <snip>
> > > or to code than N lines of C.  But if you want the students to
> > > understand say quicksort, it's a lot easier showing them 20 lines
> > > of C than 100 lines of assembler.
> > 
> > Who's talking about showing them?  I would suggest that if
> > they wrote a quicksort in assembler, they will have a much
> > better "feel" for the algorithm, than if they wrote it in C.
> 
> Nonsense.  They will have a much better feel for how to shift stuff from
> one register to another, but will never realize _why_ they are doing it.
> Problem solving in anything but the most trivial of cases is the process
> of moving from the specific (the problem at hand, for which we have no
> solution) to the general (the algorithmic solution, which fits
> the problem domain).  Accomplishing this in assembly language is
> unnecessary and cruel.  Any HOL has the lexical elements necessary to
> encapsulate the concept of a quicksort without the agony of dealing with
> assembler.

Cruel?  Agony?  Assembly is *not* that hard.

> > > Also, we want to get our students into the habit of writing
> > > robust and reusable code, and this is very difficult in assembler.
> > > At least C has malloc()/free(); with assembler, you need to write
> > > the memory management from scratch.
> > 
> > Well, I don't the student has to rewrite all the library
> > routines!  Nothing precludes you from using them from assembler.
> 
> If you are allowing them to use higher level constructs (abstractions)
> to accomplish lower level tasks (solve specific problems), then you
> are upholding the very concept you are arguing against!

No, I see no reason to have them rewrite the O/S if that's not
the purpose of the assignment.  They can get input from the library
routines, and output using the library routines, but implementation
of the algorithm should be done using assembly.

-- Tim Behrendsen (tim@airshields.com)

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

[Lawrence Kirby]

In article <01bb846d$c6c01780$87ee6fce@timpent.airshields.com>
           tim@airshields.com "Tim Behrendsen" writes:

>Who's talking about showing them?  I would suggest that if
>they wrote a quicksort in assembler, they will have a much
>better "feel" for the algorithm, than if they wrote it in C.

They might have a good feel for how to implement quicksort in that
particular machine code however it would be so wrapped up in
implementation details that they wouldn't have a good understanding of
the algorithm itself, at last not in the same timescale.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

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

[Tim Behrendsen]

Lawrence Kirby <fred@genesis.demon.co.uk> wrote in article
<840288278snz@genesis.demon.co.uk>...
> In article <01bb846d$c6c01780$87ee6fce@timpent.airshields.com>
>            tim@airshields.com "Tim Behrendsen" writes:
> 
> >Who's talking about showing them?  I would suggest that if
> >they wrote a quicksort in assembler, they will have a much
> >better "feel" for the algorithm, than if they wrote it in C.
> 
> They might have a good feel for how to implement quicksort in that
> particular machine code however it would be so wrapped up in
> implementation details that they wouldn't have a good understanding of
> the algorithm itself, at last not in the same timescale.

And they don't get wrapped up in implementation
details if they write it in C?  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.

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.

-- Tim Behrendsen (tim@airshields.com)

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

[Bob Gilbert]

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.

> 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.

> 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.

-Bob

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

[Tim Behrendsen]

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.

> > 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.
 
> > 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.

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.  Yes, you can pack algorithms
into their head, but that doesn't mean they are learning why
the algorithm is way that it is.  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.

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?  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. :)

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

[Tim Hollebeek]

Tim Behrendsen (tim@airshields.com) wrote:

: 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.

Of course, any modern CPU is going to have tons of things like
register windows, delay slots, and pipelines.  I'd hate to manage that
stuff directly.  The future appears to be RISC and/or superscalar, and
both are a pain to program by hand.  Of course, I could be wrong about
that.  But I do know one thing:  Whatever chip will be in my computer
10 years from now, it will run my C code without modification.  Can
you say that about your assembly?

BTW, where do you find the time for 10 posts a day?  I don't have time
to *read* everything you post :-)

---------------------------------------------------------------------------
Tim Hollebeek         | Disclaimer :=> Everything above is a true statement,
Electron Psychologist |                for sufficiently false values of true.
Princeton University  | email: tim@wfn-shop.princeton.edu
----------------------| http://wfn-shop.princeton.edu/~tim (NEW! IMPROVED!)

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

[Tim Behrendsen]

Tim Hollebeek <tim@franck> wrote in article
<4vard9$9rj@cnn.Princeton.EDU>...
> Tim Behrendsen (tim@airshields.com) wrote:
> 
> : 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.
> 
> Of course, any modern CPU is going to have tons of things like
> register windows, delay slots, and pipelines.  I'd hate to manage that
> stuff directly.  The future appears to be RISC and/or superscalar, and
> both are a pain to program by hand.  Of course, I could be wrong about
> that.  But I do know one thing:  Whatever chip will be in my computer
> 10 years from now, it will run my C code without modification.  Can
> you say that about your assembly?

Nope, which is why I don't do my application programming in
assembly.  Doesn't change the fact that architectures are
still implemented in assembly, and the fact that assembly
is a much better tool to learn from because of the simple
nature (even though performance optimizations can be complex).

> BTW, where do you find the time for 10 posts a day?  I don't have time
> to *read* everything you post :-)

Well, it helps to be able to read fast and type fast.  Its
one of the benefits to being naturally impatient. :-)

-- Tim Behrendsen (tim@airshields.com)

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

[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

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

[Tim Behrendsen]

Bob Gilbert <rgilbert@unconfigured.xvnews.domain> wrote in article
<4vcac4$gm6@zeus.orl.mmc.com>...
> In article <01bb8df1$2e19d420$87ee6fce@timpent.airshields.com>, "Tim
Behrendsen" <tim@airshields.com> writes:
> > Bob Gilbert <rgilbert@unconfigured.xvnews.domain> wrote in article
> 
> > 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.

Perhaps, but you have risk prejudice somewhere.  The first
language you pick is going to give them some kind of
abstractional prejudice.
 
> > 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.

There is no other view than the procedural view.  There is no
such thing as an algorithm that exists in zero time.  Even if
there is only one operation, or (n) operations that happen
simultaneously, it is still (n) data transformations that take
place over time.

> >  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).

How can someone implement *any* sort in assembly language,
and "learn it but not really understand it"?  To implement it,
you have to do it in great detail, and you simply can't do the
"push and prod until it works" approach to programming, which
is what I think a lot of students do.

-- Tim Behrendsen (tim@airshields.com)

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

[Bob Gilbert]

In article <01bb8f19$9a89d820$32ee6fce@timhome2>, "Tim Behrendsen" <tim@airshields.com> writes:
> 
> There is no other view than the procedural view.

Don't think so.

>  There is no
> such thing as an algorithm that exists in zero time.  Even if
> there is only one operation, or (n) operations that happen
> simultaneously, it is still (n) data transformations that take
> place over time.

And this relates to procedural vs non-procedural views how????

> How can someone implement *any* sort in assembly language,
> and "learn it but not really understand it"?

Easy.  Understanding the how and why an algorithm works has little
to do with implementing it, regardless of the language used.  How 
does being able to implement a sort in assembly provide a student
with the ability to prove that the given sort algorithm will work for
all cases?  Learning to implement, and learning sound implementation
techniques (regardless of language) is a separate issue from learning
algorithm development and analysis.

>  To implement it,
> you have to do it in great detail, and you simply can't do the
> "push and prod until it works" approach to programming, which
> is what I think a lot of students do.

I think anyone can "push and prod" in any language.

-Bob

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

[Tim Behrendsen]

Bob Gilbert <rgilbert@unconfigured.xvnews.domain> wrote in article
<4vhgjk$8kc@zeus.orl.mmc.com>...
> In article <01bb8f19$9a89d820$32ee6fce@timhome2>, "Tim Behrendsen"
<tim@airshields.com> writes:
> > 
> > There is no other view than the procedural view.
> 
> Don't think so.
> 
> >  There is no
> > such thing as an algorithm that exists in zero time.  Even if
> > there is only one operation, or (n) operations that happen
> > simultaneously, it is still (n) data transformations that take
> > place over time.
> 
> And this relates to procedural vs non-procedural views how????

We may be having a terminology crisis; when I say "procedure",
I mean the computer doing work, by whatever method it uses,
over time.  Exactly how can a computer do work, either without
procedures, or without time?

> > How can someone implement *any* sort in assembly language,
> > and "learn it but not really understand it"?
> 
> Easy.  Understanding the how and why an algorithm works has little
> to do with implementing it, regardless of the language used.  How 
> does being able to implement a sort in assembly provide a student
> with the ability to prove that the given sort algorithm will work for
> all cases?  Learning to implement, and learning sound implementation
> techniques (regardless of language) is a separate issue from learning
> algorithm development and analysis.

You are right, in a mechanistic literal view of the world.  From
a human, reality view, implementation has a *lot* to do with
learning algorithm development and analysis.  You don't just
plug in the 'dev and ana' disk into the student's ear.  They
learn through trial and error, and what cements concepts
into their head is the implementation of the concepts.
 
> >  To implement it,
> > you have to do it in great detail, and you simply can't do the
> > "push and prod until it works" approach to programming, which
> > is what I think a lot of students do.
> 
> I think anyone can "push and prod" in any language.

It's a hell of lot harder to push and prod assembly.

-- Tim Behrendsen (tim@airshields.com)

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

[Lawrence Kirby]

In article <01bb8f19$9a89d820$32ee6fce@timhome2>
           tim@airshields.com "Tim Behrendsen" writes:

>Bob Gilbert <rgilbert@unconfigured.xvnews.domain> wrote in article
><4vcac4$gm6@zeus.orl.mmc.com>...

...

>> 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.
>
>There is no other view than the procedural view.

Some functional language programmers might take issue with that
statement. Prologgers may have a thought or two also.

...

>How can someone implement *any* sort in assembly language,
>and "learn it but not really understand it"?  To implement it,
>you have to do it in great detail, and you simply can't do the
>"push and prod until it works" approach to programming, which
>is what I think a lot of students do.

Example: once I had an assignment to implement a sort on IBM 360 assembler.
What I learnt to do was convert a sequence of individual operations into
assembler instructions. It didn't teach me a thing about the sort algorithm
(which was merge sort).

I can't imagine a worse way of teaching an algorithm than using assembly.
It is essential to separate the algorithm from the implementation and
assembly ties you up in knots with implementation specific details
especially when you are just learning 'computing'. Once you've learnt
an algorithm it makes a lot of sense to practice that algorithm by
writing implementations, even in assembly, but you should understand the
algorithm to a reasonable extent *before* attempting that.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

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

[Tim Behrendsen]

Lawrence Kirby <fred@genesis.demon.co.uk> wrote in article
<841797763snz@genesis.demon.co.uk>...
> In article <01bb8f19$9a89d820$32ee6fce@timhome2>
>            tim@airshields.com "Tim Behrendsen" writes:
> 
> >Bob Gilbert <rgilbert@unconfigured.xvnews.domain> wrote in article
> ><4vcac4$gm6@zeus.orl.mmc.com>...
> 
> ...
> 
> >> 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.
> >
> >There is no other view than the procedural view.
> 
> Some functional language programmers might take issue with that
> statement. Prologgers may have a thought or two also.

What I mean by that is, for work to get done, the computer
must perform transformations of data over time.  You can call
that an implementation detail if you want, but there simply is
no such thing as "instantaneous" algorithms.  You can look
at a mathematical proof as existing without procedures, in the
sense that it simply "exists", as a statement of truth, but
algorithms are different.  They are, by their nature, a
process, and processes require a time axis.

Now, there are certain rule-based languages, but these describe
a process just like any other language.  The different is, rather
than describe the process as a set of linear paths, it describes
them in a way like a pachinko machine.  You have a set of pins, and
when you drop a marble at a certain angle, it bounces along the
rules defined by the pins, and comes out a certain position.  I
haven't described a linear procedure for every angle, but I have
still defined the process by which data (the marble) flows
through the algorithm (the pins).  In other words, the purpose of
the rules is data flowing through them.

> ...
> 
> >How can someone implement *any* sort in assembly language,
> >and "learn it but not really understand it"?  To implement it,
> >you have to do it in great detail, and you simply can't do the
> >"push and prod until it works" approach to programming, which
> >is what I think a lot of students do.
> 
> Example: once I had an assignment to implement a sort on IBM 360
assembler.
> What I learnt to do was convert a sequence of individual operations into
> assembler instructions. It didn't teach me a thing about the sort
algorithm
> (which was merge sort).

I find it difficult to believe that you implemented a merge sort
in assembly without understanding the merge sort algorithm.

> I can't imagine a worse way of teaching an algorithm than using assembly.
> It is essential to separate the algorithm from the implementation and
> assembly ties you up in knots with implementation specific details
> especially when you are just learning 'computing'. Once you've learnt
> an algorithm it makes a lot of sense to practice that algorithm by
> writing implementations, even in assembly, but you should understand the
> algorithm to a reasonable extent *before* attempting that.

On the contrary, I think it is essential to focus on the
implementation in as much detail as possible.  You can pack as
much algorithm theory into a student as you want, but they don't
really "get it" until they type in a program, and experience it
not working, figuring out why, fixing it, and repeating the
process until they see the expected output.

I think you take how to "think like a programmer" for granted so
much that you don't understand that it doesn't come naturally
to the average person.  The procedural nature of the computer is
something to be learned, just like algorithms.

-- Tim Behrendsen (tim@airshields.com)

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

[Bob Gilbert]

In article <01bb9a1e$24c669e0$32ee6fcf@timhome2>, "Tim Behrendsen" <tim@airshields.com> writes:
> Lawrence Kirby <fred@genesis.demon.co.uk> wrote in article
> <841797763snz@genesis.demon.co.uk>...
> > In article <01bb8f19$9a89d820$32ee6fce@timhome2>
> >            tim@airshields.com "Tim Behrendsen" writes:
> > >Bob Gilbert <rgilbert@unconfigured.xvnews.domain> wrote in article
> > ><4vcac4$gm6@zeus.orl.mmc.com>...
> > >> 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.
> > >
> > >There is no other view than the procedural view.
> > 
> > Some functional language programmers might take issue with that
> > statement. Prologgers may have a thought or two also.
> 
> What I mean by that is, for work to get done, the computer
> must perform transformations of data over time.  You can call
> that an implementation detail if you want, but there simply is
> no such thing as "instantaneous" algorithms.  You can look
> at a mathematical proof as existing without procedures, in the
> sense that it simply "exists", as a statement of truth, but
> algorithms are different.  They are, by their nature, a
> process, and processes require a time axis.

I suspect our definitions of procedural vs non-procedural (e.g. object
oriented) views are not the same.  Non-procedural views do not imply 
"instantaneous" algorithms, the non-existence of a time axis, or whatever.
The difference is whether I veiw the problem solution as being built by
putting together a bunch of operations (procedures) that I can invoke to 
manipulate whatever data I happen to have, or I can view the problem 
solution as being built by putting together the appropiate data elements 
(objects) for which certain operations are defined.  Are the basic 
building blocks procedures or objects?  BTW, I'm not necessarily 
advocating one view over another, just trying to point out that there 
are views other than a procedural view.

-Bob

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

[Tim Behrendsen]

Bob Gilbert <rgilbert@unconfigured.xvnews.domain> wrote in article
<50p68s$cpi@zeus.orl.mmc.com>...
> In article <01bb9a1e$24c669e0$32ee6fcf@timhome2>, "Tim Behrendsen" <tim@airshields.com>
writes:
> > Lawrence Kirby <fred@genesis.demon.co.uk> wrote in article
> > <841797763snz@genesis.demon.co.uk>...
> > > In article <01bb8f19$9a89d820$32ee6fce@timhome2>
> > >            tim@airshields.com "Tim Behrendsen" writes:
> > > >Bob Gilbert <rgilbert@unconfigured.xvnews.domain> wrote in article
> > > ><4vcac4$gm6@zeus.orl.mmc.com>...
> > > >> 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.
> > > >
> > > >There is no other view than the procedural view.
> > > 
> > > Some functional language programmers might take issue with that
> > > statement. Prologgers may have a thought or two also.
> > 
> > What I mean by that is, for work to get done, the computer
> > must perform transformations of data over time.  You can call
> > that an implementation detail if you want, but there simply is
> > no such thing as "instantaneous" algorithms.  You can look
> > at a mathematical proof as existing without procedures, in the
> > sense that it simply "exists", as a statement of truth, but
> > algorithms are different.  They are, by their nature, a
> > process, and processes require a time axis.
> 
> I suspect our definitions of procedural vs non-procedural (e.g. object
> oriented) views are not the same.  Non-procedural views do not imply 
> "instantaneous" algorithms, the non-existence of a time axis, or whatever.
> The difference is whether I veiw the problem solution as being built by
> putting together a bunch of operations (procedures) that I can invoke to 
> manipulate whatever data I happen to have, or I can view the problem 
> solution as being built by putting together the appropiate data elements 
> (objects) for which certain operations are defined.  Are the basic 
> building blocks procedures or objects?  BTW, I'm not necessarily 
> advocating one view over another, just trying to point out that there 
> are views other than a procedural view.

Object-oriented is perhaps not where you want to go to make
your point; the only difference between OOP and non-OOP is
how you bind the procedures to the objects.  non-OOP you pass
an object to a procedure; in OOP, you execute the procedure
abstractly bound to the object.

A better example are the "pure" non-procedural languages, where
you give an abstract logic statement of what the algorithm *is*,
rather than how to execute it.  In other words, the ordering of the
individual clauses are not important; the cumulative meaning
of the clauses are what expresses the algorithm.  Structured
Query Language is a good example of this.

But to get back to the original point, which is teaching students
the procedural nature of the computer, it is essential that they
understand this.  One of the most dangerous people in the world
is someone who writes SQL statements who doesn't fundamentally
understand what happens inside the mechanism.  In theory, I
should be able to happily write SQL statements anyway I want to;
in practice, I *would* like my report to come out within this
millenium.

Yes, teach them non-procedural languages in the Masters or PhD
programs.  First teach them that everything boils down to
procedural mechanisms.

-- Tim Behrendsen (tim@a-sis.com)

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

[Bob Gilbert]

In article <01bb9c05$ce5b9aa0$87ee6fce@timpent.airshields.com>, "Tim Behrendsen" <tim@airshields.com> writes:
> > In article <01bb9a1e$24c669e0$32ee6fcf@timhome2>, "Tim Behrendsen" <tim@airshields.com>
> writes:
> > > > >
> > > > >There is no other view than the procedural view.

I might not have as much of a problem with the above statement if
you had said that all *implementations* are eventually procedural,
but the word "view" implies a methodology, approach, or way of thinking
to solve a problem, and there does exist non-procedural views.

> Bob Gilbert <rgilbert@unconfigured.xvnews.domain> wrote in article
> <50p68s$cpi@zeus.orl.mmc.com>...
> > I suspect our definitions of procedural vs non-procedural (e.g. object
> > oriented) views are not the same.  Non-procedural views do not imply 
> > "instantaneous" algorithms, the non-existence of a time axis, or whatever.
> > The difference is whether I veiw the problem solution as being built by
> > putting together a bunch of operations (procedures) that I can invoke to 
> > manipulate whatever data I happen to have, or I can view the problem 
> > solution as being built by putting together the appropiate data elements 
> > (objects) for which certain operations are defined.  Are the basic 
> > building blocks procedures or objects?  BTW, I'm not necessarily 
> > advocating one view over another, just trying to point out that there 
> > are views other than a procedural view.
> 
> Object-oriented is perhaps not where you want to go to make
> your point; the only difference between OOP and non-OOP is
> how you bind the procedures to the objects.  non-OOP you pass
> an object to a procedure; in OOP, you execute the procedure
> abstractly bound to the object.

I was taking object-oriented design (OOD), not necessarily object
oriented programming (OOP), which is simply the implemtation of an
OOD.  View vs implementation.

> But to get back to the original point, which is teaching students
> the procedural nature of the computer, it is essential that they
> understand this.  One of the most dangerous people in the world
> is someone who writes SQL statements who doesn't fundamentally
> understand what happens inside the mechanism.  In theory, I
> should be able to happily write SQL statements anyway I want to;
> in practice, I *would* like my report to come out within this
> millenium.
> 
> Yes, teach them non-procedural languages in the Masters or PhD
> programs.  First teach them that everything boils down to
> procedural mechanisms.

I agree that a computer science student should have a through understanding
of computer architecture(s), assembly language, and the various low level 
implementation details and concepts.  I disagree that assembly should be 
the first programming language that the student is exposed to.  I would also
disagree that assembly should be the last language taught (perhaps a close
second).  I disagree that implementing algorithms in assembly is better for 
teaching the algorithm and it's development than using a HOL such as Ada, 
Fortran, or PL/I.  Assembly should be used in conjuction with the study of 
computer architecture, but I contend that the required knowledge of the many
architecturual details necessary to effectively program in assembly hinders 
the understanding of the algorithm (e.g. sorts, random number generators, 
data base, etc.), however implementing various algorithms in assembly is a 
good exercise for the student and certainly provides a better overall 
understanding (as well as providing knowledge to better design algorithms 
to the constraints of the machine).  I wouldn't wait for Masters or PhD
programs to teach many of the HOL programming issues (OOD, etc.).

-Bob

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

[Tim Behrendsen]

Bob Gilbert <rgilbert@unconfigured.xvnews.domain> wrote in article
<511smf$b4h@zeus.orl.mmc.com>...
> In article <01bb9c05$ce5b9aa0$87ee6fce@timpent.airshields.com>, "Tim
Behrendsen" <tim@airshields.com> writes:
> > > In article <01bb9a1e$24c669e0$32ee6fcf@timhome2>, "Tim Behrendsen"
<tim@airshields.com>
> > writes:
> > > > > >
> > > > > >There is no other view than the procedural view.
> 
> I might not have as much of a problem with the above statement if
> you had said that all *implementations* are eventually procedural,
> but the word "view" implies a methodology, approach, or way of thinking
> to solve a problem, and there does exist non-procedural views.

That is a reasonable statement.  There are certainly other ways
of looking at algorithms other than procedurally (SQL, for example).
I suppose there's a certain bias on my part because I break
everything down automatically into procedures.  I admit others
may more naturally think in terms of mathematical statements.

I'm still not sure if I want those people producing my SQL reports,
however.  :)

-- Tim Behrendsen (tim@a-sis.com)

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

[Richard A. O'Keefe]

rgilbert@unconfigured.xvnews.domain (Bob Gilbert) writes:

>I suspect our definitions of procedural vs non-procedural (e.g. object
>oriented) views are not the same.  Non-procedural views do not imply 
>"instantaneous" algorithms, the non-existence of a time axis, or whatever.

It strikes me as a very strange use of language to call object-oriented
programming (of the kind exemplified by Simula 67, Smalltalk, C++, Ada 95,
CLOS, Eiffel, Self, Cecil, NewtonScript, &c) "non-procedural".  They are
about as thoroughly procedural as you can get.

The opposite of "procedural" is not "OOP" but "declarative".
Declarative languages include Haskell, Clean, Mercury, and perhaps Goedel,
which I don't know all that well.  Maybe Sisal at all, but I don't know it.
In those languages the programmer has no idea and no reason to care in
what order operations are performed; any order the compiler chooses will
make sense.  (Yes, it is still possible to write programs that interact
with the world, and at least in Clean, very simply and elegantly.)

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

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

[Kaz Kylheku]

In article <51368e$6ir@goanna.cs.rmit.edu.au>,
Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote:
>rgilbert@unconfigured.xvnews.domain (Bob Gilbert) writes:
>
>>I suspect our definitions of procedural vs non-procedural (e.g. object
>>oriented) views are not the same.  Non-procedural views do not imply 
>>"instantaneous" algorithms, the non-existence of a time axis, or whatever.
>
>It strikes me as a very strange use of language to call object-oriented
>programming (of the kind exemplified by Simula 67, Smalltalk, C++, Ada 95,
>CLOS, Eiffel, Self, Cecil, NewtonScript, &c) "non-procedural".  They are
>about as thoroughly procedural as you can get.
>
>The opposite of "procedural" is not "OOP" but "declarative".
>Declarative languages include Haskell, Clean, Mercury, and perhaps Goedel,
>which I don't know all that well.  Maybe Sisal at all, but I don't know it.

Lex and awk would also be familiar examples of such languages, to an extent.
The pattern matching rules of lex are not though of as executing in any
particular order, unless there is a conflict between two equal-length matches
in which case the pattern appearing first in the lex source is preferred.  Awk
pattern matching rules are also not arranged in a procedural sequence. Of
course, when matching occurs, ``actions'' are invoked, and the program
temporarily becomes procedural.

State machines, like the pattern matcher of a Lex generated program, are one
good example of non-procedural programming. The actual procedure which drives
the state machine is typically trivial, and is simply not telling of the intent
of the machine. It is driven by the state configuration and by input. (Of
course, the state transitions of the machine can be arranged so that the
functioning can be understood procedurally, but that's a separate issue: after
all, a state machine can interpret instructions which form a procedure).

>In those languages the programmer has no idea and no reason to care in
>what order operations are performed; any order the compiler chooses will
>make sense.  (Yes, it is still possible to write programs that interact
>with the world, and at least in Clean, very simply and elegantly.)

But this is tue of OO programming as well. You have an object, and you can
interact with it in ways that don't necessarily obey a particular order; the
object acts like a state machine. This is why OO folks like to talk about
messages rather than function calls.

OO is used a lot in GUI developemnt, and modern GUIs typify a non-procedural
approach. Most of the time, the user can interact with the interface in an
ad-hoc fashion, changing the state of various internal objects. The structure
of such a program reflects that.

I suppose that object orientation is a completely orthogonal issue to
procedural versus non-procedural. I also suppose that there are many
ways to be non procedural, so that ``declarative'' is either a very broad
umbrella, or is just one example of the many ways.

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

[Bob Gilbert]

In article <51368e$6ir@goanna.cs.rmit.edu.au>, ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
> rgilbert@unconfigured.xvnews.domain (Bob Gilbert) writes:
> 
> >I suspect our definitions of procedural vs non-procedural (e.g. object
> >oriented) views are not the same.  Non-procedural views do not imply 
> >"instantaneous" algorithms, the non-existence of a time axis, or whatever.
> 
> It strikes me as a very strange use of language to call object-oriented
> programming (of the kind exemplified by Simula 67, Smalltalk, C++, Ada 95,
> CLOS, Eiffel, Self, Cecil, NewtonScript, &c) "non-procedural".  They are
> about as thoroughly procedural as you can get.
> 
> The opposite of "procedural" is not "OOP" but "declarative".
> Declarative languages include Haskell, Clean, Mercury, and perhaps Goedel,
> which I don't know all that well.  Maybe Sisal at all, but I don't know it.
> In those languages the programmer has no idea and no reason to care in
> what order operations are performed; any order the compiler chooses will
> make sense.  (Yes, it is still possible to write programs that interact
> with the world, and at least in Clean, very simply and elegantly.)

I think I have been taken out of context here.  I wasn't discussing 
specific languages, but rather a "view" of the problem domain.  Originally
Tim Behrendsen made a statement to the effect that students must be taught
to think in terms of breaking problems into procedures with inputs and
outputs.  I simply claimed that this *view* was very procedureal and many
proponents of things like object oriented design might take exception to
that view-point, or at least the implication that it is the only way to 
view a solution.  I was only offering OOD as an example of an alternative
way of viewing the problem and designing a solution where one shouldn't
think simply in terms of inputs, processing, and outputs.

-Bob

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

[Jon S Anthony]

In article <51368e$6ir@goanna.cs.rmit.edu.au> ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

> rgilbert@unconfigured.xvnews.domain (Bob Gilbert) writes:
> 
> >I suspect our definitions of procedural vs non-procedural (e.g. object
> >oriented) views are not the same.  Non-procedural views do not imply 
> >"instantaneous" algorithms, the non-existence of a time axis, or whatever.
> 
> It strikes me as a very strange use of language to call object-oriented
> programming (of the kind exemplified by Simula 67, Smalltalk, C++, Ada 95,
> CLOS, Eiffel, Self, Cecil, NewtonScript, &c) "non-procedural".  They are
> about as thoroughly procedural as you can get.

Exactly.  A point I have tried to point out from time to time in c.o.
All to no avail.  In fact, I've actually been flamed for this
"indiscretion" as being "anti-oop".  Go figure.  What was that line
from Schiller?  "Against stupidity, the gods themselves contend in
vain".


> The opposite of "procedural" is not "OOP" but "declarative".
> Declarative languages include Haskell, Clean, Mercury, and perhaps Goedel,
> which I don't know all that well.  Maybe Sisal at all, but I don't know it.
> In those languages the programmer has no idea and no reason to care in
> what order operations are performed; any order the compiler chooses will

Hmmm, I am somewhat surprised that you of all people would not include
Prolog in that list.  What's the scoop?

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

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

[Richard A. O'Keefe]

jsa@alexandria (Jon S Anthony) writes:
>Hmmm, I am somewhat surprised that you of all people would not include
>Prolog in that list.  What's the scoop?

Prolog is a hybrid of a weak declarative language (weak because the
traditional Prolog implementation doesn't quite match the semantics of
Horn clause programs, and the difference sometimes matters a lot)
with a rather limited imperative language.  It is an _extremely_ practical
tool, but almost all Prolog programs make use of the non-declarative parts
of the language.  In the same way, Lisp is an _exceptionally_ practical tool
for almost every kind of programming, including writing web servers and
operating systems, but it is not a _pure_ declarative language, so didn't
make it into the list of declarative languages.  Mercury _is_ on the list
because the _implemented_ semantics of any Mercury program coincides with
its theoretical semantics as a Horn clause program.

For what it's worth, I do not accept _any_ of the OOP languages I listed
in my previous message as in any way declarative.  This is not to say that
you couldn't have a declarative OOP language; it is arguable that Haskell
is one.
-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

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

[Jon S Anthony]

In article <515mq2$bri@goanna.cs.rmit.edu.au> ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

> jsa@alexandria (Jon S Anthony) writes:
> >Hmmm, I am somewhat surprised that you of all people would not include
> >Prolog in that list.  What's the scoop?
> 
> Prolog is a hybrid of a weak declarative language (weak because the
> traditional Prolog implementation doesn't quite match the semantics of
> Horn clause programs, and the difference sometimes matters a lot)

Agreed.


> with a rather limited imperative language.  It is an _extremely_ practical
> tool, but almost all Prolog programs make use of the non-declarative parts
> of the language.  In the same way, Lisp is an _exceptionally_ practical tool
> for almost every kind of programming, including writing web servers and
> operating systems, but it is not a _pure_ declarative language, so didn't
> make it into the list of declarative languages.

Hmmm, I have not typically put Lisp in such a category even if it were
more "purely applicative" - making a distinction between "declarative"
and non-procedural, with Lisp falling into "functional" which is also
non-procedural, so I was not "surprised" by its ommission.  But,
shrug, I can certainly see how you could just say functional things
are simply another kind of declarative things.


>  Mercury _is_ on the list because the _implemented_ semantics of any
> Mercury program coincides with its theoretical semantics as a Horn
> clause program.

I have begun looking into Mercury and I must say that it seems to have
a lot going for it.

 
> For what it's worth, I do not accept _any_ of the OOP languages I listed
> in my previous message as in any way declarative.  This is not to say that
> you couldn't have a declarative OOP language; it is arguable that Haskell
> is one.

Completely agreed on both counts.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

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

[Jon S Anthony]

In article <5149bt$kli@bcrkh13.bnr.ca> kaz@vision.crest.nt.com (Kaz Kylheku) writes:

> I suppose that object orientation is a completely orthogonal issue to
> procedural versus non-procedural. I also suppose that there are many

You suppose correctly.


> ways to be non procedural, so that ``declarative'' is either a very broad
> umbrella, or is just one example of the many ways.

Good point.  A true functional language would also be non-procedural.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

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

[Mark Wooding]

Lawrence Kirby <fred@genesis.demon.co.uk> wrote:
> In article <01bb8f19$9a89d820$32ee6fce@timhome2>
>            tim@airshields.com "Tim Behrendsen" writes:
>
> >There is no other view than the procedural view.
> 
> Some functional language programmers might take issue with that
> statement. Prologgers may have a thought or two also.

I've not come across a computer yet which doesn't work by fetching an
instruction (or maybe a few at a time), doing them, and then going off
and fetching some more.  I guess you can pretend that this isn't the
case, and maybe come up with some nice ways of presenting algorithms
which don't depend on this, but that's not the way things work
underneath.  The One True View is that sequence of instructions; all
else is an illusion.  Maybe it's a helpful illusion, but illusion it is
nonetheless.
-- 
[mdw]

`When our backs are against the wall, we shall turn and fight.'
		-- John Major

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

[Bob Cousins]

Mark Wooding wrote:

>Lawrence Kirby <fred@genesis.demon.co.uk> wrote:
>> In article <01bb8f19$9a89d820$32ee6fce@timhome2>
>>            tim@airshields.com "Tim Behrendsen" writes:
>>
>> >There is no other view than the procedural view.
>> 
>> Some functional language programmers might take issue with that
>> statement. Prologgers may have a thought or two also.
>
>I've not come across a computer yet which doesn't work by fetching an
>instruction (or maybe a few at a time), doing them, and then going off
>and fetching some more.  I guess you can pretend that this isn't the
>case, and maybe come up with some nice ways of presenting algorithms
>which don't depend on this, but that's not the way things work
>underneath.  The One True View is that sequence of instructions; all
>else is an illusion.  Maybe it's a helpful illusion, but illusion it is
>nonetheless.

I am afraid your view is severely limited, on two counts.

1. It could be argued that executing a sequence of intructions is the
"illusion". It appears to you that that is what happens, but all the
CPU does is respond to a set of input signals on its pins, combines
them with states in internal registers, and produces a new set of
output pins and register states. 

The CPU is just a complex state machine. It is just an abstraction
that it executes instructions. Of course we have designed it to behave
according to our abstraction. If the CPU generated non-sensical
outputs, it would still be the same complex state machine, but we
would not regard it as executing instructions.

In fact, executing instructions is such a useful abstraction, that in
nearly all complex processors, there is a smaller processor executing
microcode, and in even more complex ones, the embedded processor is
executing nanocode, but at the lowest level we get to a hardware state
machine. 

The abstraction can be carried upwards, so that we can regard a
functional language as evaluating functions. It does not matter that
underneath instructions are being executed, because at the very lowest
level its just electrons whizzing around silicon. We could even
implement the functional language on a non-digital computer.

2. You either assume or mean that computer refers to a conventional
von-Neumann style digital computer. Analog computers do not execute
instructions as such, but they can be programmed and solve problems by
producing a set of outputs given a set of inputs. There was a rather
neat economic simulation which was implemented as a set of water tanks
and pipes, and it produced quite good results. Of course, it was only
implementing an abstract functional model of an economy.

Finally, you or may not consider that the human brain is a biological
computer, and that does not appear to work by fetching instructions
and executing them. So the very concept of instructions executing in
sequence is an illusion created within our own non-digital,
non-sequential, massively parallel active memory analog computer.

Regards,



-- 
Bob Cousins, Software Engineer.
Home page at http://www.demon.co.uk/sirius-cybernetics/
Note: Commercial email to bob@lintilla.demon.co.uk will be subject to a $500 handling fee.
Sending of such email constitutes acceptance of these terms.

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

[Tim Behrendsen]

Bob Cousins <bob@lintilla.demon.co.uk> wrote in article
<322f864d.42836625@news.demon.co.uk>...
> Mark Wooding wrote:
> 
> >Lawrence Kirby <fred@genesis.demon.co.uk> wrote:
> >> In article <01bb8f19$9a89d820$32ee6fce@timhome2>
> >>            tim@airshields.com "Tim Behrendsen" writes:
> >>
> >> >There is no other view than the procedural view.
> >> 
> >> Some functional language programmers might take issue with that
> >> statement. Prologgers may have a thought or two also.
> >
> >I've not come across a computer yet which doesn't work by fetching an
> >instruction (or maybe a few at a time), doing them, and then going off
> >and fetching some more.  I guess you can pretend that this isn't the
> >case, and maybe come up with some nice ways of presenting algorithms
> >which don't depend on this, but that's not the way things work
> >underneath.  The One True View is that sequence of instructions; all
> >else is an illusion.  Maybe it's a helpful illusion, but illusion it is
> >nonetheless.
> 
> I am afraid your view is severely limited, on two counts.
>
> 1. It could be argued that executing a sequence of intructions is the
> "illusion". It appears to you that that is what happens, but all the
> CPU does is respond to a set of input signals on its pins, combines
> them with states in internal registers, and produces a new set of
> output pins and register states. 
>
> The CPU is just a complex state machine. It is just an abstraction
> that it executes instructions. Of course we have designed it to behave
> according to our abstraction. If the CPU generated non-sensical
> outputs, it would still be the same complex state machine, but we
> would not regard it as executing instructions.

Sounds like sequential operations to me.
input signals --> [state machine] --> output pins
>>>------>>> Note the time axis here >>>------>>>
 
> In fact, executing instructions is such a useful abstraction, that in
> nearly all complex processors, there is a smaller processor executing
> microcode, and in even more complex ones, the embedded processor is
> executing nanocode, but at the lowest level we get to a hardware state
> machine. 

So what?  At the lowest level, we have electrons flowing around,
changing states of electrical subsystems such as flip/flops.  This
is data manipulation over time.  No instantaneous algorithms
occurring, here.
 
> The abstraction can be carried upwards, so that we can regard a
> functional language as evaluating functions. It does not matter that
> underneath instructions are being executed, because at the very lowest
> level its just electrons whizzing around silicon. We could even
> implement the functional language on a non-digital computer.

Yes, and even if you have gears turning, somewhere you have
data transformations occurring over time.  It can't be otherwise.
"Speed of light" also refers to signal propagation.
 
> 2. You either assume or mean that computer refers to a conventional
> von-Neumann style digital computer. Analog computers do not execute
> instructions as such, but they can be programmed and solve problems by
> producing a set of outputs given a set of inputs. There was a rather
> neat economic simulation which was implemented as a set of water tanks
> and pipes, and it produced quite good results. Of course, it was only
> implementing an abstract functional model of an economy.

Again, water flows through pipes, and the measurements change
over time.  The pure integrator analog computer uses time as
one of the inputs.

> Finally, you or may not consider that the human brain is a biological
> computer, and that does not appear to work by fetching instructions
> and executing them. So the very concept of instructions executing in
> sequence is an illusion created within our own non-digital,
> non-sequential, massively parallel active memory analog computer.

The human brain works (as far as anyone knows) by electrical patterns
flowing through neurons.  You have input from your senses which
stimulates pathways in your brain, and produces changes in the
memory structures, and possibly produces output through muscular
manipulations.

*There is no view other than the procedural view*.

Everything comes down to data transformations over time.  You
have yet to come up with an example where this is not true, and
you won't, simply because you can't eliminate the time axis.  An
algorithm has to have a beginning and an end, an input and an
output, and in the middle is a black box known as the "procedure".

-- Tim Behrendsen (tim@a-sis.com)

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

[Craig Franck]

"Tim Behrendsen" <tim@airshields.com> wrote:
>Bob Cousins <bob@lintilla.demon.co.uk> wrote in article
><322f864d.42836625@news.demon.co.uk>...


>> Finally, you or may not consider that the human brain is a biological
>> computer, and that does not appear to work by fetching instructions
>> and executing them. So the very concept of instructions executing in
>> sequence is an illusion created within our own non-digital,
>> non-sequential, massively parallel active memory analog computer.
>
>The human brain works (as far as anyone knows) by electrical patterns
>flowing through neurons.  You have input from your senses which
>stimulates pathways in your brain, and produces changes in the
>memory structures, and possibly produces output through muscular
>manipulations.

Yes, but the *order* of the instructions might be an illusion.


                     *
             ()               *
            earth   star A  star B

Say star A is 50 light years from Earth and star B is 100 light
years away. If A went super nova 50 years ago and B went super nova
100 years ago they appear to explode at the same time. Without 
advanced astronomical knowledge you would have no idea of the
real order in which they exploded.

If I run a program to sum a matrix of 100 numbers on a computer
with multiple execution units and several concurrent tasks, I
may have no clue in what order matrix was summed. Dependancies
will be checked and one or more execution units may be available
or not. The idea of a descrete number of steps occuring in a fixed
order would be an illusion for some steps may occur simultaneously.

>*There is no view other than the procedural view*.
>
>Everything comes down to data transformations over time.  You
>have yet to come up with an example where this is not true, and
>you won't, simply because you can't eliminate the time axis.  An
>algorithm has to have a beginning and an end, an input and an
>output, and in the middle is a black box known as the "procedure".

In a sufficently complex vector unit, everything could literally 
happen at once. So what actually happened in the "black box" might
never be acutally known, at least as far as the order in which things
occured. You can of coarse enforce inorder execution.

There can be "a set of ordered steps for solving a problem", but the 
order might be an illusion. That a computer is a "deterministic finite
state machine" is true but you could simulate one with say, groups of human 
beings pretending to be registers and doing the logic funcions in there 
heads, even though people are not "finite state" or *perhaps* 
deterministic. In this case just when and how certain things occurred
could be imposible to find out. I could lie and say that I
did some of the logic when it was someone else. How could you even
begin to model this as a state machine? Some of the behavour would
truely be random. The time line would still be there but with no
way to lay out the events the model loses it's straight "procedural"
look and feel. What if I just randomly guessed at the value of a 
logic function? Is that procedural? How come one number popped into
my head and not another?

Also, since my debugger can run a program backwards your time line
may have to be able to go in reverse. :-)



-- 
Craig  
clfranck@worldnet.att.net    
Manchester, NH
A great many people think they are thinking when they are
merely rearranging their prejudices.  -- William James

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

[Tim Behrendsen]

Craig Franck <clfranck@worldnet.att.net> wrote in article
<50sj6q$aci@mtinsc01-mgt.ops.worldnet.att.net>...
> "Tim Behrendsen" <tim@airshields.com> wrote:
> >Bob Cousins <bob@lintilla.demon.co.uk> wrote in article
> ><322f864d.42836625@news.demon.co.uk>...
> 
> 
> >> Finally, you or may not consider that the human brain is a biological
> >> computer, and that does not appear to work by fetching instructions
> >> and executing them. So the very concept of instructions executing in
> >> sequence is an illusion created within our own non-digital,
> >> non-sequential, massively parallel active memory analog computer.
> >
> >The human brain works (as far as anyone knows) by electrical patterns
> >flowing through neurons.  You have input from your senses which
> >stimulates pathways in your brain, and produces changes in the
> >memory structures, and possibly produces output through muscular
> >manipulations.
> 
> Yes, but the *order* of the instructions might be an illusion.
> 
> 
>                      *
>              ()               *
>             earth   star A  star B
> 
> Say star A is 50 light years from Earth and star B is 100 light
> years away. If A went super nova 50 years ago and B went super nova
> 100 years ago they appear to explode at the same time. Without 
> advanced astronomical knowledge you would have no idea of the
> real order in which they exploded.
> 
> If I run a program to sum a matrix of 100 numbers on a computer
> with multiple execution units and several concurrent tasks, I
> may have no clue in what order matrix was summed. Dependancies
> will be checked and one or more execution units may be available
> or not. The idea of a descrete number of steps occuring in a fixed
> order would be an illusion for some steps may occur simultaneously.

This is true, but irrelevent.  The point is that a procedure
exists, not that it's a linear procedure.
 
> >*There is no view other than the procedural view*.
> >
> >Everything comes down to data transformations over time.  You
> >have yet to come up with an example where this is not true, and
> >you won't, simply because you can't eliminate the time axis.  An
> >algorithm has to have a beginning and an end, an input and an
> >output, and in the middle is a black box known as the "procedure".
> 
> In a sufficently complex vector unit, everything could literally 
> happen at once. So what actually happened in the "black box" might
> never be acutally known, at least as far as the order in which things
> occured. You can of coarse enforce inorder execution.

What does inorder execution have to do with anything?  If I have
2 billion operations happening at once, it doesn't change the fact
that operations occurred in a unit of time.

> There can be "a set of ordered steps for solving a problem", but the 
> order might be an illusion. That a computer is a "deterministic finite
> state machine" is true but you could simulate one with say, groups of
human 
> beings pretending to be registers and doing the logic funcions in there 
> heads, even though people are not "finite state" or *perhaps* 
> deterministic. In this case just when and how certain things occurred
> could be imposible to find out. I could lie and say that I
> did some of the logic when it was someone else. How could you even
> begin to model this as a state machine? Some of the behavour would
> truely be random. The time line would still be there but with no
> way to lay out the events the model loses it's straight "procedural"
> look and feel.

Let me play devil's advocate for non-determinism.  Let's say I had
a Geiger counter (the typical "true" random number generator) and
hooked it up to my computer to give me truly random numbers.  I
use the random values to do mathemetical analysis using the
Monte Carlo method.  I run the simulation, and get the same
result, but the path of getting to the result is different every
time, because of the random nature of algorithm.

So now the question is, so what?  There is no question that I'm
using a non-deterministic statistical algorithm, but there's
still a procedure (the Monte Carlo algorithm), and it still
requires time to execute.  One of the inputs just happens to
be random numbers.

> What if I just randomly guessed at the value of a 
> logic function? Is that procedural? How come one number popped into
> my head and not another?

To answer this question, we need to know what the algorithm
is.  Just coming up with a number in your head is an output,
but what problem was solved by your coming up with the number?

You're approaching it backwards; you're trying to guess the contents
of the black box based on the input and the output.  That's
a different question from implementation of a known algorithm.

> Also, since my debugger can run a program backwards your time line
> may have to be able to go in reverse. :-)

If a computer computes in a forest, and no one is around to
see the result, how was it plugged in? :-)

-- Tim Behrendsen (tim@a-sis.com)

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

[Craig Franck]

"Tim Behrendsen" <tim@airshields.com> wrote:
>Craig Franck <clfranck@worldnet.att.net> wrote in article
><50sj6q$aci@mtinsc01-mgt.ops.worldnet.att.net>...
>> "Tim Behrendsen" <tim@airshields.com> wrote:
>> >Bob Cousins <bob@lintilla.demon.co.uk> wrote in article
>> ><322f864d.42836625@news.demon.co.uk>...
>> 
>> 
>> >> Finally, you or may not consider that the human brain is a biological
>> >> computer, and that does not appear to work by fetching instructions
>> >> and executing them. So the very concept of instructions executing in
>> >> sequence is an illusion created within our own non-digital,
>> >> non-sequential, massively parallel active memory analog computer.
>> >
>> >The human brain works (as far as anyone knows) by electrical patterns
>> >flowing through neurons.  You have input from your senses which
>> >stimulates pathways in your brain, and produces changes in the
>> >memory structures, and possibly produces output through muscular
>> >manipulations.
>> 
>> Yes, but the *order* of the instructions might be an illusion.
>> 
>> 
>>                      *
>>              ()               *
>>             earth   star A  star B
>> 
>> Say star A is 50 light years from Earth and star B is 100 light
>> years away. If A went super nova 50 years ago and B went super nova
>> 100 years ago they appear to explode at the same time. Without 
>> advanced astronomical knowledge you would have no idea of the
>> real order in which they exploded.
>> 
>> If I run a program to sum a matrix of 100 numbers on a computer
>> with multiple execution units and several concurrent tasks, I
>> may have no clue in what order matrix was summed. Dependancies
>> will be checked and one or more execution units may be available
>> or not. The idea of a descrete number of steps occuring in a fixed
>> order would be an illusion for some steps may occur simultaneously.
>
>This is true, but irrelevent.  The point is that a procedure
>exists, not that it's a linear procedure.
> 
>> >*There is no view other than the procedural view*.
>> >
>> >Everything comes down to data transformations over time.  You
>> >have yet to come up with an example where this is not true, and
>> >you won't, simply because you can't eliminate the time axis.  An
>> >algorithm has to have a beginning and an end, an input and an
>> >output, and in the middle is a black box known as the "procedure".
>> 
>> In a sufficently complex vector unit, everything could literally 
>> happen at once. So what actually happened in the "black box" might
>> never be acutally known, at least as far as the order in which things
>> occured. You can of coarse enforce inorder execution.
>
>What does inorder execution have to do with anything?  If I have
>2 billion operations happening at once, it doesn't change the fact
>that operations occurred in a unit of time.

My point was that a "time axis" is a vector; it has a direction to 
it (forward). If a line is a set of points and by anology the points 
events, it would be dificult to construct one when the order of the 
points could change. Your challenge above, as you stated it, hinged on
"eliminating the time axis". You are correct if the order of events
need not be fixed, then the above is irrelevant. If all that is 
required is "transformations over time" I would probably have to delve 
into quantum mechanics to find a suitable example.

I always associated procedural with "imperative, algorithmic". A query
language(say SQL) was non-procedural because you would describe a query 
or a table, and the SQL system would determine the best way to construct it.
You told it what you wanted to see; it figured out the best way to do it.

A rule based system would be non-procedural as well. If I have a scheduling
program that I create a rule for, say everbody gets every other weekend 
off, and it creates a schedule in which this is true(if possible) that 
would be non-procedural as well. I suspect we are using the term in two
different ways!


>> What if I just randomly guessed at the value of a 
>> logic function? Is that procedural? How come one number popped into
>> my head and not another?
>
>To answer this question, we need to know what the algorithm
>is.  Just coming up with a number in your head is an output,
>but what problem was solved by your coming up with the number?

The point was that any system that had a person coming up with numbers
by letting them just "pop into thier heads" as opposed to say, doing 
math and reporting the results, could not be fully described because
we don't know how the numbers are being generated. If this process 
turned out to non-procedural then the system as a whole could not be
described as procedural. Computing pi to 1000 digits is procedural;
so is flipping a coin. Saying "pick a number between 1 and 100" is not
the same thing.

Think of a jury system. You can pick jurists fairly and instruct them 
on how to deliberate. Nothing forces them to come up with a just verdict.
So the system can be described as just (procedural) but in the end was 
not, because they were not just (procedural).

-- 
Craig  
clfranck@worldnet.att.net    
Manchester, NH
A great many people think they are thinking when they are
merely rearranging their prejudices.  -- William James

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

[Tim Behrendsen]

Craig Franck <clfranck@worldnet.att.net> wrote in article
<50v6k3$soo@mtinsc01-mgt.ops.worldnet.att.net>...
> "Tim Behrendsen" <tim@airshields.com> wrote:
> >Craig Franck <clfranck@worldnet.att.net> wrote in article
> 
> >> What if I just randomly guessed at the value of a 
> >> logic function? Is that procedural? How come one number popped into
> >> my head and not another?
> >
> >To answer this question, we need to know what the algorithm
> >is.  Just coming up with a number in your head is an output,
> >but what problem was solved by your coming up with the number?
> 
> The point was that any system that had a person coming up with numbers
> by letting them just "pop into thier heads" as opposed to say, doing 
> math and reporting the results, could not be fully described because
> we don't know how the numbers are being generated. If this process 
> turned out to non-procedural then the system as a whole could not be
> described as procedural.
> [snip]

This is the crux of the question.

"If this process turned out to be non-procedural..."  <--- this is
impossible according to known laws of physics.  Just because we
don't know the procedure, doesn't mean there isn't one.  Now,
given our lack of knowledge on how the brain works, it may
turn out that it is not deterministic, if the brain has truly
random elements as some speculate (I doubt it, personally), but
it would still be procedural and algorithmic.

Could you mean "deterministic" when you say "procedural"?

Going back to the SQL example, SQL is an expression of the algorithm,
but it is not possible to "directly execute" SQL; it has to be
translated into a procedural algorithm, and this is the same
with all "non-procedural expression" languages.

-- Tim Behrendsen (tim@a-sis.com)

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

[Richard A. O'Keefe]

"Tim Behrendsen" <tim@airshields.com> writes:

>"If this process turned out to be non-procedural..."  <--- this is
>impossible according to known laws of physics.

I honestly don't see this.  I don't personally know all the known laws
of physics; my Msc was in underswater acoustics which isn't exactly
TOE-of-the-month even if the refraction equation _is_ formally identical
to the one-dimensional Schroedinger equation.  I have read a number of
papers on quantum computing, and think I understand the idea.  Now
quantum computers cannot compute anything that a "procedural" computer
cannot compute, but they _can_ compute things asymptotically faster than
any possible 'procedural' computer (precisely because they are not discrete
one-step-at-a-time finite state beasts).

So if Tim Behrendsen knows which presently known laws of physics make
quantum computers impossible, he should publish in Nature.

>Going back to the SQL example, SQL is an expression of the algorithm,
>but it is not possible to "directly execute" SQL; it has to be
>translated into a procedural algorithm, and this is the same
>with all "non-procedural expression" languages.

Tell me, do you regard optical computing as procedural?
If you don't (and since it is non-discrete, with no "time axis" that
is useful in understanding how it works), then SQL _can_ be translated
into a non-procedural but executable form.
If you _do_ regard optical computing as procedural, then you have
stretched the term to the point where you are no longer saying anything.

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

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

[Tim Behrendsen]

Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote in article
<5136on$7qj@goanna.cs.rmit.edu.au>...
> "Tim Behrendsen" <tim@airshields.com> writes:
> 
> >"If this process turned out to be non-procedural..."  <--- this is
> >impossible according to known laws of physics.
> 
> I honestly don't see this.  I don't personally know all the known laws
> of physics; my Msc was in underswater acoustics which isn't exactly
> TOE-of-the-month even if the refraction equation _is_ formally identical
> to the one-dimensional Schroedinger equation.  I have read a number of
> papers on quantum computing, and think I understand the idea.  Now
> quantum computers cannot compute anything that a "procedural" computer
> cannot compute, but they _can_ compute things asymptotically faster than
> any possible 'procedural' computer (precisely because they are not discrete
> one-step-at-a-time finite state beasts).
> 
> So if Tim Behrendsen knows which presently known laws of physics make
> quantum computers impossible, he should publish in Nature.

I didn't say anything about "quantum computers", I said "non-procedural".
See below.

> >Going back to the SQL example, SQL is an expression of the algorithm,
> >but it is not possible to "directly execute" SQL; it has to be
> >translated into a procedural algorithm, and this is the same
> >with all "non-procedural expression" languages.
> 
> Tell me, do you regard optical computing as procedural?
> If you don't (and since it is non-discrete, with no "time axis" that
> is useful in understanding how it works), then SQL _can_ be translated
> into a non-procedural but executable form.

Unless I'm mistaken, you seem to regard "procedural" as meaning a
discrete sequence of steps.  My definition is a bit more broad; I
see procedural as anything with a procedure; that is, an analog
integrator is a procedural mechanism, even though there is no
sequence of individual steps.

It is similiar to the difference between summation and integration;
one consists of individual sums, the other of an infinite number
of sums.  However, both are fundamentally adding.

When I see "Optical Computing", I normally think of gates that use
photons rather than electrons, but I'm guessing you are referring to
what I know as a "data flow" computer, where the data is encoded in
a stream and "flows" through various data transformation mechanisms.

However, this still requires time.  You make a claim above that
"...and since it is non-discrete, with no 'time axis'...".  Perhaps
you could explain why non-discrete means it does not require a time
axis, and give an example of *any* algorithm that does not require
a time axis, i.e., does not require time.

> If you _do_ regard optical computing as procedural, then you have
> stretched the term to the point where you are no longer saying anything.

Procedural means "has a procedure."  Nothing in the real world
is not procedural, but we can *express* algorithms non-procedurally.
This is where the term is useful.  The term is meaningless when it
comes to implementation.

-- Tim Behrendsen (tim@a-sis.com)

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

[John Burdick]

This argument about the procedural view being the one true view
strikes me as silly. We know that Turing's machine and Church's lambda
calculus are _both_ able to express any computation the other can.
Trying to find some practical computation Turing can't do is
pointless, but that doesn't make Church subsidiary to Turing.

John

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

[Bengt Richter]

mdw@excessus.demon.co.uk (Mark Wooding) wrote:

>Lawrence Kirby <fred@genesis.demon.co.uk> wrote:
>> In article <01bb8f19$9a89d820$32ee6fce@timhome2>
>>            tim@airshields.com "Tim Behrendsen" writes:
>>
>> >There is no other view than the procedural view.
>> 
>> Some functional language programmers might take issue with that
>> statement. Prologgers may have a thought or two also.

>I've not come across a computer yet which doesn't work by fetching an
>instruction (or maybe a few at a time), doing them, and then going off
>and fetching some more.  I guess you can pretend that this isn't the
>case, and maybe come up with some nice ways of presenting algorithms
>which don't depend on this, but that's not the way things work
>underneath.  The One True View is that sequence of instructions; all
>else is an illusion.  Maybe it's a helpful illusion, but illusion it is
>nonetheless.

Au contraire. "The way things work underneath" is not sequential. All
the energized components of a computer exist and work in parallel.
It is only by focusing on certain parts and giving names to their
states and state transitions that you can see the abstract model
involving "that sequence of instructions."

E.g., to speak of "fetching an instruction" as if were a single event
is to ignore most of the reality "underneath." (Not to mention that
the reality differs among computer architectures). It may be useful
to exclude details that are not relevant to a particular abstract
model, but to think any such model embodies "the One True View" is
severely limiting, IMHO. To constrain a student's thoughts to such
a straight jacket without at some point untying the laces would be
a crime. Some may not be able to escape without help ;-)

Regards,
Bengt Richter

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

[Craig Franck]

bokr@accessone.com (Bengt Richter) wrote:
>mdw@excessus.demon.co.uk (Mark Wooding) wrote:
>
>>Lawrence Kirby <fred@genesis.demon.co.uk> wrote:
>>> In article <01bb8f19$9a89d820$32ee6fce@timhome2>
>>>            tim@airshields.com "Tim Behrendsen" writes:
>>>
>>> >There is no other view than the procedural view.
>>> 
>>> Some functional language programmers might take issue with that
>>> statement. Prologgers may have a thought or two also.
>
>>I've not come across a computer yet which doesn't work by fetching an
>>instruction (or maybe a few at a time), doing them, and then going off
>>and fetching some more.  I guess you can pretend that this isn't the
>>case, and maybe come up with some nice ways of presenting algorithms
>>which don't depend on this, but that's not the way things work
>>underneath.  The One True View is that sequence of instructions; all
>>else is an illusion.  Maybe it's a helpful illusion, but illusion it is
>>nonetheless.
>
>Au contraire. "The way things work underneath" is not sequential. All
>the energized components of a computer exist and work in parallel.
>It is only by focusing on certain parts and giving names to their
>states and state transitions that you can see the abstract model
>involving "that sequence of instructions."
>
>E.g., to speak of "fetching an instruction" as if were a single event
>is to ignore most of the reality "underneath." (Not to mention that
>the reality differs among computer architectures). It may be useful
>to exclude details that are not relevant to a particular abstract
>model, but to think any such model embodies "the One True View" is
>severely limiting, IMHO. To constrain a student's thoughts to such
>a straight jacket without at some point untying the laces would be
>a crime. Some may not be able to escape without help ;-)

I would direct such a student to Gary Zukav's "The Dancing Wu Li
Masters" or Fritjof Capra's "The Toa of Physics". From reading 
these books it will become obvious that the "One True View" is
that everything is a "dancing pattern of organic energy". In this 
very eastern view, "organic" applies to the quantum states of atoms 
as well as to carbon chemistry. 

Please note that Tim's statement had to do with teaching algorithms,
and I don't think he meant that if GOD exists HE is procedural.

-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
Knowledge is of two kinds; we know a subject ourselves, or we
know where we can find information about it. --  Samual Johnson

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

[Robert I. Eachus]

In article <slrn52tn5u.8d.mdw@excessus.demon.co.uk> mdw@excessus.demon.co.uk (Mark Wooding) writes:

  > The One True View is that sequence of instructions; all else is an
  > illusion.  Maybe it's a helpful illusion, but illusion it is
  > nonetheless.

    Sorry, this is completely false.  On most modern processors which
typically have multiple independent pipelines, your One True View is
at best a helpful illusion.  Go get a SPARC, PA-RISC, or PowerPC
reference manual and read it. (You have to sign a non-disclosure
agreement to get the same level of detail about a Pentium.)  In all
cases, the illusion that there is such a thing as a processor state is
only true in some cases of traps or signals--and even then it is not
all that well defined.  Assembler on a Z80 chip might correspond to
some One True View, but for all modern chips architecture manuals
sections on assembly should only be read by compiler vendors.  (And
they need to read it VERY carefully, but that is a different
discussion.)

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

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

[Tim Behrendsen]

Robert I. Eachus <eachus@spectre.mitre.org> wrote in article
<EACHUS.96Sep5200334@spectre.mitre.org>...
> In article <slrn52tn5u.8d.mdw@excessus.demon.co.uk>
mdw@excessus.demon.co.uk (Mark Wooding) writes:
> 
>   > The One True View is that sequence of instructions; all else is an
>   > illusion.  Maybe it's a helpful illusion, but illusion it is
>   > nonetheless.
> 
>     Sorry, this is completely false.  On most modern processors which
> typically have multiple independent pipelines, your One True View is
> at best a helpful illusion.  Go get a SPARC, PA-RISC, or PowerPC
> reference manual and read it. (You have to sign a non-disclosure
> agreement to get the same level of detail about a Pentium.)  In all
> cases, the illusion that there is such a thing as a processor state is
> only true in some cases of traps or signals--and even then it is not
> all that well defined.  Assembler on a Z80 chip might correspond to
> some One True View, but for all modern chips architecture manuals
> sections on assembly should only be read by compiler vendors.  (And
> they need to read it VERY carefully, but that is a different
> discussion.)

The point is not that there's a single thread of execution,
but that there *is* a thread of execution.  His point (and mine)
is that algorithms require instruction execution over time.  The
number of simultaneous instructions is irrelevent, and so-called
"non-procedural" languages are only non-procedural in the sense
that the programmer does not specify the procedure -- the
compiler does.

-- Tim Behrendsen (tim@a-sis.com)

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

[Richard A. O'Keefe]

"Tim Behrendsen" <tim@airshields.com> writes:
>Unless I'm mistaken, you seem to regard "procedural" as meaning a
>discrete sequence of steps.  My definition is a bit more broad; I
>see procedural as anything with a procedure; that is, an analog
>integrator is a procedural mechanism, even though there is no
>sequence of individual steps.

Ah.  So you have broadened the term "procedural" to the point of
uselessness.  I worked with analogue computers at one time, and
there's a wiring diagram, but there is *nothing* going on in them
that I would recognise as a "procedure".

>It is similiar to the difference between summation and integration;
>one consists of individual sums, the other of an infinite number
>of sums.  However, both are fundamentally adding.

Ever seen a planimeter?  One of those neat little gadgets where you
determine areas by rolling a little wheel around?  You can repeat
"it's fundamentally adding" all you like, but that isn't how the
gadgets actually _work_.

>When I see "Optical Computing", I normally think of gates that use
>photons rather than electrons, but I'm guessing you are referring to
>what I know as a "data flow" computer, where the data is encoded in
>a stream and "flows" through various data transformation mechanisms.

I am *not* talking about gates.  That might be optronics, but it isn't
optical computing.  Optical computing is where you have a spatially
coded signal and it is processed (FFT and so on) by lenses, mirrors,
holograms, and so on.

>However, this still requires time.  You make a claim above that
>"...and since it is non-discrete, with no 'time axis'...".  Perhaps
>you could explain why non-discrete means it does not require a time
>axis, and give an example of *any* algorithm that does not require
>a time axis, i.e., does not require time.

You have misquoted me and distorted what I was saying.  Yes, we are
talking about physical devices, so things happen in time.  But what
I wrote was "with no "time axis" THAT IS USEFUL IN UNDERSTANDING HOW IT
WORKS", and that is a very different claim.  The optical bench does not
vary through time.


>> If you _do_ regard optical computing as procedural, then you have
>> stretched the term to the point where you are no longer saying anything.

>Procedural means "has a procedure."

Yes, but fundamental to what everyone in computing except you means by
"procedure" is "a discrete sequence of steps".

>Nothing in the real world is not procedural,

In short, you have have stretched the words 'procedure' and 'procedural'
until _everything_ is procedural, _everything_ "has a procedure".
This is a good way to win an argument, by ensuring that you are saying
nothing.  If I re-define 'is blue' to mean 'is a physical object',
than I can be sure that no-one can prove me wrong when I say "every
phsyical object is blue", but then I haven't _said_ anything.

> but we can *express* algorithms non-procedurally.
If you are right that _everything_ is procedural, then this cannot be true.
If I write down an equation like
	Del  R      = 0
	   [a bc]de
(the Bianchi identity, equation 4.10.1 in Penrose & Rindler),
then since "nothing in the real world is not procedural" (according to
you), and since the picture of that equation before your eyes is "in the
real world" (I say the _picture_ of the equation, not the equation), then
that picture must be procedural.  (I do not know what it means for a
picture to be procedural, but we have your word that it is so.)  So that
picture is procedural, and the attempt to express something "non-procedurally"
has failed.

In short, the discussion with you has been a waste of time, because
you were never making any claim with empirical content, only playing
language games.


-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

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

[Tim Behrendsen]

Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote in article
<515o3b$d7h@goanna.cs.rmit.edu.au>...
> "Tim Behrendsen" <tim@airshields.com> writes:
> 
> >However, this still requires time.  You make a claim above that
> >"...and since it is non-discrete, with no 'time axis'...".  Perhaps
> >you could explain why non-discrete means it does not require a time
> >axis, and give an example of *any* algorithm that does not require
> >a time axis, i.e., does not require time.
> 
> You have misquoted me and distorted what I was saying.  Yes, we are
> talking about physical devices, so things happen in time.  But what
> I wrote was "with no "time axis" THAT IS USEFUL IN UNDERSTANDING HOW IT
> WORKS", and that is a very different claim.  The optical bench does not
> vary through time.

The original progenitor of this thread is my assertion that
the most important thing a student can learn is the fundamental
procedural nature of the the computer.

Time is extremely useful in understanding how something works,
although you don't normally invoke it's name.  Even in your
optical computer, you have light-encoded information flowing
through mirrors, etc.  *This is time*.  If you are explaining
to a student how it works, your finger will trace a path
through the machine.

My entire point before we went down this road is that I think
many teachers take it for granted that cause-and-effect and
procedure are so obvious they don't need to be learned, and
that's not true.

> >> If you _do_ regard optical computing as procedural, then you have
> >> stretched the term to the point where you are no longer saying anything.
> 
> >Procedural means "has a procedure."
> 
> Yes, but fundamental to what everyone in computing except you means by
> "procedure" is "a discrete sequence of steps".

No, fundamental to *you*, perhaps, but I have never heard this
definition before.  Of course, your optical computer fits this
definition, since it has a discrete sequence of steps (mirrors,
etc.), and you claim that *it* doesn't.

> >Nothing in the real world is not procedural,
> 
> In short, you have have stretched the words 'procedure' and 'procedural'
> until _everything_ is procedural, _everything_ "has a procedure".
> This is a good way to win an argument, by ensuring that you are saying
> nothing.  If I re-define 'is blue' to mean 'is a physical object',
> than I can be sure that no-one can prove me wrong when I say "every
> phsyical object is blue", but then I haven't _said_ anything.

No, the definition is very clear.  The point is that non-procedural
*expressions* are an abstract concept.  I have no problem with
saying that algorithms can be abstractly expressed non-procedurally,
but they cannot be implemented non-procedurally.

> > but we can *express* algorithms non-procedurally.
> If you are right that _everything_ is procedural, then this cannot be true.
> If I write down an equation like
> 	Del  R      = 0
> 	   [a bc]de
> (the Bianchi identity, equation 4.10.1 in Penrose & Rindler),
> then since "nothing in the real world is not procedural" (according to
> you), and since the picture of that equation before your eyes is "in the
> real world" (I say the _picture_ of the equation, not the equation), then
> that picture must be procedural.  (I do not know what it means for a
> picture to be procedural, but we have your word that it is so.)  So that
> picture is procedural, and the attempt to express something "non-procedurally"
> has failed.

Now you're arguing worthless semantics.  Obviously that's not what
I'm saying.  How about "No algorithm implementation is not
procedural", which is what you know that I meant.

A mathematical expression is non-procedural, because it is a
statement of truth, and not an algorithmic sequence.

An SQL expression is not procedural, because it is not an algorithmic
sequence, it is a mathematical transformation.

In other words, procedural mechanisms have a start, middle, and
end.  Non-procedural expressions do not.

> In short, the discussion with you has been a waste of time, because
> you were never making any claim with empirical content, only playing
> language games.

Well, I'm sorry you feel that way, but you are wrong.

You prove my point that programmers take the procedural nature
of the computer as so obvious as to be beneath discussion, but
it's not.  I cannot stress this enough: THIS MUST BE LEARNED BY
STUDENTS.  This is the primary, fundamental axiom of computers.

How many questions do we get in this newsgroup where a student
simply didn't follow the flow of the program to see what happens?
This is so obvious to you and I that we don't think about it,
but *they didn't*!  Because they have only a vague feeling of
flow, and are still looking at the program as a kind of
weird combination of a solid object and something with a flow
of time.

Take recursion.  How can you not understand recursion if you
understand in your soul that computers execute a flow of
instructions?  You can't, and that's the point.  Understanding
the time axis is the key.

-- Tim Behrendsen (tim@a-sis.com)

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

[Peter Seebach]

In article <01bb9fe6$7299d800$87ee6fce@timpent.a-sis.com>,
Tim Behrendsen <tim@airshields.com> wrote:
>The original progenitor of this thread is my assertion that
>the most important thing a student can learn is the fundamental
>procedural nature of the the computer.

I would probably disagree.  I don't consider the implementation to be
nearly as important as the design.  Students should be learning the
principles of proof and design.

>Time is extremely useful in understanding how something works,
>although you don't normally invoke it's name.  Even in your
>optical computer, you have light-encoded information flowing
>through mirrors, etc.  *This is time*.  If you are explaining
>to a student how it works, your finger will trace a path
>through the machine.

But that explanation is an explanation of *another way to think
about it*, not of how it works.

We frequently use the procedural view because it's the most natural for
languages such as English to describe; we don't have a "simultaneous" tense.

This is frequently a downright *bad* way to model a problem, or to think about
the model.

>My entire point before we went down this road is that I think
>many teachers take it for granted that cause-and-effect and
>procedure are so obvious they don't need to be learned, and
>that's not true.

They are important, but not necessarily the most important.

>> Yes, but fundamental to what everyone in computing except you means by
>> "procedure" is "a discrete sequence of steps".

>No, fundamental to *you*, perhaps, but I have never heard this
>definition before.  Of course, your optical computer fits this
>definition, since it has a discrete sequence of steps (mirrors,
>etc.), and you claim that *it* doesn't.

That's what I'd mean by a procedure; if they aren't separate, they're only one
step.  If there's only one step in the whole process, it's not much of a
procedure.

How to build a house:

Step 1.  Assemble the materials in the form of a house.

This is *not* a procedure.  :)

I would not think of an optical computer in terms of steps happening over
time, unless it was a very *large* optical computer.  In practice, it will act
as though everything happens all at once and continuously.  This is harder to
think about, but much more useful to understanding it, and less prone to
making the wrong kinds of design decisions.

>No, the definition is very clear.  The point is that non-procedural
>*expressions* are an abstract concept.  I have no problem with
>saying that algorithms can be abstractly expressed non-procedurally,
>but they cannot be implemented non-procedurally.

So we should avoid procedural things and implementations until students are
comfortable with the abstractions, since abstraction is much more important to
an understanding of *anything* than any procedure or implementation.

>Now you're arguing worthless semantics.  Obviously that's not what
>I'm saying.  How about "No algorithm implementation is not
>procedural", which is what you know that I meant.

I'd debate that.

>In other words, procedural mechanisms have a start, middle, and
>end.  Non-procedural expressions do not.

In which case, much programming is not procedural.  In which case,
it is very bad to try to convince students that the computer
is "fundementally" procedural, because this will not help them
understand the domain they're working in.

Proceduralness is like 5-volt-ness.  It's basic to the majority of
implementations, but not relevant to a lot of the things people
will need to know to use a computer.

>You prove my point that programmers take the procedural nature
>of the computer as so obvious as to be beneath discussion, but
>it's not.  I cannot stress this enough: THIS MUST BE LEARNED BY
>STUDENTS.  This is the primary, fundamental axiom of computers.

Nonsense.  It's completely irrelevant to a good understanding of many
aspects of computers, and downright misleading for whole families of
programming languages.

It is very important that they learn to use this view of computers;
it is neither desirable nor necessary that they believe it is the only view,
or that it is the most correct view, or any such.

>How many questions do we get in this newsgroup where a student
>simply didn't follow the flow of the program to see what happens?

Quite a lot.  We also get a fair number where the flow of the program is not
relevant to an understanding of the problem.  We even get problems where
an attempt to think of the "flow" of the program will bite the student,
because they're compile-time problems, not run-time problems.

>This is so obvious to you and I that we don't think about it,
>but *they didn't*!  Because they have only a vague feeling of
>flow, and are still looking at the program as a kind of
>weird combination of a solid object and something with a flow
>of time.

It is.

>Take recursion.  How can you not understand recursion if you
>understand in your soul that computers execute a flow of
>instructions?  You can't, and that's the point.  Understanding
>the time axis is the key.

I disagree.  I think I understand recursion, and I don't think of it
in time at all, I think of it in space.  Recursion doesn't move forward
in time, it moves down in space.  I tend to look at the naive recursive
quicksort as a tree of sorts, not as a sequence of sorts.  This makes it
much more obvious how it *works*.

Not how it's implemented, mind you; how it *works*.

The flow in a recursive algorithm is up-down, not forward-back.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

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

[Tim Behrendsen]

Peter Seebach <seebs@solutions.solon.com> wrote in article
<519i0o$mgb@solutions.solon.com>...
> In article <01bb9fe6$7299d800$87ee6fce@timpent.a-sis.com>,
> Tim Behrendsen <tim@airshields.com> wrote:
> >The original progenitor of this thread is my assertion that
> >the most important thing a student can learn is the fundamental
> >procedural nature of the the computer.
> 
> I would probably disagree.  I don't consider the implementation to be
> nearly as important as the design.  Students should be learning the
> principles of proof and design.

Agreed that proof and design are important, but we are talking
about first principles.  We want to get them thinking in
"normal" computer terms first, so that they are capable of knowing
what they are learning later on.  These are the students
that I'm getting; all memorized knowledge and no understanding.

Perhaps in the future, we will have "non-procedural" languages
that can be useful over a broader range of problems, and
learning these concepts will be less important.  At this time
in computer history, however, it's critical.

> >Time is extremely useful in understanding how something works,
> >although you don't normally invoke it's name.  Even in your
> >optical computer, you have light-encoded information flowing
> >through mirrors, etc.  *This is time*.  If you are explaining
> >to a student how it works, your finger will trace a path
> >through the machine.
> 
> But that explanation is an explanation of *another way to think
> about it*, not of how it works.
> 
> We frequently use the procedural view because it's the most natural for
> languages such as English to describe; we don't have a "simultaneous" tense.
> 
> This is frequently a downright *bad* way to model a problem, or to think about
> the model.

There may be some problems that are easier to understand/model
using a non-procedural view, but they are usually very
specialized and trivial.  And the execution is always a
mechanistic model.

> >My entire point before we went down this road is that I think
> >many teachers take it for granted that cause-and-effect and
> >procedure are so obvious they don't need to be learned, and
> >that's not true.
> 
> They are important, but not necessarily the most important.

But the point is, the concepts are frequently neglected as a
subject in and unto itself.

Given that this is by far the dominant implementation style,
I don't think it's a stretch to say that is the most important
thing to learn.

> >> Yes, but fundamental to what everyone in computing except you means by
> >> "procedure" is "a discrete sequence of steps".
> 
> >No, fundamental to *you*, perhaps, but I have never heard this
> >definition before.  Of course, your optical computer fits this
> >definition, since it has a discrete sequence of steps (mirrors,
> >etc.), and you claim that *it* doesn't.
> 
> That's what I'd mean by a procedure; if they aren't separate, they're only one
> step.  If there's only one step in the whole process, it's not much of a
> procedure.
> 
> How to build a house:
> 
> Step 1.  Assemble the materials in the form of a house.
> 
> This is *not* a procedure.  :)

Sure it is; it's just a big procedure. :)

Every step is composed of sub-steps; it just depends on how
much you want to split them down.  I execute a printf; this
would commonly be referred to as one step.  However, it invokes
a great deal of assembly language to create the action.  Taking
it further, it causes a lot of gates within the CPU to open
and close.  Taking it still further, it causes various
quantum changes within the transisters within the gates.

You'll note that what you call a "step-by-step" process is
actually composed of a continuous flow of electrons.

> I would not think of an optical computer in terms of steps happening over
> time, unless it was a very *large* optical computer.  In practice, it will act
> as though everything happens all at once and continuously.  This is harder to
> think about, but much more useful to understanding it, and less prone to
> making the wrong kinds of design decisions.

Ridiculous!  Even if things happen very, very fast, it still
requires time for the light to travel through the various gates.
In practice, a modern CPU can add an array of a hundred numbers
"as though it happens all at once and continuously".
 
> >No, the definition is very clear.  The point is that non-procedural
> >*expressions* are an abstract concept.  I have no problem with
> >saying that algorithms can be abstractly expressed non-procedurally,
> >but they cannot be implemented non-procedurally.
> 
> So we should avoid procedural things and implementations until students are
> comfortable with the abstractions, since abstraction is much more important to
> an understanding of *anything* than any procedure or implementation.

I strongly disagree.  Abstraction is extremely difficult to understand
without an understanding of cause-and-effect and procedure.  Look
at the questions we get in this newsgroup.  I would wager that
90% of them are simply that the student doesn't follow the flow
of the program (e.g. uninitialize variables).

> >You prove my point that programmers take the procedural nature
> >of the computer as so obvious as to be beneath discussion, but
> >it's not.  I cannot stress this enough: THIS MUST BE LEARNED BY
> >STUDENTS.  This is the primary, fundamental axiom of computers.
> 
> Nonsense.  It's completely irrelevant to a good understanding of many
> aspects of computers, and downright misleading for whole families of
> programming languages.

I should have said the execution of programs must be
procedural; my phrasing was not very good.

> It is very important that they learn to use this view of computers;
> it is neither desirable nor necessary that they believe it is the only view,
> or that it is the most correct view, or any such.
> 
> >How many questions do we get in this newsgroup where a student
> >simply didn't follow the flow of the program to see what happens?
> 
> Quite a lot.  We also get a fair number where the flow of the program is not
> relevant to an understanding of the problem.  We even get problems where
> an attempt to think of the "flow" of the program will bite the student,
> because they're compile-time problems, not run-time problems.
> 
> >This is so obvious to you and I that we don't think about it,
> >but *they didn't*!  Because they have only a vague feeling of
> >flow, and are still looking at the program as a kind of
> >weird combination of a solid object and something with a flow
> >of time.
> 
> It is.

It is, in the sense that each line of code is a solid object,
but not in the sense of the overall flow.

Yes, there are certain languages that are do not have a
programmer-specified flow, but we are talking about first
principles.

> >Take recursion.  How can you not understand recursion if you
> >understand in your soul that computers execute a flow of
> >instructions?  You can't, and that's the point.  Understanding
> >the time axis is the key.
> 
> I disagree.  I think I understand recursion, and I don't think of it
> in time at all, I think of it in space.  Recursion doesn't move forward
> in time, it moves down in space.  I tend to look at the naive recursive
> quicksort as a tree of sorts, not as a sequence of sorts.  This makes it
> much more obvious how it *works*.

But moving in space *is* time.  You can't get away from it.  Time
is only one element; data movement is certainly important as well.

The point is, execution requires time, which is why teaching
this fundamental point is so important.

> Not how it's implemented, mind you; how it *works*.
> 
> The flow in a recursive algorithm is up-down, not forward-back.

Well, all algorithms are up-down if they have any looping in
them. :)  To tell you the truth, I'm not sure what "forward-back"
means v.s. up-down.

-- Tim Behrendsen (tim@a-sis.com)

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

[Richard A. O'Keefe]

"Tim Behrendsen" <tim@airshields.com> writes:

>Time is extremely useful in understanding how something works,
>although you don't normally invoke it's name.  Even in your
>optical computer, you have light-encoded information flowing
>through mirrors, etc.  *This is time*.  If you are explaining
>to a student how it works, your finger will trace a path
>through the machine.

This is simply false.  When I was taught about these beasts, this
simply didn't happen.  To the extent that there was a progression
of _ideas_, the progression went from the _output_ back to the input.
No doubt other teachers than mine have other methods of presentation,
but that's not how it was for me.

What's more, I was introduced to Feynman's treatment of electromagnetic
radiation involving a wave propagating _backwards_ in time.

>My entire point before we went down this road is that I think
>many teachers take it for granted that cause-and-effect and
>procedure are so obvious they don't need to be learned, and
>that's not true.

There are some people who believe that backwards causation is
self-contradictory, while there are others like me, who think
that Goedel's rotating universe model has shown backwards
causation to be compatible with the presently accepted laws of
physics ("Tipler machines" are basically inside-out Goedel universes).
Then there are the old distinctions between cause and ground, between
formal, material, and final causes.  Millenia of philosophy have shown
the concept to be very tricky indeed.  But what has that to do with
computing?  If I write a constraint logic program, you cannot point
to any part of the program and say "this causes that", but it is
computer programming for all that.

And I certainly agree that "procedure" is not an obvious concept.
I have just conducted a thorough search of my office.
Three English dictionaries agree that "procedure" means something like
"rules of behaviour", in the bureaucratic sense.  I have quite a few
books about algorithms, algorithmics, foundations of computing, &c.
All of *them* basically boiled down to "procedure, see subroutine".

>> Yes, but fundamental to what everyone in computing except you means by
>> "procedure" is "a discrete sequence of steps".

>No, fundamental to *you*, perhaps, but I have never heard this
>definition before.

As I said, the English dictionaries are talking about bureaucratic
procedures, which are often written down in rule books.  Even when they
are not, to follow a (bureaucratic) procedure means to engage in a sequence
of behaviours regulated by rules, and those behaviours are conceptualised
as discrete.  In computing, as I said above, I have been unable to find
any definition of "procedure" that distinguishes it from a Fortran
subroutine or Pascal procedure.  In fact, that is why the "procedural"
languages are so-called, because a procedural program is organised as
a possibly structured collections of procedures in the Fortran/Algol/Pascal
sense.  *This* in the meaning that leaps to mind to everyone who has
posted in this thread except you.

I have been able to locate a definition of algorithm.  I wonder if you
will recognise it:

	The notion of an _algorithm_ is basic to all of
	computer programming, so we should begin with a
	careful analysis of this concept.
	...
	So this is an algorithm.  The modern meaning for algorithm
	is quite similar to that of _recipie_, _process_, _method_,
	_technique_, _procedure_, _routine_, except that the word
	"algorithm" connotes something just a little different.
	Besides merely being a finite set of rules which gives a
	sequence o operations for solving a specific type of
	problem [%], an algorithm has five important features:

	1) Finiteness.  An algorithm must always terminate after a
	finite number of steps.  ... (A procedure which has all of
	the characteristics of an algorithm except that it possibly
	lacks finiteness may be called a "computational method." ...[%])

	2) Definiteness.  Each step of an algorithm must be
	precisely defined; the actions to be carried out must be
	rigorously and unambiguously specified for each case.

	3) Input.  An algorithm has zero or more inputs ...

	4) Output.  An algorithm has one or more outputs ...

	5) Effectiveness.  An algorithm is also generally
	expected to be _effective_.  This means that all of the
	operations to be performed in the algorithm must be
	sufficiently basic that they can in principle be done
	exactly and in a finite length of time by a man using
	pencil and paper. ..

[%] These statements make it clear that the distinguished computer
scientist who wrote this important textbook, whose emeritus chair
is in fact named after the book, considers "procedures" and
"algorithms" to be pretty much the same kind of thing, except that
"procedure" is a _slightly_ looser term.  This is actually the same
book containing "procedure, see subroutine" in the index, but every
other book in this office agrees with that.

>Of course, your optical computer fits this
>definition, since it has a discrete sequence of steps (mirrors,
>etc.), and you claim that *it* doesn't.

No, the mirrors are not steps.  It is in principle possible to build
an optical computer as a single translucent block with varying refractive
index. You don't need a crisp metal/air interface to get reflection; a
continuous change in refractive index (I did say my MSc was in underwater
acoustics) will do the job nicely.  The holographic transformation of an
optical signal _certainly_ takes place in a continously varying medium;
that's why I chose that example.

Let's compute a 2-dimensional optical signal propagating through a
medium with a predetermined static spatial modulation of its refractive
index.  

    1. Finiteness:  Not necessary for a procedure.
    2. Definiteness:  the transformation is precisely defined by
	partial differential equations.
    3. Input:  the incoming stream of photons.
    4. Output:  the outgoing stream of photons.
    5. Effectiveness:  fails miserably.  The relevant number here
	is the power of the continuum.  That was the point of selecting
	a model where _continuously_ varying media are involved.

>No, the definition is very clear.

You may _say_ that the definition is very clear, but you still haven't
told us what your definition of a procedure _is_, and why such an
extremely general redefinition of "procedure" is _relevant_ to CS
education.

>The point is that non-procedural
>*expressions* are an abstract concept.

So are *any* expressions.  So are "so", "are", "any", and "expressions".
What is the _point_?  Causality is (or are) an abstract concept.  Effect
is an abstract concept.  Number is a highly abstract concept.

>I have no problem with
>saying that algorithms can be abstractly expressed non-procedurally,
>but they cannot be implemented non-procedurally.

I have said this before:  according to your definition, EVERYTHING is
procedural.  Clouds, cockroaches, ink drops swirling in milk, alpha
particles tunnelling out of nuclei, they are all in the real world and
according to you _everything_ in the real world is procedural.  If you
are right, a non-procedure expression is simply an impossibility,
because strive as hard as we may, we end up with something in the real
world, and you say "no, *everything* in the real world is procedural".

>Now you're arguing worthless semantics.  Obviously that's not what
>I'm saying.

No, it is *not* obvious.

>How about "No algorithm implementation is not
>procedural", which is what you know that I meant.

No, I did *not* know that you meant that.  But *any* method of expressing
an algorithm (and as soon as you say "algorithm" you are conceding me
finiteness, definiteness, input, output, and effectiveness") is an
implementation.  This is my claim:  any intelligible expression of an
algorithm _is_ an implementation.  Proof:  if a human being can determine
that it _is_ the expression of an algorithm, then the human being has
determined that s/he could at least in principle execute the algorithm
with pencil and paper (the definition of effectiveness).  Anything that
no human being cannot figure out a method of calculating with pencil
and paper (in principle), cannot be the expression of an algorithm.

Since any human-intelligible expression of an algorithm _is_ by its
very nature an implementation of that algorithm, and since you claim
that no algorithm implementation is not procedural, then every
human-intelligible expression of an algorithm MUST, if you are correct,
count as procedural.

>A mathematical expression is non-procedural, because it is a
>statement of truth, and not an algorithmic sequence.

_I_ have no difficulty with this, because to me most mathematical
expressions are not algorithms.  But _you_ say that _everything_ is
procedural.  If mathematical expressions are part of the real world,
and if everything in the real world is procedural, how come you now
surprise us with a claim that a mathematical expression is not
procedural?  And if a mathematical expression is not procedural,
how is a constraint logic program, in which everything is non-directional
statements of truth, procedural?

>An SQL expression is not procedural, because it is not an algorithmic
>sequence, it is a mathematical transformation.

Here I disagree.  I think an SQL expression _is_ procedural.
Is an SQL expression an algorithm?  Let's see
    Finiteness:  yes.
    Definiteness:  yes.
    Input:  yes (the extensional data base).
    Output:  yes (the computed relation).
    Effectiveness:  yes.  There is an obvious naive pencil-and-paper
	method for computing the result of an SQL formula.  In fact,
	when students are taught SQL, they are sometimes required to
	evaluate SQL expressions in their exercises.
So an SQL expression passes all the tests for being an algorithm.
Why do you say it isn't?  Sure, a computer program may compute the
value of an SQL expression some other way, but that is equally true
for every programming language.  The student machine here has
asynchronous loads:  execute a load instruction, and the result might
not arrive until 30 cycles later, during which time more than 100
other instructions may have completed.  (It's an UltraSPARC.)  The
sequence _as written_ is not the sequence _as executed_, so we can't
let _that_ be a criterion for whether something is procedural or
mathematical.

>In other words, procedural mechanisms have a start, middle, and
>end.  Non-procedural expressions do not.

Hang on, you _denied_ that "steps" were an important part of a procedure,
and now here you are listing three steps that must be part of every
procedure.

>> In short, the discussion with you has been a waste of time, because
>> you were never making any claim with empirical content, only playing
>> language games.

>Well, I'm sorry you feel that way, but you are wrong.

1.  You use a covert redefinition of procedure (you _still_ have not
    supplied a clear explanation of what you mean by this term)
    which conflicts with a book that has been one of _the_ most 
    unfluential books in CS since 1968

2.  You use a redefinition in which _everything_ is procedural, so
    there is simply no contrast.  If everything has the Buddha
    nature, then to say that something has the Buddha nature tells
    you _nothing_ about it.

3.  You use a redefinition which makes no empirical claim.
    If a digital computer with discrete components and discrete
    states is no more and no less "procedural" than an optical
    computer with continuous components and continuous states,
    then we are left with no way to predict which things you
    will call procedural and which things you will not.

4.  You miss an *extremely* important point about computational
    mechanisms.  The definition of "algorithm" given above, and
    the definition of "procedure" that goes with it, has an
    incredibly important and rather shocking consequence:

	Anything which cannot be expressed in terms of properties
	of polynomials with integer variables and integer
	coefficients cannot be computed.

    This is even true of quantum computers.  Surely a definition
    of "procedure" or "procedural" which is to be _relevant_ to
    computing must be bounded by "procedures" (whatever they are)
    that can be followed by _computing_ mechanisms.

    This says to _me_ that the majority of processes occurring in
    the real world are not computable, so any definition of
    "procedure" that encompasses them os NOT RELEVANT TO COMPUTING.

>You prove my point that programmers take the procedural nature
>of the computer as so obvious as to be beneath discussion, but
>it's not.  I cannot stress this enough: THIS MUST BE LEARNED BY
>STUDENTS.  This is the primary, fundamental axiom of computers.

No, I do not prove your point.  No, we do _not_ take the nature
to the computer as being obvious.  We *DO* teach students about
computability; we *DO* teach students that every known computing
mechanism has no more and no less power than a Turing machine;
we *DO* teach students about computer architecture, at say the
level in Hennessy & Patterson and perhaps a little lower.  But
we sure as heck don't tell them that _everything_ in the real world
is procedural.

>How many questions do we get in this newsgroup where a student
>simply didn't follow the flow of the program to see what happens?
>This is so obvious to you and I that we don't think about it,
>but *they didn't*!  Because they have only a vague feeling of
>flow, and are still looking at the program as a kind of
>weird combination of a solid object and something with a flow
>of time.

There is a fatal flaw in your argument.
Students don't think of looking in the index of their textbook.
Students are capable of staring at a GNAT error message:
	"foobar.adb must be recompiled"
and wondering what to do about it.
Students are capable of handing in an Ada program starting
like this:  "procedure 8puzzle is".  (That happened yesterday.)
Amongst the students I have to deal with, some of the _native_
speakers of English have only the shakiest grasp of English
grammar.  It used to be that if I saw "Chinglish" comments I
knew I was dealing with an Asian student.  Not any more.

There is a sort of "learned helplessness" around.  It's not that
they don't think of following the flow; it's that a lot of them
don't think of _anything_; they wait for someone to _tell_ them.

There is another flaw in the argument:  the most powerful way of
understanding a program that I know, and I am not a bad programmer,
is to see it as a web of relations and constraints.  When _I_ have
a problem with an Ada program, I don't start playing computer, I
look for relations that I have not made explicit, for constraints
that I can check.

>Take recursion.  How can you not understand recursion if you
>understand in your soul that computers execute a flow of
>instructions?  You can't, and that's the point.  Understanding
>the time axis is the key.

There is spatial recursion as well as temporal recursion.
I am completely comfortable with recursion in programming and have been
since I met it.  But I _understand_ recursion the same way I understand
mathematical induction, and the train of thought when I write, analyse,
or debug recursive code is at best indirectly related to the "flow" in
the program.  The core metaphors I use to grasp recursion are primarily
spatial.

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

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

[Tim Behrendsen]

Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote in article
<5182u7$17b@goanna.cs.rmit.edu.au>...
> "Tim Behrendsen" <tim@airshields.com> writes:
>
>[snip] 
> As I said, the English dictionaries are talking about bureaucratic
> procedures, which are often written down in rule books.  Even when they
> are not, to follow a (bureaucratic) procedure means to engage in a
sequence
> of behaviours regulated by rules, and those behaviours are conceptualised
> as discrete.  In computing, as I said above, I have been unable to find
> any definition of "procedure" that distinguishes it from a Fortran
> subroutine or Pascal procedure.  In fact, that is why the "procedural"
> languages are so-called, because a procedural program is organised as
> a possibly structured collections of procedures in the
Fortran/Algol/Pascal
> sense.  *This* in the meaning that leaps to mind to everyone who has
> posted in this thread except you.
> 
> I have been able to locate a definition of algorithm.  I wonder if you
> will recognise it:
> 
> 	The notion of an _algorithm_ is basic to all of
> 	computer programming, so we should begin with a
> 	careful analysis of this concept.
> 	...
> 	So this is an algorithm.  The modern meaning for algorithm
> 	is quite similar to that of _recipie_, _process_, _method_,
> 	_technique_, _procedure_, _routine_, except that the word
> 	"algorithm" connotes something just a little different.
> 	Besides merely being a finite set of rules which gives a
> 	sequence o operations for solving a specific type of
> 	problem [%], an algorithm has five important features:
> 
> 	1) Finiteness.  An algorithm must always terminate after a
> 	finite number of steps.  ... (A procedure which has all of
> 	the characteristics of an algorithm except that it possibly
> 	lacks finiteness may be called a "computational method." ...[%])
> 
> 	2) Definiteness.  Each step of an algorithm must be
> 	precisely defined; the actions to be carried out must be
> 	rigorously and unambiguously specified for each case.
> 
> 	3) Input.  An algorithm has zero or more inputs ...
> 
> 	4) Output.  An algorithm has one or more outputs ...
> 
> 	5) Effectiveness.  An algorithm is also generally
> 	expected to be _effective_.  This means that all of the
> 	operations to be performed in the algorithm must be
> 	sufficiently basic that they can in principle be done
> 	exactly and in a finite length of time by a man using
> 	pencil and paper. ..
> 
> [%] These statements make it clear that the distinguished computer
> scientist who wrote this important textbook, whose emeritus chair
> is in fact named after the book, considers "procedures" and
> "algorithms" to be pretty much the same kind of thing, except that
> "procedure" is a _slightly_ looser term.  This is actually the same
> book containing "procedure, see subroutine" in the index, but every
> other book in this office agrees with that.

This sounds reasonable to me.  I interpret (1) to mean that
it should not have an asymptotic solution; i.e., it should be
able to solved in finite time.

> >Of course, your optical computer fits this
> >definition, since it has a discrete sequence of steps (mirrors,
> >etc.), and you claim that *it* doesn't.
> 
> No, the mirrors are not steps.  It is in principle possible to build
> an optical computer as a single translucent block with varying refractive
> index. You don't need a crisp metal/air interface to get reflection; a
> continuous change in refractive index (I did say my MSc was in underwater
> acoustics) will do the job nicely.  The holographic transformation of an
> optical signal _certainly_ takes place in a continously varying medium;
> that's why I chose that example.
> 
> Let's compute a 2-dimensional optical signal propagating through a
> medium with a predetermined static spatial modulation of its refractive
> index.  
> 
>     1. Finiteness:  Not necessary for a procedure.
>     2. Definiteness:  the transformation is precisely defined by
> 	partial differential equations.
>     3. Input:  the incoming stream of photons.
>     4. Output:  the outgoing stream of photons.

>     5. Effectiveness:  fails miserably.  The relevant number here
> 	is the power of the continuum.  That was the point of selecting
> 	a model where _continuously_ varying media are involved.
      ^^^

Does it fail?  I suggest that your machine is equivalent to a
CPU with a single instruction.  The single instruction calculates
a particular mathematical formula.  I could simulate this using
pencil and paper. I quote the definition:

    "This means that all of the operations to be performed in
     the algorithm must be sufficiently basic that they can in
     principle be done exactly and in a finite length of time by  
     a man using pencil and paper."

Note that it does *not* say that I have to do the operations using
exactly the same method, only the same operations.  Your light
based algorithm is simply a mathematical operation, which I
can do using pencil and paper quite easily.

This is like saying that since most computers are based on the
flow of electrons through gates, I have to simulate the electron
flow in order to prove Quicksort is an algorithm.

> >No, the definition is very clear.
> 
> You may _say_ that the definition is very clear, but you still haven't
> told us what your definition of a procedure _is_, and why such an
> extremely general redefinition of "procedure" is _relevant_ to CS
> education.
> [giant snip of procedural debate]

OK, obviously I'm failing miserably to get my point across.  Let
me try different terms rather than the obviously loaded term
"procedural".

Try this on for size:

1. There are two ways an algorithm can be expressed:
   a. Using a methodology that expresses a path of execution (aka
      procedural languages).
   b. Using a methodology that does *not* specify a path of
      execution (aka non-procedural languages).

2. Algorithms can execute *only* using a time-based mechanism.

Now, as for education, I submit that at the beginning it is more
important to focus on what execution means rather than the
abstract expression of algorithms via languages.  Certainly
you need some form of expression, but it should be kept as
simple as possible to get the student brain into the general
concept of a flow of execution without the distraction of
methodologies.

In fact, the algorithm definition you posted above is a good
one.  Do you use that in your classes?  I would show it to
the students the first day and have them burn it into their
brains.  It very forcefully shows what algorithms are all
about.

> >How many questions do we get in this newsgroup where a student
> >simply didn't follow the flow of the program to see what happens?
> >This is so obvious to you and I that we don't think about it,
> >but *they didn't*!  Because they have only a vague feeling of
> >flow, and are still looking at the program as a kind of
> >weird combination of a solid object and something with a flow
> >of time.
> 
> There is a fatal flaw in your argument.
> Students don't think of looking in the index of their textbook.
> Students are capable of staring at a GNAT error message:
> 	"foobar.adb must be recompiled"
> and wondering what to do about it.
> Students are capable of handing in an Ada program starting
> like this:  "procedure 8puzzle is".  (That happened yesterday.)
> Amongst the students I have to deal with, some of the _native_
> speakers of English have only the shakiest grasp of English
> grammar.  It used to be that if I saw "Chinglish" comments I
> knew I was dealing with an Asian student.  Not any more.
> 
> There is a sort of "learned helplessness" around.  It's not that
> they don't think of following the flow; it's that a lot of them
> don't think of _anything_; they wait for someone to _tell_ them.

Well, certainly there are large number of students in that
frame of mind, I cannot disagree.

> There is another flaw in the argument:  the most powerful way of
> understanding a program that I know, and I am not a bad programmer,
> is to see it as a web of relations and constraints.  When _I_ have
> a problem with an Ada program, I don't start playing computer, I
> look for relations that I have not made explicit, for constraints
> that I can check.

Well, I have to admit that when I think about an algorithm,
I visualize data flowing through the algorithm undergoing
transformations until it's what I want.  I start with the
highest level "black box" transformations, and then gradually
break down each black box in greater and greater detail until
I have C code (or whatever).

This is certainly not the only way to look at problems, but it
is the closest to the reality of how algorithms execute.  And
I submit that it is the most straightforward to understand.  I
admit, though, that I have a natural bias toward this point of
view.

> >Take recursion.  How can you not understand recursion if you
> >understand in your soul that computers execute a flow of
> >instructions?  You can't, and that's the point.  Understanding
> >the time axis is the key.
> 
> There is spatial recursion as well as temporal recursion.
> I am completely comfortable with recursion in programming and have been
> since I met it.  But I _understand_ recursion the same way I understand
> mathematical induction, and the train of thought when I write, analyse,
> or debug recursive code is at best indirectly related to the "flow" in
> the program.  The core metaphors I use to grasp recursion are primarily
> spatial.

Hmm; I'm not sure if I view it the same way or not.  If I
visualize Quicksort, for example, I visualize a big block of data
that I divvy into two parts.  Each of those parts get divided,
and so on.  To map into the computer domain, I think about a
black box that does the divvying process, and then each piece
gets put back through the black box.  I suppose my core metaphor
is also spatial, but I'm not sure if it's the same way.

The point is that I (at least) don't view Quicksort as a
static "hall of mirrors", everything reflecting back and forth
with no sense of execution.  I see a "movie" of the data breaking
down section by section, and I can see the pattern between
each break and generalize it.

-- Tim Behrendsen (tim@a-sis.com)

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

[Richard A. O'Keefe]

"Tim Behrendsen" <tim@airshields.com> writes:

>Does it fail?  I suggest that your machine is equivalent to a
>CPU with a single instruction.  The single instruction calculates
>a particular mathematical formula.  I could simulate this using
>pencil and paper.

Does the word *continuous* convey nothing to you?
No, you *couldn't* simulate the machine using pencil and paper.
An optical computer works in the *real* (\br{R}) world.

>Note that it does *not* say that I have to do the operations using
>exactly the same method, only the same operations.  Your light
>based algorithm is simply a mathematical operation, which I
>can do using pencil and paper quite easily.

Here you are making a claim to be able to compute non-computable
functions.  I don't believe you.

>This is like saying that since most computers are based on the
>flow of electrons through gates, I have to simulate the electron
>flow in order to prove Quicksort is an algorithm.

Totally false.

>Try this on for size:

>1. There are two ways an algorithm can be expressed:
>   a. Using a methodology that expresses a path of execution (aka
>      procedural languages).
>   b. Using a methodology that does *not* specify a path of
>      execution (aka non-procedural languages).

This is false.  If I write a Horn clause program, one person will
look at it and say "ah hah, that is a Prolog program, it specifies
a path of execution, it is procedural", while another will look at
it and say "ah hah, that is a logical formulal, it expresses a
timeless truth which can be computed in many ways."  They are both
right.  Take for example a Definite Clause Grammar written in pure
Prolog.  ONE AND THE SAME FORM OF EXPRESSION may behave
 - as a top-down recursive descent parser (Prolog execution)
 - as a left-corner parser (I've got parsers running this way; this
   is not a theoretical point)
 - as a chart parser (XSB execution).
Take another example.  There is a programming language called Euclid.
Euclid is in the Pascal family.  It's full of records, arrays, pointers,
assignment statements, all that stuff.  But there was a paper from Xerox
showing how a Euclid program could be *naturally* and *directly* viewed
as a pure functional program.  ONE form of expression, but BOTH a
"procedural" reading AND a "declarative" reading.  Heck, it's more than
30 years since (de?) Bakker showed how to view an Algol 60 "procedural"
program as a lambda-calculus "declarative" formula.  For another example,
you accepted SQL as a non-procedural form of expression, but I countered
that I can "see" an imperative reading.

The point that I am making is that the distinction you are trying to make
is _not_ a distinction that is present in the forms of expression themselves;
the procedural and declarative views are ways that human beings _choose_ to
read texts which are themselves neutral. 

I must stress that this is not a theoretical point.  There are a couple of
companies making what seemed to me at the time "big bucks" taking COBOL
programs, *viewing* them as declarative expressions, and emitting new COBOL
code with the same _declarative_ meaning but different _procedural_ form
and behaviour.  And there are people using functional languages to design
VLSI circuits.

>2. Algorithms can execute *only* using a time-based mechanism.

You are taking "we can only _tell_ that an algorithm has executed
by contrasting a later situation with an earlier one" for a property of
algorithms rather than a property of human perception and embedding in
the world.  You may be right, but we can only notice *anything* by
contrasting earlier and later situations (I am using "situations" in
a Barwisian sense here).  That doesn't mean that it is the most fruitful
way to think about everything.  One very important computing technique,
after all, is converting time to space.  (What else is parallelism?)

You are also not confronting your assumption that the most important
thing to understand about an algorithm is its _execution_.

>Now, as for education, I submit that at the beginning it is more
>important to focus on what execution means 

I _really_ don't get you here.  The phrase is actually ambiguous.
I don't understand either of the readings.

If you mean "it is important for students to understand what it is like
when a machine executes a program", fine, we agree that it is important,
but why is it the _most_ important thing?

Case in point:  I learned matrix algebra before I learned about machines.
I know what the execution of a Gaussian elimination "means" because I
know matrix algebra, not because I know machines (though I do know both).
If I just knew machines, I wouldn't have the faintest notion what a
Gaussian elimination meant.

>Certainly
>you need some form of expression, but it should be kept as
>simple as possible to get the student brain into the general
>concept of a flow of execution without the distraction of
>methodologies.

"Methodologies" is not a word that I use; it is pretentious.

Do we teach children about the mechanics of speech before they
learn to talk?

When I was taught to play the piano as a child, I was taught about
forms of expression (how to read music), not about how to build a
piano or what happens when you press a key.

When my wife bought a knitting machine as a teenager, she was taught
how to read patterns, and how to control the machine, not how the
machine is constructed or operates.

When you are taught to drive a car, you are taught the rules of the
road and a few heuristics for operating the machine.  You are not
taught the theory of combustion; you are not shown the wiring diagram
of the car.  Heck, people these days don't even learn what gears _are_,
let alone how they work.

I got a ham license without having to learn what actually goes on inside
a valve or transistor.

What is so different about computing?

>In fact, the algorithm definition you posted above is a good
>one.  Do you use that in your classes?  

As I don't teach first year, no.  It is, of course, Knuth, The Art
of Computer Programming, Volume 1.

>Well, I have to admit that when I think about an algorithm,
>I visualize data flowing through the algorithm undergoing
>transformations until it's what I want.  I start with the
>highest level "black box" transformations, and then gradually
>break down each black box in greater and greater detail until
>I have C code (or whatever).

>This is certainly not the only way to look at problems, but it
>is the closest to the reality of how algorithms execute.  And
>I submit that it is the most straightforward to understand.  I
>admit, though, that I have a natural bias toward this point of
>view.

Just at the moment I'm playing around with trying to speed up
back-propagation neural nets.  A student here has NN programs
that regularly take 4 hours.  So far I've worked on just one
stage, but already that stage goes 5 times as fast.  (That's
the practical ceiling for that stage.)  What's the trick?  To
step *BACK* from the procedural view; with considerable effort
to figure out that the bulk of the work goes on in what _should_
have been two calls to SGEMV and one call to SGER (level-2 BLAS).
(Well, actually I'm using APL notation, not calls to the BLAS.)
Then you notice that there are a SAXPY and SDOT lying around that
could be fused with the SGER and one of the SGEMVs (making this
decision _solely_ on the timeless mathematics), and then you
see that two loops can be fused making it possible to eliminate
a vector store and reload, and before you know it, almost all of
the branches have gone.  The bit I've looked at is one of the
SGEMV steps, and the speed of that chunk has gone from 8 Mflops
to 40 Mflops on the same machine.  (To start with, one branch
per 50 instructions.)

I am already aware of one bottleneck that makes it unlikely that
the whole NN training phase will speed up that much.  (Anyone know
a really fast way to compute a reasonable approximation to a logistic
function?)

The point here is that people before me had already tried to write
good code, but their minds were straitjacketed by thinking the way
you want them to think.  I had to think at the (timeless) mathematical
level to see how to reorganise this code.

>Hmm; I'm not sure if I view it the same way or not.  If I
>visualize Quicksort, for example, I visualize a big block of data
>that I divvy into two parts.  Each of those parts get divided,
>and so on.  To map into the computer domain, I think about a
>black box that does the divvying process, and then each piece
>gets put back through the black box.  I suppose my core metaphor
>is also spatial, but I'm not sure if it's the same way.

>The point is that I (at least) don't view Quicksort as a
>static "hall of mirrors", everything reflecting back and forth
>with no sense of execution.  I see a "movie" of the data breaking
>down section by section, and I can see the pattern between
>each break and generalize it.

Done much parallel programming yet?  You are describing an approach
to understanding algorithms which makes parallel programming _very_
difficult.
-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

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

[Tim Behrendsen]

Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote in article
<51b8i4$m9m@goanna.cs.rmit.edu.au>...
> "Tim Behrendsen" <tim@airshields.com> writes:
> 
> >Does it fail?  I suggest that your machine is equivalent to a
> >CPU with a single instruction.  The single instruction calculates
> >a particular mathematical formula.  I could simulate this using
> >pencil and paper.
> 
> Does the word *continuous* convey nothing to you?

I simply don't understand the resistance to the idea that a
procedure could consist of a continuous medium.  In fact, the
computer you're typing on uses a continuous flow of electrons
to give to process algorithms.

> No, you *couldn't* simulate the machine using pencil and paper.
>> An optical computer works in the *real* (\br{R}) world.

> >Note that it does *not* say that I have to do the operations using
> >exactly the same method, only the same operations.  Your light
> >based algorithm is simply a mathematical operation, which I
> >can do using pencil and paper quite easily.
> 
> Here you are making a claim to be able to compute non-computable
> functions.  I don't believe you. 

As I understood what you wrote, your optical computer was
modulating a signal based on refraction index of a medium.  This
sounds calculable to me, assuming we know how the refraction
function of your crystal is set up.  We are getting a bit
beyond my knowledge;  I don't know if you mean that the
mathematics is unknown, or unknowable, but let me take both
cases.

Unknown: Just because a natural law is not understood, doesn't
mean there is not an algorithm behind it.

Unknowable: There are certainly cases in physics where the
underlying algorithm is not predictable; for example, the
output of a geiger counter could not be simulated using pencil
and paper (that we know of, anyway).  Now, this is a much more
interesting question.  Is there an algorithm behind atomic
decay?  There must be a *method*, even if it is not predictable
(or known).  Your author's definition obviously wasn't designed
to handle questions of this type; I think it comes down to
opinion whether this fits a definition of algorithm.

> >Try this on for size:
> 
> >1. There are two ways an algorithm can be expressed:
> >   a. Using a methodology that expresses a path of execution (aka
> >      procedural languages).
> >   b. Using a methodology that does *not* specify a path of
> >      execution (aka non-procedural languages).
> 
> This is false.  If I write a Horn clause program, one person will
> look at it and say "ah hah, that is a Prolog program, it specifies
> a path of execution, it is procedural", while another will look at
> it and say "ah hah, that is a logical formulal, it expresses a
> timeless truth which can be computed in many ways."  They are both
> right.  Take for example a Definite Clause Grammar written in pure
> Prolog.  ONE AND THE SAME FORM OF EXPRESSION may behave
>  - as a top-down recursive descent parser (Prolog execution)
>  - as a left-corner parser (I've got parsers running this way; this
>    is not a theoretical point)
>  - as a chart parser (XSB execution).
> Take another example.  There is a programming language called Euclid.
> Euclid is in the Pascal family.  It's full of records, arrays, pointers,
> assignment statements, all that stuff.  But there was a paper from Xerox
> showing how a Euclid program could be *naturally* and *directly* viewed
> as a pure functional program.  ONE form of expression, but BOTH a
> "procedural" reading AND a "declarative" reading.  Heck, it's more than
> 30 years since (de?) Bakker showed how to view an Algol 60 "procedural"
> program as a lambda-calculus "declarative" formula.  For another example,
> you accepted SQL as a non-procedural form of expression, but I countered
> that I can "see" an imperative reading.
> 
> The point that I am making is that the distinction you are trying to make
> is _not_ a distinction that is present in the forms of expression themselves;
> the procedural and declarative views are ways that human beings _choose_ to
> read texts which are themselves neutral. 
> 
> I must stress that this is not a theoretical point.  There are a couple of
> companies making what seemed to me at the time "big bucks" taking COBOL
> programs, *viewing* them as declarative expressions, and emitting new COBOL
> code with the same _declarative_ meaning but different _procedural_ form
> and behaviour.  And there are people using functional languages to design
> VLSI circuits.

I probably should have said "some proportion of ..."

Even a C program has "non-procedural" elements, if you take look
at a function call such as printf as an atomic operation where
you do not specify how to do it, only what you want to be done.
In fact, "function call" pretty much says it all, doesn't it?

I was mostly referring to the "pure" non-procedural languages
that have *zero* procedural elements to it, and it's completely
up to the compiler/interpreter to figure it out.  Past that,
you have to give up some control of the procedure at some
level.

As far as SQL goes, it is a pure mathematical statement, with
no procedural element at all (assuming we are not talking about
cursors, etc.).  It simply describes a function on one or more
matrices.  In fact, joins are usually described in terms of
cartesian products, but we all know the implementation tries
to avoid the cartesian product at all costs.  There are entire
industries devoted to getting an SQL engine to do what *you* want
it to do, not what *it* wants to do. :)

> >2. Algorithms can execute *only* using a time-based mechanism.
> 
> You are taking "we can only _tell_ that an algorithm has executed
> by contrasting a later situation with an earlier one" for a property of
> algorithms rather than a property of human perception and embedding in
> the world.  You may be right, but we can only notice *anything* by
> contrasting earlier and later situations (I am using "situations" in
> a Barwisian sense here).  That doesn't mean that it is the most fruitful
> way to think about everything.  One very important computing technique,
> after all, is converting time to space.  (What else is parallelism?)

I don't think I'm looking at in a perceptual sense; relativity tells
us that signals cannot propagate faster than the speed of light.
To execute an algorithm requires signals to move through space
and change energy states in some manner.  Since propagation is
required, time is required.

I look at parellelism as simply simultaneous signals flowing
through an algorithmic system.

> You are also not confronting your assumption that the most important
> thing to understand about an algorithm is its _execution_.
>
> >Now, as for education, I submit that at the beginning it is more
> >important to focus on what execution means 
> 
> I _really_ don't get you here.  The phrase is actually ambiguous.
> I don't understand either of the readings.
> 
> If you mean "it is important for students to understand what it is like
> when a machine executes a program", fine, we agree that it is important,
> but why is it the _most_ important thing?
> 
> Case in point:  I learned matrix algebra before I learned about machines.
> I know what the execution of a Gaussian elimination "means" because I
> know matrix algebra, not because I know machines (though I do know both).
> If I just knew machines, I wouldn't have the faintest notion what a
> Gaussian elimination meant. 

There may come a day when non-procedural languages can be used
for more than very specialized uses, but let's fact it; the
"normal" procedural languages such as C are domininant at this
point in our computer history.  As such, I think it's very
important to give the student a grounding in this type of thinking.
This doesn't preclude them from learning more exotic types of
languages, but we should give them a foundation based on where
the state of the art is.

And there's a reason for the dominance of procedural languages
such as C.  They are simply the most efficient way (in an
execution sense) to express algorithms at this point.  There
may come a time when they are less important, but we are
far off from the point, and we do disservice to students when
we try and give them exotic thinking modes as the primary
outlook.  Secondarily is OK, to give them a balanced viewpoint,
but the primary viewpoint should be procedural.

> >Certainly
> >you need some form of expression, but it should be kept as
> >simple as possible to get the student brain into the general
> >concept of a flow of execution without the distraction of
> >methodologies.
> 
> "Methodologies" is not a word that I use; it is pretentious.

I suppose it *is* right up there with "paradigm" (one of my
personal favorites).

> Do we teach children about the mechanics of speech before they
> learn to talk?

I think I am taking exactly the opposite viewpoint.  I want to
focus on the basics of execution. It sounds you like you want to
teach them about the abstraction of phonemes and language
construction before they learn to talk.

> When I was taught to play the piano as a child, I was taught about
> forms of expression (how to read music), not about how to build a
> piano or what happens when you press a key.

Yes, but first you were taught how to move your fingers in
sequence and rhythm.  You were not taught the abstraction of
composition first.  Perhaps later, but not at first.

> When my wife bought a knitting machine as a teenager, she was taught
> how to read patterns, and how to control the machine, not how the
> machine is constructed or operates.

Exactly.  She focused on the practical aspects of taking the
pattern and executing the steps.  Same principle.

> When you are taught to drive a car, you are taught the rules of the
> road and a few heuristics for operating the machine.  You are not
> taught the theory of combustion; you are not shown the wiring diagram
> of the car.  Heck, people these days don't even learn what gears _are_,
> let alone how they work.
>
> I got a ham license without having to learn what actually goes on inside
> a valve or transistor.

Yes, but drivers don't "program" the car.  These both are more the
"user" model than the "programmer" model.

> What is so different about computing?

You make my point for me.  You argue above that teaching at
a high level of abstraction is good, kind of like having your
wife learn the theory of clothing design before she starts
to sew.  I say that starting with basics of execution is a
much better foundation to build on, because you don't overwhelm
them with the entire world of possibilities.

Limiting the view of the entire picture when you're first
learning something is not a bad thing; it's necessary in order
to give a "foothold" on the concepts, and to give the student
something to compare everything else to.

Just because you teach procedural concepts doesn't preclude
the student from learning non-procedural concepts.

> >In fact, the algorithm definition you posted above is a good
> >one.  Do you use that in your classes?  
> 
> As I don't teach first year, no.  It is, of course, Knuth, The Art
> of Computer Programming, Volume 1.

Erg; pretty heavy duty.  I always wondered if anyone used them
as textbooks.  A better or more complete textbook there couldn't
be, but they are, shall we say, difficult to approach. :)

> >Well, I have to admit that when I think about an algorithm,
> >I visualize data flowing through the algorithm undergoing
> >transformations until it's what I want.  I start with the
> >highest level "black box" transformations, and then gradually
> >break down each black box in greater and greater detail until
> >I have C code (or whatever).
> 
> >This is certainly not the only way to look at problems, but it
> >is the closest to the reality of how algorithms execute.  And
> >I submit that it is the most straightforward to understand.  I
> >admit, though, that I have a natural bias toward this point of
> >view.
> 
> Just at the moment I'm playing around with trying to speed up
> back-propagation neural nets.  A student here has NN programs
> that regularly take 4 hours.  So far I've worked on just one
> stage, but already that stage goes 5 times as fast.  (That's
> the practical ceiling for that stage.)  What's the trick?  To
> step *BACK* from the procedural view; with considerable effort
> to figure out that the bulk of the work goes on in what _should_
> have been two calls to SGEMV and one call to SGER (level-2 BLAS).
> (Well, actually I'm using APL notation, not calls to the BLAS.)
> Then you notice that there are a SAXPY and SDOT lying around that
> could be fused with the SGER and one of the SGEMVs (making this
> decision _solely_ on the timeless mathematics), and then you
> see that two loops can be fused making it possible to eliminate
> a vector store and reload, and before you know it, almost all of
> the branches have gone.  The bit I've looked at is one of the
> SGEMV steps, and the speed of that chunk has gone from 8 Mflops
> to 40 Mflops on the same machine.  (To start with, one branch
> per 50 instructions.)
>
> I am already aware of one bottleneck that makes it unlikely that
> the whole NN training phase will speed up that much.  (Anyone know
> a really fast way to compute a reasonable approximation to a logistic
> function?)
> 
> The point here is that people before me had already tried to write
> good code, but their minds were straitjacketed by thinking the way
> you want them to think.  I had to think at the (timeless) mathematical
> level to see how to reorganise this code. 

Well, I'm not familiar with the concepts in that juicy of
detail, but come on; this is sort of a specialized application.
There are certainly times that a mathematical view can provide
insight into a particular problem.

But even your neural net is composed of stages, and in fact,
the vast majority of problems break down the way I outlined.

> >Hmm; I'm not sure if I view it the same way or not.  If I
> >visualize Quicksort, for example, I visualize a big block of data
> >that I divvy into two parts.  Each of those parts get divided,
> >and so on.  To map into the computer domain, I think about a
> >black box that does the divvying process, and then each piece
> >gets put back through the black box.  I suppose my core metaphor
> >is also spatial, but I'm not sure if it's the same way.
> 
> >The point is that I (at least) don't view Quicksort as a
> >static "hall of mirrors", everything reflecting back and forth
> >with no sense of execution.  I see a "movie" of the data breaking
> >down section by section, and I can see the pattern between
> >each break and generalize it.
> 
> Done much parallel programming yet?  You are describing an approach
> to understanding algorithms which makes parallel programming _very_
> difficult.

Not at all.  I can visual parallel processing very easily.  I
simply have multiple transformations of data happening
simultaneously.  In fact, I usually visualize Quicksort
happening in parellel (although the implementation is linear,
of course. :) ).

Let's take the brain.  I submit my visualization of the brain
as a huge collection of "black box" neurons with signals
flowing between them is more accurate (and practical) than
a view of the brain in terms of mathematical formulas.  The
latter seems to me a complete failure if someone ever wants
to really understand what's going on.

-- Tim Behrendsen (tim@a-sis.com)

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

[Richard A. O'Keefe]

"Tim Behrendsen" <tim@a-sis.com> writes:
>> Here you are making a claim to be able to compute non-computable
>> functions.  I don't believe you. 

>As I understood what you wrote, your optical computer was
>modulating a signal based on refraction index of a medium.  This
>sounds calculable to me, assuming we know how the refraction
>function of your crystal is set up.  We are getting a bit
>beyond my knowledge;  I don't know if you mean that the
>mathematics is unknown, or unknowable, but let me take both
>cases.

Neither.  "Computable" has a standard precise technical sense, which you
appear to be unaware of.

>Unknown: Just because a natural law is not understood, doesn't
>mean there is not an algorithm behind it.

For Ghu's sake, there are functions from the naturals to the naturals
which are not computable, let alone functions from nondenumerable spaces!

>Unknowable: There are certainly cases in physics where the
>underlying algorithm is not predictable; for example, the
>output of a geiger counter could not be simulated using pencil
>and paper (that we know of, anyway).  Now, this is a much more
>interesting question.  Is there an algorithm behind atomic
>decay?  There must be a *method*, even if it is not predictable
>(or known).  Your author's definition obviously wasn't designed
>to handle questions of this type; I think it comes down to
>opinion whether this fits a definition of algorithm.

You are confusing predictability with determinism.
Popper showed several decades ago that a Newtonian universe is not
*predictable* by any computing mechanism even though it is *deterministic*.
(To the best of my knowledge, Popper published this well before "chaos"
became a fashionable concept.)

The Universe *does* things which cannot be accurately modelled by
anything that has ever been proposed as a realistic physical model
of computation.  Weather is the most obvious case.

When you talk about about there being an "algorithm" or "method"
behind atomic decay, you enter the realms of science fiction.
(Wasn't it A.E.van Vogt who had 'electron psychology' in one of his
stories?)  Either I have completely misunderstood (which is likely,
because quantum mechanics was by far my worst subject) or the current
belief is that there are *no* hidden variables and there is *no*
"algorithm" or "method", quantum events just happen as often as their
amplitudes say they should.  (Mermin savaged Popper for failing to
distinguish between probabilities and amplitudes.  Rather a relief
to me, as I had never quite understood Popper's "propensities".)

If you are _right_ that everything in the real world including atomic
decay is procedural, then everything in modern physics is as wrong as
it can possibly be, not just incomplete but wrong-headed through and
through.

>Even a C program has "non-procedural" elements, if you take look
>at a function call such as printf as an atomic operation where
>you do not specify how to do it, only what you want to be done.
>In fact, "function call" pretty much says it all, doesn't it?

>I was mostly referring to the "pure" non-procedural languages
>that have *zero* procedural elements to it, and it's completely
>up to the compiler/interpreter to figure it out.

How often do I have to say it before you get the point?

    A.	THERE IS NO SUCH THING AS A FORM OF EXPRESSION FOR
	COMPUTABLE FUNCTIONS WHICH DOES NOT ADMIT A
	PROCEDURAL READING.

    B.	THERE IS SUCH THING AS A FORM OF EXPRESSION FOR
	COMPUTABLE FUNCTIONS WHICH DOES NOT ADMIT A
	NON-PROCEDURAL READING.

"Function" here is to be interpreted in a wide sense including mappings
from concurrent input streams to concurrent output streams ("functions
over histories").  The class of languages you are trying to talk about
simply does not exist.

>As far as SQL goes, it is a pure mathematical statement, with
>no procedural element at all (assuming we are not talking about
>cursors, etc.).

No, no, and no.  You are insisting that your reading of SQL is the
only possible correct one.  But it isn't.  I am allowed to read the
specification of a computable function any way I want as long as I
get the same answers.

The classical example of this is of course the lambda calculus.
There is a large body of work on alternative readings of the lambda
calculus.

>It simply describes a function on one or more
>matrices.

In exactly the same way, I can say of *any* program that it "simply
describes a function on" certain denotations.

>In fact, joins are usually described in terms of
>cartesian products, but we all know the implementation tries
>to avoid the cartesian product at all costs.

The readings a particular computer program applies to a formalism
place no upper bound on the set of readings the formalism admits,
not even on the set of *useful* readings.

>There may come a day when non-procedural languages can be used
>for more than very specialized uses, but let's fact it; the
>"normal" procedural languages such as C are domininant at this
>point in our computer history.  As such, I think it's very
>important to give the student a grounding in this type of thinking.
>This doesn't preclude them from learning more exotic types of
>languages, but we should give them a foundation based on where
>the state of the art is.


There are so many differences between us packed into this one little
paragraph that I think it is time for me to pull out of this thread
after listing a few of them.  Recall that the context is teaching;
nobody disputs that computing professionals should _eventually_ know
a whole lot of things.

1.  "The imperative paradigm is dominant."

    I wonder whether it is _true_ that the imperative paradigm is
    dominant.  Does anybody know what proportion of work is done
    using spreadsheets and data base languages compared with the
    proportion of work done using imperative languages?  I am
    supervising a Masters student doing a project on data quality;
    this student has a lot of experience with software engineering
    and commands high consulting pay from *big* companies, but hasn't
    written an imperative program in *years*.

2.  "Whatever is, is right."
    I'm Dr O'Keefe, not Dr Pangloss.  I don't believe this.

3.  "The initial approach to _teaching_ a subject should be confined
    to what is currently fashionable in some blinkered view of 'the
    real world'."

    This sounds to me like a good recipe for ensuring
    that your students will be obsolete when they graduate.

4.  "The initial approach to _teaching_ a subject should be based on
    what yesterday's practitioners identified as the foundations of
    the subject."

    This proved a disaster when applied to the teaching
    of mathematics in schools.  Should we expect computing to be
    different?  (I am not saying that foundations can or should be
    ignored, just that one starts a five-year-old with "one, two,
    three", not with metamathematics or category theory.)

5.  "Non-procedural languages cannot be used for anything but
    specialised uses."

    Talk about blinkered.  Take a look at what you can do with Clean.
    It's perhaps the easiest language I've found for writing GUIs, and
    its performance is darned good.  Take a look at FoxNet 2.0 (TCP/IP
    in ML).  Take a look at Sisal.  Take a look at Erlang.  Let's see,
    that's GUI, TCP/IP, scientific computing, telecoms, distributed,
    all covered.

    I have to concede that if I were doing any 8051 programming I would
    use C or assembler.  Hmm.  Maybe.  It might be better engineering
    to design a declarative language tailored to the application and to
    write a compiler for it.  In an application like that you really
    *really* cannot afford the kinds of errors that imperative programming
    allows.

6.  "Declarative forms of expression are exotic."

    Alas, there is some truth in this.  When I and my peers entered
    University and started to learn about computing, we already had a
    good grounding in differential and integral calculus, elementary
    probability and statistics, vector and matrix algebra, and had
    met differential equations.  We had studied Euclidean geometry
    (the textbook was basically Euclid's Elements) and the notion of
    proof, including proof by cases and proof by induction.  To us,
    _discrete_ mathematics was exotic; the idea of step-by-step
    calculations in the computer was exotic.

    Alas, we in this department are not allowed to turn down prospective
    students simply because they didn't do mathematics at high school.
    (Or so I was told when I helped in the selection process.)
    And the ones who _did_ do it don't seem to recognise much of it when
    they see it again.  One of the scariest things I've heard in the
    last decade was a student complaining to me because a lecture had
    been too 'mathematical':  "I took CS because I'm no good at maths"
    and a large group of his friends agreeing with him.

    So it is unfortunately true that declarative forms of expression
    are exotic to a majority of our students.

    It is also unfortunately true that the high schools offer computing
    subjects, and that students sometimes take these instead of mathematics.
    Now, I know a high school teacher.  She is qualified as a librarian.
    A couple of months ago she was complaining about having to learn
    Italian because the school was going to have to teach it, and she'd
    been selected as one of the teachers.  Friends of the Italian language,
    are you quaking in your boots?  Are you weeping?  If they do that for
    Italian, in a state with a lot of fluent speakers of Italian, what do
    think they do for computing?

    So it is unfortunately true that procedural forms of expression
    are _familiar_ to a lot of our students.  "Unfortunately" because
    they think they understand it, which makes it harder for us to teach
    them.  Which brings me to the next point:

7.  "It is always best to teach using familiar concepts."

    One of the reasons why a number of Universities are using Miranda,
    or Haskell, or Orwell, or something of the sort, and certainly one
    of the reasons why we carefully selected a procedural language that
    was not currently being taught in the local schools (Ada) was that
    we'd like to get the students' attention.  And we simply don't get
    it as long as we are trying to teach them something they _think_
    they already know.  We did seriously consider something less like
    Pascal, but we got phone calls from high school careers people saying
    "if you go 'academic' we'll tell our students to stay away from you".
    No good doing the best thing if you go out of business, so we're
    doing a _good_ thing (Ada) and staying in business.

    The fact remains that one good educational reason for selecting a
    declarative language like Haskell is "listen up, we've got things
    to tell you that you don't already know".

8.  "How last decade's computers used to execute programs is the most
    important thing to understand, so it should be taught first."

    Well, there are a _lot_ of things we have to teach.  How to use the
    index in a textbook.  How to look things up in a library.  How to
    use a spelling checker, a word processor, electronic mail.  How to
    write comments (we need to put more effort into that).  How to write
    documentation for a computer program (they're doing better than they
    used to before we started teaching this explicitly, but not well
    enough yet) or project.  (We really need to fit in a remedial English
    course.  The Center for English Learning already offers such courses
    for overseas students, and the department pays for students who need
    them badly to attend them, but very very few of those who need them
    actually go.  In another year or two we'll have to make it compulsory
    for all students.)  How to name things.  Elementary discrete
    mathematics.  Elementary probability and statistics.  The idea of
    testing.  I could go on and on and on.

    The machine our students use is four-way superscalar, with 6
    functional units, longish pipes, and loads may be up to 30 cycles
    "in flight" before a datum arrives.  I don't know if it does out-
    of-order execution or not; if it doesn't, then a paper I was reading
    yesterday from NYU would call it an "early" RISC!  This is why I call
    the 'classical' procedural reading of an imperative program "how
    last decade's computers used to execute programs."  The vendor's C
    compiler automatically does function inlining, loop unrolling, and
    apparently will do modulo scheduling (though the option for that is
    not documented).  The order specified in a C program isn't even
    close to the order in which things actually happen in the hardware.

    So why is an abstraction which is NOT genuinely the way the students'
    computer works the FIRST thing they should learn?  Why is it more
    important than, oh, first order predicate calculus?  Or elementary
    probability?  Or how to write a specification?  Or, come to that, how
    to _read_ a specification?  (Such as an assignment.  Some of our
    students, even articulate ones, have real trouble with that.  If they
    do what my high-school teachers called "comprehension" exercises, it
    doesn't seem to help enough.)

    I put it to the few remaining readers of this thread that it is MUCH
    more urgent to learn how to communicate with other human beings
    about what is to be computed than it is to learn how last decade's
    machines used to work.


>And there's a reason for the dominance of procedural languages
>such as C.  They are simply the most efficient way (in an
>execution sense) to express algorithms at this point.

This hasn't been true for some time.  Sisal is perhaps the oldest
counter-example.

The reason for the continued dominance of imperative languages is
economics, nothing else.  It doesn't matter if declarative languages
have now reached the point where their compilers can routinely run
rings around C compilers (but not Fortran compilers); if the bulk
of programmers are trained in old-fashioned techniques and the bulk
of development tools support old-fashioned techniques, then the
conversion cost may be prohibitive.

I gave an example in my last posting where abandoning C, going back to
a declarative notation, and then writing a specialised code generator
gave me a speed-up of about 5 or 6 over the best that C could do.
It turns out that using the next generation of the hardware gives a
factor of 7 speedup.  (The specialised code speeds up too, but it doesn't
speed up as much.  Improving the scheduler should restore the relative
positions of the "derived-from-declarative" and C code.  I hope to have
that--still fairly crude--scheduler finished today.)

The point here is that even a factor of 5 or 6 speedup for abandoning
the procedural paradigm isn't a big enough reward for people and
organisations already mired in the old procedural mindset.  Wait a
couple of years, buy new hardware, and you get about the same speed,
*without* retraining or retooling.  "Incumbent advantage" can survive
major challenges.

If the most efficient execution were the main, or even a very important,
reason for programming language choice, who would use Java?  or Visual
Basic?  Or C?  We would all be using High Performance Fortran.

The things I like in Ada (generics, packages, static type checking without
too tight a straitjacket, &c) have very little to do with its procedural
side.  We didn't pick it as our first year language because it was faster
than C!  Although for a number of benchmarks that I've tried, it _is_.  So
if execution speed were the most important thing, we'd see everyone jumping
from C to Ada 95.  We don't see that.  Incumbent advantage.

>There
>may come a time when they are less important, but we are
>far off from the point, and we do disservice to students when
>we try and give them exotic thinking modes as the primary
>outlook.  Secondarily is OK, to give them a balanced viewpoint,
>but the primary viewpoint should be procedural.

Now I begin to understand how Sun were able to release Java on the
world with a clear conscience.  A specification of what exactly the
security model is (not available), a specification of exactly what it
is that the byte code verifier has to do (not available), and a proof
that the latter ensures the former (not available) would have involved
"exotic thinking modes".  Better to ship a "secure" language implementation
with security holes and rely on net users to finish the debugging than to
"do disservice" to anyone by taking "exotic thinking modes" as primary.
All that counts is how it works, not what it is supposed to do, right?


			WELL I AM SICK OF IT!

You can rail at it as much as you like; you can call it exotic; you can
say it's a disservice; you can say that the real world is algorithmic
right down to the nuclei.  But the fact remains that the viewpoint you
advocate as primary is the one which has flooded us with buggy software.
(Java isn't even _close_ to being the worst offender.  I was unfair to
Sun.  Windows 95 is probably doing far more real damage.)

When our students have trouble writing a working program, it is not because
they don't understand how the computer works.  It's because they never sat
down and said clearly, even to themselves, what the program was *supposed*
to do.  We preach at them and preach at them "Write the comments FIRST",
and they keep on handing in uncommented stuff saying "I didn't have the
time to write the comments."  The students *HAVE* your primary view as
their primary view, and that's why they are bad programmers.  They *HAVE*
your primary view as their primary view, and that's why they are so
hopeless at debugging.  They will spend hours stepping through a program
rather than 10 minutes thinking about it.

Mind you, I'm talking about 1st and 2nd year students.  We put a *lot* of
effort into trying to teach software engineering, not just programming,
and by the time the students graduate they have improved somewhat.

>> Do we teach children about the mechanics of speech before they
>> learn to talk?

>I think I am taking exactly the opposite viewpoint.  I want to
>focus on the basics of execution. It sounds you like you want to
>teach them about the abstraction of phonemes and language
>construction before they learn to talk.

This is like Hitler calling the Chief Rabbi a fascist.  Sigh.

SEQUENTIAL EXECUTION IS AN ABSTRACTION.

This rather remote abstraction (which is not true to the
way modern distributed systems with multi-processor superscalar out-of-order
executing pipelined machines actually work) is not basic.

"WHAT DO YOU *WANT* TO COMPUTE?"

is basic.  I don't know any theory of child language learning that
doesn't start from the child having something it wants to say.

>> When I was taught to play the piano as a child, I was taught about
>> forms of expression (how to read music), not about how to build a
>> piano or what happens when you press a key.

>Yes, but first you were taught how to move your fingers in
>sequence and rhythm.

Not so.  Nobody ever taught me how to move my fingers.

>You were not taught the abstraction of composition first.

Perhaps not, but this is a point to me, not a point to you.
Because composition is precisely the analogue of the sequential
execution abstraction.

>> When my wife bought a knitting machine as a teenager, she was taught
>> how to read patterns, and how to control the machine, not how the
>> machine is constructed or operates.

>Exactly.  She focused on the practical aspects of taking the
>pattern and executing the steps.  Same principle.

No, it's the *opposite* of your principle.  When you use a knitting
machine, you have little or no concern with the steps that the MACHINE
follows.  You lay the pattern out SPATIALLY.  The machine does it
temporarlly, but the human being sets it out SPATIALLY.

There are admittedly data-flow constraints on the order of setups,
but they too are understood in structural/geometric rather than
algorithmic terms.

>> I got a ham license without having to learn what actually goes on inside
>> a valve or transistor.

>Yes, but drivers don't "program" the car.  These both are more the
>"user" model than the "programmer" model.

I built my own ham equipment.  The radio amateur license exam tests your
knowledge of circuit and antenna theory.  Building your own equipment is
a hell of a lot closer to the "programmer" model than the "user" model.
My point is that, just as I didn't have to understand the device physics
underlying valves and transistors, only the mathematical "transducer"
model, in order to read, understand, and build an electronic circuit,
neither do programmers need to understand the low level mechanics of
computers in order to build programs.

>> What is so different about computing?

>You make my point for me.  You argue above that teaching at
>a high level of abstraction is good, 

This is exactly the opposite of what I said and meant.

The point that I am making is that you start from

	WHAT DO YOU WANT TO DO?

in all these areas, not

	HOW DOES THE MACHINE DO IT?

You have consistently argued that the fundamental which must be mastered
first is the sequential execution abstraction, which is concerned with
the secondary question "how does the machine do it".

Children learn to talk by having something they want to say.
They are explicitly taught the sequential execution abstraction
(grammar) much later.

People learn to drive by having somewhere they want to go
and wanting to learn how to make the car go there.
They are explicitly taught the execution abstract "the steering wheel
is connected to the rack and pinion which is connected to the steering
rods which are connected to the front wheels" (or whatever it is, I
don't really know, don't really care, and don't have any particular
reason why I _should_ know or care) afterwards, if at all.

People learn to play a musical instrument by having a tune that
they want to produce.
They learn how a piano actually _works_ much later, if at all.
(How many drummers need to understand the physics of vibrating
membranes?  Apart from Richard Feynman, that is.)

*How things work* is secondary to *what they are for*.

>Just because you teach procedural concepts doesn't preclude
>the student from learning non-procedural concepts.

Given that we and the students have only limited time,  the more time
we spend on abstractions like sequential execution the less time we
have to spend on fundamentals like requirements and specifications.

Just because we teach Ada doesn't mean the students are precluded from
learning Sisal or Haskell or RAISE or ...   The fact remains that they
*don't* learn these things.  (We do teach some Z.  But they learn it
*only* as a specification language.  Alas.)  Heck, just because we
teach computing doesn't preclude them learning quantum chromodynamics
either.  But that doesn't happen.

>> As I don't teach first year, no.  It is, of course, Knuth, The Art
>> of Computer Programming, Volume 1.

>Erg; pretty heavy duty.  I always wondered if anyone used them
>as textbooks.

Pretty heavy duty?  Well, the mathematics is a lot of fun.  It's closely
related to recreational mathematics after all.  I take it you are
referring to all that MIX assembly code as the "heavy duty" stuff.

>But even your neural net is composed of stages, and in fact,
>the vast majority of problems break down the way I outlined.

The neural net is composed of *layers*, not *stages*.
The defining concept is *data* flow, not *control* flow.
One way to wring another nice big constant factor out of the
computation, which I am not going to bother with, is to throw yet
another sequential imposition down the toilet, and run several training
instances through the net in parallel.  This can be done in two ways,
both of which should be followed up:  folded into the code so that we're
doing level-3 BLAS rather than level-2 BLAS, which would make better use
of the cache, and true real-world parallelism with multiple CPUs crunching
at the same time.

The really important thing here is not the particular problem or the
details, but that the kind of thinking I need for this problem is the
kind of thinking you need to write parallel code.  Allowing myself to
be hypnotised by one-step-at-a-time thinking, or how C does things,
would have been *fatal*.
	
>> Done much parallel programming yet?  You are describing an approach
>> to understanding algorithms which makes parallel programming _very_
>> difficult.

>Not at all.  I can visual parallel processing very easily.

I didn't ask whether you can _visualise_ parallel processing,
but whether you have *done* much parallel programming.
Since the only "parallel" operation you mention is quicksort,
I suspect that the answer is "no".

>Let's take the brain.  I submit my visualization of the brain
>as a huge collection of "black box" neurons with signals
>flowing between them is more accurate (and practical) than
>a view of the brain in terms of mathematical formulas.

A fuzzy mental "visualisation" with no specification as to _how_
the signals are transformed is more accurate (and practical)?
Surely you are living on the other side of the looking glass.

>The latter seems to me a complete failure if someone ever wants
>to really understand what's going on.

For your information, people *do* model neurons by mathematical formulas.
In fact, it wasn't until the formulas fitted actual neural behaviour
reasonably well that people believed they understood what was going on
inside neurons.

And of course "neural nets" *are* mathematical formulas.


Enough.  It has taken me about an hour and a half to write this,
and while it has been good to let off steam (I am still outraged by
the idea that teaching people to say what their programs are supposed
to do, which is a declarative notion, is an "exotic mode of thinking"
and a "disservice") it probably won't accomplish much else.

The thread is going in my kill-file.
-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

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

[George]

"Tim Behrendsen" <tim@airshields.com> wrote:

> You prove my point that programmers take the procedural nature
> of the computer as so obvious as to be beneath discussion, but
> it's not.  I cannot stress this enough: THIS MUST BE LEARNED BY
> STUDENTS.  This is the primary, fundamental axiom of computers.

> How many questions do we get in this newsgroup where a student
> simply didn't follow the flow of the program to see what happens?
> This is so obvious to you and I that we don't think about it,
> but *they didn't*!  Because they have only a vague feeling of
> flow, and are still looking at the program as a kind of
> weird combination of a solid object and something with a flow
> of time.


Just to get away from the pointless symantic argument; are your really
suggesting that students don't understand something this basic.
If this is the effect of teaching OOA/OOP and similar mumbo jumbo,
then maybe it's time we got back to BASICs; no way they could they
fail to understand. 

What do they actually think happens inside a computer *magic*????


> Take recursion.  How can you not understand recursion if you
> understand in your soul that computers execute a flow of
> instructions?  You can't, and that's the point.  Understanding
> the time axis is the key.

They should never have been allowed to get this far without realizing
that.

> -- Tim Behrendsen (tim@a-sis.com)

G.

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

[Tim Behrendsen]

George <grs@liyorkrd.li.co.uk> wrote in article
<51knkn$j61@dub-news-svc-8.compuserve.com>...
> "Tim Behrendsen" <tim@airshields.com> wrote:
> 
> > You prove my point that programmers take the procedural nature
> > of the computer as so obvious as to be beneath discussion, but
> > it's not.  I cannot stress this enough: THIS MUST BE LEARNED BY
> > STUDENTS.  This is the primary, fundamental axiom of computers.
> 
> > How many questions do we get in this newsgroup where a student
> > simply didn't follow the flow of the program to see what happens?
> > This is so obvious to you and I that we don't think about it,
> > but *they didn't*!  Because they have only a vague feeling of
> > flow, and are still looking at the program as a kind of
> > weird combination of a solid object and something with a flow
> > of time.
> 
> 
> Just to get away from the pointless symantic argument; are your really
> suggesting that students don't understand something this basic.
> If this is the effect of teaching OOA/OOP and similar mumbo jumbo,
> then maybe it's time we got back to BASICs; no way they could they
> fail to understand. 
> 
> What do they actually think happens inside a computer *magic*????

They don't think *anything*.  Think about the fresh-faced newbie on
his/her first day in CS 101.  Their only experience with computers,
if they have any at all, is interacting with them at the user
level.  They press a button, something happens.  There's obviously
a mechanism behind it, but they don't have any concept of how it
works.

Way back in the thread where this all started, one of the first
points was my complaint about the huge number of graduates that
come to me and are completely unable to take a problem that they
have never seen before and generate a solution.  I chalked this
up to students being unable to "think like a programmer", and
are only memorizing lists of algorithms that they can cough up
on a test, but not really understanding them.

> > Take recursion.  How can you not understand recursion if you
> > understand in your soul that computers execute a flow of
> > instructions?  You can't, and that's the point.  Understanding
> > the time axis is the key.
> 
> They should never have been allowed to get this far without realizing
> that.

Well, I agree.  Unfortunately, computer science today is not
focused on thinking, it's focused on packing as many abstractions
as possible into a student's head to protect them from the
evils of "what's really going on."

-- Tim Behrendsen (tim@a-sis.com)

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

[Matthew M. Lih]

Hope you don't mind if I interject an experience.

Tim Behrendsen wrote:

> > What do they actually think happens inside a computer *magic*????

In some cases, yes!

> They don't think *anything*.  Think about the fresh-faced newbie on
> his/her first day in CS 101.  Their only experience with computers,
> if they have any at all, is interacting with them at the user
> level.  They press a button, something happens.  There's obviously
> a mechanism behind it, but they don't have any concept of how it
> works.

Even some veterans don't have any idea. I'm taking
a C++ class, and the instructor didn't have any idea
that the "++" operator was developed because it
corresponded to a very quick machine language
instruction in the old PDP machines. When I pointed
this out, his comment was along the lines of "Oh,
you hardware types."

I mention this not to rag on my instructor (who
*is* knowledgable and good), but to point out that
we have successfully insulated the users from the
machine, which was intended. Unfortunately, a lot
of times we *do* need to know what's happening behind
the scenes. I was rather disillusioned when I figured
out that in order to be a successful database programmer
I really had to know how the DBMS worked in order to
develop useful software.


Matthew M. Lih
Software Lead
TRW Enterprise Solutions

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

[Richard A. O'Keefe]

"Matthew M. Lih" <matt.lih@trw.com> writes:

>Even some veterans don't have any idea. I'm taking
>a C++ class, and the instructor didn't have any idea
>that the "++" operator was developed because it
>corresponded to a very quick machine language
>instruction in the old PDP machines.

This isn't true.
C inherited ++ from B, which was an *interpreted* language.
The updated operators += -= and so on were copied from Algol 68
(where they were spelled +:= -:= and so on), and the designers
of Algol 68 paid very little attention to hardware issues.
On at least some models of PDP-11, the INC instruction was *not*
quicker than ADD, just shorter.

>When I pointed
>this out, his comment was along the lines of "Oh,
>you hardware types."

He *should* have said "oh, you superstitious types!
Dennis Ritchie has been trying to kill this lie for _years_."

>I mention this not to rag on my instructor (who
>*is* knowledgable and good), but to point out that
>we have successfully insulated the users from the
>machine, which was intended.

Your instructor even has the right gaps in his knowledge:
he didn't know something that wasn't true.

C has *not* insulated the programmers from the machine.
One look at the type system will tell you *that*.
If you want to insulate the programmers from the machine,
try Lisp, or Ada.

>I was rather disillusioned when I figured
>out that in order to be a successful database programmer
>I really had to know how the DBMS worked in order to
>develop useful software.

Can anyone please supply the source and correct form of this
quotation:
	"When anyone tells me 'I want to have a programming language
	in which I have merely to say what I want done' I give him a
	lollipop."

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

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

[Mark Wooding]

Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote:

> Can anyone please supply the source and correct form of this
> quotation:

`When someone says, ``I want a programming language in which I need only
say what I wish done,'' give him a lollipop.'
		-- Alan Perlis, Epigrams on Programming (1982)

(Good ol' Don Knuth -- always gives his sources.  That one is on
page 365 of the TeXbook.)

[Well off topic now -- followups to poster.]
-- 
[mdw]

`When our backs are against the wall, we shall turn and fight.'
		-- John Major

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

[Bjarne Stroustrup]

"Matthew M. Lih" <matt.lih@trw.com> writes:

 > Hope you don't mind if I interject an experience.
 > 
 > Tim Behrendsen wrote:
 > 
 > > > What do they actually think happens inside a computer *magic*????
 > 
 > In some cases, yes!
 > 
 > > They don't think *anything*.  Think about the fresh-faced newbie on
 > > his/her first day in CS 101.  Their only experience with computers,
 > > if they have any at all, is interacting with them at the user
 > > level.  They press a button, something happens.  There's obviously
 > > a mechanism behind it, but they don't have any concept of how it
 > > works.
 > 
 > Even some veterans don't have any idea. I'm taking
 > a C++ class, and the instructor didn't have any idea
 > that the "++" operator was developed because it
 > corresponded to a very quick machine language
 > instruction in the old PDP machines. When I pointed
 > this out, his comment was along the lines of "Oh,
 > you hardware types."

Actually, the story that ++ comes from the PDP11 instruction
set is a myth. Dennis Ritchie has denied it quite often, but
that doesn't seem to impress people. ++ is in C and C++ because
Dennis (being a mathematician) considered it a fundamental
(and useful) operation. It was in the PDP11 instruction set
because the designers at DEC independently had figured out
that it was an important operation to optimize.

	- Bjarne

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

[Bengt Richter]

bs@research.att.com (Bjarne Stroustrup) wrote:


>"Matthew M. Lih" <matt.lih@trw.com> writes:

> > Hope you don't mind if I interject an experience.
> > 
> > Tim Behrendsen wrote:
> > 
> > > > What do they actually think happens inside a computer *magic*????
> > 
> > In some cases, yes!
> > 
> > > They don't think *anything*.  Think about the fresh-faced newbie on
> > > his/her first day in CS 101.  Their only experience with computers,
> > > if they have any at all, is interacting with them at the user
> > > level.  They press a button, something happens.  There's obviously
> > > a mechanism behind it, but they don't have any concept of how it
> > > works.
> > 
> > Even some veterans don't have any idea. I'm taking
> > a C++ class, and the instructor didn't have any idea
> > that the "++" operator was developed because it
> > corresponded to a very quick machine language
> > instruction in the old PDP machines. When I pointed
> > this out, his comment was along the lines of "Oh,
> > you hardware types."

>Actually, the story that ++ comes from the PDP11 instruction
>set is a myth. Dennis Ritchie has denied it quite often, but
>that doesn't seem to impress people. ++ is in C and C++ because
>Dennis (being a mathematician) considered it a fundamental
>(and useful) operation. It was in the PDP11 instruction set
>because the designers at DEC independently had figured out
>that it was an important operation to optimize.

>	- Bjarne

You are certainly the one to correct me if I'm wrong, but
to me the most important aspect of ++ (and --) is not
that i++ increments and --k decrements, but that
i++ evaluates to i and has the side effect i+=1,
whereas --k evaluates to k-1 and has the side effect k-=1,
allowing C statements such as a[i++] = b[--k]; to have
special useful meaning.

The really strikingly similar thing about the PDP-11
architecture was not instructions per se, but
particular addressing modes for memory-referencing
instructions, namely post-incremented register indexing
and pre-decremented register indexing, providing
a practically direct correspondence to a[i++] or
b[--k].

If memory serves, PDP-11 machine language syntax
used a single '+' suffix to indicate a post-incremented
register index addressing mode, applicable to many
memory-referencing instructions. A single prefixed '-'
signified the corresponding pre-decrement indexing mode.
E.g.,something like  mov r0,(r1)+ or mov r0,-(r1).

Instructions implementing a C statement such as i++; or
--k; don't reflect the pre/post semantics that are
important in  a[i++] = b[--k]; and the corresponding
addressing modes of the PDP-11.

My 2 cents ;-)
Regards,
Bengt Richter
(We had the 2nd PDP-11/45 on the West Coast, I believe :-)
(With 4k added bipolar 300ns memory to keep your feet warm in winter).

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

[Dan Pop]

In <Dy9KEL.6nD@research.att.com> bs@research.att.com (Bjarne Stroustrup) writes:

>"Matthew M. Lih" <matt.lih@trw.com> writes:
> > 
> > Even some veterans don't have any idea. I'm taking
> > a C++ class, and the instructor didn't have any idea
> > that the "++" operator was developed because it
> > corresponded to a very quick machine language
> > instruction in the old PDP machines. When I pointed
> > this out, his comment was along the lines of "Oh,
> > you hardware types."
>
>Actually, the story that ++ comes from the PDP11 instruction
>set is a myth. Dennis Ritchie has denied it quite often, but
>that doesn't seem to impress people. ++ is in C and C++ because
>Dennis (being a mathematician) considered it a fundamental
>(and useful) operation. It was in the PDP11 instruction set
>because the designers at DEC independently had figured out
>that it was an important operation to optimize.
>
>	- Bjarne

Actually, according to Dennis, ++ is in C because it was inherited from
B :-) and the credit for it has to be given to Ken Thompson.  Quoting
from Ritchie himself:

# C was developed on the PDP-11; most of it aside from the type
# structure and associated syntax came from B, which was developed on
# the PDP-7.  B already had the ++ and -- operators (and the associated
# idioms like *p++).  The first B compiler produced interpreted
# (threaded) code.  Doubtless the invention of ++ and -- (due to
# Thompson) was suggested by the auto-increment cells of the PDP-7, or
# perhaps the one such cell on the PDP-8, or perhaps some of the more
# recondite indirection modes on the GE 635/645, or the
# count-increment-refill mechanism of the Stretch.  In any event, neither
# B nor the first C compiler generated -7 or -11 instructions that used
# autoincrement.
# 
# C was less influenced by the PDP-11 than most people think.  Certainly
# the addition of types was motivated by the desire to take advantage
# of byte addressing and the (future) existence of floating point
# (indeed, C compiled 11/45 floating point instructions before
# the delivery of any 11/45s; it was an annoyance when DEC changed
# its mind about what opcodes to use.)
# 
# Discounting general things like that, the only strong PDP-11isms I can
# think of in C are the signed characters and about 50% of the
# justification for the widening rules for floats.  (The other 50% is
# simplification of the language rules and libraries).
# 
#       Dennis Ritchie
#       research!dmr
#       dmr@research.att.com


--
Dan Pop
CERN, CN Division
Email: Dan.Pop@cern.ch 
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland

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

[Jon S Anthony]

In article <Dy9KEL.6nD@research.att.com> bs@research.att.com (Bjarne Stroustrup) writes:

> Actually, the story that ++ comes from the PDP11 instruction
> set is a myth. Dennis Ritchie has denied it quite often, but
> that doesn't seem to impress people. ++ is in C and C++ because
> Dennis (being a mathematician) considered it a fundamental
          ^^^^^^^^^^^^^^^^^^^^^
> (and useful) operation. It was in the PDP11 instruction set

I don't see how that has anything to do with it.  I'm a mathematician
and I don't see it as a particularly interesting or useful operation
to be singled out for special status (I'm not talking about the machine
level here...)

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

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

[Dann Corbit]

It's the successor to the object.
Dennis probaly loved to play the peano.
(I'm not really a mathematician,
my degree is in Numerical Analysis)
;-)
-- 
"I speak for myself and all of the lawyers of the world"
If I say something dumb, then they will have to sue themselves.


Jon S Anthony <jsa@alexandria> wrote in article
<JSA.96Sep26151720@alexandria>...
> In article <Dy9KEL.6nD@research.att.com> bs@research.att.com (Bjarne
Stroustrup) writes:
> 
> > Actually, the story that ++ comes from the PDP11 instruction
> > set is a myth. Dennis Ritchie has denied it quite often, but
> > that doesn't seem to impress people. ++ is in C and C++ because
> > Dennis (being a mathematician) considered it a fundamental
>           ^^^^^^^^^^^^^^^^^^^^^
> > (and useful) operation. It was in the PDP11 instruction set
> 
> I don't see how that has anything to do with it.  I'm a mathematician
> and I don't see it as a particularly interesting or useful operation
> to be singled out for special status (I'm not talking about the machine
> level here...)
> 
> /Jon
> 
> -- 
> Jon Anthony
> Organon Motives, Inc.
> 1 Williston Road, Suite 4
> Belmont, MA 02178
> 
> 617.484.3383
> jsa@organon.com
> 
> 

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

[Jay Martin]

jsa@alexandria (Jon S Anthony) writes:

>In article <Dy9KEL.6nD@research.att.com> bs@research.att.com (Bjarne Stroustrup) writes:

>> Actually, the story that ++ comes from the PDP11 instruction
>> set is a myth. Dennis Ritchie has denied it quite often, but
>> that doesn't seem to impress people. ++ is in C and C++ because
>> Dennis (being a mathematician) considered it a fundamental
>          ^^^^^^^^^^^^^^^^^^^^^
>> (and useful) operation. It was in the PDP11 instruction set

>I don't see how that has anything to do with it.  I'm a mathematician
>and I don't see it as a particularly interesting or useful operation
>to be singled out for special status (I'm not talking about the machine
>level here...)

I don't see any mathematical justification for it either, maybe Mr
Richie should publish a paper on the fundamental nature of "++" to the
foundations of mathematical thought. It seems incredible to me that Mr
Ritchie had never seen an "increment" assembly instruction or that the
inclusion of 10+ REDUNDANT and side-effect producing operators was not
motivated by some low-level performance concern/"too lazy to write an
optimizing compiler"  or an anti-software engineering desire to
minimize keystrokes on some primitive input device.   If he did think
he was doing mathematics, then I would say that he is an even poorer
mathematician than he is a language designer.

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

[Kent Budge]

Jay Martin wrote:
...
> I don't see any mathematical justification for it either, maybe Mr
> Richie should publish a paper on the fundamental nature of "++" to the
> foundations of mathematical thought. It seems incredible to me that Mr
> Ritchie had never seen an "increment" assembly instruction or that the
> inclusion of 10+ REDUNDANT and side-effect producing operators was not
> motivated by some low-level performance concern/"too lazy to write an
> optimizing compiler"  or an anti-software engineering desire to
> minimize keystrokes on some primitive input device.   If he did think
> he was doing mathematics, then I would say that he is an even poorer
> mathematician than he is a language designer.

Sorry to see this degenerating into a flame war.  Hope I'm not putting
more gasoline on the fire ...

The mathematical concept of "successor to i", which corresponds quite
closely to the C notation "i++", has been a fundamental part of 
mathematics (in the guise of typographical number theory) since at 
least the time of Hilbert.

I agree that the correspondence between the ++ operator and the 
autoincrement address mode on the old PDP is sufficiently close to
make it surprising that Richie didn't get his inspiration in this way.
But if he says he didn't (why should he lie?) and if his background
is as a mathematician, then I accept that the inspiration was the
concept of "successor to i" in typographical number theory.

Incidentally (to go off on a completely different tangent) I really
miss the ol' PDP-11 ... the only assembly language I've used that was 
really a pleasure to work in.  Sure, it was 16 bit and the floating
point and memory management were a kludgy add-on ... but the basic
integer instruction set and addressing modes were beautifully simple
and simply beautiful.   

kgbudge@sandia.gov
(usual disclaimer)

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

[George Haddad]

Kent Budge wrote:
> The mathematical concept of "successor to i", which corresponds quite
> closely to the C notation "i++", has been a fundamental part of
> mathematics (in the guise of typographical number theory) since at
> least the time of Hilbert.

   Disclaimer:  I am not any kind of mathematician.

   Observation: Ada models the notion of the "successor of i" much more 
closely (IMHO) with T'SUCC(i).  AFAIK, "the successor of i" does not 
imply that i _changes_ as a result.  Of course, if you are referring to 
i as used in sigma and pi notation (i.e., summations and product 
sequences) then one might think of i as "taking on the value of its 
successor".
-- 
I found these opinions on my doorstep, would you please give them a good 
home?

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

[Matthew Heaney]

In article <324C2C77.1B72@lmco.com>, george.haddad@lmco.com wrote:

>   Observation: Ada models the notion of the "successor of i" much more 
>closely (IMHO) with T'SUCC(i).  AFAIK, "the successor of i" does not 
>imply that i _changes_ as a result.  Of course, if you are referring to 
>i as used in sigma and pi notation (i.e., summations and product 
>sequences) then one might think of i as "taking on the value of its 
>successor".

You've identified the fact that there are really 2 issues we're debating:
the concept of a value and the concept of assignment of a value to an
object.

The concept of "successor to i" is modeled very elegantly in Ada by T'Succ
(i), but people seem to be having a problem with how one assigns that
value.

The abstract world of mathematics is all very theoretically interesting,
but in the end, we still have to program real programs on very concrete
computers.  So the pure, theoretical model that mathematics gives us is of
course the goal, but in this world on this computer I might not reach that
goal exactly.

So while the statement

 i := t'succ(i);

might make the mathematician happy, it doesn't seem to sit well with many
real-world programmers, who would seem to prefer

increment (i);

This is an area where one may justifiably criticize Ada (and many have), in
that it's *too* abstract.

For example, I've often seen something on paper that uses pure functions,
but when I have to code it, would use procedures, for no other reason than
efficiency.  Consider a set:

   S = {1, 2, 3}

Now to add an element to S, on paper, I would say

   S <- S union 4

If I did this exactly in Ada:

   S : Set;
...
   S := Union_Of (S, 4);

this would be horribly inefficient, because I'd have to make a copy of S,
then add 4 to that copy, and assign the whole thing back to S.   But the
procedure

   Add (4, To => S);

conveys exactly what I want to do, which is to add an element to an
already-existing set.  So the paper-based solution isn't always directly
applicable to what must be done on this computer, it's more a model for
what must be done.

So when the C programmer says

i++;

he is saying "increment the object i," which I feel is better than

i = i + 1;

because it more clearly captures his intent, and in spite of the fact the
2nd method is more pure.

matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

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

[George Haddad]

Kent Budge wrote:
> The mathematical concept of "successor to i", which corresponds quite
> closely to the C notation "i++", has been a fundamental part of
> mathematics (in the guise of typographical number theory) since at
> least the time of Hilbert.

   Disclaimer:  I am not any kind of mathematician.

   Observation: Ada models the notion of the "successor of i" much more 
closely (IMHO) with T'SUCC(i).  AFAIK, "the successor of i" does not 
imply that i _changes_ as a result.  Of course, if you are referring to 
i as used in sigma and pi notation (i.e., summations and product 
sequences) then one might think of i as "taking on the value of its 
successor".
-- 
I found these opinions on my doorstep, would you please give them a good 
home?

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

[George Haddad]

Disclaimer:  It isn't much of a mail program.

   Sorry for repeating my post excessive numbers of times.  (I suppose 
there are some of you out there who considered the first one 
"excessive".  :-))
-- 
I found these opinions on my doorstep, would you please give them a good 
home?

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

[George Haddad]

Kent Budge wrote:
> The mathematical concept of "successor to i", which corresponds quite
> closely to the C notation "i++", has been a fundamental part of
> mathematics (in the guise of typographical number theory) since at
> least the time of Hilbert.

   Disclaimer:  I am not any kind of mathematician.

   Observation: Ada models the notion of the "successor of i" much more 
closely (IMHO) with T'SUCC(i).  AFAIK, "the successor of i" does not 
imply that i _changes_ as a result.  Of course, if you are referring to 
i as used in sigma and pi notation (i.e., summations and product 
sequences) then one might think of i as "taking on the value of its 
successor".
-- 
I found these opinions on my doorstep, would you please give them a good 
home?

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

[George Haddad]

Kent Budge wrote:
> The mathematical concept of "successor to i", which corresponds quite
> closely to the C notation "i++", has been a fundamental part of
> mathematics (in the guise of typographical number theory) since at
> least the time of Hilbert.

   Disclaimer:  I am not any kind of mathematician.

   Observation: Ada models the notion of the "successor of i" much more 
closely (IMHO) with T'SUCC(i).  AFAIK, "the successor of i" does not 
imply that i _changes_ as a result.  Of course, if you are referring to 
i as used in sigma and pi notation (i.e., summations and product 
sequences) then one might think of i as "taking on the value of its 
successor".

-- 
I found these opinions on my doorstep, would you please give them a good 
home?

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

[Steve Heller]

Kent Budge <kgbudge@sandia.gov> wrote:

>Incidentally (to go off on a completely different tangent) I really
>miss the ol' PDP-11 ... the only assembly language I've used that was 
>really a pleasure to work in.  Sure, it was 16 bit and the floating
>point and memory management were a kludgy add-on ... but the basic
>integer instruction set and addressing modes were beautifully simple
>and simply beautiful.   
  I liked the PDP-11 instruction set too, as well as the PDP-10 set.
By the way, have you ever seen the 6809? I think it may have been even
prettier than either of the PDP sets mentioned above, as it made
virtually perfect use of a small set of registers. Of course, the
68000 and its successors look a lot like a 32-bit PDP-11 with separate
address and data registers, and is also quite pleasant to program.

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

[DJ Kindberg]

Off on a tangent, yes. I miss the ol' PDP-11, too.

I've written many programs using 6809 assembler. But alas, the past is
gone.

Darren

:   I liked the PDP-11 instruction set too, as well as the PDP-10 set.
: By the way, have you ever seen the 6809? I think it may have been even
: prettier than either of the PDP sets mentioned above, as it made
: virtually perfect use of a small set of registers. Of course, the
: 68000 and its successors look a lot like a 32-bit PDP-11 with separate
: address and data registers, and is also quite pleasant to program.
: 
: 
: 
: 
: 
: 

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

[Tim Behrendsen]

Jay Martin <jmartin@cs.ucla.edu> wrote in article <52g7f6$1fv0@uni.library.ucla.edu>...
> jsa@alexandria (Jon S Anthony) writes:
> 
> >In article <Dy9KEL.6nD@research.att.com> bs@research.att.com (Bjarne Stroustrup)
writes:
> 
> >> Actually, the story that ++ comes from the PDP11 instruction
> >> set is a myth. Dennis Ritchie has denied it quite often, but
> >> that doesn't seem to impress people. ++ is in C and C++ because
> >> Dennis (being a mathematician) considered it a fundamental
> >          ^^^^^^^^^^^^^^^^^^^^^
> >> (and useful) operation. It was in the PDP11 instruction set
> 
> >I don't see how that has anything to do with it.  I'm a mathematician
> >and I don't see it as a particularly interesting or useful operation
> >to be singled out for special status (I'm not talking about the machine
> >level here...)
> 
> I don't see any mathematical justification for it either, maybe Mr
> Richie should publish a paper on the fundamental nature of "++" to the
> foundations of mathematical thought. It seems incredible to me that Mr
> Ritchie had never seen an "increment" assembly instruction or that the
> inclusion of 10+ REDUNDANT and side-effect producing operators was not
> motivated by some low-level performance concern/"too lazy to write an
> optimizing compiler"  or an anti-software engineering desire to
> minimize keystrokes on some primitive input device.   If he did think
> he was doing mathematics, then I would say that he is an even poorer
> mathematician than he is a language designer.

I don't know about mathematical thought, but if you find it
difficult to imagine why increment and decrement are useful,
perhaps you need to practice a bit more programming before making
criticisms.

-- Tim Behrendsen (tim@a-sis.com)

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

[Art Schwarz]

(I hate to enter the fray.)

During the time of initial construction of the C compilers, not much was
available with respect to optimization. The nearest that I remember, there
was peephole optimization (McKeeman, Wortman, et alia) and various articles
by (for example) Cocke, a (rather good) book by Schwartz and little else. 
The seminal article by Knuth (Software Practices and Experiences, Vol. 1, 
Issue 1 - I believe) on his observation of typical Fortran expression usage
and the first article on sourcle level optimization (Software Practices and
Experiences, Vol ?) had yet to be written.

I can't speak for any of the developers, however, given the state of the
art in compiling at that time, it does not appear to be far-fetched to
consider the various 'condensed' operators to be a cheap way of doing 
optimization. An aid to the compiler given the state of the compiling art
at that time.

On the other hand, there are probably any number of people who were initially
on the C project who could answer the why's and wherefor's. Maybe one of them
could be asked to contribute.

art schwarz

(My opinions are someone else's.)

In article <01bbac7f$23e42940$87ee6fce@timpent.a-sis.com>, "Tim Behrendsen" <tim@a-sis.com> writes:
>Jay Martin <jmartin@cs.ucla.edu> wrote in article <52g7f6$1fv0@uni.library.ucla.edu>...
>> jsa@alexandria (Jon S Anthony) writes:
>> 
>> >In article <Dy9KEL.6nD@research.att.com> bs@research.att.com (Bjarne Stroustrup)
>writes:
>> 
>> >> Actually, the story that ++ comes from the PDP11 instruction
>> >> set is a myth. Dennis Ritchie has denied it quite often, but
>> >> that doesn't seem to impress people. ++ is in C and C++ because
>> >> Dennis (being a mathematician) considered it a fundamental
>> >          ^^^^^^^^^^^^^^^^^^^^^
>> >> (and useful) operation. It was in the PDP11 instruction set
>> 
>> >I don't see how that has anything to do with it.  I'm a mathematician
>> >and I don't see it as a particularly interesting or useful operation
>> >to be singled out for special status (I'm not talking about the machine
>> >level here...)
>> 
>> I don't see any mathematical justification for it either, maybe Mr
>> Richie should publish a paper on the fundamental nature of "++" to the
>> foundations of mathematical thought. It seems incredible to me that Mr
>> Ritchie had never seen an "increment" assembly instruction or that the
>> inclusion of 10+ REDUNDANT and side-effect producing operators was not
>> motivated by some low-level performance concern/"too lazy to write an
>> optimizing compiler"  or an anti-software engineering desire to
>> minimize keystrokes on some primitive input device.   If he did think
>> he was doing mathematics, then I would say that he is an even poorer
>> mathematician than he is a language designer.
>
>I don't know about mathematical thought, but if you find it
>difficult to imagine why increment and decrement are useful,
>perhaps you need to practice a bit more programming before making
>criticisms.
>
>-- Tim Behrendsen (tim@a-sis.com)

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

[Craig Franck]

jsa@alexandria (Jon S Anthony) wrote:
>In article <Dy9KEL.6nD@research.att.com> bs@research.att.com (Bjarne Stroustrup) writes:
>
>> Actually, the story that ++ comes from the PDP11 instruction
>> set is a myth. Dennis Ritchie has denied it quite often, but
>> that doesn't seem to impress people. ++ is in C and C++ because
>> Dennis (being a mathematician) considered it a fundamental
>          ^^^^^^^^^^^^^^^^^^^^^
>> (and useful) operation. It was in the PDP11 instruction set
>
>I don't see how that has anything to do with it.  I'm a mathematician
>and I don't see it as a particularly interesting or useful operation
>to be singled out for special status (I'm not talking about the machine
>level here...)

Well, I'm not a mathematician, but I have noticed that a large 
number of them have a fascination with numbers theory. Maybe the
addition of integers seems "fundamental". I hope I do not need to
mention that c++; blows the doors off c = c + 1; nor shall I begin
to discuss the obvious inferiority of c := c + 1; :-)


-- 
Craig
clfranck@worldnet.att.net
Manchester, NH
"What Java revolution?"  -- Bjarne Stroustrup

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

[Bob Cousins]

In comp.lang.c, Craig Franck wrote:

>jsa@alexandria (Jon S Anthony) wrote:
>>In article <Dy9KEL.6nD@research.att.com> bs@research.att.com (Bjarne Stroustrup) writes:
>>
>>> Actually, the story that ++ comes from the PDP11 instruction
>>> set is a myth. Dennis Ritchie has denied it quite often, but
>>> that doesn't seem to impress people. ++ is in C and C++ because
>>> Dennis (being a mathematician) considered it a fundamental
>>          ^^^^^^^^^^^^^^^^^^^^^
>>> (and useful) operation. It was in the PDP11 instruction set
>>
>>I don't see how that has anything to do with it.  I'm a mathematician
>>and I don't see it as a particularly interesting or useful operation
>>to be singled out for special status (I'm not talking about the machine
>>level here...)
>
>Well, I'm not a mathematician, but I have noticed that a large 
>number of them have a fascination with numbers theory. Maybe the
>addition of integers seems "fundamental". I hope I do not need to
>mention that c++; blows the doors off c = c + 1; nor shall I begin
>to discuss the obvious inferiority of c := c + 1; :-)

I don't think a mathematician would write c = c + 1 either.

-- 
Bob Cousins, Software Engineer.
Home page at http://www.demon.co.uk/sirius-cybernetics/

Please do NOT use my email address on mailing lists without my prior permission.

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

[Jon S Anthony]

In article <324b5c87.3413989@news.demon.co.uk> bob@lintilla.demon.co.uk (Bob Cousins) writes:

> 
> I don't think a mathematician would write c = c + 1 either.

Depends on.  If C is an infinite cardinal (say Aleph0) they would.  If
not, then it is an obvious _false_ statement, and one would hope your
are correct.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

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

[Jon S Anthony]

In article <515o3b$d7h@goanna.cs.rmit.edu.au> ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

> In short, the discussion with you has been a waste of time, because
> you were never making any claim with empirical content, only playing
> language games.

Never discount a "language game".  They can surprise you sometimes and
offer a good deal more than what you were originally looking for.

But - not in this case :-)

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

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

[Jon S Anthony]

In article <01bb9f26$36c870e0$87ee6fce@timpent.a-sis.com> "Tim Behrendsen" <tim@airshields.com> writes:

> It is similiar to the difference between summation and integration;
> one consists of individual sums, the other of an infinite number
> of sums.  However, both are fundamentally adding.

Well, that is one option.  But as "everyone" knows, the FTC allows you
to compute definite integrals without taking the limits of sums or
using summations at all.  Incidentally, none of the standard
definitions (Riemann Sum or something) uses "an infinite number of
sums".  Can't - infinity is not part of the real numbers...


> Procedural means "has a procedure."  Nothing in the real world
> is not procedural, but we can *express* algorithms non-procedurally.
> This is where the term is useful.  The term is meaningless when it
> comes to implementation.

Well, at this point, I'd have to say that your _definition_ has become
meaningless, or at the very least, empty of content.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

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

[Craig Franck]

jsa@alexandria (Jon S Anthony) wrote:
>In article <01bb9f26$36c870e0$87ee6fce@timpent.a-sis.com> "Tim Behrendsen" <tim@airshields.com> writes:


>> Procedural means "has a procedure."  Nothing in the real world
>> is not procedural, but we can *express* algorithms non-procedurally.
>> This is where the term is useful.  The term is meaningless when it
>> comes to implementation.
>
>Well, at this point, I'd have to say that your _definition_ has become
>meaningless, or at the very least, empty of content.

It would be meaningfull if Tim could come up with an example of 
"non-procedural" behavour. Procedural means it "has a procedure" adds
nothing, unless an example of "not having a procedure" is given. For 
something to be a theory, you must be able to come up with a testable
example in which it is proven false. For a word to have meaning it must
be shown to have a "creditable distinction". "All is Up" impresses no one. 
If, say, a random change from one state into the next, with the current
state having nothing to do with the past one, is considered "non-procedural",
then the definition has meaning.

Remember, everything in the real world is real, and some things are 
inexpressable, even though they have meaning. All algorithms may be
"procedural" when they are implemented, because that is the way an
"implementation" of an algorithm is defined by some.

-- 
Craig  
clfranck@worldnet.att.net    
Manchester, NH
A great many people think they are thinking when they are
merely rearranging their prejudices.  -- William James

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

[Tim Behrendsen]

Craig Franck <clfranck@worldnet.att.net> wrote in article
<515al5$lm8@mtinsc01-mgt.ops.worldnet.att.net>...
> jsa@alexandria (Jon S Anthony) wrote:
> >In article <01bb9f26$36c870e0$87ee6fce@timpent.a-sis.com> "Tim
Behrendsen" <tim@airshields.com> writes:
> 
> 
> >> Procedural means "has a procedure."  Nothing in the real world
> >> is not procedural, but we can *express* algorithms non-procedurally.
> >> This is where the term is useful.  The term is meaningless when it
> >> comes to implementation.
> >
> >Well, at this point, I'd have to say that your _definition_ has become
> >meaningless, or at the very least, empty of content.
> 
> It would be meaningfull if Tim could come up with an example of 
> "non-procedural" behavour. Procedural means it "has a procedure" adds
> nothing, unless an example of "not having a procedure" is given. For 
> something to be a theory, you must be able to come up with a testable
> example in which it is proven false. For a word to have meaning it must
> be shown to have a "creditable distinction". "All is Up" impresses no
one. 
> If, say, a random change from one state into the next, with the current
> state having nothing to do with the past one, is considered
"non-procedural",
> then the definition has meaning.
> 
> Remember, everything in the real world is real, and some things are 
> inexpressable, even though they have meaning. All algorithms may be
> "procedural" when they are implemented, because that is the way an
> "implementation" of an algorithm is defined by some.

I agree.  Procedural vs Non-procedural only has meaning in the
expression of an algorithm, not in the implementation.

Where this all started was my making a statement that the most
crucial thing a student can learn is the procedural nature of the
computer, to which someone responded (paraphrase) "well, what
about non-procedural algorithms?", to which I said something to
the effect of "everything is procedural".  I should probably have
said "all implementations are procedural", and that would have
saved all these posts. :)  [but perhaps not]

I still stand by my statement, however, that the most critical
thing a student can learn is the fundamentally procedural nature
of the computer.  Before syntax, before subroutines, before style,
they must learn that algorithms are a forward-moving,
cause-and-effect process.

And this *is* something that must be learned, that most
programmers take for granted as obvious.

-- Tim Behrendsen (tim@a-sis.com)

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

[George]

jsa@alexandria (Jon S Anthony) wrote:

> In article <01bb9f26$36c870e0$87ee6fce@timpent.a-sis.com> "Tim Behrendsen" <tim@airshields.com> writes:

> > It is similiar to the difference between summation and integration;
> > one consists of individual sums, the other of an infinite number
> > of sums.  However, both are fundamentally adding.

> Well, that is one option.  But as "everyone" knows, the FTC allows you
> to compute definite integrals without taking the limits of sums or
> using summations at all.  Incidentally, none of the standard
> definitions (Riemann Sum or something) uses "an infinite number of
> sums".  Can't - infinity is not part of the real numbers...


Surely the definition of integration contains the phrase "...tends to
infinity", i.e. it's _as if_ there was an infinite number of sums.

G.

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

[Joel VanLaven]

George (grs@liyorkrd.li.co.uk) wrote:
: jsa@alexandria (Jon S Anthony) wrote:

: > In article <01bb9f26$36c870e0$87ee6fce@timpent.a-sis.com> "Tim Behrendsen" <tim@airshields.com> writes:

: > > It is similiar to the difference between summation and integration;
: > > one consists of individual sums, the other of an infinite number
: > > of sums.  However, both are fundamentally adding.

: > Well, that is one option.  But as "everyone" knows, the FTC allows you
: > to compute definite integrals without taking the limits of sums or
: > using summations at all.  Incidentally, none of the standard
: > definitions (Riemann Sum or something) uses "an infinite number of
: > sums".  Can't - infinity is not part of the real numbers...


: Surely the definition of integration contains the phrase "...tends to
: infinity", i.e. it's _as if_ there was an infinite number of sums.

: G.

  Actually, not all functions are integrable.  The most complete and
irrefutable definition of the integral of a function to my knowledge is :

Given a partition P of [a,b] 
          (P is a finite subset of [a,b] including a and b)
P={x0,x1,x2,...xn} such that a=x0, b=xn, and x(j+1)>xj
call Mj the lub(f([x(j-1),xj]) (least upper bound)
call mj the glb(f([x(j-1),xj]) (greatest lower bound)

The number Uf(P)=SUM(Mj(xj-x(j-1))) 1<=j<=n 
is called the P upper sum for f

The number Lf(P)=SUM(mj(xj-x(j-1))) 1<=j<=n
is called the P lower sum for f

The unique number I that satisfies the inequality
Lf(P)<=I<=Uf(P) for all possible P of [a,b]
is called the definite integral of f from a to b.

So, you could talk about an infinite (aleph 2)! number of sums, but it
is ridiculus.  We are talking about more uncountable that uncountable.
No one integrates this way.  It is a mathematical abstraction. This is
the definition that we then prove is equivalent to some simpler method
for certain "nice" functions.  Riemann sums only work for uniformly
continuous functions.  Even then we don't actually USE the Riemann sums!
We use them only as ways to let us use even better methods.  In the
mathematics there are REAL infinities but a good mathematician NEVER
actually calculates an infinite anything, as that is impossible! they 
PROVE that thier answer is correct through techniques that remove
infiniteness like induction or certain properties of the real numbers
like completeness.  While a hand-wavy infinite sums explanation usually
satisfies the non-mathematicians (like say engineers), the truth is at
once more complicated, simple, and beautiful.

-- A Mathematician
is correct

If the the most REAL :) definition of integration (as I was taught in
advanced calculus) is:
-- 
-- Joel VanLaven

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

[Dann Corbit]

Joel VanLaven <jvl@ocsystems.com> wrote in article
<1996Sep24.133312.9745@ocsystems.com>...
>   Actually, not all functions are integrable.  The most complete and
> irrefutable definition of the integral of a function to my knowledge is :
> 
> Given a partition P of [a,b] 
>           (P is a finite subset of [a,b] including a and b)
> P={x0,x1,x2,...xn} such that a=x0, b=xn, and x(j+1)>xj
> call Mj the lub(f([x(j-1),xj]) (least upper bound)
> call mj the glb(f([x(j-1),xj]) (greatest lower bound)
> 
> The number Uf(P)=SUM(Mj(xj-x(j-1))) 1<=j<=n 
> is called the P upper sum for f
> 
> The number Lf(P)=SUM(mj(xj-x(j-1))) 1<=j<=n
> is called the P lower sum for f
> 
> The unique number I that satisfies the inequality
> Lf(P)<=I<=Uf(P) for all possible P of [a,b]
> is called the definite integral of f from a to b.
There are far simpler examples of functions that
are not integrable.
Consder f(x) = 1/x over [-1,1]
(It is not continuous) 

Or consider the integral of e^x over [0, infinity]
There is no finite value to the integral of this smooth,
continuous function.
There is however, for e^(-x*x) over the same interval
being sqrt(pi)/2.

> So, you could talk about an infinite (aleph 2)! number of sums, but it
> is ridiculus.  We are talking about more uncountable that uncountable.
> No one integrates this way.  It is a mathematical abstraction. This is
> the definition that we then prove is equivalent to some simpler method
> for certain "nice" functions.  Riemann sums only work for uniformly
> continuous functions.  Even then we don't actually USE the Riemann sums!
> We use them only as ways to let us use even better methods.  In the
> mathematics there are REAL infinities but a good mathematician NEVER
> actually calculates an infinite anything, as that is impossible! they 
> PROVE that thier answer is correct through techniques that remove
> infiniteness like induction or certain properties of the real numbers
> like completeness.  While a hand-wavy infinite sums explanation usually
> satisfies the non-mathematicians (like say engineers), the truth is at
> once more complicated, simple, and beautiful.

Often, infinte integrals can be converted to simple
finite integrals with a change of variables. 
"Numerical Recipies in C" discusses several solutions
to "improper" integrals.

> -- A Mathematician
> is correct
> 
> If the the most REAL :) definition of integration (as I was taught in
> advanced calculus) is:
> -- 
> -- Joel VanLaven
> 
-- 
"I speak for myself and all of the lawyers of the world"
If I say something dumb, then they will have to sue themselves.

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

[Tom Payne]

In comp.lang.c++ Joel VanLaven <jvl@ocsystems.com> wrote:
[...]
:   Actually, not all functions are integrable.  The most complete and
: irrefutable definition of the integral of a function to my knowledge is :

: Given a partition P of [a,b] 
:           (P is a finite subset of [a,b] including a and b)
: P={x0,x1,x2,...xn} such that a=x0, b=xn, and x(j+1)>xj
: call Mj the lub(f([x(j-1),xj]) (least upper bound)
: call mj the glb(f([x(j-1),xj]) (greatest lower bound)

: The number Uf(P)=SUM(Mj(xj-x(j-1))) 1<=j<=n 
: is called the P upper sum for f

: The number Lf(P)=SUM(mj(xj-x(j-1))) 1<=j<=n
: is called the P lower sum for f

: The unique number I that satisfies the inequality
  ^^^^^^^^^^^^^^^^^^^
   if it exists

: Lf(P)<=I<=Uf(P) for all possible P of [a,b]
: is called the definite integral of f from a to b.

Actually, there is a significant generalization, called Lebesgue
integration, that can be found in any graduate text on Real Analysis
(e.g., those by Royden and by Rudin).  Nevertheless, if you believe in
the axiom of choice, there are still functions that are not integrable
(but they get pretty weird).

Tom Payne

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

[Tim Behrendsen]

Tom Payne <thp@cs.ucr.edu> wrote in article <52gvu3$jhb@rumors.ucr.edu>...
> In comp.lang.c++ Joel VanLaven <jvl@ocsystems.com> wrote:
> [...]
> :   Actually, not all functions are integrable.  The most complete and
> : irrefutable definition of the integral of a function to my knowledge is
:
> 
> : Given a partition P of [a,b] 
> :           (P is a finite subset of [a,b] including a and b)
> : P={x0,x1,x2,...xn} such that a=x0, b=xn, and x(j+1)>xj
> : call Mj the lub(f([x(j-1),xj]) (least upper bound)
> : call mj the glb(f([x(j-1),xj]) (greatest lower bound)
> 
> : The number Uf(P)=SUM(Mj(xj-x(j-1))) 1<=j<=n 
> : is called the P upper sum for f
> 
> : The number Lf(P)=SUM(mj(xj-x(j-1))) 1<=j<=n
> : is called the P lower sum for f
> 
> : The unique number I that satisfies the inequality
>   ^^^^^^^^^^^^^^^^^^^
>    if it exists
> 
> : Lf(P)<=I<=Uf(P) for all possible P of [a,b]
> : is called the definite integral of f from a to b.
> 
> Actually, there is a significant generalization, called Lebesgue
> integration, that can be found in any graduate text on Real Analysis
> (e.g., those by Royden and by Rudin).  Nevertheless, if you believe in
> the axiom of choice, there are still functions that are not integrable
> (but they get pretty weird).

Somewhat off the subject (but way off the subject of comp.lang.*), the
site http://www.integrals.com (sponsored by Mathematica?) that allows
you to type an integral in and it will try and evaluate it.  If it
can't do it, it's either not integrable or their algorithm doesn't
support it (they ask you to e-mail them if you think it can be done).
I managed to break it right off by

   integral X^X dx

Which I *think* is integrable (at least I remember figuring it out
in college, but that was a long time ago and I may have done it
wrong. :-) )

-- Tim Behrendsen (tim@a-sis.com)

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

[Jon S Anthony]

In article <51knhg$j61@dub-news-svc-8.compuserve.com> grs@liyorkrd.li.co.uk (George) writes:

> jsa@alexandria (Jon S Anthony) wrote:
> 
> > In article <01bb9f26$36c870e0$87ee6fce@timpent.a-sis.com> "Tim Behrendsen" <tim@airshields.com> writes:
> 
> > > It is similiar to the difference between summation and integration;
> > > one consists of individual sums, the other of an infinite number
> > > of sums.  However, both are fundamentally adding.
> 
> > Well, that is one option.  But as "everyone" knows, the FTC allows you
> > to compute definite integrals without taking the limits of sums or
> > using summations at all.  Incidentally, none of the standard
> > definitions (Riemann Sum or something) uses "an infinite number of
> > sums".  Can't - infinity is not part of the real numbers...
> 
> 
> Surely the definition of integration contains the phrase "...tends to
> infinity", i.e. it's _as if_ there was an infinite number of sums.

Nothing so sloppy as that.  You can't have "real definitions" that
hand wave stuff like "as if", "tends to infinity", etc.  Also,
"integration" is an activity - the definitions in question involve the
notions of "definite integral" and "indefinite integral" of a function
(over some interval).  Integration then involves various techniques
for finding such things.  In _standard_ analysis the definitions for
definite integral (the sort of "summing stuff" first mentioned) all
involve the _formal_ notion of a limit (you remember that - all that
epsilon and delta stuff with universal and existential quantification).
Infinity (as in a completed concept, i.e., transfinite number) does
not enter into it.  If you are really interested, I can give you the
details in email - or you can just pull out that first year calculus
book...

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

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

[Jon S Anthony]

In article <1996Sep24.133312.9745@ocsystems.com> jvl@ocsystems.com (Joel VanLaven) writes:

> George (grs@liyorkrd.li.co.uk) wrote:
> : Surely the definition of integration contains the phrase "...tends to
> : infinity", i.e. it's _as if_ there was an infinite number of sums.
> 
> : G.

>   Actually, not all functions are integrable.  The most complete and
> irrefutable definition of the integral of a function to my knowledge is :
> 
> Given a partition P of [a,b] 
>           (P is a finite subset of [a,b] including a and b)
> P={x0,x1,x2,...xn} such that a=x0, b=xn, and x(j+1)>xj
> call Mj the lub(f([x(j-1),xj]) (least upper bound)
> call mj the glb(f([x(j-1),xj]) (greatest lower bound)
> 
> The number Uf(P)=SUM(Mj(xj-x(j-1))) 1<=j<=n 
> is called the P upper sum for f
> 
> The number Lf(P)=SUM(mj(xj-x(j-1))) 1<=j<=n
> is called the P lower sum for f
> 
> The unique number I that satisfies the inequality
> Lf(P)<=I<=Uf(P) for all possible P of [a,b]
> is called the definite integral of f from a to b.

*IF* it exists.  If f is not "nice" it won't.  When it does, it is
also the LUB of the set of all lower sums and the GLB of set of all
the upper sums.  Actually, I've always been partial to the
upper-and-lower sums definition for the definite integral.  However,
it is _not_ any more "complete and irrefutable" than Riemann Sums.


> So, you could talk about an infinite (aleph 2)! number of sums, but it

Actually, when people use the side-ways "8" notation, the typical
intent is simply that of indicating "arbitrarily large" or (somewhat
less so) denumerably infinite (size of naturals - aka Aleph0).  Your
"Aleph2" is a denotation for the size of sets the size of the power
set of R (the reals) where Aleph1 denotes the size of sets
equinumerous with R.  In general you have this whole "backbone" of
transfinite numbers constructed (typically) via the power set
operation.


> is ridiculus.  We are talking about more uncountable that uncountable.
> No one integrates this way.  It is a mathematical abstraction. This is

Well, Archimedes _did_! :-) (Just one of the reasons he is often
regarded among the top 3 mathematicians of all time).  But you only
need countably infinite sums.


> the definition that we then prove is equivalent to some simpler method
> for certain "nice" functions.  Riemann sums only work for uniformly
> continuous functions.

The RS definition is _equivalent_ to the ULS definition.  This is
reasonably straightforward to prove, but it is definitely NON-trivial.


> mathematics there are REAL infinities but a good mathematician NEVER
> actually calculates an infinite anything, as that is impossible! they

Depends on what you mean by "calculate".  If you mean "construct"
(ala' Poincare or Intuitionism) then what you say is accurate.  OTOH,
letting P be the power set of operation, then P(R) is a perfectly nice
entity (IMO) and the cardinality (size) of P(R) is a perfectly nice
transfinite number.


> While a hand-wavy infinite sums explanation usually
> satisfies the non-mathematicians (like say engineers), the truth is at
> once more complicated, simple, and beautiful.

Hey, you really are a mathematician! :-)


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

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

[Andrew Gierth]

>>>>> "Craig" == Craig Franck <clfranck@worldnet.att.net> writes:

 > "Spencer M. Simpson, Jr." <mapwiz@erols.com> wrote:
 >> Adam Beneschan wrote:
 >>> 
 >>> jsa@alexandria (Jon S Anthony) writes:
 >>> >
 >>> >Actually, when people use the side-ways "8" notation,...
 >>> 
 >>> As long as we're getting pedantic:...
 >> As long as we're getting pedantic, shouldn't this thread have a 
 >> defferent name?

 Craig> The problem is that you never know what a thread will evolve into!
 Craig> Certain threads exist as a kind of dumping ground for idle musings.
 Craig> I remember pondering "If god exists, is he procedural?". Also, notice
 Craig> that it has already undergone a name change.

It's also been going on for over 2 months now, and it's *still* off-topic
in comp.unix.programmer. The References: headers got so big that several
people's newsreaders have trashed them, and various additional groups
have migrated in and out of the Newsgroups: line. At least the religious
wars that it used to contain have died down a little (or possibly migrated
elsewhere). Ah well, such is Usenet.

-- 
Andrew Gierth (andrewg@microlise.co.uk)

"Ceterum censeo Microsoftam delendam esse" - Alain Knaff in nanam

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

[Bengt Richter]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 6705 bytes --]


"Tim Behrendsen" <tim@airshields.com> wrote:

>Lawrence Kirby <fred@genesis.demon.co.uk> wrote in article
><840288278snz@genesis.demon.co.uk>...
>> In article <01bb846d$c6c01780$87ee6fce@timpent.airshields.com>
>>            tim@airshields.com "Tim Behrendsen" writes:
>> 
>> >Who's talking about showing them?  I would suggest that if
>> >they wrote a quicksort in assembler, they will have a much
>> >better "feel" for the algorithm, than if they wrote it in C.
>> 
>> They might have a good feel for how to implement quicksort in that
>> particular machine code however it would be so wrapped up in
>> implementation details that they wouldn't have a good understanding of
>> the algorithm itself, at last not in the same timescale.

>And they don't get wrapped up in implementation
>details if they write it in C?  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.
	What if computers are totally irrelevant? If
an algorithm is an abstract procedure for manipulating
symbols, or accomplishing some mathematical purpose?
Then any computerized implementation will just be an
instance of a broad class of implementation possibilities.
And assembler would be just one of a number of possible
intermediate code representations in translating to
an executable representation for a particular platform/
OS environment.
	If you are more fluent in assembler than in
the native terms/notation of the original abstraction,
then you may look at the assembler code and say, "Aha,
that's what that meant," and be helped in understanding
the original algorithm, ...if the latter was relatively
trivial. But I don't think looking at assembler is a good
way to understand system-level workings of things, even
though it may help with a given primitive. Even C can
be too low a level. How do you see object hierarchies in
assembler? Or even C++ source code -- you need a way of
seeing the woods as well as the trees. E.g., the important
aspects of OpenGL are not the language it's been ported
to, though you can be sure there are assembler-coded
primitives supporting any given implementation. An annotated
dataflow diagram supplemented with some equations etc. may
be one of the best helps in arriving at understanding.
A riveter sees the importance of rivets everywhere, but
it's a limited view.

>The most important thing a student can learn about
>computers is the fundamentally simple nature.  The
	I think the "fundamentally simple nature" you
are talking about is a simplified *view/abstraction* of an
older-architecture computer. If you focus on small enough
a detail, it becomes "simple," e.g., a bus transaction
that moves a word from memory to cpu chip, but to keep it
simple you may have to ignore caches, burst modes, split
address/data transactions, multiple bus masters, etc. etc.
not to mention multiple CPUs each with separate multiple
execution units, pipelines, etc. Perhaps what is needed
is a standard virtual machine for teaching purposes.
>mystery of execution *must* be broken down in order for
	This mystery sounds suspiciously like step-step,
i.e., a rule of sequential evaluation. I think a lot of these
things benefit from being considered in the abstract (assuming
one is comfortable in that domain). A nice book is "Anatomy
of Lisp" by John Allen, (c) 1978 by McGraw-Hill, Inc.
ISBN-0-07-001115-X. I don't think they'll mind if I quote a
quotation the author put at the head of the preface:

	"'... it is important not to lose sight of the fact that
there is a difference between training and education. If computer
science is a fundamental discipline, then university education in
this field should emphasize enduring fundamental principles rather
than transient current technology.'
	Peter Wegner, Three Computer Cultures"

As true now as then, I think. A particular assembler for a particular
CPU/OS environment is "transient current technology." A well-chosen
VM might not be. An object-oriented implementation of an emulator
for such a VM might be an interesting multi-perspective project...

>the student to being to think like a programmer.
Of Smalltalk/LISP/CLOS or C++/Delphi or assembler/Fortran/C? ;-)
>Once they can think like a programmer, all the rest
>of the knowledge they learn becomes trivial.
A terrifying prospect!
After 70k+- hrs of OJT as programmer, I still run into
stuff that seems non-trivial to me, thank goodness.
But then I have been trying to get beyond my assembler origins ;-)

BTW, what about thinking like a mathematician ;-) Or a
problem-solver? Or an artist?

If you are teaching programming, how much "transient current
technology" is it worth while to teach, projecting trends to
graduation time? Just enough to use it for lab work (education),
or in depth as case studies exemplifying the principles you
are trying to teach, or focused on a job market (training)?
I don't think there is a one-size-fits-all answer.

If you want students to know about *computers*, why not
teach them a little logical design and electronics?
So they have an idea of how data actually moves around
in that minitower. Hm. Should we leave caches out of it?
ISA vs VLB vs PCI? VME as example of non-synchronous
alternatives? Do they need to know how to write a BIOS?
What does the power-on reset do to all those chips on
all those boards that it reaches? Oh, and how about the
OS? After all, we don't usually run an assembler on the
bare metal. So, to have a decent concept of what really
is going on, don't they have to know how an OS boots up
and gets to the point where it's able to run a shell?
And how that shell gets its input and interacts with OS
services to allocate memory and load and start execution
of the assembler, and how that's going to get your code
from a file and translate it to object form in another file.
How about the linker and that whole story? Should we be
satisfied with knowing how this works in DOS as OS? "Puh-leez!"
It's maybe a little much to go into both Unix and WinXX
(and system 7?), so what to choose?

Ok, when are they going to be ready to learn about continuations?
Or meta-object protocol? Or unification? or Corba?
What is helpful? What is a scenic detour?

IMHO, over-emphasis on the sequential-execution aspect of programming
represented by assembler may well leave students so used to one view
of the optical illusion that they cannot easily snap their mental
image into another just-as-valid form. I.e., they may not "get"
OO design very easily.

My 2�

Regards,
Bengt Richter

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

[Frank Manning]

In article <4vgs4p$evl@news.accessone.com> bokr@accessone.com (Bengt
Richter) writes:

> What if computers are totally irrelevant? 

When you give students a programming assignment, are the students
required to run the program on actual, physical, real-life computers?
If so, that presents certain...ah...practical problems

Should the students know how to turn on the computer? Do you expect
them to know where the on/off switch is? Suppose they flip the switch
and nothing happens? Are they expected to know that the computer is
supposed to get electrical power somewhere -- is it plugged into a
wall socket, or does it have internal batteries, or what? What if the
fuse is blown? Are they supposed to sit there helplessly?

>         "'... it is important not to lose sight of the fact that
> there is a difference between training and education. If computer
> science is a fundamental discipline, then university education in
> this field should emphasize enduring fundamental principles rather
> than transient current technology.'
>         Peter Wegner, Three Computer Cultures"

Ah, yes. The eternal training-vs-education dilemma.

I totally agree that university education should emphasize fundamentals,
but not to the exclusion of hands-on experience. What happens if you
want to do research, especially if experiments are required? Who's going
to run the experiments? Technicians? You can't get technicians to do
everything. At large research universities, for example, students are
relied on for quite a lot.

And if the students know only abstract theory, how are professors going
to explore new theories if the students are incapable of running
experiments, as the students most certainly will be if they don't know
the details of how the hardware actually works? There are countless ways
an experiment can go wrong or give misleading results. It's difficult to
prevent those problems without a thorough understanding of hardware
details.

-- Frank Manning
-- Chair, AIAA-Tucson Section

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

[Bengt Richter]

frank@bigdog.engr.arizona.edu (Frank Manning) wrote:

>In article <4vgs4p$evl@news.accessone.com> bokr@accessone.com (Bengt
>Richter) writes:

>> What if computers are totally irrelevant? 

>When you give students a programming assignment, are the students
>required to run the program on actual, physical, real-life computers?
>If so, that presents certain...ah...practical problems

	First, I agree with you. But the topic I was trying to comment
on was the efficacy of assembler code as a vehicle for getting an
understanding of an algorithm. And I was trying to point out that an
algorithm may be fundamentally abstract, making computers
*essentially* irrelevant. That is not to say that the practical
ability to use computers is irrelevant to a programming assignment
involving the algorithm, nor is it to say that such an assignment
could not help a student understand the algorithm.
	I felt the value of assembler level concerns was being
evangelized to such an extent that I counter-reacted. If I had
encountered my own post out of context, emphasizing the abstract,
I would probably have felt the urge to point out that I wouldn't
want to do without a CPU/machine language view in my debugger, as
things stand now.
[...]	
>And if the students know only abstract theory, how are professors going
>to explore new theories if the students are incapable of running
>experiments, as the students most certainly will be if they don't know
>the details of how the hardware actually works? There are countless ways
>an experiment can go wrong or give misleading results. It's difficult to
>prevent those problems without a thorough understanding of hardware
>details.
	Certainly I don't think students should know only abstract theory,
even if they're math majors. But I think you could play with
algorithms in Scheme and not have to worry too much about how the
hardware works. I would think a central goal in choosing or
constructing an experimental environment would be to eliminate
extraneous concerns. 
	Of course what's extraneous for some is central to others.
There can be bugs in Scheme interpreters or compilers, but those
are presumably in a different domain from the domain of the algorithm.
Should driving school students be able to fix the transmission if that
breaks during a lesson? It's a worthy subject, but out of scope.

Regards,
Bengt Richter
BTW, did I detect a hint of exclusivity in "...professors going to
explore new theories...?" I think many students will quickly outrun
their coaches when allowed on the same track :-)

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

[Frank Manning]

In article <5085r7$ra7@kanga.accessone.com> bokr@accessone.com (Bengt
Richter) writes:

   [...]
>         I felt the value of assembler level concerns was being
> evangelized to such an extent that I counter-reacted. If I had
> encountered my own post out of context, emphasizing the abstract,
> I would probably have felt the urge to point out that I wouldn't
> want to do without a CPU/machine language view in my debugger, as
> things stand now.

I see your point. Personally, think Tim is going too far in
evangelizing assembly language. I agree with him that students should
get some exposure, but I personally would be satisfied with the bare
minimum for the students to get a vague idea about what actually goes
on inside the machine.

Such as -- move a couple of words from memory into registers, do a math
operation on the pair, then move the result back into memory. Maybe add
simple I/O and a jump instruction -- just enough for them to get a hint
of what's actually going on inside the magic box.

I think Tim has the right idea, but teaching sorting in assembly goes a
bit too far, IMHO.

[...]
> Should driving school students be able to fix the transmission if that
> breaks during a lesson? It's a worthy subject, but out of scope.

Good point. I agree that transmission repair doesn't belong in a driving
school. On the other hand, I'd hope the students have at least a vague
idea that transmissions usually have gears and some kind of oil or
transmission fluid inside.

"What am I gonna do? There's this weird red puddle in my driveway and
my cousin Vinny's fiance isn't around to help!"

I look at the problem from the following point of view -- in a former
life I worked at a university, and one thing I did was assist professors
in research or running labs in an engineering department.

Engineering professors, especially older ones, tend to be rather hostile
toward or intimidated by computers, especially when computers are used
for data acquisition during experiments. They're worried that students
won't learn anything if a computer reads a sensor. Some professors tend
to think that *students* need to read thermometers, pressure gages and
voltmeters themselves in order to understand physically what's going on.
Otherwise the computer does everything and magically spits out an answer,
and the students supposedly won't learn anything.

In my humble opinion, the solution to that problem is to teach the
students what actually goes on inside the computer, how a transducer
signal wends its way through an ADC into the computer memory, and how to
write the software that controls all that stuff. Students also need to
understand that things can go wrong and the computer will tell you a
direct lie if it can possibly get away with it.

-- Frank Manning
-- Chair, AIAA-Tucson Section

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

[Frank Manning]

I wrote:

> Engineering professors, especially older ones, tend to be rather hostile
> toward or intimidated by computers [...]

In retrospect, I think my statement is overgeneralizing. Many
engineering professors are of course experts when it comes to
computers.

-- Frank Manning
-- Chair, AIAA-Tucson Section

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

[deafen]

Frank Manning (frank@bigdog.engr.arizona.edu) wrote:
   [...]

: In my humble opinion, the solution to that problem is to teach the
: students what actually goes on inside the computer, how a transducer
: signal wends its way through an ADC into the computer memory, and how to
: write the software that controls all that stuff. Students also need to
: understand that things can go wrong and the computer will tell you a
: direct lie if it can possibly get away with it.

Frank, please allow me to speak from a student's point of view.  I'm a
senior in CIS, so I'm not required to do any assembly coding.  (For that
matter, I'm not required to learn much programming at all; I consider
myself the "odd man out" because I actually enjoy doing it and learning
about it.)

I do have a point.  Please be patient.  :)

Computer science students entering college today face a dilemma.  While 
we understand that the fundamentals (how the "transducer signal wends its 
way...into the computer memory") are important, we need to keep up with 
the state of the art, as well.

Those who have been in computing for twenty (or even ten) years have an 
advantage over us; they've had the time to learn all of the fundamentals 
and grow with the technology and paradigm shifts.  We are faced with the 
daunting task of learning all of these things in a few years, rather than 
a decade or two.

If I were to specialize in "how to write the software that controls all 
that stuff," I'd be left with no time at all to learn the more 
sophisticated things -- the MS Windows API, for example.

I can't speak much for the academic or research communities.  However, if 
a programmer is going to be of much use at all to the business community, 
it's far more important *to the employer* that s/he know the current 
state of the art than the underlying foundation.

I'm not saying that it shouldn't be taught.  However, before decrying the 
lack of fundamental knowledge in current CS graduates, it's important to 
take these things into consideration.

Colleges are stuck with the unenviable task of ensuring that their 
graduates will be employable and proficient.  An employer (in the 
business community) doesn't much care if a programmer knows what object 
code is created from their source code.  They care that the programmer 
can program well *in the environment of that particular organization*.

As to the statement that students should learn that the computer will lie 
at every opportunity, be assured that this IS being taught.  Perhaps it's 
not being explained in terms of the actual machine language, but we're 
learning it.  Believe me.  (Actually, I think that that knowledge comes 
from hands-on programming experience, which we've all got to do.)

Side note: I'm glad that this is the first thread I picked up in 
c.l.c++.  Nice to see intelligent discourse on Usenet for once.  :)

--
Hal Haygood :: PC/Network/Unix technician, Suntek Integrated Technologies
hal@suncap.com  ::  deafen@asu.edu  ::  hagar@mail.hvs.com
My opinions and those of my employer rarely, if ever, coincide.

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

[Frank Manning]

In article <50fmsm$3o2@news.asu.edu> deafen@imap2.asu.edu writes:

> Computer science students entering college today face a dilemma.  While 
> we understand that the fundamentals (how the "transducer signal wends its 
> way...into the computer memory") are important, we need to keep up with 
> the state of the art, as well.

I see I haven't expressed myself very well. My fault.

I was questioning how *engineering* students were being educated about
computers -- aerospace and mechanical students, in particular, which I
should have mentioned. Obviously electrical & computer engineering
students are being taught about ADC's and stuff (at least I assume
they are).

I don't have any particular complaints about CS education per se. For
one thing, I don't know much about the CS curriculum, other than the
bits and pieces I pick up in cla from Mike Feldman et al.

I've seen many aero/mech research projects get bogged down in software
problems because neither the students nor professors -- with some
exceptions -- know much about software development. Examples:

   (1)  "Why should I put a program in more than one file? If I'm
	looking for something, I know it's either above or below the
	cursor."

   (2)  Professor writes GOSUB 5000 and expects everybody else on
	the team to know what that means.

   (3)  "Local variable? What's that?"

   (4)  Wind tunnel software written in HP Basic runs on machine
	that was new when Fred Flintstone was in diapers. Porting
	to somewhat newer PC in QuickBasic is nightmare.

   (5)  Computerized vehicle is field tested. PC with floppy
	drives is used as an embedded computer. Rather than store
	test data on floppies for later analysis, a printer is set
	up next to the test track. At the end of each run,
	professor drives to printer, plugs in printer and does
	screen dump.

> Those who have been in computing for twenty (or even ten) years have an 
> advantage over us; they've had the time to learn all of the fundamentals 
> and grow with the technology and paradigm shifts.  

Don't worry about it. You can replace the experienced boneheads I've
just alluded to. There are plenty of them around.

-- Frank Manning
-- Chair, AIAA-Tucson Section

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

[Steve Howard]

deafen@imap2.asu.edu wrote:
> 
> Computer science students entering college today face a dilemma.  While
> we understand that the fundamentals (how the "transducer signal wends its
> way...into the computer memory") are important, we need to keep up with
> the state of the art, as well.
> 

This is not unique to students. Those of us in the "business" have to do this as well. This is, in 
fact, true with almost any profession (law, medicine, etc.) The state of the art is constantly 
changing, and the most valuable professionals are those who know both how things are currently done and 
how the industry is progressing. This is one of the reasons that there are so many professional 
programming journals and magazines.

> Those who have been in computing for twenty (or even ten) years have an
> advantage over us; they've had the time to learn all of the fundamentals
> and grow with the technology and paradigm shifts.  We are faced with the
> daunting task of learning all of these things in a few years, rather than
> a decade or two.
> 

I don't think students have a unique claim to this, either. I believe that it was as hard for me to 
change from what I learned in college to what was done on my first job 10+ years ago than it will be 
for someone graduating today. The same will probably true 10 years hence for the kids graduating then.

> If I were to specialize in "how to write the software that controls all
> that stuff," I'd be left with no time at all to learn the more
> sophisticated things -- the MS Windows API, for example.
> 

Learning the Windows API may be important to get a specific job, but what if the only jobs available 
are for Unix or Mac developers. The basic concepts for programming a Unix GUI or the Mac GUI are 
essentially the same conceptually as Windows, but vastly different in the details. 

> I can't speak much for the academic or research communities.  However, if
> a programmer is going to be of much use at all to the business community,
> it's far more important *to the employer* that s/he know the current
> state of the art than the underlying foundation.
> 

Which state of the art would that be? Opearating system design for the newest parallel processor? Java 
development for Internet applications? C++ for Windows development? Assembly or Ada development for 
embedded microprocessor systems?

All of these tasks are going on today, as well as a million more. To teach all of these things to every 
student so that s/he could walk into a job and start right away would be impossible. All of these tasks 
share some common base of "fundamental" concepts. Teaching these fundamentals would allow a new hire to 
adapt to them quickly. Familiarity with the more specific concepts might be desireable, but IMHO the 
details will be out of date an hour after they are taught.

In addition, I suspect that much (most?) of the work out there in the computer field is somewhat 
distant from the state of the art. A lot of it is integrating data from existing systems with new 
systems.... maintaining legacy applications and code... adapting systems to new operating 
environments... etc.

> I'm not saying that it shouldn't be taught.  However, before decrying the
> lack of fundamental knowledge in current CS graduates, it's important to
> take these things into consideration.
> 
> Colleges are stuck with the unenviable task of ensuring that their
> graduates will be employable and proficient.  An employer (in the
> business community) doesn't much care if a programmer knows what object
> code is created from their source code.  They care that the programmer
> can program well *in the environment of that particular organization*.
> 

The problem as I see it is that the new stuff changes far too fast to teach. It is a moving target, and 
if the wrong "state of the art" is taught, you have a bunch of grads who lack both the fundamentals of 
software development, and lack training in the development methods currently in vogue. Teaching the 
fundamentals will rarely miss the mark, since it is the historical basis for all of the state of the 
art. 
-- 
E. Steve Howard                | Lockheed Martin
                               | Ocean, Radar, & Sensor Systems        
mailto:howard@mtm.syr.lmco.com | Syracuse, NY

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

[Bob Kitzberger]

deafen@imap2.asu.edu wrote:

: An employer (in the 
: business community) doesn't much care if a programmer knows what object 
: code is created from their source code.  They care that the programmer 
: can program well *in the environment of that particular organization*.

Not all companies have that point of view.  Around here, we assume
that a strength in the fundamentals, plus a proven above-the-rim
level of competence allows our developers to switch from today's
environment to tomorrows.  One thing that's certain in this industry
is rapid change.  If you spend all of your college years learning
the technology du jour, how can a company be assured that you can
quickly shift to tomorrow's technology?

: Side note: I'm glad that this is the first thread I picked up in 
: c.l.c++.  Nice to see intelligent discourse on Usenet for once.  :)

Clearly because it's cross-posted to comp.lang.ada :-)

--
Bob Kitzberger	      Rational Software Corporation       rlk@rational.com
http://www.rational.com http://www.rational.com/pst/products/testmate.html

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

[Tim Behrendsen]

deafen@imap2.asu.edu wrote in article <50fmsm$3o2@news.asu.edu>...
> Frank Manning (frank@bigdog.engr.arizona.edu) wrote:
>    [...]
> 
> : In my humble opinion, the solution to that problem is to teach the
> : students what actually goes on inside the computer, how a transducer
> : signal wends its way through an ADC into the computer memory, and how
to
> : write the software that controls all that stuff. Students also need to
> : understand that things can go wrong and the computer will tell you a
> : direct lie if it can possibly get away with it.
> 
> Frank, please allow me to speak from a student's point of view.  I'm a
> senior in CIS, so I'm not required to do any assembly coding.  (For that
> matter, I'm not required to learn much programming at all; I consider
> myself the "odd man out" because I actually enjoy doing it and learning
> about it.)
> 
> I do have a point.  Please be patient.  :)
> 
> Computer science students entering college today face a dilemma.  While 
> we understand that the fundamentals (how the "transducer signal wends its

> way...into the computer memory") are important, we need to keep up with 
> the state of the art, as well.
> 
> Those who have been in computing for twenty (or even ten) years have an 
> advantage over us; they've had the time to learn all of the fundamentals 
> and grow with the technology and paradigm shifts.  We are faced with the 
> daunting task of learning all of these things in a few years, rather than

> a decade or two.
> 
> If I were to specialize in "how to write the software that controls all 
> that stuff," I'd be left with no time at all to learn the more 
> sophisticated things -- the MS Windows API, for example.
>
> I can't speak much for the academic or research communities.  However, if

> a programmer is going to be of much use at all to the business community,

> it's far more important *to the employer* that s/he know the current 
> state of the art than the underlying foundation.

I think this is a sub-point of this thread; which is more
important, learning the general concepts of programming, or
learning specific knowledge such as the MS Windows API?

With all due respect, I have to tell you that you know almost
nothing that is useful to me as an employer.  What I mean by
that is you have smattering of this, and a smattering of that,
but all that pales compared to all the knowledge that you need
to be a truly useful asset.

When I hire new people, I look for the person that has the best
understanding of the fundamental concepts, because any specific
subject you will have learned (such as the Windows API) is so
shallow as to be useless.  I often say that "I would rather have
smart and ignorant, rather than stupid and knowledgeable."
 
> I'm not saying that it shouldn't be taught.  However, before decrying the

> lack of fundamental knowledge in current CS graduates, it's important to 
> take these things into consideration.
> 
> Colleges are stuck with the unenviable task of ensuring that their 
> graduates will be employable and proficient.  An employer (in the 
> business community) doesn't much care if a programmer knows what object 
> code is created from their source code.  They care that the programmer 
> can program well *in the environment of that particular organization*.

The problem is, the programmer can't program well.  They just
plain don't have enough experience from the toy projects in the
typical CS curriculum. The question, how well prepared are they to
learn new environments?  In other words, how well prepared are you
to "think like a programmer"?  Any API can be learned; the question
is, how good is your fundamental understanding of computer
programming so that you can have some perspective in order to
understand the API?

> As to the statement that students should learn that the computer will lie

> at every opportunity, be assured that this IS being taught.  Perhaps it's

> not being explained in terms of the actual machine language, but we're 
> learning it.  Believe me.  (Actually, I think that that knowledge comes 
> from hands-on programming experience, which we've all got to do.)

Are you...?  Not the students that I get.  The majority of the
ones that I get are not capable of taking a programming problem
that they've never seen before and coming up with an algorithm
for a solution.  In one hiring cycle I went through, I got 1 guy
out of 50 applicants that could do my testing process.  I hired
him, and the rest went elsewhere.

I'm not trying to downplay the value of your CS degree, but the
world of programming is far, far larger than the tunnel-visioned
view you've been given at school.

-- Tim Behrendsen (tim@airshields.com)

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

[Phil Barnett]

In article <50fmsm$3o2@news.asu.edu>, deafen@imap2.asu.edu says...

>I can't speak much for the academic or research communities.  However, if 
>a programmer is going to be of much use at all to the business community, 
>it's far more important *to the employer* that s/he know the current 
>state of the art than the underlying foundation.

This is a total crock. If you don't know the foundations, you will build 
shakey apps with your state of the art technology with completely good 
intentions. You have it exactly backwards.

If you know the foundations, you can create excellent, stable and robust code 
in ANY language. 

If you don't know the foundations, you will be beat to death by your 
mistakes or will build as many beautiful pieces of useless or wrong code as 
you will good ones.

>I'm not saying that it shouldn't be taught.  However, before decrying the 
>lack of fundamental knowledge in current CS graduates, it's important to 
>take these things into consideration.

No, after being in the business community for many years, I can tell you by 
experience that this is simply not the case.

>Colleges are stuck with the unenviable task of ensuring that their 
>graduates will be employable and proficient.  An employer (in the 
>business community) doesn't much care if a programmer knows what object 
>code is created from their source code.  They care that the programmer 
>can program well *in the environment of that particular organization*.

College graduates are seldom useful for the large organization until they 
have spent a few years learning how it all actually works. (of course, there 
are exceptions)

I work for a large multinational corporation with a huge IS department, and 
college graduates are not placed in the planning or management of projects 
until they have many years on the job. There is a reason for this. They do 
not know the foundations of THIS PARTICULAR business.

Only experience teaches what an employee needs to know to become valuable.

Foundations make the trip quicker.

Foundations allow you to know where the mistakes and errors lie without 
actually commiting them.

Foundations keep you from going down the wrong path in the first place.

State of the Art technology provides none of this. 

---
              Phil Barnett  mailto:philb@iag.net
                       WWW  http://www.iag.net/~philb/
                  FTP Site  ftp://ftp.iag.net/pub/clipper

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

[Tim Behrendsen]

Bengt Richter <bokr@accessone.com> wrote in article
<4vgs4p$evl@news.accessone.com>...
> "Tim Behrendsen" <tim@airshields.com> wrote:
> 
> >Lawrence Kirby <fred@genesis.demon.co.uk> wrote in article
> ><840288278snz@genesis.demon.co.uk>...
> >> 
> >> They might have a good feel for how to implement quicksort in that
> >> particular machine code however it would be so wrapped up in
> >> implementation details that they wouldn't have a good understanding of
> >> the algorithm itself, at last not in the same timescale.
> 
> >And they don't get wrapped up in implementation
> >details if they write it in C?  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.
> 	What if computers are totally irrelevant? If
> an algorithm is an abstract procedure for manipulating
> symbols, or accomplishing some mathematical purpose?
> Then any computerized implementation will just be an
> instance of a broad class of implementation possibilities.
> And assembler would be just one of a number of possible
> intermediate code representations in translating to
> an executable representation for a particular platform/
> OS environment.

So what?  Remember who we're talking about.  We're talking
about Joe Schmoe off the street in CS 101.  Are we going
to hit him full-bore with the entire universe of possible
computer architectures?  You have to start somewhere, and
you have to try and convey the procedural nature of the
computer in the simplest possible terms.

Also, manipulating symbols or mathematics are still
data transformations over time.

> 	If you are more fluent in assembler than in
> the native terms/notation of the original abstraction,
> then you may look at the assembler code and say, "Aha,
> that's what that meant," and be helped in understanding
> the original algorithm, ...if the latter was relatively
> trivial. But I don't think looking at assembler is a good
> way to understand system-level workings of things, even
> though it may help with a given primitive. Even C can
> be too low a level. How do you see object hierarchies in
> assembler? Or even C++ source code -- you need a way of
> seeing the woods as well as the trees. E.g., the important
> aspects of OpenGL are not the language it's been ported
> to, though you can be sure there are assembler-coded
> primitives supporting any given implementation. An annotated
> dataflow diagram supplemented with some equations etc. may
> be one of the best helps in arriving at understanding.
> A riveter sees the importance of rivets everywhere, but
> it's a limited view.

Indeed, all this is important ... later.  They are simply
not capable of understanding any of this completely until
they have grasped the procedural nature of the computer.

> >The most important thing a student can learn about
> >computers is the fundamentally simple nature.  The
> 	I think the "fundamentally simple nature" you
> are talking about is a simplified *view/abstraction* of an
> older-architecture computer. If you focus on small enough
> a detail, it becomes "simple," e.g., a bus transaction
> that moves a word from memory to cpu chip, but to keep it
> simple you may have to ignore caches, burst modes, split
> address/data transactions, multiple bus masters, etc. etc.
> not to mention multiple CPUs each with separate multiple
> execution units, pipelines, etc. Perhaps what is needed
> is a standard virtual machine for teaching purposes.

I agree.  I think I mentioned this a long time ago, but
it got lost in the noise.  I've suggested a 68000 or 6809
processor; nice orthogonal instruction set.  It's not that
I want everyone to learn assembler so they'll use it
everyday on the job, I want them to get a "feel" for
data movement/flow.

> >mystery of execution *must* be broken down in order for
> 	This mystery sounds suspiciously like step-step,
> i.e., a rule of sequential evaluation. I think a lot of these
> things benefit from being considered in the abstract (assuming
> one is comfortable in that domain). A nice book is "Anatomy
> of Lisp" by John Allen, (c) 1978 by McGraw-Hill, Inc.
> ISBN-0-07-001115-X. I don't think they'll mind if I quote a
> quotation the author put at the head of the preface:
> 
> 	"'... it is important not to lose sight of the fact that
> there is a difference between training and education. If computer
> science is a fundamental discipline, then university education in
> this field should emphasize enduring fundamental principles rather
> than transient current technology.'
> 	Peter Wegner, Three Computer Cultures"

EXACTLY!  I just think that we don't spend enough time on trying
to establish fundamental thinking skills, rather than
immediately jumping into the "grand abstractions".

> As true now as then, I think. A particular assembler for a particular
> CPU/OS environment is "transient current technology." A well-chosen
> VM might not be. An object-oriented implementation of an emulator
> for such a VM might be an interesting multi-perspective project...
> 
> >the student to being to think like a programmer.
> Of Smalltalk/LISP/CLOS or C++/Delphi or assembler/Fortran/C? ;-)
> >Once they can think like a programmer, all the rest
> >of the knowledge they learn becomes trivial.
> A terrifying prospect!
> After 70k+- hrs of OJT as programmer, I still run into
> stuff that seems non-trivial to me, thank goodness.
> But then I have been trying to get beyond my assembler origins ;-)
> 
> BTW, what about thinking like a mathematician ;-) Or a
> problem-solver? Or an artist?

What about them?  Take an artist: Thinking like an artist
means learning to see.  Reminds of when I learned to draw.
I was a hopeless failure, until I figure out that problem
wasn't with my hands, it was with the way I physically
looked at the world.

If we're talking about programming, then we are talking
about thinking in terms of data.
 
> If you are teaching programming, how much "transient current
> technology" is it worth while to teach, projecting trends to
> graduation time? Just enough to use it for lab work (education),
> or in depth as case studies exemplifying the principles you
> are trying to teach, or focused on a job market (training)?
> I don't think there is a one-size-fits-all answer.

I would say I would way rather have someone that can think
very well, with minimal knowledge, rather than some who
has merely memorized a large amount of knowledge, but
has no clue how to apply it.  The latter is by far the
norm based on my attempting to hire new graduates.

> If you want students to know about *computers*, why not
> teach them a little logical design and electronics?

Good! Yes!

> So they have an idea of how data actually moves around
> in that minitower. Hm. Should we leave caches out of it?
> ISA vs VLB vs PCI? VME as example of non-synchronous
> alternatives? Do they need to know how to write a BIOS?
> What does the power-on reset do to all those chips on
> all those boards that it reaches? Oh, and how about the
> OS? After all, we don't usually run an assembler on the
> bare metal. So, to have a decent concept of what really
> is going on, don't they have to know how an OS boots up
> and gets to the point where it's able to run a shell?
> And how that shell gets its input and interacts with OS
> services to allocate memory and load and start execution
> of the assembler, and how that's going to get your code
> from a file and translate it to object form in another file.
> How about the linker and that whole story? Should we be
> satisfied with knowing how this works in DOS as OS? "Puh-leez!"
> It's maybe a little much to go into both Unix and WinXX
> (and system 7?), so what to choose?

All of that notwithstanding, you have to start somewhere.
Why pick anything?  Maybe we should lock them in a room
away from all the distractions of reality, because we
might have to teach one thing at the expense of everything
else.

Bottom line, you pick a nice, simple architecture!  Heck,
CP/M on a Z80!

> Ok, when are they going to be ready to learn about continuations?
> Or meta-object protocol? Or unification? or Corba?
> What is helpful? What is a scenic detour?
> 
> IMHO, over-emphasis on the sequential-execution aspect of programming
> represented by assembler may well leave students so used to one view
> of the optical illusion that they cannot easily snap their mental
> image into another just-as-valid form. I.e., they may not "get"
> OO design very easily.

I think they will get it much easier, because they will be
able to see the simply nature of it.

-- Tim Behrendsen (tim@airshields.com)

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

[Larry J. Elmore]

Tim Behrendsen <tim@airshields.com> wrote in article
<01bb903e$bee0db80$87ee6fce@timpent.airshields.com>...
> Bengt Richter <bokr@accessone.com> wrote in article
> <4vgs4p$evl@news.accessone.com>...
> So what?  Remember who we're talking about.  We're talking
> about Joe Schmoe off the street in CS 101.  Are we going
> to hit him full-bore with the entire universe of possible
> computer architectures?  You have to start somewhere, and
> you have to try and convey the procedural nature of the
> computer in the simplest possible terms.
 
Speaking as a sophomore in the CS program at Montana State University, I
must agree most wholeheartedly with Tim. The program here starts out
teaching simple program design in a generic PDL with a lab in C, Fortran or
Ada. The rest of the program is mostly Ada 83, though Ada 95 is coming Real
Soon Now. Most of the students with little prior experience with computers
beyond playing games and using a word processor appear to have very little
understanding of what they are actually doing. It seems a lot like learning
English without learning English grammar. Yes, you can write fairly
decently, but you'll never really command the language or communicate as
clearly as someone who does understand the grammar.

While I'm only a sophomore in college, I've been learning about and
programming computers since 1981 on my own, starting with a TRS-80 Model I
with 48k RAM and Basic. I've taken a handful of college classes before I
started college "for real" this time, things like basic EE, digital logic,
Fortran, plus a 6-month electronics tech school in the Air Force. I don't
think there's any substitute for learning what's "really happening" in the
machine at an early stage.
 
> > trivial. But I don't think looking at assembler is a good
> > way to understand system-level workings of things, even
> > though it may help with a given primitive. Even C can
> > be too low a level. How do you see object hierarchies in
> > assembler? Or even C++ source code -- you need a way of
> > seeing the woods as well as the trees.

> Indeed, all this is important ... later.  They are simply
> not capable of understanding any of this completely until
> they have grasped the procedural nature of the computer.

Absolutely correct! One can't put up a building without a proper
foundation...

> > execution units, pipelines, etc. Perhaps what is needed
> > is a standard virtual machine for teaching purposes.
> 
> I agree.  I think I mentioned this a long time ago, but
> it got lost in the noise.  I've suggested a 68000 or 6809
> processor; nice orthogonal instruction set.  It's not that
> I want everyone to learn assembler so they'll use it
> everyday on the job, I want them to get a "feel" for
> data movement/flow.

Yes, definitely use a simple machine! The other stuff (caches, virtual
memory, pipelines, superscalar or parallel processors) can all be taught
later! It can also be used to illustrate the history of computer design as
all these features were developed decades ago for mainframes and now are
being used by microprocessors.

> Bottom line, you pick a nice, simple architecture!  Heck,
> CP/M on a Z80!

That's what I learned on, and it's quite good for learning the basics.
Especially why Intel processors have the architecture they do now. Also
teach 6809 to compare another simple, but very different architecture. (And
a much more elegant one, in my opinion. I really liked the 6809 (and OS/9)
in the Tandy Color Computer way back when). This is a great way to
demonstrate simple operating systems, and how programs make calls to them.
I strongly believe such a basic beginning is vital to really understanding
what one is doing, even if you never actually use it again. There's more
than a few students in CS here that _don't_ understand exactly what it is
they're doing or why... Going immediately on to OO will just confuse them
more, and unnecessarily, IMHO.

Larry Elmore
ljelmore@montana.campus.mci.net

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

[Stephen M O'Shaughnessy]

c6c01780$87ee6fce@timpent.airshields.com> <4uaqqg$203@mulga.cs.mu.OZ.AU> <01bb84b4$75304ce0$87ee6fce@timpent.airshields.com>
MIME-Version: 1.0

In article <01bb84b4$75304ce0$87ee6fce@timpent.airshields.com>, 
tim@airshields.com says...
>
>
>Easily learned. Later. More important to understand the
>procedural nature of the computer at first.
>
I view my computer(s) more as a standard tool to solve problems.  Like the drill
in my garage.  I don't need to know the voltage and current rating of an electric
drill to use it,  BECAUSE most house wiring is standardized and the drill is
designed to work with house wiring.  The same can be said of HLLs, they
standardize away (abstract) the details of the computer that I do not need
to be concerned with.  This is not to say these details are not important.  When
my drill starts tripping circuit breakers I have a problem that needs to be 
solved. 

My point is that I take exception to the Tim's claim that we need to learn the
computer "first".

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

[Tim Behrendsen]

Stephen M O'Shaughnessy <smosha@most.fw.hac.com> wrote in article
<Dvtnon.I49@most.fw.hac.com>...
> c6c01780$87ee6fce@timpent.airshields.com> <4uaqqg$203@mulga.cs.mu.OZ.AU>
<01bb84b4$75304ce0$87ee6fce@timpent.airshields.com>
> MIME-Version: 1.0
> 
> In article <01bb84b4$75304ce0$87ee6fce@timpent.airshields.com>, 
> tim@airshields.com says...
> >
> >
> >Easily learned. Later. More important to understand the
> >procedural nature of the computer at first.
> >
> I view my computer(s) more as a standard tool to solve problems.  Like
the drill
> in my garage.  I don't need to know the voltage and current rating of an
electric
> drill to use it,  BECAUSE most house wiring is standardized and the drill
is
> designed to work with house wiring.  The same can be said of HLLs, they
> standardize away (abstract) the details of the computer that I do not
need
> to be concerned with.  This is not to say these details are not
important.  When
> my drill starts tripping circuit breakers I have a problem that needs to
be 
> solved. 
> 
> My point is that I take exception to the Tim's claim that we need to
learn the
> computer "first".

I think a more correct analogy is the current and voltage
are the underlying hardware, and the tools are assembly.
HLLs are like prefab walls you slap together to build the
house.  Now, you can build a lot of houses that way, and
they will be generally be built well.  But if you want to
understand how houses are put together, you have to go to the
fundamental tools, with an understanding of structural
dynamics.

-- Tim Behrendsen (tim@airshields.com)

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

[Stephen M O'Shaughnessy]

In article <01bb85af$e83cf2a0$32ee6fce@timhome2>, tim@airshields.com says...

>I think a more correct analogy is the current and voltage
>are the underlying hardware, and the tools are assembly.
>HLLs are like prefab walls you slap together to build the
>house.  Now, you can build a lot of houses that way, and
>they will be generally be built well.  But if you want to
>understand how houses are put together, you have to go to the
>fundamental tools, with an understanding of structural
>dynamics.
>
>-- Tim Behrendsen (tim@airshields.com)

I still have trouble with your definition of assembly.  An assembly language
is just the one for one translation of the machine code.  For the 8051

mov 90h,#0ffh is the machine code 75 90 FF

This is directly voltages existing in the hardware (bits).  In this sense
assembly is the hardware.  My position is that I don't need to know 
hardware specifics to learn algorithms and programming.  Certainly I don't
need that understanding FIRST.  And my boss, customer, 
or whomever, does not care about my understanding as long as I can 
deliver a well built product.  Which, as you pointed out above, I can do.

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

[Tim Behrendsen]

Stephen M O'Shaughnessy <smosha@most.fw.hac.com> wrote in article
<DvvG3E.3sy@most.fw.hac.com>...
> In article <01bb85af$e83cf2a0$32ee6fce@timhome2>, tim@airshields.com
says...
> 
> >I think a more correct analogy is the current and voltage
> >are the underlying hardware, and the tools are assembly.
> >HLLs are like prefab walls you slap together to build the
> >house.  Now, you can build a lot of houses that way, and
> >they will be generally be built well.  But if you want to
> >understand how houses are put together, you have to go to the
> >fundamental tools, with an understanding of structural
> >dynamics.
> >
> >-- Tim Behrendsen (tim@airshields.com)
> 
> I still have trouble with your definition of assembly.  An assembly
language
> is just the one for one translation of the machine code.  For the 8051
> 
> mov 90h,#0ffh is the machine code 75 90 FF
> 
> This is directly voltages existing in the hardware (bits).  In this sense
> assembly is the hardware.  My position is that I don't need to know 
> hardware specifics to learn algorithms and programming.  Certainly I
don't
> need that understanding FIRST.  And my boss, customer, 
> or whomever, does not care about my understanding as long as I can 
> deliver a well built product.  Which, as you pointed out above, I can do.

It's not a question of whether you "need to know" assembly to
learn, it's a question of what's best.  In my experience, CS
students are being graduated without the necessary skills to build
"well built products".  We have the world you're describing,
and it's not working.  CS graduates quite simply are not being
taught to think like programmers, that is, in an efficient
procedural way.

-- Tim Behrendsen (tim@airshields.com)

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

[Szu-Wen Huang]

Tim Behrendsen (tim@airshields.com) wrote:
: Fergus Henderson <fjh@mundook.cs.mu.OZ.AU> wrote in article
: <4u5a11$siv@mulga.cs.mu.OZ.AU>...

: > That's not a realistic thought experiment.  Teaching abstraction,
: > data structures, etc. is easier in a higher level language,
: > and so it is unlikely that Jane will have managed to complete
: > the same curriculum that John can, given the handicap of using
: > a low-level language.

: This seems to be a common theme; that programming things in
: assembly in necessarily harder than programming in a HLL.

It is, in general.

: 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.

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.

: Now, you wouldn't want to *maintain* large systems of assembly,
: which is why HLLs have taken over the world, but it seems to
: me that assembly per se is just not that hard to use.

It's not hard to use.  It just hampers the *goal* by dumping the
students with more things to learn needlessly.

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

[Tim Behrendsen]

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.
> 
> 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.

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.

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.

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

-- Tim Behrendsen (tim@airshields.com)

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

[Peter Seebach]

In article <01bb83ad$29c3cfa0$87ee6fce@timpent.airshields.com>,
Tim Behrendsen <tim@airshields.com> wrote:
>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.

These are fundementally abstract operations.  Generalization is the core of
algorithm design; you must abstract what the problem is, what a solution looks
like, and what their relationship is.  Logic is entirely an abstract beast.

>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.

The entire concept of a solution to a problem, rather than the answer to a
question, is a matter of abstraction.

>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.

But the training wheels protect them, not from the problem, but from the
implementation.

Consider string searching.

An *algorithm* for searching strings has nothing to do with whether you can
use a postdecrement or postincrement addressing mode.

An assembly program for doing so may well *have to* consider these issues.

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

What we're doing now is exactly what we do in every other field; we give them
lists of desired answers.  Most math programs would be just as bad if math
were as high paying and easy to get a job in as CS.

I've seen *very* few good teachers in any field, especially ones which require
abstraction.

The problem I've seen is that students think too much about how to implement,
and not enough about the abstract design.  I have this problem, even.  I spend
way too much time, during designs, thinking about what the data type will need
to look like, rather than what it will need to be able to do.  This frequently
turns into extra time about halfway through the implementation, because I
didn't think enough about the *abstract* part of the problem.

I haven't even thought about memory layouts, and I'm *still* too specific and
not abstract enough.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

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

[Tim Behrendsen]

Peter Seebach <seebs@solutions.solon.com> wrote in article
<4u89c4$p7p@solutions.solon.com>...
> In article <01bb83ad$29c3cfa0$87ee6fce@timpent.airshields.com>,
> Tim Behrendsen <tim@airshields.com> wrote:
> >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.
> 
> These are fundementally abstract operations.  Generalization is the core
of
> algorithm design; you must abstract what the problem is, what a solution
looks
> like, and what their relationship is.  Logic is entirely an abstract
beast.
> 
> >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.
> 
> The entire concept of a solution to a problem, rather than the answer to
a
> question, is a matter of abstraction.

I agree; my point is that I think the student learns more if they
are thinking purely in terms of fundamental operations (which are
still abstractions above the raw hardware components), rather
than layers and layers of syntax that hide the essential essence
of what the computer is doing.

The people I saw could quote me book definitions of C syntax.  But
they had very little knowledge of what it really meant, and how
to use it.

If programming is reduced to fundamentals of move, arithmetic,
test, branch, etc it prevents the student from leaning on the
abstraction rather than truly understanding the solution to the
problem.  In other words, if they can express it in the above
terms, you *know* they understand the solution.
 
> >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.
> 
> But the training wheels protect them, not from the problem, but from the
> implementation.
> 
> Consider string searching.
> 
> An *algorithm* for searching strings has nothing to do with whether you
can
> use a postdecrement or postincrement addressing mode.
> 
> An assembly program for doing so may well *have to* consider these
issues.

True; there is assembly syntax that could be considered irrelevent
to the central issues.  I really don't see that as a big problem
compared to the much larger problem of the brain-damaged students
that are asking me for jobs.

Perhaps the solution is a middle ground one; rather than "real"
assembly for students, maybe what they need is a "MIX" kind of
thing where it is reduced to fundamental elements, an assembly
abstraction if you will.  That way, "dangerous" concepts such
as post-increment, etc. can be safely hidden away, but we can
still give allow them to think in pure data manipulation terms.
 
> >Whatever were doing now is *not working*, let me tell you.
> 
> What we're doing now is exactly what we do in every other field; we give
them
> lists of desired answers.  Most math programs would be just as bad if
math
> were as high paying and easy to get a job in as CS.
> 
> I've seen *very* few good teachers in any field, especially ones which
require
> abstraction.
> 
> The problem I've seen is that students think too much about how to
implement,
> and not enough about the abstract design.  I have this problem, even.  I
spend
> way too much time, during designs, thinking about what the data type will
need
> to look like, rather than what it will need to be able to do.  This
frequently
> turns into extra time about halfway through the implementation, because I
> didn't think enough about the *abstract* part of the problem.
> 
> I haven't even thought about memory layouts, and I'm *still* too specific
and
> not abstract enough.

The problem is that we *can't* think purely abstractly,
otherwise we end up with slow crap code.  It is simply not
possible to ignore the way code is structured, and completely
depend on the compiler to save us.  That is just not the
real world.

At least not my world, where I have to pack as many users
as possible onto one CPU.

-- Tim Behrendsen (tim@airshields.com)

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

[Dan Pop]

In <01bb83f5$923391e0$87ee6fce@timpent.airshields.com> "Tim Behrendsen" <tim@airshields.com> writes:

>The problem is that we *can't* think purely abstractly,
>otherwise we end up with slow crap code.

Care to provide some concrete examples?

>It is simply not
>possible to ignore the way code is structured, and completely
>depend on the compiler to save us.

This doesn't make any sense to me.  Could you be a little bit more
explicit?

The compiler definitely won't save my ass if I choose to use bubblesort
instead of quicksort on a large dataset, but the selection between the
two algorithms is made based on an abstraction (algorithm analysis) not
on how the compiler generates code for one or another.  It's very likely
that quicksort will be better, no matter the compiler and the underlying 
platform.

Once you put micro-optimizations based on knowledge about the
compiler and/or hardware into the code, you impair both the 
readability/maintainability/portability of the code and the opportunities
of another compiler, on another platform, to generate optimal code.
There are situations when this _has_ to be done, but they are isolated
exceptions, not the norm.

Dan
--
Dan Pop
CERN, CN Division
Email: Dan.Pop@cern.ch 
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland

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

[Christopher R Volpe]

Dan Pop wrote:
> 
> In <01bb83f5$923391e0$87ee6fce@timpent.airshields.com> "Tim Behrendsen" <tim@airshields.com> writes:
> 
> >The problem is that we *can't* think purely abstractly,
> >otherwise we end up with slow crap code.
> 
> Care to provide some concrete examples?

I'll give ya one: Michael Laszlo's implementation of the Bentley and
Ottmann plane sweep line intersection algorithm in "Computational
Geometry and Computer Graphics in C++". Very well designed code, in
terms of abstract data structures. Nice O(n log n) algorithm. Looks like
a work of art. Runs a hundred times as slow as a brute-force O(n^2)
algorithm, except when the dataset is a bit on the large side, in which
case it dies after exhausting the virtual memory of my Sparc 20.

--

Chris Volpe			Phone: (518) 387-7766 
GE Corporate R&D		Fax:   (518) 387-6560
PO Box 8 			Email: volpecr@crd.ge.com
Schenectady, NY 12301		Web:   http://www.crd.ge.com/~volpecr

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

[Tim Behrendsen]

Dan Pop <Dan.Pop@cern.ch> wrote in article
<danpop.839450672@news.cern.ch>...
> In <01bb83f5$923391e0$87ee6fce@timpent.airshields.com> "Tim Behrendsen"
<tim@airshields.com> writes:
> 
> >The problem is that we *can't* think purely abstractly,
> >otherwise we end up with slow crap code.
> 
> Care to provide some concrete examples?

Look at the code-bloated and slow-software world we live in,
particularly on desktop platforms.  I think this is caused by
people not truly understanding what's *really* going on.

For example, look at OOP.  Very naive implementations of OOP
used a huge amount of dynamic memory allocation, which can cause
severe performance problems.  That's why I don't use C++ for my
products; to do it right you have to do a very careful analysis
of how your classes are going fit together efficiently.

I've spoken to enough people that have had C++ disasters to
convince me that the more abstraction there is, the more
danger there is of inefficient code.  This shouldn't be that
hard to believe; any time you abstract away details you are
giving up knowledge of what is going to be efficient.

I alluded to this in another post, but a good example is Motif
and X11.  A programmer who only understands Motif, but does not
understand X11 is going to write slow crap, period.

> >It is simply not
> >possible to ignore the way code is structured, and completely
> >depend on the compiler to save us.
> 
> This doesn't make any sense to me.  Could you be a little bit more
> explicit?
> 
> The compiler definitely won't save my ass if I choose to use bubblesort
> instead of quicksort on a large dataset, but the selection between the
> two algorithms is made based on an abstraction (algorithm analysis) not
> on how the compiler generates code for one or another.  It's very likely
> that quicksort will be better, no matter the compiler and the underlying 
> platform.
> 
> Once you put micro-optimizations based on knowledge about the
> compiler and/or hardware into the code, you impair both the 
> readability/maintainability/portability of the code and the opportunities
> of another compiler, on another platform, to generate optimal code.
> There are situations when this _has_ to be done, but they are isolated
> exceptions, not the norm.

I gave this example in another post, but nobody responded.  I think
it was too good. :-)  I'll try again ...

I can prove that your statement is wrong.

Let's say I have the perfect optimizer that takes C code and
provides the absolute most efficient translation possible.  Given
that's the case, it won't improve an O(n) algorithm to an O(n^2)
algorithm.

Now, that should mean that I can order my C code into any
algorithmically valid sequence and end up with exactly the same
running time, because the optimizer is always perfect.

Now, we know that this does not reflect the real world.  The
question is, how does a programmer learn the efficient
implementations that the optimizer can deal with effectively
from the boneheaded ones?

Here's an example:

int a[50000],b[50000],c[50000],d[50000],e[50000];

void test1()
{
    int i, j;
    for (j = 0; j < 10; ++j) {
        for (i = 0; i < 50000; ++i) {
            ++a[i]; ++b[i]; ++c[i]; ++d[i]; ++e[i];
        }
    }
}

void test2()
{
    int i, j;
    for (j = 0; j < 10; ++j) {
        for (i = 0; i < 50000; ++i) ++a[i];
        for (i = 0; i < 50000; ++i) ++b[i];
        for (i = 0; i < 50000; ++i) ++c[i];
        for (i = 0; i < 50000; ++i) ++d[i];
        for (i = 0; i < 50000; ++i) ++e[i];
    }
}

On my AIX system, test1 runs in 2.47 seconds, and test2
runs in 1.95 seconds using maximum optimization (-O3).  The
reason I knew the second would be faster is because I know
to limit the amount of context information the optimizer has
to deal with in the inner loops, and I know to keep memory
localized.

Now I submit that if I showed the average C programmer
both programs, they would guess that test1 is faster because
it has "less code", and that is where abstraction,
ignorance, and niavete begin to hurt.

-- Tim Behrendsen (tim@airshields.com)

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

[Peter Seebach]

In article <01bb8534$b2718bc0$87ee6fce@timpent.airshields.com>,
Tim Behrendsen <tim@airshields.com> wrote:
>Look at the code-bloated and slow-software world we live in,
>particularly on desktop platforms.  I think this is caused by
>people not truly understanding what's *really* going on.

I believe it's caused by people who have a poor understanding of what
they're trying to do.

>I've spoken to enough people that have had C++ disasters to
>convince me that the more abstraction there is, the more
>danger there is of inefficient code.  This shouldn't be that
>hard to believe; any time you abstract away details you are
>giving up knowledge of what is going to be efficient.

Abstraction itself is an intentional inefficiency in most cases.  A
function which writes to files on disks *or* to terminal devices is
*guaranteed* to take at least one more test than a simpler function
which handles only one.

>I alluded to this in another post, but a good example is Motif
>and X11.  A programmer who only understands Motif, but does not
>understand X11 is going to write slow crap, period.

No, a programmer who uses Motif at all is likely to generate slow programs,
because there are too many layers involved, and I'm not sure either X *or*
Motif is a good model.

>Now, we know that this does not reflect the real world.  The
>question is, how does a programmer learn the efficient
>implementations that the optimizer can deal with effectively
>from the boneheaded ones?

A programmer does this, *IF IT BECOMES NECESSARY*, by experimenting.

>Here's an example:

>int a[50000],b[50000],c[50000],d[50000],e[50000];

This is not a strictly conforming C program.

>void test1()
>{
>    int i, j;
>    for (j = 0; j < 10; ++j) {
>        for (i = 0; i < 50000; ++i) {
>            ++a[i]; ++b[i]; ++c[i]; ++d[i]; ++e[i];
>        }
>    }
>}

>void test2()
>{
>    int i, j;
>    for (j = 0; j < 10; ++j) {
>        for (i = 0; i < 50000; ++i) ++a[i];
>        for (i = 0; i < 50000; ++i) ++b[i];
>        for (i = 0; i < 50000; ++i) ++c[i];
>        for (i = 0; i < 50000; ++i) ++d[i];
>        for (i = 0; i < 50000; ++i) ++e[i];
>    }
>}

>On my AIX system, test1 runs in 2.47 seconds, and test2
>runs in 1.95 seconds using maximum optimization (-O3).  The
>reason I knew the second would be faster is because I know
>to limit the amount of context information the optimizer has
>to deal with in the inner loops, and I know to keep memory
>localized.

>Now I submit that if I showed the average C programmer
>both programs, they would guess that test1 is faster because
>it has "less code", and that is where abstraction,
>ignorance, and niavete begin to hurt.

I am unconvinced that this example is remotely relevant to the general case.

In particular, in the real world, would you rather maintain code more like
the first or the second?  I'd prefer to maintain the first; it would be
easier to change all occurances of 50000, if this needed to be done.

Abstraction is a trade-off of maintainability and readability vs. code
speed.

I would not expect test1 to be faster.  I would write it anyway, because
I would not expect it to be much slower.  If, *and only if*, there turned
out to be a performance problem, I'd probably start by unrolling the loop
in test1, possibly getting a much greater performance increase.

The cool thing is, I can unroll the loop in test1 much faster than you can
unroll all the loops in test2.  Further, it is obvious in test1 that the
intent is to do the same thing to each array.

The problem with most slow code is not microoptimizations like this; it's vast
inefficiencies at the basic design level.

If I could arrange to need only one of those five arrays, I bet my code would
be faster than yours, no matter *how* much you optimized it.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

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

[Randy Kaelber]

Peter Seebach (seebs@solutions.solon.com) wrote:
> In article <01bb8534$b2718bc0$87ee6fce@timpent.airshields.com>,
> Tim Behrendsen <tim@airshields.com> wrote:

> In particular, in the real world, would you rather maintain code more like
> the first or the second?  I'd prefer to maintain the first; it would be
> easier to change all occurances of 50000, if this needed to be done.

I'd prefer the second, myself, but first, I'd put in:

#define ARRAY_SIZE 50000

and replace all occurences of 50000 with it. Then, you only have to 
change the 50000 once. :)
--
Randy Kaelber:  kaelbers@muohio.edu
DARS Programmer/Analyst, Miami University, Oxford, OH 45056 USA
http://avian.dars.muohio.edu/~kaelbers/

Unsolicited commercial E-mail will be spell checked for a fee of $50.
Sending such mail constitutes acceptance of these terms. 

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

[Chris Sonnack]

Peter Seebach (seebs@solutions.solon.com) wrote:

>> Look at the code-bloated and slow-software world we live in,
>> particularly on desktop platforms.  I think this is caused by
>> people not truly understanding what's *really* going on.
>
> I believe it's caused by people who have a poor understanding of what
> they're trying to do.

Or more likely, both.

>> void test1() {
>>    int i, j;
>>    for (j = 0; j < 10; ++j) {
>>        for (i = 0; i < 50000; ++i) {
>>            ++a[i]; ++b[i]; ++c[i]; ++d[i]; ++e[i];
>>        }
>>    }
>> }
>>void test2() {
>>    int i, j;
>>    for (j = 0; j < 10; ++j) {
>>        for (i = 0; i < 50000; ++i) ++a[i];
>>        for (i = 0; i < 50000; ++i) ++b[i];
>>        for (i = 0; i < 50000; ++i) ++c[i];
>>        for (i = 0; i < 50000; ++i) ++d[i];
>>        for (i = 0; i < 50000; ++i) ++e[i];
>>    }
>> }
>> On my AIX system, test1 runs in 2.47 seconds, and test2
>> runs in 1.95 seconds using maximum optimization (-O3).
>
> I am unconvinced that this example is remotely relevant to the general
> case.

Probably not, but the real world does contain specific cases like this.
I really don't understand the resistance to the idea that programmers
should understand AS MUCH AS POSSIBLE about their craft. I really don't.

It's like an auto mechanic who doesn't want to know as much as possible
about how car engines work. Which mechanic would you rather hire; one
who knows the high-level stuff and can do MOST types of work, or one
who can build an engine from scrap metal?

If you (generic you) don't want to learn about the metal, fine. That
means I can get hired over you when the job entails embedded programming
or device drivers or a lot of other tasks fully rounded programmers may
face.

Do I like assembly? Hell, no. Am I fully capable of being hired for a
job that requires its use? Hell, yes.

> In particular, in the real world, would you rather maintain code more like
> the first or the second?  I'd prefer to maintain the first; it would be
> easier to change all occurances of 50000, if this needed to be done.

They're both pretty clear. And any real programmer knows rule #27: "There
should be no constants in your code except the numbers 1 and 0, and you
should view those with suspicion." A real programmer would use a #define
for the 50000, so changing it would be easy in either event.

> Abstraction is a trade-off of maintainability and readability vs. code
> speed.

The above example has little to do with abstraction either way. The more
general case would be, how does one code large loop constructs. This is
one case where understanding the underlying concepts does help.

> If, *and only if*, there turned out to be a performance problem, I'd
> probably start by unrolling the loop in test1, possibly getting a
> much greater performance increase.

I'm not sure unfolding a ten-fold iteration would do much. Ten times a
really tiny bit is still a pretty tiny bit. The key here is that a
programmer who already understands BOTH the high- and the low-level
would naturally write it the "right" way first. In the real world, doing
it right the first time counts for a lot.

> Further, it is obvious in test1 that the intent is to do the same thing
> to each array.

As written, it's obvious in both cases.

> The problem with most slow code is not microoptimizations like this; it's
> vast inefficiencies at the basic design level.

Absolutely.

--
Chris Sonnack  <cjsonnack@mmm.com>                  http://eishcq.mmm.com
Engineering Information Services/Information Technology/3M, St.Paul, Minn
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It takes a long time to understand nothing.

Opinions expressed herein are my own and may not represent those of my employer.

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

[Tim Behrendsen]

Chris Sonnack <cjsonnack@mmm.com> wrote in article
<4ug5u5$kha@dawn.mmm.com>...

> They're both pretty clear. And any real programmer knows rule #27: "There
> should be no constants in your code except the numbers 1 and 0, and you
> should view those with suspicion."

I would say, "There should be no constants in your code except 0.  Tests
should be less than, equal, greater than, or not equal 0.  Otherwise,
it better involve a symbol."

-- Tim Behrendsen (tim@airshields.com)

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

[Chris Sonnack]

Tim Behrendsen (tim@airshields.com) wrote:
> Chris Sonnack <cjsonnack@mmm.com> wrote in article
>
>> They're both pretty clear. And any real programmer knows rule #27: "There
>> should be no constants in your code except the numbers 1 and 0, and you
>> should view those with suspicion."
>
> I would say, "There should be no constants in your code except 0.  Tests
> should be less than, equal, greater than, or not equal 0.  Otherwise,
> it better involve a symbol."

Some languages don't have increment/decrement operators, hence:

    foo = foo + 1

--
Chris Sonnack  <cjsonnack@mmm.com>                  http://eishcq.mmm.com
Engineering Information Services/Information Technology/3M, St.Paul, Minn
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TODAY'S RULE: No Smoffing or Fnargling!

Opinions expressed herein are my own and may not represent those of my employer.

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

[Dan Pop]

In <01bb86f6$d92cf6a0$32ee6fce@timhome2> "Tim Behrendsen" <tim@airshields.com> writes:

>Chris Sonnack <cjsonnack@mmm.com> wrote in article
><4ug5u5$kha@dawn.mmm.com>...
>
>> They're both pretty clear. And any real programmer knows rule #27: "There
>> should be no constants in your code except the numbers 1 and 0, and you
>> should view those with suspicion."
>
>I would say, "There should be no constants in your code except 0.  Tests
>should be less than, equal, greater than, or not equal 0.  Otherwise,
>it better involve a symbol."

This is ludicrous.  When coding a binary search, NO symbol will be better
than the constant 2.  Ditto for the constant 10 when doing binary to 
decimal conversions.  And the list could go on and on.

The rule is: "there should be no _arbitrary_ constants in your code,
with no exceptions".

Dan
--
Dan Pop
CERN, CN Division
Email: Dan.Pop@cern.ch 
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland

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

[Tim Behrendsen]

Dan Pop <Dan.Pop@cern.ch> wrote in article
<danpop.839791373@news.cern.ch>...
> In <01bb86f6$d92cf6a0$32ee6fce@timhome2> "Tim Behrendsen"
<tim@airshields.com> writes:
> 
> >Chris Sonnack <cjsonnack@mmm.com> wrote in article
> ><4ug5u5$kha@dawn.mmm.com>...
> >
> >> They're both pretty clear. And any real programmer knows rule #27:
"There
> >> should be no constants in your code except the numbers 1 and 0, and
you
> >> should view those with suspicion."
> >
> >I would say, "There should be no constants in your code except 0.  Tests
> >should be less than, equal, greater than, or not equal 0.  Otherwise,
> >it better involve a symbol."
> 
> This is ludicrous.  When coding a binary search, NO symbol will be better
> than the constant 2.  Ditto for the constant 10 when doing binary to 
> decimal conversions.  And the list could go on and on.
> 
> The rule is: "there should be no _arbitrary_ constants in your code,
> with no exceptions".

That's a good point; "natural" constants would be an exception.
I was mostly thinking in terms of testing return values.

-- Tim Behrendsen (tim@airshields.com)

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

[Chris Sonnack]

Dan Pop (Dan.Pop@cern.ch) wrote:

>>> They're both pretty clear. And any real programmer knows rule #27: "There
>>> should be no constants in your code except the numbers 1 and 0, and you
>>> should view those with suspicion."
>>
>> I would say, "There should be no constants in your code except 0.  Tests
>> should be less than, equal, greater than, or not equal 0.  Otherwise,
>> it better involve a symbol."
>
> This is ludicrous.  When coding a binary search, NO symbol will be better
> than the constant 2.  Ditto for the constant 10 when doing binary to 
> decimal conversions.  And the list could go on and on.

Absolutely! (Although generally binary searches don't need to divide by
2 so much as shift right one bit.) Like most "rules", there's always
exceptions. But it's still a very good rule (of thumb).

--
Chris Sonnack  <cjsonnack@mmm.com>                  http://eishcq.mmm.com
Engineering Information Services/Information Technology/3M, St.Paul, Minn
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
An intellectual is someone whose mind watches itself

Opinions expressed herein are my own and may not represent those of my employer.

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

[Bob Hoffmann]

Chris Sonnack wrote:
> 
> Dan Pop (Dan.Pop@cern.ch) wrote:
> 
> >>> They're both pretty clear. And any real programmer knows rule #27: "There
> >>> should be no constants in your code except the numbers 1 and 0, and you
> >>> should view those with suspicion."
> >>
> >> I would say, "There should be no constants in your code except 0.  Tests
> >> should be less than, equal, greater than, or not equal 0.  Otherwise,
> >> it better involve a symbol."
> >
> > This is ludicrous.  When coding a binary search, NO symbol will be better
> > than the constant 2.  Ditto for the constant 10 when doing binary to
> > decimal conversions.  And the list could go on and on.
> 
> Absolutely! (Although generally binary searches don't need to divide by
> 2 so much as shift right one bit.) Like most "rules", there's always
> exceptions. But it's still a very good rule (of thumb).
> 
> --
> Chris Sonnack  <cjsonnack@mmm.com>                  http://eishcq.mmm.com
> Engineering Information Services/Information Technology/3M, St.Paul, Minn
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> An intellectual is someone whose mind watches itself
> 
> Opinions expressed herein are my own and may not represent those of my employer.


If you really want to start from scratch, and then ALL LANGUAGES ARE 
EASY AFTER THAT, get an old HP-41C programmable calculator and do some 
"synthetic programming" (something I pioneered with W.C.Wickes and 
others).  

That is the best ! .

All other languages are for kids.

BobX

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

[J. Blustein]

In article <4ud81d$5ii@solutions.solon.com>,
Peter Seebach <seebs@solon.com> wrote:
>Abstraction is a trade-off of maintainability and readability vs. code
>speed.
    Can we say that we should be concerned with issues of effectiveness
instead of efficency?  I know that, as programmers, we pursuing elegance
and that an important part of that is efficency, but it is not the most
important aspect.  Finally, there are outside concerns such as deadlines.

>If I could arrange to need only one of those five arrays, I bet my code would
>be faster than yours, no matter *how* much you optimized it.

    I really didn't want to get dragged into this discussion, but I very
much wanted to make that one point.  It has been made before, but I found 
that referring to effectiveness made the point clearer for me.
-- 
J. Blustein   http://www.csd.uwo.ca/~jamie/.Refs/C-refs.html  <jamie@csd.uwo.ca>

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

[Peter Seebach]

In article <4ufbmd$2e0@falcon.ccs.uwo.ca>,
J. Blustein <jamie@csd.uwo.ca> wrote:
>    Can we say that we should be concerned with issues of effectiveness
>instead of efficency?  I know that, as programmers, we pursuing elegance
>and that an important part of that is efficency, but it is not the most
>important aspect.  Finally, there are outside concerns such as deadlines.

That's an interesting way of approaching it.  Certainly, for any given real
world task, a slow solution is likely to be better than none at all.  One of
the weaknesses of assembly is that it adapts poorly to sudden changes in
requirements.  Even the best written 80x86 assembly program will take a lot of
porting effort to run on an Alpha - more than all but the worst C programs.

In the end, you have to know what your requirements are, including long-term
maintenance, speed, reliability, and due date.  There will often be more than
one way to meet them, but more often there will be no way at all to meet them
all, and you must make sacrifices.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

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

[Dan Pop]

In <01bb8534$b2718bc0$87ee6fce@timpent.airshields.com> "Tim Behrendsen" <tim@airshields.com> writes:

>Dan Pop <Dan.Pop@cern.ch> wrote in article
><danpop.839450672@news.cern.ch>...
>> In <01bb83f5$923391e0$87ee6fce@timpent.airshields.com> "Tim Behrendsen"
><tim@airshields.com> writes:
>> 
>> >The problem is that we *can't* think purely abstractly,
>> >otherwise we end up with slow crap code.
>> 
>> Care to provide some concrete examples?
>
>Look at the code-bloated and slow-software world we live in,
>particularly on desktop platforms.  I think this is caused by
>people not truly understanding what's *really* going on.

I was asking for a concrete example, like a quicksort implementation
made by someone thinking purely abstractly as opposed to a quicksort
implementation made by someone who understands the low level details.

>For example, look at OOP.  Very naive implementations of OOP
>used a huge amount of dynamic memory allocation, which can cause
>severe performance problems.  That's why I don't use C++ for my
>products; to do it right you have to do a very careful analysis
>of how your classes are going fit together efficiently.
>
>I've spoken to enough people that have had C++ disasters to
>convince me that the more abstraction there is, the more
>danger there is of inefficient code.  This shouldn't be that
>hard to believe; any time you abstract away details you are
>giving up knowledge of what is going to be efficient.

Nonsense.  The efficiency of an implementation can be also thought in
abstract terms, you don't need to know how the compiler works or
assembly language in order to implement your application in an efficient
way.  Or you may know all these irrelevant details and still write 
inefficient code, because it's so much easier in many OOPLs.

>I alluded to this in another post, but a good example is Motif
>and X11.  A programmer who only understands Motif, but does not
>understand X11 is going to write slow crap, period.

More nonsense.  Unless your applications spend the bulk of their CPU
time in the user interface, that should be a non-issue.

>Here's an example:
>
>int a[50000],b[50000],c[50000],d[50000],e[50000];
>
>void test1()
>{
>    int i, j;
>    for (j = 0; j < 10; ++j) {
>        for (i = 0; i < 50000; ++i) {
>            ++a[i]; ++b[i]; ++c[i]; ++d[i]; ++e[i];
>        }
>    }
>}
>
>void test2()
>{
>    int i, j;
>    for (j = 0; j < 10; ++j) {
>        for (i = 0; i < 50000; ++i) ++a[i];
>        for (i = 0; i < 50000; ++i) ++b[i];
>        for (i = 0; i < 50000; ++i) ++c[i];
>        for (i = 0; i < 50000; ++i) ++d[i];
>        for (i = 0; i < 50000; ++i) ++e[i];
>    }
>}
>
>On my AIX system, test1 runs in 2.47 seconds, and test2
>runs in 1.95 seconds using maximum optimization (-O3).  The
>reason I knew the second would be faster is because I know
>to limit the amount of context information the optimizer has
>to deal with in the inner loops, and I know to keep memory
>localized.

1. For a marginal speed increase (~25%), you compromised the readability
   of the code.

2. Another compiler, on another system, might generate faster code
   out of the test1.  This is especially true for supercomputers,
   which have no cache memory (and where the micro-optimizations are done
   based on a completely different set of criteria) and where the cpu time
   is really expensive.

3. You used exclusively abstract concepts to justify why test2 is
   faster on your particular platform/compiler combination.  No references
   to the length of a cache line or to the compiler being able to use
   a more efficient instruction or instruction combination in one case
   than in the other.

Let's see what happens on my 486DX33 box:

    ues4:~/afs/tmp 32> cc -O2 -o test1 test1.c
    ues4:~/afs/tmp 33> time ./test1
    1.100u 0.230s 0:01.51 88.0% 0+0k 0+0io 13pf+0w
    ues4:~/afs/tmp 34> cc -O2 -o test2 test2.c
    ues4:~/afs/tmp 35> time ./test2
    1.170u 0.180s 0:01.45 93.1% 0+0k 0+0io 13pf+0w

So, it's 1.10 + 0.23 = 1.33 seconds of cpu time for test1 versus
1.17 + 0.18 = 1.35 seconds for test2.  Conclusions:

1. My 486DX33 is faster than your AIX system (or maybe gcc is faster than
   xlc) :-)

2. Your results are not reproducible.  Your extra "insight" simply "helped"
   you to generate less readable code.

>Now I submit that if I showed the average C programmer
>both programs, they would guess that test1 is faster because
>it has "less code",

And he might be right, both on a CP/M-80 micro and a Cray supercomputer.
Or on most systems with a compiler that can do loop unrolling.

>and that is where abstraction,
>ignorance, and niavete begin to hurt.

The key to proper optimization is profiling.  Additional knowledge about
a certain platform is a lot less important.  

And if the wrong algorithm has been chosen in the first place, no
amount of micro-optimization will save the code performance.  The guy
who can do a decent algorithm analysis (an entirely abstract operation)
will always beat the one who is an expert assembly programmer but
prefers to spend his time coding instead of dealing with abstractions.

This is an old story (it happened during the early to mid eighties) and
I forgot the details.  One software company had a nice product for the PC,
but it was rather slow.  To get the "best" performance, it was coded in
assembly.  Another company decided to emulate that product and they did it
quite successfully (their version is about 4 times faster).  They 
implemented it in C, but they've carefully chosen their algorithms.

Dan
--
Dan Pop
CERN, CN Division
Email: Dan.Pop@cern.ch 
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland

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

[Tim Behrendsen]

Dan Pop <Dan.Pop@cern.ch> wrote in article
<danpop.839594575@news.cern.ch>...
> In <01bb8534$b2718bc0$87ee6fce@timpent.airshields.com> "Tim Behrendsen"
<tim@airshields.com> writes:
> 
> >Dan Pop <Dan.Pop@cern.ch> wrote in article
> ><danpop.839450672@news.cern.ch>...
> >
> >I've spoken to enough people that have had C++ disasters to
> >convince me that the more abstraction there is, the more
> >danger there is of inefficient code.  This shouldn't be that
> >hard to believe; any time you abstract away details you are
> >giving up knowledge of what is going to be efficient.
> 
> Nonsense.  The efficiency of an implementation can be also thought in
> abstract terms, you don't need to know how the compiler works or
> assembly language in order to implement your application in an efficient
> way.  Or you may know all these irrelevant details and still write 
> inefficient code, because it's so much easier in many OOPLs.

Certainly the most influential factor to the speed of an
application is the algorithms that are chosen.  No question.

That having been said, why are application written in OOPLs
often very inefficient?  I think it's because they are built up
with so many abstract black boxes that it's difficult to keep
track of the interactions between the pieces.

Same with HLLs.  They are nothing more than "objects" on top
of the assembly language.  Any time you have generalization
you introduce inefficiency, and knowing the general principles
behind how things are going to compile can only help.

An example from another post is recursion; show me the
computer where recursion is not slower than a non-recursive
implementation of an algorithm

> >I alluded to this in another post, but a good example is Motif
> >and X11.  A programmer who only understands Motif, but does not
> >understand X11 is going to write slow crap, period.
> 
> More nonsense.  Unless your applications spend the bulk of their CPU
> time in the user interface, that should be a non-issue.

You obviously haven't done much Motif programming.  Example: If
you are not careful, you can introduce a round trip every time
you specify a color.

> >Here's an example:
> >
> >int a[50000],b[50000],c[50000],d[50000],e[50000];
> >
> >void test1()
> >{
> >    int i, j;
> >    for (j = 0; j < 10; ++j) {
> >        for (i = 0; i < 50000; ++i) {
> >            ++a[i]; ++b[i]; ++c[i]; ++d[i]; ++e[i];
> >        }
> >    }
> >}
> >
> >void test2()
> >{
> >    int i, j;
> >    for (j = 0; j < 10; ++j) {
> >        for (i = 0; i < 50000; ++i) ++a[i];
> >        for (i = 0; i < 50000; ++i) ++b[i];
> >        for (i = 0; i < 50000; ++i) ++c[i];
> >        for (i = 0; i < 50000; ++i) ++d[i];
> >        for (i = 0; i < 50000; ++i) ++e[i];
> >    }
> >}
> >
> >On my AIX system, test1 runs in 2.47 seconds, and test2
> >runs in 1.95 seconds using maximum optimization (-O3).  The
> >reason I knew the second would be faster is because I know
> >to limit the amount of context information the optimizer has
> >to deal with in the inner loops, and I know to keep memory
> >localized.
> 
> 1. For a marginal speed increase (~25%), you compromised the readability
>    of the code.

You call 25% a "marginal" increase?  It's attitudes like this
that give us the slow code world we have right now.  And how
is one less readable than the other?

> 2. Another compiler, on another system, might generate faster code
>    out of the test1.  This is especially true for supercomputers,
>    which have no cache memory (and where the micro-optimizations are done
>    based on a completely different set of criteria) and where the cpu
time
>    is really expensive.

Show me the computer where test1 comes out faster.  Or shouldn't
we depend on the compiler to optimize this?

> 3. You used exclusively abstract concepts to justify why test2 is
>    faster on your particular platform/compiler combination.  No
references
>    to the length of a cache line or to the compiler being able to use
>    a more efficient instruction or instruction combination in one case
>    than in the other.
> 
> Let's see what happens on my 486DX33 box:
> 
> So, it's 1.10 + 0.23 = 1.33 seconds of cpu time for test1 versus
> 1.17 + 0.18 = 1.35 seconds for test2.  Conclusions:
> 
> 1. My 486DX33 is faster than your AIX system (or maybe gcc is faster than
>    xlc) :-)

Oops!  I just realized my AIX program had 100 for the outer loop, not
10 (had me worried for a minute there ...)

> 2. Your results are not reproducible.  Your extra "insight" simply
"helped"
>    you to generate less readable code.

Actually, try again with 500 or 5000 in the inner loops; 50000
probably flushed the cache.  In any case, the code is identically
readable either way IMO, and costs you nothing to implement
the efficient way.  So it wasn't on one architecture, big deal.
On the average, it will be, and costs nothing to do it that way/

> >Now I submit that if I showed the average C programmer
> >both programs, they would guess that test1 is faster because
> >it has "less code",
> 
> And he might be right, both on a CP/M-80 micro and a Cray supercomputer.
> Or on most systems with a compiler that can do loop unrolling.

Not gonna find this mythical bizarre beast, except for trivial
differences because of the extra loop overhead.

> >and that is where abstraction,
> >ignorance, and niavete begin to hurt.
> 
> The key to proper optimization is profiling.  Additional knowledge about
> a certain platform is a lot less important.  

Agreed; optimization shouldn't be to a certain platform, but
optimizations can be made on general basis.

Again, is it the case that I can order my code into any
algorithmically valid sequence and get identical running times?

> And if the wrong algorithm has been chosen in the first place, no
> amount of micro-optimization will save the code performance.  The guy
> who can do a decent algorithm analysis (an entirely abstract operation)
> will always beat the one who is an expert assembly programmer but
> prefers to spend his time coding instead of dealing with abstractions.

Agreed.

-- Tim Behrendsen (tim@airshields.com)

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

[Dan Pop]

In <01bb87cf$97ae8e80$87ee6fce@timpent.airshields.com> "Tim Behrendsen" <tim@airshields.com> writes:

>Dan Pop <Dan.Pop@cern.ch> wrote in article
><danpop.839594575@news.cern.ch>...
>> In <01bb8534$b2718bc0$87ee6fce@timpent.airshields.com> "Tim Behrendsen"
><tim@airshields.com> writes:
>> 
>> >Here's an example:
>> >
>> >int a[50000],b[50000],c[50000],d[50000],e[50000];
>> >
>> >void test1()
>> >{
>> >    int i, j;
>> >    for (j = 0; j < 10; ++j) {
>> >        for (i = 0; i < 50000; ++i) {
>> >            ++a[i]; ++b[i]; ++c[i]; ++d[i]; ++e[i];
>> >        }
>> >    }
>> >}
>> >
>> >void test2()
>> >{
>> >    int i, j;
>> >    for (j = 0; j < 10; ++j) {
>> >        for (i = 0; i < 50000; ++i) ++a[i];
>> >        for (i = 0; i < 50000; ++i) ++b[i];
>> >        for (i = 0; i < 50000; ++i) ++c[i];
>> >        for (i = 0; i < 50000; ++i) ++d[i];
>> >        for (i = 0; i < 50000; ++i) ++e[i];
>> >    }
>> >}
>> >
>> >On my AIX system, test1 runs in 2.47 seconds, and test2
>> >runs in 1.95 seconds using maximum optimization (-O3).  The
>> >reason I knew the second would be faster is because I know
>> >to limit the amount of context information the optimizer has
>> >to deal with in the inner loops, and I know to keep memory
>> >localized.
>> 
>> 1. For a marginal speed increase (~25%), you compromised the readability
>>    of the code.
>
>You call 25% a "marginal" increase?  It's attitudes like this
>that give us the slow code world we have right now.

Yes, I do call 25% a marginal increase.  Would you be considerably happier
if everything would run 25% faster, at the expense of everything being
harder to develop and maintain by a factor of 2?

>And how is one less readable than the other?

Methinks one loop is easier to read than five.

>> 2. Another compiler, on another system, might generate faster code
>>    out of the test1.  This is especially true for supercomputers,
>>    which have no cache memory (and where the micro-optimizations are done
>>    based on a completely different set of criteria) and where the cpu
>time
>>    is really expensive.
>
>Show me the computer where test1 comes out faster. 

Already done: my notebook.

>Or shouldn't we depend on the compiler to optimize this?

Exactly, it's compiler's job to optimize it, not mine.

>> Let's see what happens on my 486DX33 box:
>> 
>> So, it's 1.10 + 0.23 = 1.33 seconds of cpu time for test1 versus
>> 1.17 + 0.18 = 1.35 seconds for test2.  Conclusions:
>> 
>> 1. My 486DX33 is faster than your AIX system (or maybe gcc is faster than
>>    xlc) :-)
>
>Oops!  I just realized my AIX program had 100 for the outer loop, not
>10 (had me worried for a minute there ...)
>
>> 2. Your results are not reproducible.  Your extra "insight" simply
>"helped"
>>    you to generate less readable code.
>
>Actually, try again with 500 or 5000 in the inner loops; 50000
>probably flushed the cache.

Get a clue.  If test1 flushes the cache, test2 will flush it, as well.
Both implementations behave the same way WRT cache utilization: all
5 x 50000 array elements are accessed in a single iteration of the outer
loop, hence the same thing (cache hit or cache miss) will happen at the
next iteration in both versions.  Cache is simply a non-issue in your
example (even if you intended it to be :-)

>In any case, the code is identically
>readable either way IMO, and costs you nothing to implement
>the efficient way.

You forgot to provide a VALID justification for your claim that test2
is the "efficient way".

>So it wasn't on one architecture, big deal.

Can you prove that it will be on any other architecture?  According
to your line of argumentation, I could say: "so it was on one architecture,
big deal" :-)

>On the average, it will be, and costs nothing to do it that way/

I still have to see the proof.  If your time is worth nothing, then you're
right, it costs nothing.

>> The key to proper optimization is profiling.  Additional knowledge about
>> a certain platform is a lot less important.  
>
>Agreed; optimization shouldn't be to a certain platform, but
>optimizations can be made on general basis.

Right.  By selecting the proper algorithm.  Most other kinds of
optimizations will be specific to a certain machine, or, at best, class
of machines.  For example, an optimization which tries to improve the
cache hit rate might hurt on a supercomputer which has no cache, but it
is adversely affected by certain memory access patterns.

When programming for a single platform/compiler combination, it makes
sense to perform micro-optimizations, _if they're rewarding enough_.
But then, if portability is not an issue, the critical code could be
written in assembly, as well.  When writing portable code in a HLL,
micro-optimizations are usually a waste of effort and programmer time.

Dan
--
Dan Pop
CERN, CN Division
Email: Dan.Pop@cern.ch 
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland

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

[Tim Behrendsen]

Dan Pop <Dan.Pop@cern.ch> wrote in article
<danpop.839807980@news.cern.ch>...
> In <01bb87cf$97ae8e80$87ee6fce@timpent.airshields.com> "Tim Behrendsen"
<tim@airshields.com> writes:
> 
> >Dan Pop <Dan.Pop@cern.ch> wrote in article
> ><danpop.839594575@news.cern.ch>...
> >> In <01bb8534$b2718bc0$87ee6fce@timpent.airshields.com> "Tim
Behrendsen"
> ><tim@airshields.com> writes:
> >> 
> >> >Here's an example:
> >> >
> >> >int a[50000],b[50000],c[50000],d[50000],e[50000];
> >> >
> >> >void test1()
> >> >{
> >> >    int i, j;
> >> >    for (j = 0; j < 10; ++j) {
> >> >        for (i = 0; i < 50000; ++i) {
> >> >            ++a[i]; ++b[i]; ++c[i]; ++d[i]; ++e[i];
> >> >        }
> >> >    }
> >> >}
> >> >
> >> >void test2()
> >> >{
> >> >    int i, j;
> >> >    for (j = 0; j < 10; ++j) {
> >> >        for (i = 0; i < 50000; ++i) ++a[i];
> >> >        for (i = 0; i < 50000; ++i) ++b[i];
> >> >        for (i = 0; i < 50000; ++i) ++c[i];
> >> >        for (i = 0; i < 50000; ++i) ++d[i];
> >> >        for (i = 0; i < 50000; ++i) ++e[i];
> >> >    }
> >> >}
> >> >
> >> >On my AIX system, test1 runs in 2.47 seconds, and test2
> >> >runs in 1.95 seconds using maximum optimization (-O3).  The
> >> >reason I knew the second would be faster is because I know
> >> >to limit the amount of context information the optimizer has
> >> >to deal with in the inner loops, and I know to keep memory
> >> >localized.
> >> 
> >> 1. For a marginal speed increase (~25%), you compromised the
readability
> >>    of the code.
> >
> >You call 25% a "marginal" increase?  It's attitudes like this
> >that give us the slow code world we have right now.
> 
> Yes, I do call 25% a marginal increase.  Would you be considerably
happier
> if everything would run 25% faster, at the expense of everything being
> harder to develop and maintain by a factor of 2?

No, I wouldn't be happier with "a factor of 2", but that's a
very large presumption.  Who's doing anything strange and
arcane?  I just made it easier on the compiler / computer.

> >And how is one less readable than the other?
> 
> Methinks one loop is easier to read than five.

Sometimes, but other times I would rather read five small
loops right in a row than one mammoth loop that I have to
take in all at once.

In this particular case, I think they are both equally
readable.

> >> 2. Another compiler, on another system, might generate faster code
> >>    out of the test1.  This is especially true for supercomputers,
> >>    which have no cache memory (and where the micro-optimizations are
done
> >>    based on a completely different set of criteria) and where the cpu
> >time
> >>    is really expensive.
> >
> >Show me the computer where test1 comes out faster. 
> 
> Already done: my notebook.

Yes, trivially faster.  But how about significantly faster?

> >Or shouldn't we depend on the compiler to optimize this?
> 
> Exactly, it's compiler's job to optimize it, not mine.

Well, the compiler didn't do a very good job, does it?
And that's the whole point.  It is ivory tower naivete to
think that compilers optimize everything perfectly every
time.  Yes, you can just wave your hand and say, "well,
obviously AIX sucks", but in my experience at least, ALL
compilers suck in one way or another.
 
> >> Let's see what happens on my 486DX33 box:
> >> 
> >> So, it's 1.10 + 0.23 = 1.33 seconds of cpu time for test1 versus
> >> 1.17 + 0.18 = 1.35 seconds for test2.  Conclusions:
> >> 1. My 486DX33 is faster than your AIX system (or maybe gcc is faster
than
> >>    xlc) :-)
> >Oops!  I just realized my AIX program had 100 for the outer loop, not
> >10 (had me worried for a minute there ...)
> >
> >> 2. Your results are not reproducible.  Your extra "insight" simply
> >"helped"
> >>    you to generate less readable code.
> >
> >Actually, try again with 500 or 5000 in the inner loops; 50000
> >probably flushed the cache.
> 
> Get a clue.  If test1 flushes the cache, test2 will flush it, as well.
> Both implementations behave the same way WRT cache utilization: all
> 5 x 50000 array elements are accessed in a single iteration of the outer
> loop, hence the same thing (cache hit or cache miss) will happen at the
> next iteration in both versions.  Cache is simply a non-issue in your
> example (even if you intended it to be :-)

- Sigh - I must really think about these posts for more than
the two minutes per thread.  You are right, of course.  The
cache is irrelevent to this example.  It's more likely the
fact that the first case is makes better use of page locality.
It may also be that the compiler ran out of address registers
with five arrays (or a combination of both).

Of course, I could restructure the example to take advantage
of the cache, and get even more improvement. :)
 
> >In any case, the code is identically
> >readable either way IMO, and costs you nothing to implement
> >the efficient way.
> 
> You forgot to provide a VALID justification for your claim that test2
> is the "efficient way".

It's probably mostly the paging locality.  Did you run your
test under DOS or Windows?  It would be interesting to see
if there was a difference.

> >So it wasn't on one architecture, big deal.
> 
> Can you prove that it will be on any other architecture?  According
> to your line of argumentation, I could say: "so it was on one
architecture,
> big deal" :-)

I would have to try it on other architectures to be sure, but
can you come up with a scenerio that the second would be
significantly slower?  I would say that on the average paging
architecture, memory locality tends to be quite important to
performance.

> >On the average, it will be, and costs nothing to do it that way/
> 
> I still have to see the proof.  If your time is worth nothing, then
you're
> right, it costs nothing.

Take the same amount of time, either way.  Just a matter of
paying attention to what you do.

> >> The key to proper optimization is profiling.  Additional knowledge
about
> >> a certain platform is a lot less important.  
> >
> >Agreed; optimization shouldn't be to a certain platform, but
> >optimizations can be made on general basis.
> 
> Right.  By selecting the proper algorithm.  Most other kinds of
> optimizations will be specific to a certain machine, or, at best, class
> of machines.  For example, an optimization which tries to improve the
> cache hit rate might hurt on a supercomputer which has no cache, but it
> is adversely affected by certain memory access patterns.

Well, if you're using a super computer, chances are you *will*
optimize to that architecture, because super computer time
tends to be expensive.  For general purpose software, the
architectures are pretty much the same all around.  They all
have caches, they all have paging.

> When programming for a single platform/compiler combination, it makes
> sense to perform micro-optimizations, _if they're rewarding enough_.
> But then, if portability is not an issue, the critical code could be
> written in assembly, as well.  When writing portable code in a HLL,
> micro-optimizations are usually a waste of effort and programmer time.

I think that most architectures in the real world are close
enough that you can find commonality, such as inefficient
recursion.

-- Tim Behrendsen (tim@airshields.com)

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

[Giuliano Carlini]

Tim Behrendsen wrote:
> 
> Dan Pop <Dan.Pop@cern.ch> wrote in article
> <danpop.839807980@news.cern.ch>...
> > In <01bb87cf$97ae8e80$87ee6fce@timpent.airshields.com> "Tim Behrendsen"
> <tim@airshields.com> writes:
> >
> > >Dan Pop <Dan.Pop@cern.ch> wrote in article
> > ><danpop.839594575@news.cern.ch>...
> > >> In <01bb8534$b2718bc0$87ee6fce@timpent.airshields.com> "Tim
> Behrendsen"
> > ><tim@airshields.com> writes:
> > >>
> > >> >Here's an example:
> > >> >
> > >> >int a[50000],b[50000],c[50000],d[50000],e[50000];
> > >> >
> > >> >void test1()
> > >> >{
> > >> >    int i, j;
> > >> >    for (j = 0; j < 10; ++j) {
> > >> >        for (i = 0; i < 50000; ++i) {
> > >> >            ++a[i]; ++b[i]; ++c[i]; ++d[i]; ++e[i];
> > >> >        }
> > >> >    }
> > >> >}
> > >> >
> > >> >void test2()
> > >> >{
> > >> >    int i, j;
> > >> >    for (j = 0; j < 10; ++j) {
> > >> >        for (i = 0; i < 50000; ++i) ++a[i];
> > >> >        for (i = 0; i < 50000; ++i) ++b[i];
> > >> >        for (i = 0; i < 50000; ++i) ++c[i];
> > >> >        for (i = 0; i < 50000; ++i) ++d[i];
> > >> >        for (i = 0; i < 50000; ++i) ++e[i];
> > >> >    }
> > >> >}
> > >> >
> > >> >On my AIX system, test1 runs in 2.47 seconds, and test2
> > >> >runs in 1.95 seconds using maximum optimization (-O3).  The
> > >> >reason I knew the second would be faster is because I know
> > >> >to limit the amount of context information the optimizer has
> > >> >to deal with in the inner loops, and I know to keep memory
> > >> >localized.
> > >>
> > >> 1. For a marginal speed increase (~25%), you compromised the
> readability
> > >>    of the code.
> > >
> > >You call 25% a "marginal" increase?

Actually, I would too. Typically, attacking slow spots by changing
algorithms, small changes to interface that permit massive
performance speedups, etc will often result in 50 to 90%
speedups. And these optimizations are portable, whereas depending
on the optimizer is not.

> >
> > Yes, I do call 25% a marginal increase.  Would you be considerably
> happier
> > if everything would run 25% faster, at the expense of everything being
> > harder to develop and maintain by a factor of 2?
> 
> No, I wouldn't be happier with "a factor of 2", but that's a
> very large presumption.  Who's doing anything strange and
> arcane?  I just made it easier on the compiler / computer.

As another data point, It did take me a lot longer to understand
code snippet 2 than one. Maybe 50%, maybe 200%, I can't say for
sure; my internal clock doesn't act like a stopwatch ;->

Depending on where in the code we're talking about, either of you could
be "right". The only 90/10 rule (90% of the execution time is taken
by 10% of the code) would dictate using this optimization in frequently
executed paths. The original is superior everyplace else due to
comprehension.

> Well, the compiler didn't do a very good job, does it?
> And that's the whole point.  It is ivory tower naivete to
> think that compilers optimize everything perfectly every
> time.

Generally programmers shouldn't be optimizing code by hand
unless they are sure it affects the "bottom line". So, if
a performance analysis shows that you need to contort your
code to get a major speed-up, I'm all for it. Otherwise,
avoid them like the plague.


g

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

[Dan Pop]

In <01bb88d4$022bf4a0$32ee6fce@timhome2> "Tim Behrendsen" <tim@airshields.com> writes:

>Dan Pop <Dan.Pop@cern.ch> wrote in article
><danpop.839807980@news.cern.ch>...
>> In <01bb87cf$97ae8e80$87ee6fce@timpent.airshields.com> "Tim Behrendsen"
><tim@airshields.com> writes:
>> 
>> >Dan Pop <Dan.Pop@cern.ch> wrote in article
>> ><danpop.839594575@news.cern.ch>...
>> >> In <01bb8534$b2718bc0$87ee6fce@timpent.airshields.com> "Tim
>Behrendsen"
>> ><tim@airshields.com> writes:
>> >> 
>> >> >Here's an example:
>> >> >
>> >> >int a[50000],b[50000],c[50000],d[50000],e[50000];
>> >> >
>> >> >void test1()
>> >> >{
>> >> >    int i, j;
>> >> >    for (j = 0; j < 10; ++j) {
>> >> >        for (i = 0; i < 50000; ++i) {
>> >> >            ++a[i]; ++b[i]; ++c[i]; ++d[i]; ++e[i];
>> >> >        }
>> >> >    }
>> >> >}
>> >> >
>> >> >void test2()
>> >> >{
>> >> >    int i, j;
>> >> >    for (j = 0; j < 10; ++j) {
>> >> >        for (i = 0; i < 50000; ++i) ++a[i];
>> >> >        for (i = 0; i < 50000; ++i) ++b[i];
>> >> >        for (i = 0; i < 50000; ++i) ++c[i];
>> >> >        for (i = 0; i < 50000; ++i) ++d[i];
>> >> >        for (i = 0; i < 50000; ++i) ++e[i];
>> >> >    }
>> >> >}
>> >> >
>> >> >On my AIX system, test1 runs in 2.47 seconds, and test2
>> >> >runs in 1.95 seconds using maximum optimization (-O3).  The
>> >> >reason I knew the second would be faster is because I know
>> >> >to limit the amount of context information the optimizer has
>> >> >to deal with in the inner loops, and I know to keep memory
>> >> >localized.
>> >> 
>> >> 1. For a marginal speed increase (~25%), you compromised the
>readability
>> >>    of the code.
>> >
>> >You call 25% a "marginal" increase?  It's attitudes like this
>> >that give us the slow code world we have right now.
>> 
>> Yes, I do call 25% a marginal increase.  Would you be considerably
>happier
>> if everything would run 25% faster, at the expense of everything being
>> harder to develop and maintain by a factor of 2?
>
>No, I wouldn't be happier with "a factor of 2", but that's a
>very large presumption. 

No, it isn't.  In nontrivial and meaningful examples (i.e. not like yours)
there is quite a difference between the effort to express an algorithm
in the most natural way and in the most efficient way for a certain
compiler/platform combination.  Compare a plain loop with Duff's device
and you'll see what I mean.

>Who's doing anything strange and
>arcane?  I just made it easier on the compiler / computer.

You made it easier on your compiler/computer combination, but not on mine.

>> >And how is one less readable than the other?
>> 
>> Methinks one loop is easier to read than five.
>
>Sometimes, but other times I would rather read five small
>loops right in a row than one mammoth loop that I have to
>take in all at once.

In this particular case, test1 is easier to read.  It also happens to be
faster on some machines.

>In this particular case, I think they are both equally
>readable.

I don't.

>> >> 2. Another compiler, on another system, might generate faster code
>> >>    out of the test1.  This is especially true for supercomputers,
>> >>    which have no cache memory (and where the micro-optimizations are
>done
>> >>    based on a completely different set of criteria) and where the cpu
>> >time
>> >>    is really expensive.
>> >
>> >Show me the computer where test1 comes out faster. 
>> 
>> Already done: my notebook.
>
>Yes, trivially faster.  But how about significantly faster?

There is no machine that I can think of where one of them would be
significantly faster than the other.  Do you have a counterexample?

>> >Or shouldn't we depend on the compiler to optimize this?
>> 
>> Exactly, it's compiler's job to optimize it, not mine.
>
>Well, the compiler didn't do a very good job, does it?

YOUR compiler didn't do a very good job.  By crippling your code for
your compiler you made it less efficient for other platforms.  Hence,
your example was a very bad one.

>And that's the whole point.  It is ivory tower naivete to
>think that compilers optimize everything perfectly every
>time.

It's equally naive to believe that code micro-optimized for one 
platform will be faster on any other platform.

>Yes, you can just wave your hand and say, "well,
>obviously AIX sucks", but in my experience at least, ALL
>compilers suck in one way or another.

And adapting your code to one particular sucking compiler is a great 
idea, if I understood your point right.

>> >> Let's see what happens on my 486DX33 box:
>> >> 
>> >> So, it's 1.10 + 0.23 = 1.33 seconds of cpu time for test1 versus
>> >> 1.17 + 0.18 = 1.35 seconds for test2. 
>> 
>> Get a clue.  If test1 flushes the cache, test2 will flush it, as well.
>> Both implementations behave the same way WRT cache utilization: all
>> 5 x 50000 array elements are accessed in a single iteration of the outer
>> loop, hence the same thing (cache hit or cache miss) will happen at the
>> next iteration in both versions.  Cache is simply a non-issue in your
>> example (even if you intended it to be :-)
>
>- Sigh - I must really think about these posts for more than
>the two minutes per thread.  You are right, of course.  The
>cache is irrelevent to this example.  It's more likely the
>fact that the first case is makes better use of page locality.
>It may also be that the compiler ran out of address registers
>with five arrays (or a combination of both).

I wasn't aware that the POWER architecture has "address registers".
Anyway, my 486 definitely ran out of registers, but this didn't prevent
test1 from be marginally faster.

>Of course, I could restructure the example to take advantage
>of the cache, and get even more improvement. :)

Or make test1 even faster on my notebook, with only 8k of cache :-)
 
>> >In any case, the code is identically
>> >readable either way IMO, and costs you nothing to implement
>> >the efficient way.
>> 
>> You forgot to provide a VALID justification for your claim that test2
>> is the "efficient way".
>
>It's probably mostly the paging locality.

Both versions have excellent paging locality.  Read them again and tell
me which one is likely to produce more page faults than the other.

>Did you run your
>test under DOS or Windows?  It would be interesting to see
>if there was a difference.

I have better uses for my time than to use DOS and Windows.  But the
Linux/gcc combination proved your claim wrong.

>> >So it wasn't on one architecture, big deal.
>> 
>> Can you prove that it will be on any other architecture?  According
>> to your line of argumentation, I could say: "so it was on one
>architecture,
>> big deal" :-)
>
>I would have to try it on other architectures to be sure, but
>can you come up with a scenerio that the second would be
>significantly slower?

Can you come with a scenario that the second would be significantly
faster?

>I would say that on the average paging
>architecture, memory locality tends to be quite important to
>performance.

And I have to repeat that both implementations have similar memory
locality.  Unless you can prove otherwise.

>> >Agreed; optimization shouldn't be to a certain platform, but
>> >optimizations can be made on general basis.
>> 
>> Right.  By selecting the proper algorithm.  Most other kinds of
>> optimizations will be specific to a certain machine, or, at best, class
>> of machines.  For example, an optimization which tries to improve the
>> cache hit rate might hurt on a supercomputer which has no cache, but it
>> is adversely affected by certain memory access patterns.
>
>Well, if you're using a super computer, chances are you *will*
>optimize to that architecture, because super computer time
>tends to be expensive.  For general purpose software, the
>architectures are pretty much the same all around.  They all
>have caches, they all have paging.

Are you kidding or what?  Please explain the paging sheme of MSDOS, the
most popular platform in the world (unfortunately).  And cacheless
architectures are common at both ends of the spectrum.

>> When programming for a single platform/compiler combination, it makes
>> sense to perform micro-optimizations, _if they're rewarding enough_.
>> But then, if portability is not an issue, the critical code could be
>> written in assembly, as well.  When writing portable code in a HLL,
>> micro-optimizations are usually a waste of effort and programmer time.
>
>I think that most architectures in the real world are close
>enough that you can find commonality, such as inefficient
>recursion.

There are plenty of algorithms where recursion is the most efficient
implementation.  Just ask any Fortran programmer who had to implement
such an algorithm without using recursion.

Try to find a better example next time.

Dan
--
Dan Pop
CERN, CN Division
Email: Dan.Pop@cern.ch 
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland

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

[Tim Behrendsen]

Dan Pop <Dan.Pop@cern.ch> wrote in article
<danpop.840019072@news.cern.ch>...
> >
> >It's probably mostly the paging locality.
> 
> Both versions have excellent paging locality.  Read them again and tell
> me which one is likely to produce more page faults than the other.

By paging locality, I mean that virtual-to-physical address
translation happens faster when you are dealing with one
page at a time rather than "striping" in the second case.

> >I think that most architectures in the real world are close
> >enough that you can find commonality, such as inefficient
> >recursion.
> 
> There are plenty of algorithms where recursion is the most efficient
> implementation.  Just ask any Fortran programmer who had to implement
> such an algorithm without using recursion.

For example?

-- Tim Behrendsen (tim@airshields.com)

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

[Dik T. Winter]

In article <danpop.840019072@news.cern.ch> Dan.Pop@cern.ch (Dan Pop) writes:
 > >> >> >    for (j = 0; j < 10; ++j) {
 > >> >> >        for (i = 0; i < 50000; ++i) {
 > >> >> >            ++a[i]; ++b[i]; ++c[i]; ++d[i]; ++e[i];
 > >> >> >        }
 > >> >> >    }
...
 > Both versions have excellent paging locality.  Read them again and tell
 > me which one is likely to produce more page faults than the other.

Dan, obviously on a machine with only four pages the code above produces
an enormous amount of page faults!  Ah, a Commodore C64 with virtual
memory.
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland, +31205924098
home: bovenover 215, 1025 jn  amsterdam, nederland; http://www.cwi.nl/~dik/

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

[Peter Seebach]

In article <01bb87cf$97ae8e80$87ee6fce@timpent.airshields.com>,
Tim Behrendsen <tim@airshields.com> wrote:
>> >int a[50000],b[50000],c[50000],d[50000],e[50000];

>> >void test1()
>> >{
>> >    int i, j;
>> >    for (j = 0; j < 10; ++j) {
>> >        for (i = 0; i < 50000; ++i) {
>> >            ++a[i]; ++b[i]; ++c[i]; ++d[i]; ++e[i];
>> >        }
>> >    }
>> >}

>> >void test2()
>> >{
>> >    int i, j;
>> >    for (j = 0; j < 10; ++j) {
>> >        for (i = 0; i < 50000; ++i) ++a[i];
>> >        for (i = 0; i < 50000; ++i) ++b[i];
>> >        for (i = 0; i < 50000; ++i) ++c[i];
>> >        for (i = 0; i < 50000; ++i) ++d[i];
>> >        for (i = 0; i < 50000; ++i) ++e[i];
>> >    }
>> >}

>Show me the computer where test1 comes out faster.

gcc/SPARC, with *NO* optimization.  test1 runs 10 times in 15.66 seconds,
test2 takes 22.02 seconds.

With optimization, test2 comes out faster on that compiler.

In other words, which is faster depends on the compiler.  And on context.

>Not gonna find this mythical bizarre beast, except for trivial
>differences because of the extra loop overhead.

Trivial, like a factor of 50%.

>Again, is it the case that I can order my code into any
>algorithmically valid sequence and get identical running times?

No.  However, it is the case that the differences simply don't justify the
overhead.  I see the "faster" version as having more code, and no real reason
for it.  The pithy 10% advantage it has when it's better does not justify the
50% disadvantage it has when it's worse.  On my systems.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

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

[Tim Behrendsen]

Peter Seebach <seebs@solutions.solon.com> wrote in article
<4unn8o$rkl@solutions.solon.com>...
> In article <01bb87cf$97ae8e80$87ee6fce@timpent.airshields.com>,
> Tim Behrendsen <tim@airshields.com> wrote:
> >> >int a[50000],b[50000],c[50000],d[50000],e[50000];
> 
> >> >void test1()
> >> >{
> >> >    int i, j;
> >> >    for (j = 0; j < 10; ++j) {
> >> >        for (i = 0; i < 50000; ++i) {
> >> >            ++a[i]; ++b[i]; ++c[i]; ++d[i]; ++e[i];
> >> >        }
> >> >    }
> >> >}
> 
> >> >void test2()
> >> >{
> >> >    int i, j;
> >> >    for (j = 0; j < 10; ++j) {
> >> >        for (i = 0; i < 50000; ++i) ++a[i];
> >> >        for (i = 0; i < 50000; ++i) ++b[i];
> >> >        for (i = 0; i < 50000; ++i) ++c[i];
> >> >        for (i = 0; i < 50000; ++i) ++d[i];
> >> >        for (i = 0; i < 50000; ++i) ++e[i];
> >> >    }
> >> >}
> 
> >Show me the computer where test1 comes out faster.
> 
> gcc/SPARC, with *NO* optimization.  test1 runs 10 times in 15.66 seconds,
> test2 takes 22.02 seconds.
> 
> With optimization, test2 comes out faster on that compiler.
> 
> In other words, which is faster depends on the compiler.  And on context.
>
> >Not gonna find this mythical bizarre beast, except for trivial
> >differences because of the extra loop overhead.
> 
> Trivial, like a factor of 50%.

I suspect that no optimization is not using pointers/registers.
Try rewriting the subroutines to use pointers both ways and then
try it with no optimization.

> >Again, is it the case that I can order my code into any
> >algorithmically valid sequence and get identical running times?
> 
> No.  However, it is the case that the differences simply don't justify
the
> overhead.  I see the "faster" version as having more code, and no real
reason
> for it.  The pithy 10% advantage it has when it's better does not justify
the
> 50% disadvantage it has when it's worse.  On my systems.

Only 10% on SPARC?  Crummy paging architecture.

-- Tim Behrendsen (tim@airshields.com)

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

[Mark Wooding]

Dan Pop <Dan.Pop@cern.ch> wrote:
> In <01bb8534$b2718bc0$87ee6fce@timpent.airshields.com> "Tim Behrendsen" <tim@airshields.com> writes:
> 
> >For example, look at OOP.  Very naive implementations of OOP
> >used a huge amount of dynamic memory allocation, which can cause
> >severe performance problems.  That's why I don't use C++ for my
> >products; to do it right you have to do a very careful analysis
> >of how your classes are going fit together efficiently.
> >
> >I've spoken to enough people that have had C++ disasters to
> >convince me that the more abstraction there is, the more
> >danger there is of inefficient code.  This shouldn't be that
> >hard to believe; any time you abstract away details you are
> >giving up knowledge of what is going to be efficient.
> 
> Nonsense.  The efficiency of an implementation can be also thought in
> abstract terms, you don't need to know how the compiler works or
> assembly language in order to implement your application in an efficient
> way.  Or you may know all these irrelevant details and still write 
> inefficient code, because it's so much easier in many OOPLs.

Indeed.  But in the same way, if you use (the same) good algorithms in
the non-OOPy language, I suspect you'll end up with it going faster.
It's important to get your algorithms right, but it's also important to
get the right level of abstraction.

> More nonsense.  Unless your applications spend the bulk of their CPU
> time in the user interface, that should be a non-issue.

Applications do tend to be spending a suspiciously long time in their
user interfaces.  You're right that it /should/ be a non-issue, but it
doesn't appear to be.  Responsiveness of interfaces is rather important
as far as producing a good impression is concerned.

On a platform I've done a lot of work on, the main user interface kit
has wandered in the direction of being more abstract and HLL-based.  I
spotted this trend a couple of years ago, wrote a user interface library
entirely in assembler (it took two of us about a year); it ended up
being considerably more responsive, more featureful, and smaller by
about a factor of five.  This scared me quite a lot.

> And if the wrong algorithm has been chosen in the first place, no
> amount of micro-optimization will save the code performance.  The guy
> who can do a decent algorithm analysis (an entirely abstract
> operation) will always beat the one who is an expert assembly
> programmer but prefers to spend his time coding instead of dealing
> with abstractions.

An easy solution presents itself: do both.  Implementing a complicated
algorithm in assembler isn't much harder than implementing it in C (so
I've found), and maybe I'm just a bit odd, but my assembler code is
usually less buggy and easier to debug.  I'd only consider using a HLL
if development time is really tight, quality is totally unimportant,
portability is an issue or the instruction set in question is truly
horrid.

> This is an old story (it happened during the early to mid eighties)
> and I forgot the details.  One software company had a nice product for
> the PC, but it was rather slow.  To get the "best" performance, it was
> coded in assembly.  Another company decided to emulate that product
> and they did it quite successfully (their version is about 4 times
> faster).  They implemented it in C, but they've carefully chosen their
> algorithms.

I shan't stand here and defend assembler programmers who use the wrong
algorithms: that's silly.  But an assembler programmer who uses the
/right/ algorithms, now there's someone to look up to.

Why is it, by the way, that no-one here (apart from me) has mentioned
the issue of code size?  Does no-one care?  If it's accepted that the
performance of 90% of a program is not particularly relevant, why isn't
it written to save space?  Surely /this/ is the reason that programs are
too big.
-- 
[mdw]

`When our backs are against the wall, we shall turn and fight.'
		-- John Major

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

[James Youngman]

In article <4ul191$38j@excessus.demon.co.uk>, mdw@excessus.demon.co.uk says...

>Why is it, by the way, that no-one here (apart from me) has mentioned
>the issue of code size?  Does no-one care?  

Perhaps because it's orthogonal....

-- 
James Youngman                               VG Gas Analysis Systems
The trouble with the rat-race is, even if you win, you're still a rat.

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

[Sam B. Siegel]

I have to agree with Tim on this one.  Good working knowldge of
assembler and machine acretecture (sp?) make it painfully obviously on
how memory and data is manipulated.
Sam
"Tim Behrendsen" <tim@airshields.com> wrote:

>Dan Pop <Dan.Pop@cern.ch> wrote in article
><danpop.839450672@news.cern.ch>...
>> In <01bb83f5$923391e0$87ee6fce@timpent.airshields.com> "Tim Behrendsen"
><tim@airshields.com> writes:
>> 
>> >The problem is that we *can't* think purely abstractly,
>> >otherwise we end up with slow crap code.
>> 
>> Care to provide some concrete examples?

>Look at the code-bloated and slow-software world we live in,
>particularly on desktop platforms.  I think this is caused by
>people not truly understanding what's *really* going on.

>For example, look at OOP.  Very naive implementations of OOP
>used a huge amount of dynamic memory allocation, which can cause
>severe performance problems.  That's why I don't use C++ for my
>products; to do it right you have to do a very careful analysis
>of how your classes are going fit together efficiently.

>I've spoken to enough people that have had C++ disasters to
>convince me that the more abstraction there is, the more
>danger there is of inefficient code.  This shouldn't be that
>hard to believe; any time you abstract away details you are
>giving up knowledge of what is going to be efficient.

>I alluded to this in another post, but a good example is Motif
>and X11.  A programmer who only understands Motif, but does not
>understand X11 is going to write slow crap, period.

>> >It is simply not
>> >possible to ignore the way code is structured, and completely
>> >depend on the compiler to save us.
>> 
>> This doesn't make any sense to me.  Could you be a little bit more
>> explicit?
>> 
>> The compiler definitely won't save my ass if I choose to use bubblesort
>> instead of quicksort on a large dataset, but the selection between the
>> two algorithms is made based on an abstraction (algorithm analysis) not
>> on how the compiler generates code for one or another.  It's very likely
>> that quicksort will be better, no matter the compiler and the underlying 
>> platform.
>> 
>> Once you put micro-optimizations based on knowledge about the
>> compiler and/or hardware into the code, you impair both the 
>> readability/maintainability/portability of the code and the opportunities
>> of another compiler, on another platform, to generate optimal code.
>> There are situations when this _has_ to be done, but they are isolated
>> exceptions, not the norm.

>I gave this example in another post, but nobody responded.  I think
>it was too good. :-)  I'll try again ...

>I can prove that your statement is wrong.

>Let's say I have the perfect optimizer that takes C code and
>provides the absolute most efficient translation possible.  Given
>that's the case, it won't improve an O(n) algorithm to an O(n^2)
>algorithm.

>Now, that should mean that I can order my C code into any
>algorithmically valid sequence and end up with exactly the same
>running time, because the optimizer is always perfect.

>Now, we know that this does not reflect the real world.  The
>question is, how does a programmer learn the efficient
>implementations that the optimizer can deal with effectively
>from the boneheaded ones?

>Here's an example:

>int a[50000],b[50000],c[50000],d[50000],e[50000];

>void test1()
>{
>    int i, j;
>    for (j = 0; j < 10; ++j) {
>        for (i = 0; i < 50000; ++i) {
>            ++a[i]; ++b[i]; ++c[i]; ++d[i]; ++e[i];
>        }
>    }
>}

>void test2()
>{
>    int i, j;
>    for (j = 0; j < 10; ++j) {
>        for (i = 0; i < 50000; ++i) ++a[i];
>        for (i = 0; i < 50000; ++i) ++b[i];
>        for (i = 0; i < 50000; ++i) ++c[i];
>        for (i = 0; i < 50000; ++i) ++d[i];
>        for (i = 0; i < 50000; ++i) ++e[i];
>    }
>}

>On my AIX system, test1 runs in 2.47 seconds, and test2
>runs in 1.95 seconds using maximum optimization (-O3).  The
>reason I knew the second would be faster is because I know
>to limit the amount of context information the optimizer has
>to deal with in the inner loops, and I know to keep memory
>localized.

>Now I submit that if I showed the average C programmer
>both programs, they would guess that test1 is faster because
>it has "less code", and that is where abstraction,
>ignorance, and niavete begin to hurt.

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

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

[Dan Pop]

In <4v62h3$33c4@news-s01.ny.us.ibm.net> sam0001@ibm.net (Sam B. Siegel) writes:

>I have to agree with Tim on this one.  Good working knowldge of
>assembler and machine acretecture (sp?) make it painfully obviously on
>how memory and data is manipulated.

What happens to the code when it is ported to a machine with a different
architecture (this is the correct spelling) and assembly language?
Chances are that, if it was correctly written on the first machine, it
will run just fine on the second one.  So, the knowledge about the
assembly and architecture of the first machine was not that important.

What is really important when learning programming in a HLL is a good
understanding of the basics of digital computers, not of the specific
details of one or another.

Dan
--
Dan Pop
CERN, CN Division
Email: Dan.Pop@cern.ch 
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland

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

[Peter Seebach]

In article <01bb83f5$923391e0$87ee6fce@timpent.airshields.com>,
Tim Behrendsen <tim@airshields.com> wrote:
>I agree; my point is that I think the student learns more if they
>are thinking purely in terms of fundamental operations (which are
>still abstractions above the raw hardware components), rather
>than layers and layers of syntax that hide the essential essence
>of what the computer is doing.

But your concept of what the "fundemental operations" are is completely tied
up in how specific hardware you've seen operates.  Algorithms exist in terms
of abstract operations, not moves and branches.

Something like CWEB might be a good language in which to learn algorithms.
Scheme might too.

Let's look at a specific algorithm; the infamous gcd(x, y).

In C, we write

	int
	gcd(int x, int y) {
		if (y == 0)
			return x;
		return gcd(y, (x % y));
	}

or something similar.

What's important here is not any theories people may have about where the x
and y are stored, or how a stack works, but the concept that you can define an
algorithm in terms of a previous case.  Learning that the if() may be
implemented with "a branch" does not help the student understand how the
*algorithm* works, it helps the student understand how the *compiler* works.
These are distinct things.

>If programming is reduced to fundamentals of move, arithmetic,
>test, branch, etc it prevents the student from leaning on the
>abstraction rather than truly understanding the solution to the
>problem.  In other words, if they can express it in the above
>terms, you *know* they understand the solution.

But it also prevents them from learning the abstraction, and truly
understanding the *principle* of the solution.

A student who has memorized the multiplication table for x=1..10, y=1..20,
but doesn't know that 5*12 and 12*5 are the same thing, has learned nothing.

Learning details and implementation does not help except in so far as they are
good examples.

>Perhaps the solution is a middle ground one; rather than "real"
>assembly for students, maybe what they need is a "MIX" kind of
>thing where it is reduced to fundamental elements, an assembly
>abstraction if you will.  That way, "dangerous" concepts such
>as post-increment, etc. can be safely hidden away, but we can
>still give allow them to think in pure data manipulation terms.

Ahh, like C.  :)

But even then, students should not be thinking in terms of tables of bytes
which they manipulate, but in terms of objects which they manipulate.

>The problem is that we *can't* think purely abstractly,
>otherwise we end up with slow crap code.

Nonsense.  A well designed and considered abstraction will generally lend
itself to an efficient and elegant implementation.  An ill-considered
abstraction will spend more time on cruft than it will on solving the problem.

I've heard that 50% of the articles Byte gets are marginal optimizations to
bubblesort.  People with a good understanding of what operations they are
using to express the algorithm are finding real improvements, frequently 40%.
Unfortunately, it's still an N^2 algorithm.

The code bloat problem is almost invariably a result of an ill-considered
abstraction.  Someone comes up with a first approximation of a solution
(bubblesort, for the sorting problem).  Then management sees that it appears
to run, and ships it.  Poof!  Time that should have been spent writing it
correctly, taking advantage of the mistakes made in the prototype, turns into
time spent trying desparately to get a fundementally flawed product to market,
and keep it running.  No one ever gets around to doing a good job of the
initial design.

>It is simply not
>possible to ignore the way code is structured, and completely
>depend on the compiler to save us.  That is just not the
>real world.

No, but I have never seen a good algorithm that didn't lend itself to elegant
and efficient implementation.  If we do decent designs first, and worry about
implementation second, we will find the implementation to be pleasant, easy,
and efficient.

>At least not my world, where I have to pack as many users
>as possible onto one CPU.

Compare the *efficiency* for this purpose of Unix, which is designed, and
MS-DOS, which has had millions of dollars thrown at making it as efficient as
possible.  Compare also things like NT and Berkeley Unix.  You *have* to do
your design in theoretical terms before you think about implementation, or you
end up with a system where 32 megs is seen as too small to run multiple users,
and you need a third party add-on to do it anyway.

The Berkeley people have thrown out more code than the system has in it.  The
algorithms are designed based on the *algorithmic* weaknesses of previous
designs.  Hardware efficiency is evaluated only after you've found a good
algorithm.  And they get excellent performance.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

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

[Tim Behrendsen]

Peter Seebach <seebs@solutions.solon.com> wrote in article
<4uah1k$b2o@solutions.solon.com>...
> In article <01bb83f5$923391e0$87ee6fce@timpent.airshields.com>,
> Tim Behrendsen <tim@airshields.com> wrote:
> >I agree; my point is that I think the student learns more if they
> >are thinking purely in terms of fundamental operations (which are
> >still abstractions above the raw hardware components), rather
> >than layers and layers of syntax that hide the essential essence
> >of what the computer is doing.
> 
> But your concept of what the "fundemental operations" are is completely
tied
> up in how specific hardware you've seen operates.  Algorithms exist in
terms
> of abstract operations, not moves and branches.

Please name me the hardware that does not use moves and branches.

> Something like CWEB might be a good language in which to learn
algorithms.
> Scheme might too.
> 
> Let's look at a specific algorithm; the infamous gcd(x, y).
> 
> In C, we write
> 
> 	int
> 	gcd(int x, int y) {
> 		if (y == 0)
> 			return x;
> 		return gcd(y, (x % y));
> 	}
> 
> or something similar.
> 
> What's important here is not any theories people may have about where the
x
> and y are stored, or how a stack works, but the concept that you can
define an
> algorithm in terms of a previous case.  Learning that the if() may be
> implemented with "a branch" does not help the student understand how the
> *algorithm* works, it helps the student understand how the *compiler*
works.
> These are distinct things.

This is an interesting case, because it is somewhat inefficently
implemented.  If you're interested in speed, you would do...

int gcd(int x, int y) {
    int z;
    while (y != 0)
        z = y; y = x % y; x = z;
    return(y);
}

Using my AIX compiler, I get a nominal improvement of about
10%, mostly because the speed of the modulo is much slower
than the inefficiency of recursion.

My point is that how does a C programmer know that recursive
implementations are somewhat inefficient?  Recently the C/C++
Users Journal had a little bite-sized article about a
general looping algorithm, where you could specify the number
of nested loops in a dynamic fashion.  It was implemented
recursively.  I wrote a letter back reimplementing the
algorithm non-recursively, and got like a 40% increase in
speed.

These sorts of issues are where code bloat comes from, and
it comes from naive implementations of "valid C syntax".

> >If programming is reduced to fundamentals of move, arithmetic,
> >test, branch, etc it prevents the student from leaning on the
> >abstraction rather than truly understanding the solution to the
> >problem.  In other words, if they can express it in the above
> >terms, you *know* they understand the solution.
> 
> But it also prevents them from learning the abstraction, and truly
> understanding the *principle* of the solution.

If the C abstraction is good, more abstraction must be better
then.  How about we teach everything in APL, where we can
*really* abstract away the details?  No data types, full
array operations.  Talk about easy quicksort!  I can write it
in one line of code using a handful of operations (my APL
is *really* rusty, so I can't give the example).

The student learns Quicksort, there is no question about it.
But what have they *really* learned?

[snip]
> Nonsense.  A well designed and considered abstraction will generally lend
> itself to an efficient and elegant implementation.  An ill-considered
> abstraction will spend more time on cruft than it will on solving the
problem.

Like recursive algorithms?

[snip]
> >It is simply not
> >possible to ignore the way code is structured, and completely
> >depend on the compiler to save us.  That is just not the
> >real world.
> 
> No, but I have never seen a good algorithm that didn't lend itself to
elegant
> and efficient implementation.  If we do decent designs first, and worry
about
> implementation second, we will find the implementation to be pleasant,
easy,
> and efficient.

Well, now you have (see above) :)

> >At least not my world, where I have to pack as many users
> >as possible onto one CPU.
> 
> Compare the *efficiency* for this purpose of Unix, which is designed, and
> MS-DOS, which has had millions of dollars thrown at making it as
efficient as
> possible.  Compare also things like NT and Berkeley Unix.  You *have* to
do
> your design in theoretical terms before you think about implementation,
or you
> end up with a system where 32 megs is seen as too small to run multiple
users,
> and you need a third party add-on to do it anyway.
> 
> The Berkeley people have thrown out more code than the system has in it. 
The
> algorithms are designed based on the *algorithmic* weaknesses of previous
> designs.  Hardware efficiency is evaluated only after you've found a good
> algorithm.  And they get excellent performance.

Agreed; but there are general principles that can be learned
across *all* architectures.  See follow up to Dan Pop post for
example of this.

-- Tim Behrendsen (tim@airshields.com)

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

[Peter Seebach]

In article <01bb853b$ca4c8e00$87ee6fce@timpent.airshields.com>,
Tim Behrendsen <tim@airshields.com> wrote:
>> But your concept of what the "fundemental operations" are is completely
>tied
>> up in how specific hardware you've seen operates.  Algorithms exist in
>terms
>> of abstract operations, not moves and branches.

>Please name me the hardware that does not use moves and branches.

That's not the *point*.  Can you name me hardware with no protons?  Can you
name me hardware students are likely to learn on that doesn't use 5 volt
power on the chip?

However, the algorithm is *NOT DEPENDANT ON* moves and branches.  I can
do quicksort.  In my head.  On paper.  I can sit down, with a pencil, and
implement quicksort.  You can say "these operations correspond to moves and
branches", but really, moves and branches are corresponding to more general
operations.  If you teach the students that it's all moves and branches, they
end up with more understanding of the specific hardware you teach them on, and
current trends in CPU design, *and less of the algorithm*.

I think algorithms should be taught on paper.  *Away* from implementations
on computer.

Believe me, you understand quicksort much better after *DOING* it than you
can from writing any reasonable number of implementations.

>> In C, we write

>> 	int
>> 	gcd(int x, int y) {
>> 		if (y == 0)
>> 			return x;
>> 		return gcd(y, (x % y));
>> 	}

>This is an interesting case, because it is somewhat inefficently
>implemented.  If you're interested in speed, you would do...

>int gcd(int x, int y) {
>    int z;
>    while (y != 0)
>        z = y; y = x % y; x = z;
>    return(y);
>}

Yes, you would.  But so would at least one compiler I use.  Internally.

It doesn't *matter*.  The realization is that, for non-zero x and y, the
greatest common divisor of x and y is conveniently the greatest common
divisor of y and (x mod y).  *THAT* is the algorithm.  The rest is fluff
and nonsense.  You can do that operation on paper, too.

>Using my AIX compiler, I get a nominal improvement of about
>10%, mostly because the speed of the modulo is much slower
>than the inefficiency of recursion.

So?

What numbers are students entering that we *CARE* about the 10% speed
difference?  Optimization is an interesting thing to look at, but has
nothing to do with algorithms.

>My point is that how does a C programmer know that recursive
>implementations are somewhat inefficient?

The C programmer doesn't.  And at least one compiler has been known
to optimize tail-recursion into iteration, sometimes even in the 2-function
case.

>Recently the C/C++
>Users Journal had a little bite-sized article about a
>general looping algorithm, where you could specify the number
>of nested loops in a dynamic fashion.  It was implemented
>recursively.  I wrote a letter back reimplementing the
>algorithm non-recursively, and got like a 40% increase in
>speed.

Neat.  And?  The key here is that, once they showed you *the algorithm*, you
could implement it however you want.  The algorithm itself does not depend on
your speed.

>These sorts of issues are where code bloat comes from, and
>it comes from naive implementations of "valid C syntax".

No, they aren't.  All of those put together wouldn't explain code bloat.

We are seeing programs that are a factor of ten, or more, larger than we think
they are.  These would have to be *mind-numbing* idiocy.

Microoptimizing will not fix it.  Teaching people about *real* design
principles will.

It's worth observing good programmers rewriting.  A good programmer will
add features and cut the size of a program slightly; a bad programmer will
bloat it hugely to add the feature.  (Assuming the original program to be
mediocre.)

A good design will save more space and time than any amount of optimization of
a bad design.

>> But it also prevents them from learning the abstraction, and truly
>> understanding the *principle* of the solution.

>If the C abstraction is good, more abstraction must be better
>then.  How about we teach everything in APL, where we can
>*really* abstract away the details?  No data types, full
>array operations.  Talk about easy quicksort!  I can write it
>in one line of code using a handful of operations (my APL
>is *really* rusty, so I can't give the example).

I sorta favor lisp, which I don't know, but which is elegant and readable.

>The student learns Quicksort, there is no question about it.
>But what have they *really* learned?

They've learned the algorithm itself.  If you want to teach them about
optimization and efficiency, go right ahead, but distinguish O(n) vs O(N^2)
type efficiency from the kinds of efficiency you're talking about.

Remember, that O() includes arbitrary constant multipliers and additions.
8N is just the same as N in complexity.

I think it's a cool idea to teach people how to turn an 8N into a 4N
algorithm.  I don't think it's part of the algorithm, I think it's a different
thing.

>> Nonsense.  A well designed and considered abstraction will generally lend
>> itself to an efficient and elegant implementation.  An ill-considered
>> abstraction will spend more time on cruft than it will on solving the
>problem.

>Like recursive algorithms?

I'm not sure what you're referring back to.  Recursion is one of the first
things I look to eliminate if I have an expensive implementation of what I
know to be a good algorithm.  But if the cost is small, it tends to stay,
because it's frequently obvious how it's supposed to work.

>Agreed; but there are general principles that can be learned
>across *all* architectures.  See follow up to Dan Pop post for
>example of this.

Sure, there are.  And these, I think, can reasonably be taught.  But that
teaching doesn't need any assembly.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

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

[Tim Behrendsen]

Peter Seebach <seebs@solutions.solon.com> wrote in article
<4udb2o$7io@solutions.solon.com>...
> >> In C, we write
> 
> >> 	int
> >> 	gcd(int x, int y) {
> >> 		if (y == 0)
> >> 			return x;
> >> 		return gcd(y, (x % y));
> >> 	}
> 
> >This is an interesting case, because it is somewhat inefficently
> >implemented.  If you're interested in speed, you would do...
> 
> >int gcd(int x, int y) {
> >    int z;
> >    while (y != 0)
> >        z = y; y = x % y; x = z;
> >    return(y);
> >}
> 
> Yes, you would.  But so would at least one compiler I use.  Internally.

Which compiler is that?  I would like to see the compiler that
unravels recursion into non-recursive algorithms.
 
> It doesn't *matter*.  The realization is that, for non-zero x and y, the
> greatest common divisor of x and y is conveniently the greatest common
> divisor of y and (x mod y).  *THAT* is the algorithm.  The rest is fluff
> and nonsense.  You can do that operation on paper, too.
> 
> >Using my AIX compiler, I get a nominal improvement of about
> >10%, mostly because the speed of the modulo is much slower
> >than the inefficiency of recursion.
> 
> So?
> 
> What numbers are students entering that we *CARE* about the 10% speed
> difference?  Optimization is an interesting thing to look at, but has
> nothing to do with algorithms.

That is ivory tower insanity!  :)

It has *everthing* to do with algorithms.  You showed me a recursive
algorithm, I rewrote it to be faster.  The fact that in this case
it's only 10% is irrelevent; for another algorithm it could have
been much more (compare recursive v.s. non-recursive quicksort).

I consider a recursive solution to be a different algorithm than a
non-recursive one, although I realize that is arguably an
implementation issue.

Not teaching students about optimization is why we have such
a code-bloat problem right now.  They think there is no difference
by coding something.

> >My point is that how does a C programmer know that recursive
> >implementations are somewhat inefficient?
> 
> The C programmer doesn't.  And at least one compiler has been known
> to optimize tail-recursion into iteration, sometimes even in the
2-function
> case.

Big deal, one compiler does it, and I would like to see how
it handles more complex cases.  The point is that in the
real world, these issues make big differences.

> >These sorts of issues are where code bloat comes from, and
> >it comes from naive implementations of "valid C syntax".
> 
> No, they aren't.  All of those put together wouldn't explain code bloat.
> 
> We are seeing programs that are a factor of ten, or more, larger than we
think
> they are.  These would have to be *mind-numbing* idiocy.
> 
> Microoptimizing will not fix it.  Teaching people about *real* design
> principles will.

What "real" design principles are you referring to?

If every algorithm is written efficiently and correctly, the
cumulative effect is a well written product.

> It's worth observing good programmers rewriting.  A good programmer will
> add features and cut the size of a program slightly; a bad programmer
will
> bloat it hugely to add the feature.  (Assuming the original program to be
> mediocre.)
> 
> A good design will save more space and time than any amount of
optimization of
> a bad design.

Agreed.  But a bad implementation of a good design will destroy
a product just as easily.

> >The student learns Quicksort [in APL], there is no question about it.
> >But what have they *really* learned?
> 
> They've learned the algorithm itself.  If you want to teach them about
> optimization and efficiency, go right ahead, but distinguish O(n) vs
O(N^2)
> type efficiency from the kinds of efficiency you're talking about.
> 
> Remember, that O() includes arbitrary constant multipliers and additions.
> 8N is just the same as N in complexity.
> 
> I think it's a cool idea to teach people how to turn an 8N into a 4N
> algorithm.  I don't think it's part of the algorithm, I think it's a
different
> thing.

Agreed.  That's why I think that starting out implementing
algorithms so that they inherently see the flow of the data
helps to understand these issues.  If you're doing quicksort,
*data moves* no matter what the architecture is, and the more
movement, the less efficiency.

If I implemented Quicksort in APL, say (which has direct
manipulation of arrays in one operation), the student would
not see the movement, because they would just see the computer
doing the array "in one fell swoop", but wouldn't really
experience the fact that the computer doesn't really do it
that way in reality.

> >> Nonsense.  A well designed and considered abstraction will generally
lend
> >> itself to an efficient and elegant implementation.  An ill-considered
> >> abstraction will spend more time on cruft than it will on solving the
> >problem.
> 
> >Like recursive algorithms?
> 
> I'm not sure what you're referring back to.  Recursion is one of the
first
> things I look to eliminate if I have an expensive implementation of what
I
> know to be a good algorithm.  But if the cost is small, it tends to stay,
> because it's frequently obvious how it's supposed to work.

But why do you look to eliminate recursion in the expensive case?
It is part of the C standard, it is perfectly valid C syntax.

-- Tim Behrendsen (tim@airshields.com)

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

[Peter Seebach]

In article <01bb8569$9910dca0$87ee6fce@timpent.airshields.com>,
Tim Behrendsen <tim@airshields.com> wrote:
>Peter Seebach <seebs@solutions.solon.com> wrote in article
><4udb2o$7io@solutions.solon.com>...
>> >> In C, we write

>> >> 	int
>> >> 	gcd(int x, int y) {
>> >> 		if (y == 0)
>> >> 			return x;
>> >> 		return gcd(y, (x % y));
>> >> 	}

>> >This is an interesting case, because it is somewhat inefficently
>> >implemented.  If you're interested in speed, you would do...

>> >int gcd(int x, int y) {
>> >    int z;
>> >    while (y != 0)
>> >        z = y; y = x % y; x = z;
>> >    return(y);
>> >}

>> Yes, you would.  But so would at least one compiler I use.  Internally.

>Which compiler is that?  I would like to see the compiler that
>unravels recursion into non-recursive algorithms.

gcc handles trivial tail recursion, or so we're told.

>> >Using my AIX compiler, I get a nominal improvement of about
>> >10%, mostly because the speed of the modulo is much slower
>> >than the inefficiency of recursion.

>> What numbers are students entering that we *CARE* about the 10% speed
>> difference?  Optimization is an interesting thing to look at, but has
>> nothing to do with algorithms.

>That is ivory tower insanity!  :)

It is also the essense of learning the difference between algorithm and
implementation, which are very different arts.

>It has *everthing* to do with algorithms.  You showed me a recursive
>algorithm, I rewrote it to be faster.  The fact that in this case
>it's only 10% is irrelevent; for another algorithm it could have
>been much more (compare recursive v.s. non-recursive quicksort).

>I consider a recursive solution to be a different algorithm than a
>non-recursive one, although I realize that is arguably an
>implementation issue.

For the greatest common divisor, it certainly is.  It's like realizing
that you can say "a %= b" instead of "while (a > b) a -= b;".  It doesn't
change the *meaning*, only the representation.

>Not teaching students about optimization is why we have such
>a code-bloat problem right now.  They think there is no difference
>by coding something.

That doesn't make them identical fields of study.  Algorithms and
optimization are two different things.

>Big deal, one compiler does it, and I would like to see how
>it handles more complex cases.  The point is that in the
>real world, these issues make big differences.

Then real-world programmers will, rather than guessing about what compilers
are and aren't smart enough to do, try several implementations and benchmark
them.

>> Microoptimizing will not fix it.  Teaching people about *real* design
>> principles will.

>What "real" design principles are you referring to?

The basic questions of what data types to use to represent your model, and
what model to use to represent your problem.  If I design a word processor
as a set of operations, each of which is always done in sequence, I may end
up with a loop like
	while (1) {
		update_menu();
		update_display();
		update_cursor();
		...
		process_last_command();
		get_command();
	}

in which each command is processed by setting flags, which each of the various
update functions reacts to.  For instance, when I select "bold", the function
which redraws the entire display every time through the loop gets a flag set
to embolden something.

You could make your display algorithm take less than 1% of the time a "normal"
one would, and this program will *still* suck.

>If every algorithm is written efficiently and correctly, the
>cumulative effect is a well written product.

Unless the basic design is fundementally flawed.

Lest you say that the above is too stupid to be imagined, let's remember how
much harder good design gets as the goals get larger and more complicated.

Further, I have seen *an actual commercial product* whose inner loop is
essentially a large set of nested switch statements to process the cursor
location in terms of which menus are active.  An actual reported bug, since
fixed, was that moving the mouse over a certain button *without clicking on
it* inserted text if you had previously selected a certain other button.

The person who designed that *didn't* design it, and no amount of improvement
in the "efficiency" will ever correct that.

>Agreed.  But a bad implementation of a good design will destroy
>a product just as easily.

I don't think so.  It'll be easier to correct, for once.

>Agreed.  That's why I think that starting out implementing
>algorithms so that they inherently see the flow of the data
>helps to understand these issues.  If you're doing quicksort,
>*data moves* no matter what the architecture is, and the more
>movement, the less efficiency.

Perhaps; however, counting move instructions in the code won't show you how
much the data moves.  A "good" bubblesort may easily have fewer moves.

>If I implemented Quicksort in APL, say (which has direct
>manipulation of arrays in one operation), the student would
>not see the movement, because they would just see the computer
>doing the array "in one fell swoop", but wouldn't really
>experience the fact that the computer doesn't really do it
>that way in reality.

So talk to them about it.  Take the opportunity to clarify something about
APL.

>But why do you look to eliminate recursion in the expensive case?
>It is part of the C standard, it is perfectly valid C syntax.

Because my experience has shown that, often, it produces slow code, and
I can produce better results iteratively.  But I don't worry about speed until
I've shown that my design is functional.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

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

[Richard A. O'Keefe]

Recursive gcd:
    int gcd(int x, int y) {
	if (y == 0) return x;
	return gcd(y, x%y);
    }

Iterative gcd:
    int gcd(int x, int y) {
	int z;
	while (y != 0) z = y, y = x%y, x = z;
	return y;
    }

Peter Seebach <seebs@solutions.solon.com> wrote that
the compiler he uses would generate the equivalent of the iterative
code from the recursive source.

"Tim Behrendsen" <tim@airshields.com> asked incredulously
>Which compiler is that?  I would like to see the compiler that
>unravels recursion into non-recursive algorithms.

GCC 2.7.2 will do it.  So will SPARCompiler C 4.0.
(I mention those versions because they are the versions I have.)
So will any even half-way decent Lisp or Scheme compiler.

>It has *everthing* to do with algorithms.  You showed me a recursive
>algorithm, I rewrote it to be faster.  The fact that in this case
>it's only 10% is irrelevent

Actually, it isn't irrelevant.  The speed up is only a by a constant
factor, and all it tells you is that you are using a compiler that
does a really bad job of compiling function calls.  Any effort spent
speeding up this version of gcd is wasted, because GCD can be implemented
to have the same cost as division.  On a machine like a V7 SPARC, where
there was no division instruction, a well-written formally recursive
gcd could be as fast as a single x%y.

>for another algorithm it could have
>been much more (compare recursive v.s. non-recursive quicksort).

>I consider a recursive solution to be a different algorithm than a
>non-recursive one, although I realize that is arguably an
>implementation issue.

This is a lot like calling a procedure that uses an 'if (...) goto'
a different *algorithm* from the same procedure expressed using 'while'.
We have known since the 70s how to compile tail calls into jumps, and
since the late 70s at least have had a substantial body of theory about
how to automatically translate many uses of recursion into iteration
at the implementation level.  Turning tail calls into jumps is the very
simplest of these techniques.  (And yes, the loop thus uncovered can of
course be unrolled, just like any other loop.)

If you encounter any significant difference in speed between recursive
and non-recursive quicksort, all that tells you is that it is time to
change compilers.  Come to that, if you really cared about speed you
wouldn't be using quicksort anyway.

>If I implemented Quicksort in APL, say (which has direct
>manipulation of arrays in one operation), 

Given the grade-up primitive, I can't think why anybody would _want_
to implement quicksort in APL.

>the student would
>not see the movement, because they would just see the computer
>doing the array "in one fell swoop", but wouldn't really
>experience the fact that the computer doesn't really do it
>that way in reality.

Interestingly enough, the APL sorting primitive DOESN'T move the data
at all.  It returns a permutation vector.  The APL idiom for sorting is
	X[.GradeUP X]
where the necessary movement is quite visible.

-- 
Fifty years of programming language research, and we end up with C++ ???
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

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

[Tim Behrendsen]

Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote in article
<4urqam$r9u@goanna.cs.rmit.edu.au>...
> 
> If you encounter any significant difference in speed between recursive
> and non-recursive quicksort, all that tells you is that it is time to
> change compilers.  Come to that, if you really cared about speed you
> wouldn't be using quicksort anyway.

Yes, but you can use the "get a better compiler" argument to
justify anything.  Real programs run on real computers using
real compilers.  The "Super-Duper Ivory Tower 9000 Compiler"
just doesn't exist.

> >If I implemented Quicksort in APL, say (which has direct
> >manipulation of arrays in one operation), 
> 
> Given the grade-up primitive, I can't think why anybody would _want_
> to implement quicksort in APL.

Well, I realize that APL has a built-in sort, but the point
was in learning quicksort through an implementation in APL.

> >the student would
> >not see the movement, because they would just see the computer
> >doing the array "in one fell swoop", but wouldn't really
> >experience the fact that the computer doesn't really do it
> >that way in reality.
> 
> Interestingly enough, the APL sorting primitive DOESN'T move the data
> at all.  It returns a permutation vector.  The APL idiom for sorting is
> 	X[.GradeUP X]
> where the necessary movement is quite visible.

But the reality is *not* visible.  What has the student really
learned?

-- Tim Behrendsen (tim@airshields.com)

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

[Richard A. O'Keefe]

"Tim Behrendsen" <tim@airshields.com> writes:

>Yes, but you can use the "get a better compiler" argument to
>justify anything.  Real programs run on real computers using
>real compilers.  The "Super-Duper Ivory Tower 9000 Compiler"
>just doesn't exist.

This is a bogus argument, because the better compilers *I* was talking
about ACTUALLY EXIST.  As a particular example, GCC does self-tail-call
optimisation and SPARCompiler C 4.0 does general tail-call optimisation.
Compilers for other languages doing very well indeed with procedures
include Mercury and Stalin.

It does nobody any good to pretend that good compilers do not exist.

>> Interestingly enough, the APL sorting primitive DOESN'T move the data
>> at all.  It returns a permutation vector.  The APL idiom for sorting is
>> 	X[.GradeUP X]
>> where the necessary movement is quite visible.

>But the reality is *not* visible.  What has the student really
>learned?

Scuse please?  WHAT reality?  The reality in this case is that you can
in fact in just about any reasonable programming language sort data
WITHOUT moving it.  Indeed, for a number of statistical and numeric
calculations, the permutation vector is more useful than moving the
data would be.  The reality could well be a sorting network made of
comparators and wires.  On the machine I'm posting from, sorting
_could_ be done using parallel processes (not concurrent, parallel;
the machine has more than one CPU).  And of course there have been
at least two machines built that directly executed APL; APL _was_
their assembly language.

In the case of APL, the student has learned to express his/her intent
in a concise notation with a clear mathematical semantics (this applies
to APL primitives only, alas; the rest of APL is rather murkier) which
permits effective reasoning at a much higher level.

"Mathematical skills" came into it somewhere.

Consider the insertion sort and bubble sort procedures posted in
comp.lang.ada recently.  I think it is easier to see the potential
optimisation in
	X .IN A[.GRADE_UP A]
(written as 6 characters) than to see the potential optimisation in
	subtype Element is Float;
	subtype Index is Integer range 1..N;
	type Vector is array (Index) of Element;
	A : Vector := ...;
	X : Element := ...;
	I : Index;

	procedure Sort is new Insertion_Sort;
	function Find is new Linear_Search;

    begin
	Sort(A);
	I := Find(A, X);

This does not establish the superiority of APL over Ada as a general
programming language, only that it makes a much better *design* language
for some (but important) parts of some (but important) applications.

The ability to do "algebraic" reasoning about a program is quite as
important as the ability to do assembly level thinking (which I agree
is important).  When you really need big improvements in performance,
you get it from the high level thinking.


-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

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

[Alan Bowler]

In article <4vbbf6$g0a@goanna.cs.rmit.edu.au> ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
>"Tim Behrendsen" <tim@airshields.com> writes:
>
>>Yes, but you can use the "get a better compiler" argument to
>>justify anything.  Real programs run on real computers using
>>real compilers.  The "Super-Duper Ivory Tower 9000 Compiler"
>>just doesn't exist.
>
>This is a bogus argument, because the better compilers *I* was talking
>about ACTUALLY EXIST.  As a particular example, GCC does self-tail-call
>optimisation and SPARCompiler C 4.0 does general tail-call optimisation.

The compiler implemention may have chosen not to to implement this
optimization.  There are still systems where the there are limits on
the resources that the compiler itself has available, and the so the
total amount of code in the compiler has a practical limit.  Also
tail call optimizations may conflict with other useful extensions
such as the old nargs() function.

While you should not spend excessive time prematurely optimizing code,
you also should not bloat your code with junk that depends on a fancy
optimizer simply to get decent performance.

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

[Tim Behrendsen]

Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote in article
<4vbbf6$g0a@goanna.cs.rmit.edu.au>...
> "Tim Behrendsen" <tim@airshields.com> writes:
> 
> >Yes, but you can use the "get a better compiler" argument to
> >justify anything.  Real programs run on real computers using
> >real compilers.  The "Super-Duper Ivory Tower 9000 Compiler"
> >just doesn't exist.
> 
> This is a bogus argument, because the better compilers *I* was talking
> about ACTUALLY EXIST.  As a particular example, GCC does self-tail-call
> optimisation and SPARCompiler C 4.0 does general tail-call optimisation.
> Compilers for other languages doing very well indeed with procedures
> include Mercury and Stalin.
> 
> It does nobody any good to pretend that good compilers do not exist.

They may exist, but does it exist universally?  The point is that to
go out of your way to use left-field optimizations is just bad
portability practice.  For example, if someone does this:

void sub(char *s)
{
    ...
    if (strlen(s) == 0) {     /* check for null string */
        ...
    }
}

and they know it's stupid, but they also know the compiler
just happens to have optimization for it, should they
still be shot?  "Diana, get me my rifle."
 
> >> Interestingly enough, the APL sorting primitive DOESN'T move the data
> >> at all.  It returns a permutation vector.  The APL idiom for sorting
is
> >> 	X[.GradeUP X]
> >> where the necessary movement is quite visible.
> 
> >But the reality is *not* visible.  What has the student really
> >learned?
> 
> Scuse please?  WHAT reality?  The reality in this case is that you can
> in fact in just about any reasonable programming language sort data
> WITHOUT moving it.  Indeed, for a number of statistical and numeric
> calculations, the permutation vector is more useful than moving the
> data would be.  The reality could well be a sorting network made of
> comparators and wires.  On the machine I'm posting from, sorting
> _could_ be done using parallel processes (not concurrent, parallel;
> the machine has more than one CPU).  And of course there have been
> at least two machines built that directly executed APL; APL _was_
> their assembly language.

Wait, hold the phone!  "Sorts the data without moving it"?  What,
is APL's sorting algorithm O(1)?  Yes, it may not actually get
sorted until it gets printed, but that's irrelevent to the fact
that it eventually gets sorted.

> In the case of APL, the student has learned to express his/her intent
> in a concise notation with a clear mathematical semantics (this applies
> to APL primitives only, alas; the rest of APL is rather murkier) which
> permits effective reasoning at a much higher level.
> 
> "Mathematical skills" came into it somewhere.

Indeed, and I think APL is kind of a neat language to learn.  But
it hides so much about the internals of the computer, that I think
it would give a student too many false impressions about how
things really work.

> [snip] 
> The ability to do "algebraic" reasoning about a program is quite as
> important as the ability to do assembly level thinking (which I agree
> is important).  When you really need big improvements in performance,
> you get it from the high level thinking.

I actually quite agree with this; it's how you get the "high level
thinking" that I think is an issue.  Even in a mathematical proof,
you are talking about a sequence of micro-steps.  Yes, most
proofs are built of other proofs, but I think this is more of
a "proof macro language" than a "high-level mathematical
language" (whatever that means).  My "proof" of this is the
fact that when a proof is used within another proof, you can
pretty much do a straight insertion of the lower-level
"macro proof" into the text of the proof-to-be-proven.  There
is no "proof compilation", so to speak (I don't know if that
last made *any* sense :-) )

-- Tim Behrendsen (tim@airshields.com)

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

[Bengt Richter]

"Tim Behrendsen" <tim@airshields.com> wrote:
[...]
>Wait, hold the phone!  "Sorts the data without moving it"?  What,
>is APL's sorting algorithm O(1)?  Yes, it may not actually get
>sorted until it gets printed, but that's irrelevent to the fact
>that it eventually gets sorted.
	Does that mean that your concept of the essential aspect of
sorting is putting the data into sort order, rather than establishing
the order itself? The respective timings say otherwise to me ;-)
[...]

Regards,
Bengt Richter

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

[Tim Behrendsen]

Bengt Richter <bokr@accessone.com> wrote in article
<4vgs4j$evl@news.accessone.com>...
> "Tim Behrendsen" <tim@airshields.com> wrote:
> [...]
> >Wait, hold the phone!  "Sorts the data without moving it"?  What,
> >is APL's sorting algorithm O(1)?  Yes, it may not actually get
> >sorted until it gets printed, but that's irrelevent to the fact
> >that it eventually gets sorted.
> 	Does that mean that your concept of the essential aspect of
> sorting is putting the data into sort order, rather than establishing
> the order itself? The respective timings say otherwise to me ;-)

I'm not sure what you're trying to say, but if I have a data set,
and I set a bit that says "this data set has the property of
being ordered", then technically I have an ordered data set in
O(1) time.  Now, if I do an add reduction (terminology?), the
sorting doesn't actually have to be done, and I've saved some
CPU cycles.

But all that's not the point.  If my point is to take a vector as
input, order it, and then display it on the screen, the vector
will be sorted.  And sorting something requires moving it into
a sorted order.

-- Tim Behrendsen (tim@airshields.com)

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

[Bengt Richter]

"Tim Behrendsen" <tim@airshields.com> wrote:

>Bengt Richter <bokr@accessone.com> wrote in article
><4vgs4j$evl@news.accessone.com>...
>> "Tim Behrendsen" <tim@airshields.com> wrote:
>> [...]
>> >Wait, hold the phone!  "Sorts the data without moving it"?  What,
>> >is APL's sorting algorithm O(1)?  Yes, it may not actually get
>> >sorted until it gets printed, but that's irrelevent to the fact
>> >that it eventually gets sorted.
>> 	Does that mean that your concept of the essential aspect of
>> sorting is putting the data into sort order, rather than establishing
>> the order itself? The respective timings say otherwise to me ;-)

>I'm not sure what you're trying to say, but if I have a data set,
>and I set a bit that says "this data set has the property of
>being ordered", then technically I have an ordered data set in
>O(1) time.  Now, if I do an add reduction (terminology?), the
>sorting doesn't actually have to be done, and I've saved some
>CPU cycles.

>But all that's not the point.  If my point is to take a vector as
>input, order it, and then display it on the screen, the vector
>will be sorted.  And sorting something requires moving it into
>a sorted order.

If you have (please overlook syntax bloopers)
  struct tBigComplexThing {
    ... blah, blah
  } aBigArrayOfThem[kBig];
you could sort them by moving the data around, and then print it
by a loop such as for(i=0;i<kBig;i++)
   printf("theformat",aBigArrayOfThem[i].anItem, etc..);
You could also sort by using an array
  int aiPermute[kbig];
initialized by 
  for(i=0;i<kBig;i++) aiPermute[i]=i;
and then use a quicksort or whatever so that the
integer elements of aiPermute[] get moved around instead
of the tBigComplexThing elements of aBigArrayOfThem[].
The comparison function just has to take two indices into
aiPermute[], e.g., j and k, and compare
  aBigArrayOfThem[aiPermute[j]].someField
and
  aBigArrayOfThem[aiPermute[k]].someField
and operate on aiPermute[] as if it had compared
  aiPermute[j] with aiPermute[k].
I take it something like this is involved in the APL
use of a "permutation vector" cited in a previous post.

Anyway, now you can do your print by the loop
  for(i=0;i<kBig;i++)
    printf("theformat",aBigArrayOfThem[aiPermute[i]].anItem, etc..);
and expensive movements of the original data don't have to be part
of the sorting process, even though you could say that the data
eventually gets "moved into sorted order" into the output stream.
But the latter happens in linear time, and is not relevant to the
sorting algorithm executed beforehand.
	To summarize what I was getting at, I think
"sorting data without moving it" is a fair description of sorting
data by reordering references to it, since the sorting does not
involve moving the data. I don't think subsequent extraction of
the data itself into an ordered stream can be called sorting.

Regards,
Bengt Richter

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

[Maurice M. Carey IV]

So.

Bengt Richter <bokr@accessone.com> wrote in article
<5085ou$ra7@kanga.accessone.com>...
> "Tim Behrendsen" <tim@airshields.com> wrote:
> 
> >Bengt Richter <bokr@accessone.com> wrote in article
> ><4vgs4j$evl@news.accessone.com>...
> >> "Tim Behrendsen" <tim@airshields.com> wrote:
> >> [...]
> >> >Wait, hold the phone!  "Sorts the data without moving it"?  What,
> >> >is APL's sorting algorithm O(1)?  Yes, it may not actually get
> >> >sorted until it gets printed, but that's irrelevent to the fact
> >> >that it eventually gets sorted.
> >> 	Does that mean that your concept of the essential aspect of
> >> sorting is putting the data into sort order, rather than establishing
> >> the order itself? The respective timings say otherwise to me ;-)
> 
> >I'm not sure what you're trying to say, but if I have a data set,
> >and I set a bit that says "this data set has the property of
> >being ordered", then technically I have an ordered data set in
> >O(1) time.  Now, if I do an add reduction (terminology?), the
> >sorting doesn't actually have to be done, and I've saved some
> >CPU cycles.
> 
> >But all that's not the point.  If my point is to take a vector as
> >input, order it, and then display it on the screen, the vector
> >will be sorted.  And sorting something requires moving it into
> >a sorted order.
> 
> If you have (please overlook syntax bloopers)
>   struct tBigComplexThing {
>     ... blah, blah
>   } aBigArrayOfThem[kBig];
> you could sort them by moving the data around, and then print it
> by a loop such as for(i=0;i<kBig;i++)
>    printf("theformat",aBigArrayOfThem[i].anItem, etc..);
> You could also sort by using an array
>   int aiPermute[kbig];
> initialized by 
>   for(i=0;i<kBig;i++) aiPermute[i]=i;
> and then use a quicksort or whatever so that the
> integer elements of aiPermute[] get moved around instead
> of the tBigComplexThing elements of aBigArrayOfThem[].
> The comparison function just has to take two indices into
> aiPermute[], e.g., j and k, and compare
>   aBigArrayOfThem[aiPermute[j]].someField
> and
>   aBigArrayOfThem[aiPermute[k]].someField
> and operate on aiPermute[] as if it had compared
>   aiPermute[j] with aiPermute[k].
> I take it something like this is involved in the APL
> use of a "permutation vector" cited in a previous post.
> 
> Anyway, now you can do your print by the loop
>   for(i=0;i<kBig;i++)
>     printf("theformat",aBigArrayOfThem[aiPermute[i]].anItem, etc..);
> and expensive movements of the original data don't have to be part
> of the sorting process, even though you could say that the data
> eventually gets "moved into sorted order" into the output stream.
> But the latter happens in linear time, and is not relevant to the
> sorting algorithm executed beforehand.
> 	To summarize what I was getting at, I think
> "sorting data without moving it" is a fair description of sorting
> data by reordering references to it, since the sorting does not
> involve moving the data. I don't think subsequent extraction of
> the data itself into an ordered stream can be called sorting.
> 
> Regards,
> Bengt Richter
> 
> 
> 

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

[Richard A. O'Keefe]

"Tim Behrendsen" <tim@airshields.com> writes:

>They may exist, but does it exist universally?  The point is that to
>go out of your way to use left-field optimizations is just bad
>portability practice.

"Effen it wur good enough fur granpaw, it's good enough fur me."
in other words.  By the way, I find it EXTREMELY odd to call a technique
that has been known and used for nearly 20 years a "left-field" one.
Behrendsen is putting things exactly backwards;
*he* is advocating "do not use a technique in your programming language,
no matter how natural or readable it is, unless you know that every
compiler you use will implement it reasonably".  Well, I *can't* know
that.  Heck, I can't even know that
	X := X+1;
will take constant or even small time; almost all programming language
standardisers say "that's a quality of implementation issue which is
outside our scope".

For an *exact* parallel, consider function inlining.
These days, I expect a good compiler to at the very minimum support
programmer-supplied inlining hints, and the Fortran, Pascal, and C
compilers I normally use do it _automatically_.  This is another
of those optimisations which has been known and used for decades in
the Lisp community, which lets you write your program using a function
call instead of a macro.  I guess inline functions are another
"left-field optimisation".

> For example, if someone does this:

>void sub(char *s)
>{
>    ...
>    if (strlen(s) == 0) {     /* check for null string */
>        ...
>    }
>}

>and they know it's stupid, but they also know the compiler
>just happens to have optimization for it, should they
>still be shot?  "Diana, get me my rifle."

You have prejudged the issue by stipulating that the programmer
doing this KNOWS it is stupid.  To start with, can I just make the
obvious point that in a very large number of currently used languages,
the direct equivalent of this would be the very best thing to do.
There are a lot of *good* programmers out there (definition: in a
reasonable amount of time they can write readable code that works)
who would *not* "know that it's stupid".  It is, for example, much
less stupid than writing
	if (s == "") 

Let's see what is good about this code:
 - it is correct (not a NULL test, not a "" test, but a length test)
 - it is clear (much clearer to people not immersed in C than "!*s")
Doesn't look stupid to me yet.
What's bad about it?
 - it takes O(|s|) time.
BUT
 - standard optimisations like common subexpression elimination, can be
   applied, so that any number of calls to strlen(s) without any
   intervening potential change to s are no more expensive than a
   single call
 - in many applications, all or a large part of s will be processed
   if it is not empty, so the cost of sub() will be O(|s|) anyway
so it's only "stupid" if it occurs in a loop and you know your
compiler _doesn't_ move loop invariants out.

I would go so far as to say that

	int count_blanks(char const * const s) {
	    int i, r;

	    r = 0;
	    for (i = 0; i < strlen(s); i++)
		if (s[i] == ' ')
		    r++;
	    return r;
	}

is a _good_ function.  The ONLY strlen() optimisation that is needed here
is one that is completely general:  strlen() is a pure function and its
argument does not change, so the strlen(s) computation can be hoisted out
of the loop.  Since the optimisation in question is one which has been in
use since the very early Fortran days, it can hardly be called "left-field".
A compiler that _doesn't_ do this is indeed a poor compiler, these days.

Here I am actually arguing against my own inclination, because I strongly
dislike seeing strlen() used this way, and will take advantage of any
excuse to "fix" it.  I certainly tell students why not to do this.  But I
cannot in good conscience call clear correct code "stupid".

>> Scuse please?  WHAT reality?  The reality in this case is that you can
>> in fact in just about any reasonable programming language sort data
>> WITHOUT moving it.

>Wait, hold the phone!  "Sorts the data without moving it"?  What,
>is APL's sorting algorithm O(1)?

No of course not.  I didn't say that.  I said that
	in just about any reasonable programming language
[I did not say APL]
	you can sort data WITHOUT moving it
[I did not say O(1)].

My claim is that YOU CAN SORT THE DATA WITHOUT MOVING *THE DATA*.
I don't see how any sane reader could translate that into O(1),
unless perhaps said reader was under the delusion that sorting
involves nothing but movement!

>Yes, it may not actually get
>sorted until it gets printed, but that's irrelevent to the fact
>that it eventually gets sorted.

Printing is a complete irrelevancy indeed, dragged in solely by
Behrendsen.  It is another of the straw men I could well do without.

Sorting is not about movement.  It is about *determining a permutation*.
Depending on the type of the keys, it may do divisions (as in bucket
sort and radix sort) or comparisons (as in merge sort).
When you are sorting large or variable length records, it is of
practical importance that you can sort the data by returning a
permutation vector WITHOUT MOVING THE ORIGINAL DATA.  This is not
an academic point, because the permutation vector may be 10s or 100s
of times smaller than the original data.

My reference to the APL grade-up primitive made all clear:  grade-up
returns a permutation vector.  You can use a permutation vector to
access the original elements in ascending order, descending order, or
by binary search, or anything you want, without having to pay the
price of moving large records.  One of the things which made the
Bentley & McIlroy "Engineered" version of qsort() complicated was
having to work around the fact that qsort() is set up to sort large
fixed length records; writing the code to take advantage when the
elements turn out to fit into machine registers is tricky, and in
fact not portable.

>Indeed, and I think APL is kind of a neat language to learn.  But
>it hides so much about the internals of the computer, that I think
>it would give a student too many false impressions about how
>things really work.

Of course APL hides the internals of the computer.
That's what a high level language is FOR!
I've done enough programming in ESPOL (B6700 only) and BLISS-10 (DEC-10
only) to be grateful for languages that hide machine details.
I have manuals for
 - System/360
 - Z80 (somewhere)
 - 8051
 - 8086
 - 80960
 - Intergraph Clipper
 - Motorola 68000
 - Motorola 88000
 - SPARC
 - PA-RISC
 - (part of) MIPS 3000 (in Hennesey & someone).
and have studied them.  I not written assembly code for the Z80, 8051,
80960, or PA-RISC, though I have debugged other people's code for the
Z80 and 8051.  I have written assembler for the others, and for the
DEC-10, PDP-11, VAX, Pyramid, IBM RT-PC, and NS32532 (oh yes, and the
Computer Automation Alpha LSI 2 and the PRIME 400).  I know more about
the internals of computers than I really want to, and the better a job
the language I'm using does of hiding them, the better I like it.
(There is a *lot* to like about Oberon, but I cannot like Wirth's
reversion to C-style integral types.)

>I actually quite agree with this; it's how you get the "high level
>thinking" that I think is an issue.

There is an Edinburgh paper from the 70s that I want to quote from.
It came from the EMAS project.  The EMAS operating system was designed
and written at Edinburgh and written an Algol-like language called
IMP 77.  They observed that the operating system modules written by
people skilled in assembly language (and who even went to the extreme
of checking the assembly code produced by the compiler to make sure it
was efficient) tended to be
 - bigger,
 - less readable, and
 - SLOWER
than that produced by people who had a "high level language" perspective.
I'll try to remember to bring the paper in tomorrow so I can quote it
exactly.

>Even in a mathematical proof,
>you are talking about a sequence of micro-steps.  Yes, most
>proofs are built of other proofs, but I think this is more of
>a "proof macro language" than a "high-level mathematical
>language" (whatever that means).

I don't quite see proofs by duality or symmetry as simple macro
substitution.  I think your example here actually gives more comfort
to the anti-assembly camp than to your own.

I once took a masters level course on the Spinor Calculus.
The lecturer (who came from the Sorbonne) wanted to make sure we
understood the whole thing thoroughly, so he started with metamathematics
and constructed everything from the ground up.  We were nearly half way
through the course before we got to the rational numbers.  We ended up
with only two lectures that were actually about Spinors, and  I _still_
don't know what they are.  (I've started reading Penrose & Rindler to
find out.)  In that case at least, over-emphasis on "fundamentals" was
a major impediment to the high level understanding I really wanted.

For what it's worth, students here *do* get taught about computer
architecture, and they *do* get taught a bit of 68000 assembly code,
and they *do* work with little single board machines so they can try 
their 68000 code out.  But this is understood as a computer architecture
course, not as a data structures and algorithms course.  (The course
is not confined to the 68000, but that's all _they_ have to program at
that level.)

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

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

[Mark Wooding]

Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote:

>  - standard optimisations like common subexpression elimination, can be
>    applied, so that any number of calls to strlen(s) without any
>    intervening potential change to s are no more expensive than a
>    single call

and then later:

> strlen() is a pure function and its argument does not change, so the
> strlen(s) computation can be hoisted out of the loop.

Erk!  No it isn't.  A pure function is one whose value depends only on
its arguments.  sin() is pure.  strlen() isn't.

The argument to strlen() is a pointer to a string whose length we want.
It's the address, not the string itself.  Because the string can change
between calls to strlen(), it might give different results given the
same string address.  So the compiler can't just use its general `pure'
function mechanism for common-subexpression-optimising strlen()

Now, can a compiler do clever things and optimise strlen() all by
itself?  You comment that it might spot assignments to the string.  This
is true, but not all such assignments are visible to the compiler.  For
automatic buffers, this /is/ true, but (in my experience) calls to
strlen() and similar functions are comparitively rarerely used on
locally allocated buffers.  If the buffer is not local to the function,
there's no guarantee that (in an extreme case) its address hasn't been
made available to a signal handler which maliciously changes the
string's length.

Prove me wrong.
-- 
[mdw]

`When our backs are against the wall, we shall turn and fight.'
		-- John Major

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

[Kaz Kylheku]

In article <slrn523tpg.ce.mdw@excessus.demon.co.uk>,
Mark Wooding <mdw@excessus.demon.co.uk> wrote:

>Erk!  No it isn't.  A pure function is one whose value depends only on
>its arguments.  sin() is pure.  strlen() isn't.
>
>The argument to strlen() is a pointer to a string whose length we want.
>It's the address, not the string itself.  Because the string can change
>between calls to strlen(), it might give different results given the
>same string address.  So the compiler can't just use its general `pure'
>function mechanism for common-subexpression-optimising strlen()

So what, the value of X can change in between calls to sin(X) just the same way.

The strlen() call can indeed be eliminated via CSE. It has no side effects,
and its result depends only on the object being passed to it.

The value of strlen() can be readily reused if no pointer was dereferenced for
the purposes of storing a value since the last time strlen() was called with
the same subexpression, and if no constituent of the subexpression has
changed.

>Now, can a compiler do clever things and optimise strlen() all by
>itself?  You comment that it might spot assignments to the string.  This
>is true, but not all such assignments are visible to the compiler.  For

Yes they are all visible. The compiler can readily decide whether the
expression which is an argument to strlen() _could_ have changed by looking
at the statements that have occured since the invocation of strlen. There are
well known techniques for doing CSE in conjunction with pointers. The most
pessimistic approach will invalidate the register-cached results of all prior
expressions when a pointer has been dereferenced. From this assumption, you
can make finer adjustments. For example, you can deduce that if a pointer
was explicitly assigned to a particular object, only that object can be
modified via that pointer. That's because the rules of C state that pointer
arithmetic is not allowed to take a pointer outside of the object it is
pointed to (with the exception of pointing one element past the end of an
array, in which case a dereference is illegal so it amounts to the same thing
from the optimizer's point of view). Thus when a pointer is dereferenced,
and thanks to careful analysis you know that it cannot affect any constituent
objects named the subexprssion that was previously passed to strlen(), you can
safely use the register copy of that previous result (given that all the
other requirements for eliminating the subexpression have been met, of
course).

>automatic buffers, this /is/ true, but (in my experience) calls to
>strlen() and similar functions are comparitively rarerely used on
>locally allocated buffers.  If the buffer is not local to the function,
>there's no guarantee that (in an extreme case) its address hasn't been
>made available to a signal handler which maliciously changes the
>string's length.
>
>Prove me wrong.

That's easy: if you modify the data in the signal handler, you are violating
the rules for writing a conforming C program. Read what the C standard has to
say about signal handlers and global variables! 

The buffer could be modified by a function call, but in that case, you can do
the same invalidation as you would for a pointer dereference.

One pesky problem are pointers that are never explicitly initialized in the
function, but are obtained as parameters. These can potentially refer to
anything that is not local to the function, and the objects they point to can
overlap. Here is where languages with more powerful parameter passing
techniques and stronger typing have a win over C.

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

[Richard A. O'Keefe]

I wrote:
>> strlen() is a pure function and its argument does not change, so the
>> strlen(s) computation can be hoisted out of the loop.

mdw@excessus.demon.co.uk (Mark Wooding) writes:

>Erk!  No it isn't.  A pure function is one whose value depends only on
>its arguments.  sin() is pure.  strlen() isn't.

We are in dispute about words, not facts.
MOST annoyingly, my copy of the C standard has walked, so I can't refer
to the official rule book.

>The argument to strlen() is a pointer to a string whose length we want.

This is where I was using sloppy language.
The way I was using language, the argument *is* the "null-terminated
byte string" (to use C++ draft standard terminology), and the pointer
is merely the mechanism used to refer to it.

In the program fragment under discussion, it was not merely the pointer
that was constant, but the NTBS itself.

In what sense is strlen() pure?  In the sense that it depends only on
the NTBS variable which is the intended argument and not on the time
of day, the phase of the moon, the colour of the programmer's socks,
or any storage _other_ than the NTBS.

If I do
	n = strlen(s);
	/* much code that does not change s */
	/* NOT the NTBS that s refers to */
	m = strlen(s);
it is necessarily the case that m and n will be the same size_t value.

>It's the address, not the string itself.  Because the string can change
>between calls to strlen(), it might give different results given the
>same string address.  So the compiler can't just use its general `pure'
>function mechanism for common-subexpression-optimising strlen()

Yes it can:  in the sense in which I intended it (and I apologise for
not using the terminology in the New Testament aka ISO C standard)
the argument is NBTS(s), and detecing whether NBTS(s) has changed is
admittedly very difficult in the presence of aliasing, but it isn't
difficult *all* the time.

>Now, can a compiler do clever things and optimise strlen() all by
>itself?

The answer is unequivocally "Yes it CAN."  The standard allows it to,
and nothing in the code fragment I presented suggested that it s
referred to a global buffer.  In fact, most of my uses of strlen()
have been either to local buffers (which I have just filled from a
file) or to stored which I can be damn sure hasn't been touched
since last time.  (And I then save the result of strlen() and never
ever ask for it again.  We're talking about what makes sense, not
what I do.)

>You comment that it might spot assignments to the string.  This
>is true, but not all such assignments are visible to the compiler.  For
>automatic buffers, this /is/ true, but (in my experience) calls to
>strlen() and similar functions are comparitively rarerely used on
>locally allocated buffers.

In my experience, people spell comparatively with only one "i"
and "rarely" with only two "r"s.  Clearly our experience differs.

The question was not about what you do or what I do or what your
experience was or what my experience was but about whether repeated
calls are ever sensible.

>If the buffer is not local to the function,
[which makes an assumption not grounded in my code fragment]
>there's no guarantee that (in an extreme case) its address hasn't been
>made available to a signal handler which maliciously changes the
>string's length.

Well actually, such a guarantee is easy to come by:
 - if the program contains no calls to signal(), it can't happen.
 - if the buffer is local to a file, and its address doesn't leak
   outside, and no function in the file is passed to signal(),
   again, it can't happen.
 - a program that conforms to the C standard (we were talking about
   standard C, no?) may not legally set any variable external to the
   handler if that variable is not of type sig_atomic_t.  Now on _this_
   system, sig_atomic_t is int, so a *legal* signal handler, however
   malicious, may not change a char buffer.  (This obviously won't
   apply to systems in which sig_atomic_t is char, but it _does_
   apply to this system, and the compiler is entitled to rely on it.)

Let's take an example which _doesn't_ involve function-local buffers.
Consider

	char *dupcat(char const *a, char const *b) {
	    char *result = malloc(strlen(a) + strlen(b) + 1);
	    assert(result != 0);
	    memcpy(result, a, strlen(a));
	    memcpy(result + strlen(a), b, strlen(b));
	    memcpy(result + strlen(a) + strlen(b), "", 1);
	    return result;
	}

I repeat, this is NOT the way I would normally write it.
I contend that it is _inefficient_ but not "stupid".

If a malicious (and not strictly conforming) signal handler smashes
NBTS(a) or NBTS(b), then you have worse problems than just possible
changes to strlen().  Manually saving the numbers won't protect you
from the fact that the null-terminated-byte-strings have changed,
so that the function result (as an NBTS) is not the concatenation
of its NBTS arguments.

My understanding of the standard is that a compiler is entitled to
assume that NBTS(a) and NBTS(b) will not change (because a legal
standard C program _can't_ undergo such changes) and therefore to
optimise the calls to strlen().

If anyone wants to argue that, take it to comp.std.c and ask the
experts.

The point I am concerned to defend is solely this:
the function dupcat() may be inefficient,
but it clearly and correctly expresses the programmer's intent,
and is therefore not "stupid".

Surely nobody but an assembly hacker would dispute the point
that there are times when it is RATIONAL to write suboptimal
code (in order to devote your resources to activities with a
higher payoff)?

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

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

[Peter Seebach]

In article <50650h$rek@goanna.cs.rmit.edu.au>,
Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote:
> - a program that conforms to the C standard (we were talking about
>   standard C, no?) may not legally set any variable external to the
>   handler if that variable is not of type sig_atomic_t.  Now on _this_
>   system, sig_atomic_t is int, so a *legal* signal handler, however
>   malicious, may not change a char buffer.  (This obviously won't
>   apply to systems in which sig_atomic_t is char, but it _does_
>   apply to this system, and the compiler is entitled to rely on it.)

>Let's take an example which _doesn't_ involve function-local buffers.
>Consider

>	char *dupcat(char const *a, char const *b) {
>	    char *result = malloc(strlen(a) + strlen(b) + 1);
>	    assert(result != 0);
>	    memcpy(result, a, strlen(a));
>	    memcpy(result + strlen(a), b, strlen(b));
>	    memcpy(result + strlen(a) + strlen(b), "", 1);
>	    return result;
>	}

>I repeat, this is NOT the way I would normally write it.
>I contend that it is _inefficient_ but not "stupid".

Maybe.

There's a possible weakness.  Assume sig_atomic_t is an int.  Assume we
have an array of sig_atomic_t somewhere.  Assume we decide to, as we
are permitted by the standard, treat it as an array of characters.  The
first sig_atomic_t in the array may be overwritten by a signal handler
we have installed.  We make sure the 2nd s_a_t in the array contains at least
one null byte, so strlen((char *) sat_array) will be zero, and pass
the array to dupcat as both a and b.  (Suitably cast to (char *).)

It is entirely possible that, even though a and b are the same pointer,
that a signal handler will change the NTBS they point to between a
strlen(a) and a strlen(b) in the above, or between statements.

The problem is unique to (char *), which may point to things other than
arrays of characters, because you may treat any object as an array of
characters.

I still don't think it's stupid, merely (probably) inefficient.

On the other hand, using strlen() on objects which were not intended to be
strings is legitimately stupid.

On the other hand, using assert() for the return from malloc is, IMHO, stupid.
assert() should catch programming errors, not resource limitations.

>The point I am concerned to defend is solely this:
>the function dupcat() may be inefficient,
>but it clearly and correctly expresses the programmer's intent,
>and is therefore not "stupid".

This, I would agree with.

>Surely nobody but an assembly hacker would dispute the point
>that there are times when it is RATIONAL to write suboptimal
>code (in order to devote your resources to activities with a
>higher payoff)?

Assembly hackers spend most of their time and effort writing suboptimal code;
it ports horribly, so it's clearly not *optimal*.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

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

[Lawrence Kirby]

In article <506v0c$ne8@solutions.solon.com>
           seebs@solon.com "Peter Seebach" writes:

...

>There's a possible weakness.  Assume sig_atomic_t is an int.  Assume we
>have an array of sig_atomic_t somewhere.  Assume we decide to, as we
>are permitted by the standard, treat it as an array of characters.  The
>first sig_atomic_t in the array may be overwritten by a signal handler
>we have installed.  We make sure the 2nd s_a_t in the array contains at least
>one null byte, so strlen((char *) sat_array) will be zero, and pass
>the array to dupcat as both a and b.  (Suitably cast to (char *).)
>
>It is entirely possible that, even though a and b are the same pointer,
>that a signal handler will change the NTBS they point to between a
>strlen(a) and a strlen(b) in the above, or between statements.

However the compiler doesn't have to worry about this. If you access
a volatile object through a non-volatile lvalue you get undefined
behaviour (6.5.3). Since signal handlers can only access static variables
of type volatile sig_atomic_t and strlen does not treat the character array
as volatile the compiler doesn't have to make the strlen code signal safe.

Consider the situation where the signal handler changed the string while
strlen was running, it could easily miss the null character terminator
completely. This is simply not a sensible thing for code to do.

>The problem is unique to (char *), which may point to things other than
>arrays of characters, because you may treat any object as an array of
>characters.

That is certainly a general aliasing problem. On the other hand it may be
that a lot of those situations can't occur in strictly conforming programs
so, again, the compiler is not obliged to deal with them to be conforming,
although the compiler writer may not want the trouble of convincing irate
customers about this.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

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

[Joe Keane]

In article <4vroh3$17f@goanna.cs.rmit.edu.au>
Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> writes:
>I would go so far as to say that
>
>	int count_blanks(char const * const s) {
>	    int i, r;
>
>	    r = 0;
>	    for (i = 0; i < strlen(s); i++)
>		if (s[i] == ' ')
>		    r++;
>	    return r;
>	}
>
>is a _good_ function.

That's just bad code.  It specifies a *quadratic* algorithm for a very
simple operation.  My impression would be that the coder doesn't
understand some basic things about C programming, or they're just
inconsiderate.  How hard is it to put the length in a variable?

It's a basic fact that, in the idiomatic `for' loop, the test is
evaluated every time through the loop.  If the upper bound is fixed,
it's really good practice to put it in a local variable.  This makes it
perfectly clear to the compiler *and the reader* that it won't change.

Conversely, calling a function on every iteration connotes that the
value may change.  In a less simple example, there may be a genuine
question about what in the loop causes the bound to change.

>The ONLY strlen() optimisation that is needed here
>is one that is completely general:  strlen() is a pure function and its
>argument does not change, so the strlen(s) computation can be hoisted out
>of the loop.

It's not a pure function.  Whether the argument changes isn't the point;
it's a local variable and it's clear to everyone that it's not changed.

In article <01bb9360$21d0dbe0$87ee6fce@timpent.airshields.com>
"Tim Behrendsen" <tim@airshields.com> writes:
>Yes, yes, I've heard this before.  The compiler knows all, sees all,
>fixes all.  If my strings are a few thousand bytes long, you
>don't think it may be *slightly* inefficient?

>I can easily call clear correct code stupid if it is blatently
>inefficient.  I don't expect the compiler to fix bad code, and
>thus I am never disappointed.

Really.  I expect an optimizing compiler to do a decent job of low-level
things, such as allocating registers, selecting instructions, scheduling
instructions, and so on.  If optimization is turned off, the code will
get slower, maybe two to five times, but a constant factor.

I don't expect the compiler to work miracles, to turn crap into gold.
That would include changing a quadratic algorithm to a linear one.  Some
people may think that it's nifty, but i think it's just a bit disturbing
and i'd rather have compiler writers concentrate on compiling good code.

In article <slrn523tpg.ce.mdw@excessus.demon.co.uk>
Mark Wooding <mdw@excessus.demon.co.uk> writes:
>Erk!  No it isn't.  A pure function is one whose value depends only on
>its arguments.  sin() is pure.  strlen() isn't.

In article <50650h$rek@goanna.cs.rmit.edu.au>
Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> writes:
>This is where I was using sloppy language.
>The way I was using language, the argument *is* the "null-terminated
>byte string" (to use C++ draft standard terminology), and the pointer
>is merely the mechanism used to refer to it.

You can't blow off a level of indirection so easily.  If we're talking
about some expression that just involves the value of the pointer, we'd
agree that it's just CSE and there's nothing controversial about it.

>In the program fragment under discussion, it was not merely the pointer
>that was constant, but the NTBS itself.

I think that you misunderstand the `const' keyword.

>If I do
>	n = strlen(s);
>	/* much code that does not change s */
>	/* NOT the NTBS that s refers to */
>	m = strlen(s);
>it is necessarily the case that m and n will be the same size_t value.

I'm unclear on that comment, but if there are pointer stores in there,
the length may be changed, even if `s' isn't changed.

>The answer is unequivocally "Yes it CAN."

In your example, it is possible.  But it's based on a lot of assumptions
and it's not something you should depend on.  In many similar examples,
the compiler *must not* remove the duplicated calls.

--
Joe Keane, amateur mathematician

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

[Richard A. O'Keefe]

Joe Keane <jgk@jgk.org> writes:
>That's just bad code.  It specifies a *quadratic* algorithm for a very
>simple operation.  My impression would be that the coder doesn't
>understand some basic things about C programming, or they're just
>inconsiderate.  How hard is it to put the length in a variable?

Perhaps we have different perspectives.
Would a *professional* programmer produce code like that?
No way!

Would it be "bad" if a 3rd semester student produced it?
In my view, no way!

At the moment, I'm bogged down in marking.  Last semester, when the
students were in their 3rd semester, using C, I would have wept for
joy to see code that good.  This semester, now they have had another
semester under their belts, and understand something about big-Oh,
I would expect better code.  In fact, to my joy I *am* seeing better
code, much better code.  But the students are writing Ada this
semester, and I find that our students *do* write much better Ada
than they do C.

>It's a basic fact that, in the idiomatic `for' loop, the test is
>evaluated every time through the loop.

You have forgotten the "as if" rule.
The outcome of the program must be the same AS IF the expression had
been evaluated every time, but when part of an expression manifestly
does not change, the compiler is under no obligation to re-evaluate it.

>If the upper bound is fixed,
>it's really good practice to put it in a local variable.

We *agree* that a *professional* programmer, if using a language in which
the _only_ for-loop is like C's (which I am not knocking; I use "do" in
Lisp and Scheme all the time, and it's like C's "for" only better), would
arrange it cheaply.  By the way, a *professional* C programmer would not
call strlen() at all in such an example.

But coming from an educational perspective, I am unwilling to call
*clear*, *correct* code "stupid", or even "bad".  A student who is
capable of writing code that _good_ is one we can help to improve.

>>The ONLY strlen() optimisation that is needed here
>>is one that is completely general:  strlen() is a pure function and its
>>argument does not change, so the strlen(s) computation can be hoisted out
>>of the loop.

>It's not a pure function.  Whether the argument changes isn't the point;
>it's a local variable and it's clear to everyone that it's not changed.

In the article you quote, I explained that by "argument" I meant the
NTBS that the actual parameter points to, AND IN THIS EXAMPLE THAT
NTBS DOES NOT CHANGE, and that *IS* the point.

>Really.  I expect an optimizing compiler to do a decent job of low-level
>things, such as allocating registers, selecting instructions, scheduling
>instructions, and so on.  If optimization is turned off, the code will
>get slower, maybe two to five times, but a constant factor.

>I don't expect the compiler to work miracles, to turn crap into gold.
>That would include changing a quadratic algorithm to a linear one.  Some
>people may think that it's nifty, but i think it's just a bit disturbing
>and i'd rather have compiler writers concentrate on compiling good code.

Again, we have obviously have different perspectives.
I have one foot in the "declarative programming" community (and if you
think Haskell and Mercury are esoteric, think "SQL" which has _exactly_
the same kinds of optimisation requirements and opportunities).
For example, there is a well-known transformation which routinely
turns a class of algorithms with exponential cost if taken naively
into implementations with polynomial cost.

Do I have to explain that the strlen() optimisation is one that has been
legal for Fortran compilers since the first Fortran standard?  Or that
strlen() is a C library function, and that the C standard very carefully
allows a compiler to take advantage of special knowledge about library
functions?

>You can't blow off a level of indirection so easily.

"Blow off" iks rather offensive language.
The NTBS that the pointer pointers to does not change.
True, that is "a level of indirection", but I *explained* how that
can be handled.

>>In the program fragment under discussion, it was not merely the pointer
>>that was constant, but the NTBS itself.

>I think that you misunderstand the `const' keyword.

Bullshit.  I said nothing about the 'const' keyword.
I said that the pointer and the NTBS were *constant*.
That doesn't mean they are declared "read-only".
It means THEY DIDN'T CHANGE.  That's all.
I defy anyone to show where the pointer or the NTBS changed in my
example.  I didn't mention the 'const' keyword because it wasn't relevant.

>>If I do
>>	n = strlen(s);
>>	/* much code that does not change s */
>>	/* NOT the NTBS that s refers to */
>>	m = strlen(s);
>>it is necessarily the case that m and n will be the same size_t value.

>I'm unclear on that comment, but if there are pointer stores in there,
>the length may be changed, even if `s' isn't changed.

The comment (which should have read NOR, not NOT) *says* there are no
such stores.  You are like someone who is told

	"There are no dinosaurs in this room."

and replies

	"I'm unclear on that remark, but if there are any dinosaurs
	 in this room, one of them is about to bite your head off."

>In your example, it is possible.  But it's based on a lot of assumptions
>and it's not something you should depend on.

You have mistaken just about everything I was trying to say.
I suppose this must be my fault.
I *did* say explicitly that *I* know why naive compilers generate
costly code for this, and that it is not something that I would myself
write.  I have been using C since V6+ UNIX, and have had to live with
naive C compilers for years.

>In many similar examples,
>the compiler *must not* remove the duplicated calls.

Yes, but we aren't *talking* about similar examples.  Again, you are
shifting the argument to attack a position I am not stating or defending.
The strlen() example is a very very specific one; it is *ONLY* in the
specific case of strlen() and *ONLY* in the specific case where the
NTBS is not changing that C suckers students into writing

	for (i = 0; i < strlen(s); i++) ... process s[i] ...

All I am claiming, all I have ever claimed, is that a beginner who
writes *that* code to iterative over an unchanging NTBS is not
writing "stupid" or "bad" code, merely code which is _inefficient_
under _some_ C compilers (admittedly the majority of them).

I refuse to call clear correct *working* *readable* code "stupid"
or "bad".  That doesn't mean I am going to slobber over the author
with praise, or that I am not going to put a fair bit of red ink
on such an assignment.  It just means I'm not going to call such a
student nasty names, and am going to take it as an encouraging sign
that the student has learned how to do some important things _well_.

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

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

[Arkady Belousov]

Hello!

Richard A. O'Keefe wrote:

> Consider
>         char *dupcat(char const *a, char const *b) {
>             char *result = malloc(strlen(a) + strlen(b) + 1);
>             assert(result != 0);
>             memcpy(result, a, strlen(a));
>             memcpy(result + strlen(a), b, strlen(b));
>             memcpy(result + strlen(a) + strlen(b), "", 1);
>             return result;
>         }
> I repeat, this is NOT the way I would normally write it.
> I contend that it is _inefficient_ but not "stupid".
> If a malicious (and not strictly conforming) signal handler smashes
> NBTS(a) or NBTS(b), then you have worse problems than just possible
> changes to strlen().  Manually saving the numbers won't protect you
> from the fact that the null-terminated-byte-strings have changed,
> so that the function result (as an NBTS) is not the concatenation
> of its NBTS arguments.

     For ease controlling such situation standard have "volatile"
keyword. So you are right, I think.

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

[Tim Behrendsen]

Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote in article
<4vroh3$17f@goanna.cs.rmit.edu.au>...
> "Tim Behrendsen" <tim@airshields.com> writes:
> 
> >They may exist, but does it exist universally?  The point is that to
> >go out of your way to use left-field optimizations is just bad
> >portability practice.
> 
> "Effen it wur good enough fur granpaw, it's good enough fur me."
> in other words.  By the way, I find it EXTREMELY odd to call a technique
> that has been known and used for nearly 20 years a "left-field" one.
> Behrendsen is putting things exactly backwards;
> *he* is advocating "do not use a technique in your programming language,
> no matter how natural or readable it is, unless you know that every
> compiler you use will implement it reasonably".  Well, I *can't* know
> that.  Heck, I can't even know that
> 	X := X+1;
> will take constant or even small time; almost all programming language
> standardisers say "that's a quality of implementation issue which is
> outside our scope".

Just because it is known, doesn't mean it's implemented everywhere,
or even that people bother to put it in everywhere. I live in
what's really everywhere, not what's theoretically everywhere.

> For an *exact* parallel, consider function inlining.
> These days, I expect a good compiler to at the very minimum support
> programmer-supplied inlining hints, and the Fortran, Pascal, and C
> compilers I normally use do it _automatically_.  This is another
> of those optimisations which has been known and used for decades in
> the Lisp community, which lets you write your program using a function
> call instead of a macro.  I guess inline functions are another
> "left-field optimisation".
> 
> > For example, if someone does this:
> 
> >void sub(char *s)
> >{
> >    ...
> >    if (strlen(s) == 0) {     /* check for null string */
> >        ...
> >    }
> >}
> 
> >and they know it's stupid, but they also know the compiler
> >just happens to have optimization for it, should they
> >still be shot?  "Diana, get me my rifle."
> 
> You have prejudged the issue by stipulating that the programmer
> doing this KNOWS it is stupid.  To start with, can I just make the
> obvious point that in a very large number of currently used languages,
> the direct equivalent of this would be the very best thing to do.

We aren't talking about every language, we are talking about C.

> There are a lot of *good* programmers out there (definition: in a
> reasonable amount of time they can write readable code that works)
> who would *not* "know that it's stupid".  It is, for example, much
> less stupid than writing
> 	if (s == "") 

This is not correct code, so of course the former is "less stupid",
but does that make it non-stupid?

> Let's see what is good about this code:
>  - it is correct (not a NULL test, not a "" test, but a length test)
>  - it is clear (much clearer to people not immersed in C than "!*s")
> Doesn't look stupid to me yet.
> What's bad about it?
>  - it takes O(|s|) time.
> BUT
>  - standard optimisations like common subexpression elimination, can be
>    applied, so that any number of calls to strlen(s) without any
>    intervening potential change to s are no more expensive than a
>    single call
>  - in many applications, all or a large part of s will be processed
>    if it is not empty, so the cost of sub() will be O(|s|) anyway
> so it's only "stupid" if it occurs in a loop and you know your
> compiler _doesn't_ move loop invariants out.

Yes, yes, I've heard this before.  The compiler knows all, sees all,
fixes all.  If my strings are a few thousand bytes long, you
don't think it may be *slightly* inefficient?

> I would go so far as to say that
> 
> 	int count_blanks(char const * const s) {
> 	    int i, r;
> 
> 	    r = 0;
> 	    for (i = 0; i < strlen(s); i++)
> 		if (s[i] == ' ')
> 		    r++;
> 	    return r;
> 	}
> 
> is a _good_ function.  The ONLY strlen() optimisation that is needed here
> is one that is completely general:  strlen() is a pure function and its
> argument does not change, so the strlen(s) computation can be hoisted out
> of the loop.  Since the optimisation in question is one which has been in
> use since the very early Fortran days, it can hardly be called
"left-field".
> A compiler that _doesn't_ do this is indeed a poor compiler, these days.
> 
> Here I am actually arguing against my own inclination, because I strongly
> dislike seeing strlen() used this way, and will take advantage of any
> excuse to "fix" it.  I certainly tell students why not to do this.  But I
> cannot in good conscience call clear correct code "stupid".

I can easily call clear correct code stupid if it is blatently
inefficient.  I don't expect the compiler to fix bad code, and
thus I am never disappointed.
 
> >> Scuse please?  WHAT reality?  The reality in this case is that you can
> >> in fact in just about any reasonable programming language sort data
> >> WITHOUT moving it.
> 
> >Wait, hold the phone!  "Sorts the data without moving it"?  What,
> >is APL's sorting algorithm O(1)?
> 
> No of course not.  I didn't say that.  I said that
> 	in just about any reasonable programming language
> [I did not say APL]
> 	you can sort data WITHOUT moving it
> [I did not say O(1)].
> 
> My claim is that YOU CAN SORT THE DATA WITHOUT MOVING *THE DATA*.
> I don't see how any sane reader could translate that into O(1),
> unless perhaps said reader was under the delusion that sorting
> involves nothing but movement!

OK, fine.  Of course you can keep a pointers to the data and
sort the pointers, but that is irrelevent to the fact that some
data some where must be moved in order to produce a sort.
 

> >Indeed, and I think APL is kind of a neat language to learn.  But
> >it hides so much about the internals of the computer, that I think
> >it would give a student too many false impressions about how
> >things really work.
> 
> Of course APL hides the internals of the computer.
> That's what a high level language is FOR!
> I've done enough programming in ESPOL (B6700 only) and BLISS-10 (DEC-10
> only) to be grateful for languages that hide machine details.
> I have manuals for
>  - System/360
>  - Z80 (somewhere)
>  - 8051
>  - 8086
>  - 80960
>  - Intergraph Clipper
>  - Motorola 68000
>  - Motorola 88000
>  - SPARC
>  - PA-RISC
>  - (part of) MIPS 3000 (in Hennesey & someone).
> and have studied them.  I not written assembly code for the Z80, 8051,
> 80960, or PA-RISC, though I have debugged other people's code for the
> Z80 and 8051.  I have written assembler for the others, and for the
> DEC-10, PDP-11, VAX, Pyramid, IBM RT-PC, and NS32532 (oh yes, and the
> Computer Automation Alpha LSI 2 and the PRIME 400).  I know more about
> the internals of computers than I really want to, and the better a job
> the language I'm using does of hiding them, the better I like it.
> (There is a *lot* to like about Oberon, but I cannot like Wirth's
> reversion to C-style integral types.)

I am grateful that most of the details are hidden from me, too,
but we are talking about education.  We don't want to hide the
details from the students, we want them to learn.

You take all this for granted because you've been doing it
long enough to where you understand how to think.  I don't
think you are able to appreciate the difference between you and
someone who has never done it before.  There is a significant
amount of "learning to think" that has to be done.

> >I actually quite agree with this; it's how you get the "high level
> >thinking" that I think is an issue.
> 
> There is an Edinburgh paper from the 70s that I want to quote from.
> It came from the EMAS project.  The EMAS operating system was designed
> and written at Edinburgh and written an Algol-like language called
> IMP 77.  They observed that the operating system modules written by
> people skilled in assembly language (and who even went to the extreme
> of checking the assembly code produced by the compiler to make sure it
> was efficient) tended to be
>  - bigger,
>  - less readable, and
>  - SLOWER
> than that produced by people who had a "high level language" perspective.
> I'll try to remember to bring the paper in tomorrow so I can quote it
> exactly.

Uh, the people who coded in assembly -- AND CHECKED THE COMPILER
OUTPUT -- produced programs that were bigger and slower?  I think
that there were other factors involved other than just "assembly
vs HLL" style learning.

> >Even in a mathematical proof,
> >you are talking about a sequence of micro-steps.  Yes, most
> >proofs are built of other proofs, but I think this is more of
> >a "proof macro language" than a "high-level mathematical
> >language" (whatever that means).
> 
> I don't quite see proofs by duality or symmetry as simple macro
> substitution.  I think your example here actually gives more comfort
> to the anti-assembly camp than to your own.
> 
> I once took a masters level course on the Spinor Calculus.
> The lecturer (who came from the Sorbonne) wanted to make sure we
> understood the whole thing thoroughly, so he started with metamathematics
> and constructed everything from the ground up.  We were nearly half way
> through the course before we got to the rational numbers.  We ended up
> with only two lectures that were actually about Spinors, and  I _still_
> don't know what they are.  (I've started reading Penrose & Rindler to
> find out.)  In that case at least, over-emphasis on "fundamentals" was
> a major impediment to the high level understanding I really wanted.
> 
> For what it's worth, students here *do* get taught about computer
> architecture, and they *do* get taught a bit of 68000 assembly code,
> and they *do* work with little single board machines so they can try 
> their 68000 code out.  But this is understood as a computer architecture
> course, not as a data structures and algorithms course.  (The course
> is not confined to the 68000, but that's all _they_ have to program at
> that level.)

Again, I have to go back to the fact that *we have the world
that you want*.  And it doesn't work.

-- Tim Behrendsen (tim@airshields.com)

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

[Richard A. O'Keefe]

"Tim Behrendsen" <tim@airshields.com> writes:

>Uh, the people who coded in assembly -- AND CHECKED THE COMPILER
>OUTPUT -- produced programs that were bigger and slower?

Yes, the report says that the people who were thinking in assembly
terms (but writing IMP) and checked the compiler output DID produce
bigger slower programs than the people who were thinking in high
level (well, PL/I-ish) terms.

>I think that there were other factors involved other than just
>"assembly vs HLL" style learning.

This was a project at one of the top computer departments in one of the
top Universities in Britain, and they were desperately keen to get
working software.  In fact, when UNIX V7 first started to become popular,
IMP had been ported to more machines than C (including 16bit, 32-bit,
36-bit, and 48-bit ones) and EMAS had been ported to more machines than
UNIX.  When the University of Kent ditched ICL's operating system for
the ICL 2900 and adopted EMAS, they wanted and got an *increase* in
performance and reliability.

When I met EMAS, in 1980, it was running on ICL 2900s and serving a
large undergraduate population.  At the time I sneered at it because
it wasn't UNIX, but dynamic loading, memory mapped files, archiving,
and a bunch of other things were there and darned solid.

In short, I think you will find that the people the report was talking
about were good experienced 70s-style programmers.

>Again, I have to go back to the fact that *we have the world
>that you want*.  And it doesn't work.

You don't even BEGIN to know what world I want.
I can tell you for certain sure that we don't even begin to approach
hailing distance of the shadow of the world I want.
To start with, I would like students at entry

 - to have a really thorough grasp of their native language
   (I could count the number of 1st year students here who can tell me
    the difference between a count noun and a mass noun on the fingers
    of one ear)

 - to have an adequate grasp of English if that is not their native language

 - to take *pleasure* in reading

 - to be able to use the index in a book

 - to be able to write a short essay on a topic that interests them

 - to have a reasonable grasp of the elements of algebra and calculus
   (I learned calculus from "Teach Yourself Calculus"; a *great* little book)
   [I *know* what the high-school curriculum has in this state; I'd take
   that and say thank you but that the students don't actually -know- it]

 - to have a reasonable grasp of the really elementary points about statistics;
   I don't care if they know what a standard deviation is, but I _do_ wish
   they understood that in the presence of variation one measurement tells
   you very little
   [again, the Victorian high school currculum has everything I want and
   more; it is or was a good curriculum]

 - to have some grasp of reasoning; ideally the notion of formal proof,
   but at the very least the idea that a plausible argument might be wrong
   [there is some very good material produced for schools these days.]

 - to be able to play at least one musical instrument (including the human
   voice and drums as musical instruments) or knit or crochet or weave;
   what I have in mind here is enjoyable "humane" or "arts" activities
   that concern quasi-periodic patterns with a notation that you learn
   to read, so that you learn to take pleasure in reading things that
   are not text, but are still in some sense "stories".

I'm sorry, but it is FARCICAL to argue about whether students should learn
assembly code early on or not when I get students who cannot divide
1000 by 10 without a calculator (this really happened) and cannot spell
their own name (this happened too).  And we don't get the worst university
entrants here either, far from it.

In the world I want, it would be impossible to stop students learning
about assembly code anyway; they would be willing and able to pick it
up from a book.  In the world I want, it would not be dangerous to
teach students about assembly early on, because they would have already
caught the ideas of patterns and transformations and reasoning.  I wrote
my first (IBM/360) assembly code program while still at high school; but
I had learned matrix algebra before that, so it did me no harm.

Prioritising the thousand things we need to teach, to students
 - who find reading and writing English difficult and unpleasant
 - who loathe and dread mathematics and anything that looks like it
 - who are much more interested in producing flashy GUIs than in having
   a working algorithm for the U to I with
 - who cannot listen and take notes at the same time (preprinted lecture
   notes are now being demanded as a right)
 - ah, you get the idea
is not easy.  

Tim Behrendsen, if you think assembler is more urgent than remedial
English and elementary mathematics, we shall just have to disagree.

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

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

[Craig Franck]

ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) wrote:
>"Tim Behrendsen" <tim@airshields.com> writes:
>
>>Uh, the people who coded in assembly -- AND CHECKED THE COMPILER
>>OUTPUT -- produced programs that were bigger and slower?
>
>Yes, the report says that the people who were thinking in assembly
>terms (but writing IMP) and checked the compiler output DID produce
>bigger slower programs than the people who were thinking in high
>level (well, PL/I-ish) terms.
>
>>I think that there were other factors involved other than just
>>"assembly vs HLL" style learning.
>
>This was a project at one of the top computer departments in one of the
>top Universities in Britain, and they were desperately keen to get
>working software.  In fact, when UNIX V7 first started to become popular,
>IMP had been ported to more machines than C (including 16bit, 32-bit,
>36-bit, and 48-bit ones) and EMAS had been ported to more machines than
>UNIX.  When the University of Kent ditched ICL's operating system for
>the ICL 2900 and adopted EMAS, they wanted and got an *increase* in
>performance and reliability.
>
>When I met EMAS, in 1980, it was running on ICL 2900s and serving a
>large undergraduate population.  At the time I sneered at it because
>it wasn't UNIX, but dynamic loading, memory mapped files, archiving,
>and a bunch of other things were there and darned solid.
>
>In short, I think you will find that the people the report was talking
>about were good experienced 70s-style programmers.
>
>>Again, I have to go back to the fact that *we have the world
>>that you want*.  And it doesn't work.
>
>You don't even BEGIN to know what world I want.
>I can tell you for certain sure that we don't even begin to approach
>hailing distance of the shadow of the world I want.
>To start with, I would like students at entry
>
> - to have a really thorough grasp of their native language
>   (I could count the number of 1st year students here who can tell me
>    the difference between a count noun and a mass noun on the fingers
>    of one ear)
>
> - to have an adequate grasp of English if that is not their native language
>
> - to take *pleasure* in reading
>
> - to be able to use the index in a book
>
> - to be able to write a short essay on a topic that interests them
>
> - to have a reasonable grasp of the elements of algebra and calculus
>   (I learned calculus from "Teach Yourself Calculus"; a *great* little book)
>   [I *know* what the high-school curriculum has in this state; I'd take
>   that and say thank you but that the students don't actually -know- it]
>
> - to have a reasonable grasp of the really elementary points about statistics;
>   I don't care if they know what a standard deviation is, but I _do_ wish
>   they understood that in the presence of variation one measurement tells
>   you very little
>   [again, the Victorian high school currculum has everything I want and
>   more; it is or was a good curriculum]
>
> - to have some grasp of reasoning; ideally the notion of formal proof,
>   but at the very least the idea that a plausible argument might be wrong
>   [there is some very good material produced for schools these days.]
>
> - to be able to play at least one musical instrument (including the human
>   voice and drums as musical instruments) or knit or crochet or weave;
>   what I have in mind here is enjoyable "humane" or "arts" activities
>   that concern quasi-periodic patterns with a notation that you learn
>   to read, so that you learn to take pleasure in reading things that
>   are not text, but are still in some sense "stories".
>
>I'm sorry, but it is FARCICAL to argue about whether students should learn
>assembly code early on or not when I get students who cannot divide
>1000 by 10 without a calculator (this really happened) and cannot spell
>their own name (this happened too).  And we don't get the worst university
>entrants here either, far from it.
>
>In the world I want, it would be impossible to stop students learning
>about assembly code anyway; they would be willing and able to pick it
>up from a book.  In the world I want, it would not be dangerous to
>teach students about assembly early on, because they would have already
>caught the ideas of patterns and transformations and reasoning.  I wrote
>my first (IBM/360) assembly code program while still at high school; but
>I had learned matrix algebra before that, so it did me no harm.
>
>Prioritising the thousand things we need to teach, to students
> - who find reading and writing English difficult and unpleasant
> - who loathe and dread mathematics and anything that looks like it
> - who are much more interested in producing flashy GUIs than in having
>   a working algorithm for the U to I with
> - who cannot listen and take notes at the same time (preprinted lecture
>   notes are now being demanded as a right)
> - ah, you get the idea
>is not easy.  
>
>Tim Behrendsen, if you think assembler is more urgent than remedial
>English and elementary mathematics, we shall just have to disagree.
>

Well, Tim will have to answer that last question, but I will say
that being a well educated, moral, civic minded person is far more 
important than having a good grasp of any programming language. It
is just that a discusion of assembler VS. HLL is far more topical 
for a comp. group, all other concerns not withstanding. :-)

-- 
Craig  
clfranck@worldnet.att.net 
Manchester, NH
"You see all around you people engaged in making others live
lives which are not their own, while they themselves care
nothing for their own real lives -- men who hate life though
they fear death". -- William Morris, "News from Nowhere" (1891)

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

[system]

"Larry J. Elmore" <ljelmore@montana.campus.mci.net> writes:
>
>Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote in article
><503bq0$js@goanna.cs.rmit.edu.au>...

>> Prioritising the thousand things we need to teach, to students
>> is not easy.  

>I believe Tim was referring to qualified students actually ready for
>college, Richard. 

>The problem is not with the colleges, it is with the public school
>system from elementary to high school. 

>(It strikes me as incredible that
>the only proposed remedy not ridiculed by the mass media and politicians
>calls for handing even more money and power over to the very system

Being a bleeding heart liberal I generally listen to NPR rather than
the mass media.

As such I have heard of several possible remedies, a number of which are
being tried out with the support of politians.

I certainly believe that children _should_ be educated in the basics before 
they come to college.  The reasons they are not are multisided and can not
all be laid at the doorstep of the public education system.

Robert

>Larry J. Elmore

Morphis@physics.niu.edu

Real Men change diapers

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

[Kenneth Mays]

Making a small statement in addition to this thread, it is not so 
much the colleges fault that the public school systems do a bad job 
in most cases. Colleges and universities spend the first two years 
reeducating the student on 9-12 grade subjects. It was hard to 
believe I had to waste tuition money on College Algebra when I 
finished Trigonometry in 11th grade!!!! some of the greatest minds on 
this earth never attended one college class while others were college 
dropouts. I would not focus so much on the school systems, but more 
on the minds of the people we are dealing with. If someone asked me 
what is the best language for game development, I would wisely tell 
them C/C++. If they asked me about embedded controllers, I would 
Ada95 (easy to maintain). This, to me, doesn't take much thought 
process. Why is it so hard to get it across to those college students 
whom had to pass PSAT/SAT/GRE/GMAT/CLEP and whatever else they take 
for exams today?

Did we miss the mark? Why are companies like 3DO (Studio 3DO), 
Lockheed-Martin, MicroSoft, and Intel/Motorola able to push 
technology with some of the brightest (and not so bright) people in 
this country and over the globe? You will find out that a lot of the 
ingenious designs and inventions come from people who are NOT 
scientists and engineers - but hobbyists or "visionairs". You don't 
need a scientific calculator with slide rule and compass to 
understand transputers or build advanced rocket systems. You just 
have to have a brain, a will to learn. and the ability to accomplish 
your goals.

Imagine what you would think if you found out your environmental 
engineering supervisor had a degree in molecular biology. Your boss 
didn't belong to the IEEE or ACM, but could solve cancer and many 
ailments caused by pollution. Would you say your boss is not 
competent in engineering concepts because you have a engineering 
degree but your boss doesn't???? Read the fine print AGAIN!!!

You have to understand that it doesn't matter what language you wish 
to start with. You have to understand the CONCEPTS of programming. 
What is the thought process involved in programming, the correct ways 
of thinking to solve a problem and put it into a programming model. 
The programming language is just a tool and you have to know what 
tools to use correctly to solve your problem efficiently. 

Now if your asking me or oters what programming language should you 
learn so you can get a job in the real world, well you run into the 
same problem. What jobs are out there hiring for the language you are 
learning. C/C++, Smalltalk, MUMPS, COBOL, RPG, Ada, Query languages, 
Database programming (XTALK),  PERL, Java, FORTRAN, BASIC/Visual 
BASIC, PASCAL/Delphi, and the list goes on. Would you learn Dylan? 
Many studenmts are studying it for OOP/OOD work. Just a small 
comment: look before you leap.


Ken Mays, Ada95 Researcher
kmays@msn.com

NASA quiz:
You got one million people on a space station circling planet Earth 
and the life support system suddenly explodes and wipes out all 
backup reserves. There isn't enough time to evacuated, a large air 
leak has development in the cafeteria area, radiation is spreading 
rapidly through the air conditioning system and becasue of the 
explosion the space station is out of orbit and falling towards earth 
fast. Your personnel has less than an hour to live? What WILL you do? 
What WILL... you do?

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

[Steve Heller]

"Larry J. Elmore" <ljelmore@montana.campus.mci.net> wrote:


>The problem is not with the colleges, it is with the public school
>system from elementary to high school. (It strikes me as incredible that
>the only proposed remedy not ridiculed by the mass media and politicians
>calls for handing even more money and power over to the very system and
>people that have *presided* over the collapse of education in this country.
>And why most people swallow that bilge is beyond me...)
  That's easy. They were brainwashed by that same public school
system!

>"Anyone who isn't a socialist by the age of twenty doesn't have a heart.
> Anyone who isn't a conservative by the age of forty doesn't have a brain."
>-- Winston Churchill
  "Anyone who isn't a libertarian by the age of 30 doesn't have a
clue."
--Steve Heller

Steve Heller, author and software engineer
http://ourworld.compuserve.com/homepages/steve_heller 

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

[Clayton Weaver]

On 29 Aug 1996, Larry J. Elmore wrote:

> Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote in article
> <503bq0$js@goanna.cs.rmit.edu.au>...

> > Prioritising the thousand things we need to teach, to students
> >  - who find reading and writing English difficult and unpleasant
> >  - who loathe and dread mathematics and anything that looks like it
> >  - who are much more interested in producing flashy GUIs than in having
> >    a working algorithm for the U to I with
> >  - who cannot listen and take notes at the same time (preprinted lecture
> >    notes are now being demanded as a right)
> >  - ah, you get the idea
> > is not easy.  

> > Tim Behrendsen, if you think assembler is more urgent than remedial
> > English and elementary mathematics, we shall just have to disagree.

> I believe Tim was referring to qualified students actually ready for
> college, Richard. The fact is, remedial programs should NOT be offered by
> colleges--unqualified students should never be admitted in the first
> place!!! The problem is not with the colleges, it is with the public school
> system from elementary to high school. (It strikes me as incredible that
> the only proposed remedy not ridiculed by the mass media and politicians
> calls for handing even more money and power over to the very system and
> people that have *presided* over the collapse of education in this country.
> And why most people swallow that bilge is beyond me...)

You don't suppose this could be a question of student maturity rather than
a lack of educator dedication?

(Although I find the basic mathematics problems strange. As a student, I
always viewed math class as "less homework, more time for
extra-curricular" and thus less of a chore than some other subjects. "Do
the math first, because it only takes a short time to be current on it.
I can consider doing the rest of this stuff after dinner or on the
weekend.")

> Larry J. Elmore
> ljelmore@montana.campus.mci.net

Regards, 

Clayton Weaver                              Transparent Words
cgweav@eskimo.com      (Seattle)      http://www.eskimo.com/~cgweav/

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

[Tim Behrendsen]

Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote in article
<503bq0$js@goanna.cs.rmit.edu.au>...
> 
> You don't even BEGIN to know what world I want.
> I can tell you for certain sure that we don't even begin to approach
> hailing distance of the shadow of the world I want.
> To start with, I would like students at entry
> 
> [lots of crying out for thinking, engaged students]
> 
> Tim Behrendsen, if you think assembler is more urgent than remedial
> English and elementary mathematics, we shall just have to disagree.

Well, now your getting into a whole other can o' worms.  I completely
agree with you that today's students are woefully unprepared.  Part of
it is (at least here in the US) the complete collapse of the public
school system, and part of the reason is the explosion of knowledge
of the last 50 years means that nothing can be taught in a complete
way.

I agree that education must get away from knowledge packing and
get back to the basics of learning to think.  To tell you the
truth, I'm not sure education has *ever* been devoted to learning
to think, but "knowledge packing"-style education will simply
collapse because there is too much knowledge.

But to bring it back to learning to program; don't underestimate
the specialized skills required to learn to "think like a programmer".
Programming is a quite unique skill blending abstract problem
solving with concrete data movement.  Yet, the data movement is
still abstract.

I believe that the more you can build a programming foundation
on concrete principles, the more likely a student will "get it."
Why do many people teach sorting using a deck of cards?  It's
because the student can see the cards moving around in a concrete
way.

When a student is taught using a *simple* assembly, they experience
the bytes moving around in a nice flat map.  This makes the
concepts concrete, because it's as if they are moving marbles
around in little boxes.  They can experience the data moving
around, without the confusion of the syntax.

I think one of the biggest myths in computer science is that
"HLL syntax is simple to understand."

-- Tim Behrendsen (tim@airshields.com)

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

[madscientist]

In <4vroh3$17f@goanna.cs.rmit.edu.au>, ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
>"Tim Behrendsen" <tim@airshields.com> writes:

.snip..

>standardisers say "that's a quality of implementation issue which is
>outside our scope".
>
>For an *exact* parallel, consider function inlining.
>These days, I expect a good compiler to at the very minimum support
>programmer-supplied inlining hints, and the Fortran, Pascal, and C
>compilers I normally use do it _automatically_.  This is another
>of those optimisations which has been known and used for decades in
>the Lisp community, which lets you write your program using a function
>call instead of a macro.  I guess inline functions are another
>"left-field optimisation".
>
>> For example, if someone does this:
>
>>void sub(char *s)
>>{
>>    ...
>>    if (strlen(s) == 0) {     /* check for null string */
>>        ...
>>    }
>>}
>
>>and they know it's stupid, but they also know the compiler
>>just happens to have optimization for it, should they
>>still be shot?  "Diana, get me my rifle."
>
>You have prejudged the issue by stipulating that the programmer
>doing this KNOWS it is stupid.  To start with, can I just make the
>obvious point that in a very large number of currently used languages,
>the direct equivalent of this would be the very best thing to do.
>There are a lot of *good* programmers out there (definition: in a
>reasonable amount of time they can write readable code that works)
>who would *not* "know that it's stupid".  It is, for example, much
>less stupid than writing
>	if (s == "") 
>
>Let's see what is good about this code:
> - it is correct (not a NULL test, not a "" test, but a length test)
> - it is clear (much clearer to people not immersed in C than "!*s")
>Doesn't look stupid to me yet.
>What's bad about it?
> - it takes O(|s|) time.
>BUT
> - standard optimisations like common subexpression elimination, can be
>   applied, so that any number of calls to strlen(s) without any
>   intervening potential change to s are no more expensive than a
>   single call
> - in many applications, all or a large part of s will be processed
>   if it is not empty, so the cost of sub() will be O(|s|) anyway
>so it's only "stupid" if it occurs in a loop and you know your
>compiler _doesn't_ move loop invariants out.

I Just wanted to point out that this rediculous conversation has taken
reality right out the window!

if(strlen(s)==0) 

is *NOT* functionally equivelent to 

if(s=="")

Wanna know why??

* It would only work if s could only represent string constants
and then only if the compiler removed duplicate constants! If a null string
were allocated with strdup("") then it's address would be somewhere else
entirely and the expression would fail.

The second expression compares the pointer s to the address of the string
constant "" (null string). If that constant resides in more than one place
in memory (because the compiler didn't remove redundant copies) then the
expression would fail even if it were "essentially" true.

-Pete

BTW: I find it good practice to put constant expressions on the left side of
comparisons to point out situations where I might forget one of the '='.

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

[Richard A. O'Keefe]

SYS0.MICRO-NEIL.COM@   (madscientist) writes:
>I Just wanted to point out that this rediculous conversation has taken
>reality right out the window!

>if(strlen(s)==0) 

>is *NOT* functionally equivelent to 

>if(s=="")

No, the conversation has *not* taken reality right out the window.
I said that 'if (strlen(s) == 0)' is better than 'if (s == "")'
precisely BECAUSE both of them are syntactically legal C, but
the first one is right and the second one is wrong.
THAT WAS THE FLIPPING *POINT*.

>If a null string
>were allocated with strdup("") then it's address would be somewhere else
>entirely and the expression would fail.

(a) You have nicely illustrated my point about English being more urgent
    than assembler.
(b) There is no strdup("") in ANSI C.  (It's in the System V ABI.)
(c) ANSI C has null characters, null pointers, null preprocessing
    directives, null statements, and "strings with zero length".
   'Null string' is an exceptionally confusing phrase to use for
    empty strings, because it suggests null pointers, which are not
    empty strings.  strdup(""), if strdup() exists, may return a
    null (string) pointer, or a pointer to an empty string.

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

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

[Tanmoy Bhattacharya]

In article <506v0c$ne8@solutions.solon.com>
seebs@solutions.solon.com (Peter Seebach) writes:

PS: There's a possible weakness.  Assume sig_atomic_t is an int.  Assume we
PS: have an array of sig_atomic_t somewhere.  Assume we decide to, as we
PS: are permitted by the standard, treat it as an array of characters.  The
PS: first sig_atomic_t in the array may be overwritten by a signal handler
PS: we have installed.  We make sure the 2nd s_a_t in the array
PS: contains at least 
PS: one null byte, so strlen((char *) sat_array) will be zero, and pass
PS: the array to dupcat as both a and b.  (Suitably cast to (char *).)
PS: 
PS: It is entirely possible that, even though a and b are the same pointer,
PS: that a signal handler will change the NTBS they point to between a
PS: strlen(a) and a strlen(b) in the above, or between statements.
PS: 

Not quite: Only volatile sig_atomic_t can be handled portably by a
signal handler. Of course, one can cast away the volatile, but *that*
is bad anyways.

Cheers
Tanmoy
--
tanmoy@qcd.lanl.gov(128.165.23.46) DECNET: BETA::"tanmoy@lanl.gov"(1.218=1242)
Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: 1 (505) 665 3003   voice: 1 (505) 665 4733    [ Home: 1 (505) 662 5596 ]

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

[Tom Payne]

Tanmoy Bhattacharya <tanmoy@qcd.lanl.gov> wrote:

: Not quite: Only volatile sig_atomic_t can be handled portably by a
: signal handler. Of course, one can cast away the volatile, but *that*
: is bad anyways.

And, for the record, the only portable handling is writing.  Even
reading provokes the goblin, "undefined behavior."

Tom Payne

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

[Patrick Horgan]

In article <4vroh3$17f@goanna.cs.rmit.edu.au>, ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
 
> IMP 77.  They observed that the operating system modules written by
> people skilled in assembly language (and who even went to the extreme
> of checking the assembly code produced by the compiler to make sure it
> was efficient) tended to be
>  - bigger,
>  - less readable, and
>  - SLOWER
> than that produced by people who had a "high level language" perspective.
> I'll try to remember to bring the paper in tomorrow so I can quote it
> exactly.

You don't state any conclusion from this, but I might imply that you think
that somehow this is an implication that people that have an assembler
language background are bad programmers in high level languages.  I hope
you quote the paper in somewhat more detail, because I'd like to know how
much experience they had as programmers.  Generalizing from one small pool
of people with assembly language skills to any conclusions about the 
relative worth of knowing or not knowing assembler, or whether people with
those skills do or do not write good code is suspect logically.


-- 

   Patrick J. Horgan    patrick@broadvision.com   Have horse will ride.
   Opinions mine, not my employer's except by most bizarre coincidence.

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

[Richard A. O'Keefe]

patrick@broadvision.com (Patrick Horgan) writes:
[Quoting a fairly old posting of mine about the startling
 result in "The IMP Language and Compiler"]
 
>You don't state any conclusion from this, but I might imply that you think
>that somehow this is an implication that people that have an assembler
>language background are bad programmers in high level languages.

You might *imply* it, but you sure as heck can't *infer* it,
because *I* didn't imply it.

>I hope you quote the paper in somewhat more detail,

I already did.

>because I'd like to know how much experience they had as programmers.

It doesn't say.  The EMAS project started in 1973, back when the ICL 4-75
(was this the same as the RCA Spectra?) -- a British System/360 look-alike --
was a new machine.  The project started two years before the 4-75 was
actually delivered.  The first IMP compiler was an adaptation of the
Atlas Autocode compiler.  (Atlas Autocode was an Algol-like language.)
They actually simulated 32-bit arithmetic and byte addressing (which is
what the 4-75 had) on the 48-bit word-addressed KDF9!
"For System 4, the compiler was bootstrapped from the KDF9 compiler
via assembly language (due to difficulties with the manufacturer's
early operating systems).  This compiler was also bootstrapped onto
the IBM 360/50."  

If there is anyone associated with the project reading this, perhaps
they could supply some more information.  I think that the EMAS project
is an interesting part of computing history which deserves to be written
up in rather more detail.

>Generalizing from one small pool
>of people with assembly language skills to any conclusions about the 
>relative worth of knowing or not knowing assembler, or whether people with
>those skills do or do not write good code is suspect logically.

You have completely mistaken the structure of my argument.
The whole point of it is that I am *rebutting* a generalisation.
If I wish to rebut "all swans are white", it is sufficient to
exhibit ONE black swan; I am not obliged to show that all swans are
black.  (The swans one sees in Australia and New Zealand _are_ black,
as it happens.)

I was concerned to rebut the generalisation "exposure to assembly
language helps people become better programmers, writing more
efficient code, and it is difficult to become a good programmer
without this experience", which I took to be Tim Behrendsen's claim.

I exhibited a single real compiler-and-operating system project
which delivered bloody good working product, where it was found
that the people used to high level languages (Fortran? Algol?
BCPL? They were *certainly* aware of PL/I and intended to build
a translator from IMP to PL/I but found that they had more IMP
compilers than there were PL/I compilers to translate for)
delivered smaller faster better structured code than the people
"with a background of assembly languages" (1401? 1130? /360?).

This *establishes* no generalision, but it is good logic for
*rebutting* one.

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

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

[deafen]

I appreciate the perspectives that all of you have offered.  However, I 
feel it necessary at this point to make a clarification of my original 
post (about being a CIS student, etc.)

I may have chosen the wrong word to describe a certain concept.  The word 
I used, "fundamentals", is being interpreted as what I would describe as 
"design concepts."  FWIW, I use the word "foundations" for that.

I was commenting on the idea that all programmers need to understand just 
exactly what's going on at the assembly level to be good programmers.  I 
disagree.

As for the comments about what employers want, absolutely, I shot my 
mouth off, foot buried deep inside.  Of course I don't know what's 
expected in the business world as far as programmers go; like the .sig 
says, I'm primarily a tech, not a programmer.  On top of that, I'm a 
student, and therefore in most ways isolated from the "real world."

The curriculum in which I am enrolled stresses design and analysis rather 
than coding.  (Again, please note that I'm in CIS, not CS.  At my school, 
CIS is a business degree, and CS is an engineering degree.)  I probably 
would be having more fun if the curriculum involved more coding and less 
design, but that's neither here nor there.

Just offering a clarification.  And I guess someday I'll learn to keep my 
mouth shut.  (Or maybe not...:)

--
Hal Haygood :: PC/Network/Unix technician, Suntek Integrated Technologies
hal@suncap.com  ::  deafen@asu.edu  ::  hagar@mail.hvs.com
My opinions and those of my employer rarely, if ever, coincide.

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

[Chris Sonnack]

Peter Seebach (seebs@solutions.solon.com) wrote:

> I think algorithms should be taught on paper.  *Away* from implementations
> on computer.
>
> Believe me, you understand quicksort much better after *DOING* it than you
> can from writing any reasonable number of implementations.

Absolutely! Without qualification.

And:

> ...once they showed you *the algorithm*, you could implement it however
> you want.

Yep.

> It's worth observing good programmers rewriting.  A good programmer will
> add features and cut the size of a program slightly; a bad programmer will
> bloat it hugely to add the feature.  (Assuming the original program to be
> mediocre.)

This is so true. And it applies to ones own work. Most programs of any
size I write follow a time/size curve, getting larger as the features
are implemented. But at some point I begin to //truly// understand the
solution the program represents. This, to my mind and experience, only
comes from living with the problem and in the code for a time; a long
time. All the design analysis in the world never seems to quite touch
the heart of the matter. It's the wedding between the concrete problem
and the concrete mechanism (language) that births the elegant solution.

Once I hit that point, the code size begins to decrease and and the
solution starts to become truly elegant.

ObTopic:

I disagree students should START with assembly (although I did and it's
served me well). I do feel that any programmer who really wants to be
called a true craftsperson should know AS MUCH AS POSSIBLE about their
craft. I think there is much to be gained from looking at problems and
solutions from as many points of view, high and low, as possible.

Hell, I think it's self-evident.

--
Chris Sonnack  <cjsonnack@mmm.com>                  http://eishcq.mmm.com
Engineering Information Services/Information Technology/3M, St.Paul, Minn
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TODAY'S RULE: No Smoffing or Fnargling!

Opinions expressed herein are my own and may not represent those of my employer.

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

[telnet user]

Tim Behrendsen (tim@airshields.com) wrote:

: This is an interesting case, because it is somewhat inefficently
: implemented.  If you're interested in speed, you would do...

: int gcd(int x, int y) {
:     int z;
:     while (y != 0)
:         z = y; y = x % y; x = z;
:     return(y);
: }

However if you are interested in correctness, you use braces for the
loop.  I think this case where you write assembly in C, get it wrong,
and ...

: Using my AIX compiler, I get a nominal improvement of about
: 10%, mostly because the speed of the modulo is much slower
: than the inefficiency of recursion.

only achieve a 10% speedup proves everyone else's point, and is an
appropriate place to end this thread.

---------------------------------------------------------------------------
Tim Hollebeek         | Disclaimer :=> Everything above is a true statement,
Electron Psychologist |                for sufficiently false values of true.
Princeton University  | email: tim@wfn-shop.princeton.edu
----------------------| http://wfn-shop.princeton.edu/~tim (NEW! IMPROVED!)

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

[Ed Hook]

In article <4udjki$2l8@cnn.Princeton.EDU>, tim@franck (telnet user) writes:
|> Tim Behrendsen (tim@airshields.com) wrote:
|> 
|> : This is an interesting case, because it is somewhat inefficently
|> : implemented.  If you're interested in speed, you would do...
|> 
|> : int gcd(int x, int y) {
|> :     int z;
|> :     while (y != 0)
|> :         z = y; y = x % y; x = z;
|> :     return(y);
|> : }
|> 
|> However if you are interested in correctness, you use braces for the
|> loop.  I think this case where you write assembly in C, get it wrong,
|> and ...
|>
  And ... if, in addition, you're interested in _mathematical_ correctness,
  you'll write instead:

  int gcd(int x, int y)
  {
	int z;
	while ( y != 0 ) {
		z = y;
		y = x % z;
		x = z;
	}
	return x;
   }

   On the other hand, I can greatly speed up tha given code; just replace
   it by

   int gcd(int x, int y)
   {
	return 0;
   }

   -- it does the same thing.
 
|> : Using my AIX compiler, I get a nominal improvement of about
|> : 10%, mostly because the speed of the modulo is much slower
|> : than the inefficiency of recursion.
|> 
|> only achieve a 10% speedup proves everyone else's point, and is an
|> appropriate place to end this thread.
|>

  I can't argue with that ...
 
|> ---------------------------------------------------------------------------
|> Tim Hollebeek         | Disclaimer :=> Everything above is a true statement,
|> Electron Psychologist |                for sufficiently false values of true.
|> Princeton University  | email: tim@wfn-shop.princeton.edu
|> ----------------------| http://wfn-shop.princeton.edu/~tim (NEW! IMPROVED!)

-- 
 Ed Hook                              |       Coppula eam, se non posit
 Computer Sciences Corporation        |         acceptera jocularum.
 NASA Langley Research Center         | Me? Speak for my employer?...<*snort*>
 Internet: hook@cscsun3.larc.nasa.gov |        ... Get a _clue_ !!! ...

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

[Tim Behrendsen]

telnet user <tim@franck> wrote in article <4udjki$2l8@cnn.Princeton.EDU>...
> Tim Behrendsen (tim@airshields.com) wrote:
> 
> : This is an interesting case, because it is somewhat inefficently
> : implemented.  If you're interested in speed, you would do...
> 
> : int gcd(int x, int y) {
> :     int z;
> :     while (y != 0)
> :         z = y; y = x % y; x = z;
> :     return(y);
> : }
> 
> However if you are interested in correctness, you use braces for the
> loop.  I think this case where you write assembly in C, get it wrong,
> and ...
> : Using my AIX compiler, I get a nominal improvement of about
> : 10%, mostly because the speed of the modulo is much slower
> : than the inefficiency of recursion.
> 
> only achieve a 10% speedup proves everyone else's point, and is an
> appropriate place to end this thread.

Yes, with *this* algorithm, on *this* computer, I only got a
10% improvement.  I rewrote an algorithm to be non-recrursive
that was published in CUJ and got a 40% improvement.  This is
the reality of what happens when you let the compiler to do the
thinking.

-- Tim Behrendsen (tim@airshields.com)

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

[Mike Rubenstein]

"Tim Behrendsen" <tim@airshields.com> wrote:

> 
> 
> Peter Seebach <seebs@solutions.solon.com> wrote in article
> <4uah1k$b2o@solutions.solon.com>...
> > In article <01bb83f5$923391e0$87ee6fce@timpent.airshields.com>,
> > Tim Behrendsen <tim@airshields.com> wrote:
> > >I agree; my point is that I think the student learns more if they
> > >are thinking purely in terms of fundamental operations (which are
> > >still abstractions above the raw hardware components), rather
> > >than layers and layers of syntax that hide the essential essence
> > >of what the computer is doing.
> > 
> > But your concept of what the "fundemental operations" are is completely
> tied
> > up in how specific hardware you've seen operates.  Algorithms exist in
> terms
> > of abstract operations, not moves and branches.
> 
> Please name me the hardware that does not use moves and branches.
> 
> > Something like CWEB might be a good language in which to learn
> algorithms.
> > Scheme might too.
> > 
> > Let's look at a specific algorithm; the infamous gcd(x, y).
> > 
> > In C, we write
> > 
> > 	int
> > 	gcd(int x, int y) {
> > 		if (y == 0)
> > 			return x;
> > 		return gcd(y, (x % y));
> > 	}
> > 
> > or something similar.
> > 
> > What's important here is not any theories people may have about where the
> x
> > and y are stored, or how a stack works, but the concept that you can
> define an
> > algorithm in terms of a previous case.  Learning that the if() may be
> > implemented with "a branch" does not help the student understand how the
> > *algorithm* works, it helps the student understand how the *compiler*
> works.
> > These are distinct things.
> 
> This is an interesting case, because it is somewhat inefficently
> implemented.  If you're interested in speed, you would do...
> 
> int gcd(int x, int y) {
>     int z;
>     while (y != 0)
>         z = y; y = x % y; x = z;
>     return(y);
> }

I don't understand how going into an infinite loop when y != 0
improves the speed?  I guess I cut class that day.

Nor do I see how dividing by 0 (when y == 0) is an improvement?
Perhaps I just cut too many classes.

Let's review the bidding.  Peter gives an algorithm.  You claim that
knowledge of assembly helps one understand it better and produce a
program that goes into an infinite loop if y is not zero and divides
by 0 if y is zero.

Perhaps you meant

	int gcd(int x, int y) {
	    int z;
	    while (y != 0)
	        { z = y; y = x % y; x = z; }
	    return(y);
	}

This avoids the infinite loop, but can be made even more efficient:

	int gcd(int x, int y)
	{
	  return 0;
	}

Of course this isn't quite equivalent to Peter's function.

I guess, like Peter, I'm a little thick today.  Please explain again
how knowing assembly language helps one understand algorithms?  I got
a little confused when you transformed Peter's correct, but slightly
inefficient function into an infinite loop.


Michael M Rubenstein

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

[Tim Behrendsen]

Mike Rubenstein <miker3@ix.netcom.com> wrote in article
<320b35a2.43769707@nntp.ix.netcom.com>...
> "Tim Behrendsen" <tim@airshields.com> wrote:
> > Peter Seebach <seebs@solutions.solon.com> wrote in article
> > <4uah1k$b2o@solutions.solon.com>...
> > > In C, we write
> > > 
> > > 	int
> > > 	gcd(int x, int y) {
> > > 		if (y == 0)
> > > 			return x;
> > > 		return gcd(y, (x % y));
> > > 	}
> > > 
> > This is an interesting case, because it is somewhat inefficently
> > implemented.  If you're interested in speed, you would do...
> > 
> > int gcd(int x, int y) {
> >     int z;
> >     while (y != 0)
> >         z = y; y = x % y; x = z;
> >     return(y);
> > }
> 
> I don't understand how going into an infinite loop when y != 0
> improves the speed?  I guess I cut class that day.
> 
> Nor do I see how dividing by 0 (when y == 0) is an improvement?
> Perhaps I just cut too many classes.
> 
> Let's review the bidding.  Peter gives an algorithm.  You claim that
> knowledge of assembly helps one understand it better and produce a
> program that goes into an infinite loop if y is not zero and divides
> by 0 if y is zero.
> 
> Perhaps you meant
> 
> 	int gcd(int x, int y) {
> 	    int z;
> 	    while (y != 0)
> 	        { z = y; y = x % y; x = z; }
> 	    return(y);
> 	}
> 
> This avoids the infinite loop, but can be made even more efficient:
> 
> 	int gcd(int x, int y)
> 	{
> 	  return 0;
> 	}
> 
> Of course this isn't quite equivalent to Peter's function.
> 
> I guess, like Peter, I'm a little thick today.  Please explain again
> how knowing assembly language helps one understand algorithms?  I got
> a little confused when you transformed Peter's correct, but slightly
> inefficient function into an infinite loop.

Yes, you're right; my typo proves all my arguments false.  How can I
have been such a fool?

-- Tim Behrendsen (tim@airshields.com)

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

[Mike Rubenstein]

"Tim Behrendsen" <tim@airshields.com> wrote:

> Mike Rubenstein <miker3@ix.netcom.com> wrote in article
> <320b35a2.43769707@nntp.ix.netcom.com>...
> > "Tim Behrendsen" <tim@airshields.com> wrote:
> > > Peter Seebach <seebs@solutions.solon.com> wrote in article
> > > <4uah1k$b2o@solutions.solon.com>...
> > > > In C, we write
> > > > 
> > > > 	int
> > > > 	gcd(int x, int y) {
> > > > 		if (y == 0)
> > > > 			return x;
> > > > 		return gcd(y, (x % y));
> > > > 	}
> > > > 
> > > This is an interesting case, because it is somewhat inefficently
> > > implemented.  If you're interested in speed, you would do...
> > > 
> > > int gcd(int x, int y) {
> > >     int z;
> > >     while (y != 0)
> > >         z = y; y = x % y; x = z;
> > >     return(y);
> > > }
> > 
> > I don't understand how going into an infinite loop when y != 0
> > improves the speed?  I guess I cut class that day.
> > 
> > Nor do I see how dividing by 0 (when y == 0) is an improvement?
> > Perhaps I just cut too many classes.
> > 
> > Let's review the bidding.  Peter gives an algorithm.  You claim that
> > knowledge of assembly helps one understand it better and produce a
> > program that goes into an infinite loop if y is not zero and divides
> > by 0 if y is zero.
> > 
> > Perhaps you meant
> > 
> > 	int gcd(int x, int y) {
> > 	    int z;
> > 	    while (y != 0)
> > 	        { z = y; y = x % y; x = z; }
> > 	    return(y);
> > 	}
> > 
> > This avoids the infinite loop, but can be made even more efficient:
> > 
> > 	int gcd(int x, int y)
> > 	{
> > 	  return 0;
> > 	}
> > 
> > Of course this isn't quite equivalent to Peter's function.
> > 
> > I guess, like Peter, I'm a little thick today.  Please explain again
> > how knowing assembly language helps one understand algorithms?  I got
> > a little confused when you transformed Peter's correct, but slightly
> > inefficient function into an infinite loop.
> 
> Yes, you're right; my typo proves all my arguments false.  How can I
> have been such a fool?

Perhaps because you think like an assembly language programmer --
there's an enormous advantage to clear code.  Efficiency may, or may
not be important.  Yet you assumed that it was worthwhile to make
Peter's code more efficient.  This is the assembly language
programmer's disease.

If I were doing a lot of gcd calculations, I'd certainly try to
optimize the program.  But in most applications very little of the
code is time critical.  Where it is not, clear code wins over
efficient code.

Furthermore, when teaching algorithms Peter's code is what you want,
at least for the first cut.  It shows a general technique of algorithm
design, reducing a problem to a similar but easier one, that your
code, even if written correctly, hides.

It's near September, and I feel safe in predicting that we will soon
see quite a few posts asking how to solve the towers of Hanoi puzzle.
Those who understand Peter's formulation of Euclid's algorithm will do
better than those who only know yours.


Michael M Rubenstein

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

[Tim Behrendsen]

Mike Rubenstein <miker3@ix.netcom.com> wrote in article
<320bf032.7193774@nntp.ix.netcom.com>...
> "Tim Behrendsen" <tim@airshields.com> wrote:
> > Mike Rubenstein <miker3@ix.netcom.com> wrote in article
> > <320b35a2.43769707@nntp.ix.netcom.com>...
> 
> Perhaps because you think like an assembly language programmer --
> there's an enormous advantage to clear code.  Efficiency may, or may
> not be important.  Yet you assumed that it was worthwhile to make
> Peter's code more efficient.  This is the assembly language
> programmer's disease.

No, this is experienced programmer's disease.  It's not as if
I go around optimizing everything, I just do it automatically.
When you train yourself to think about efficiency, you naturally
do it the efficient way the *first time*.  The cumulative effect
of this is fast programs, and it doesn't cost any more effort.

> If I were doing a lot of gcd calculations, I'd certainly try to
> optimize the program.  But in most applications very little of the
> code is time critical.  Where it is not, clear code wins over
> efficient code.

Yes, I agree.  Personally, they both seem equally clear to me,
but I could see how someone may prefer the recursive solution.
It is certainly the more "beautiful" of the two.

> Furthermore, when teaching algorithms Peter's code is what you want,
> at least for the first cut.  It shows a general technique of algorithm
> design, reducing a problem to a similar but easier one, that your
> code, even if written correctly, hides.

I'm not sure if that's good or not.  One of the famous ways to
show recursion is a factorial computation.  Does that mean we
actually *want* people to implement factorial that way?

-- Tim Behrendsen (tim@airshields.com)

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

[Mike Rubenstein]

"Tim Behrendsen" <tim@airshields.com> wrote:

> Mike Rubenstein <miker3@ix.netcom.com> wrote in article
> <320bf032.7193774@nntp.ix.netcom.com>...
> > "Tim Behrendsen" <tim@airshields.com> wrote:
> > > Mike Rubenstein <miker3@ix.netcom.com> wrote in article
> > > <320b35a2.43769707@nntp.ix.netcom.com>...
> > 
> > Perhaps because you think like an assembly language programmer --
> > there's an enormous advantage to clear code.  Efficiency may, or may
> > not be important.  Yet you assumed that it was worthwhile to make
> > Peter's code more efficient.  This is the assembly language
> > programmer's disease.
> 
> No, this is experienced programmer's disease.  It's not as if
> I go around optimizing everything, I just do it automatically.
> When you train yourself to think about efficiency, you naturally
> do it the efficient way the *first time*.  The cumulative effect
> of this is fast programs, and it doesn't cost any more effort.

I see.  Experienced programmers automatically optimize slightly
inefficient, clear code to incorrect unclear code?  Guess I'll have to
remain a novice.

Perhaps you need to get some new experiences.

Changing correct clear code when there is no specific requirement is
an assembly programmer's, not an experienced programmer's disease.
Yes, I know that was just a typo (or several typos).  But that
happens.  Only an assembly language programmer (and, frankly, not a
very good one) would assume that efficiency was so important that
clear code had to be changed and risk the problems.

> 
> > If I were doing a lot of gcd calculations, I'd certainly try to
> > optimize the program.  But in most applications very little of the
> > code is time critical.  Where it is not, clear code wins over
> > efficient code.
> 
> Yes, I agree.  Personally, they both seem equally clear to me,
> but I could see how someone may prefer the recursive solution.
> It is certainly the more "beautiful" of the two.

So, why did you change it when there was no clear requirement for
better efficiency?  Even if one does not prefer that solution, it
certainly was clear enough and correct.
 
> > Furthermore, when teaching algorithms Peter's code is what you want,
> > at least for the first cut.  It shows a general technique of algorithm
> > design, reducing a problem to a similar but easier one, that your
> > code, even if written correctly, hides.
> 
> I'm not sure if that's good or not.  One of the famous ways to
> show recursion is a factorial computation.  Does that mean we
> actually *want* people to implement factorial that way?

In scheme (and some other languages) it certainly is the way to
implement it.

But that's not the point.  If one understands the algorithm, one can
code it using whatever techniques are appropriate.  Recursion is not
something to be avoided at all costs even in implmeentations where it
is not efficient.  Assembly language is not needed to understand
algorityms or efficiency.

For the record, I have extensive assembly language experience on IBM
360/370, 8080, Z80, and 80x86 and a little on IBM709x, Univac 110x, GE
425, Honeywell 6000, and DEC PDP 6/10.  I've outgrown it.


Michael M Rubenstein

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

[Tim Behrendsen]

Mike Rubenstein <miker3@ix.netcom.com> wrote in article
<320f14e5.213196860@nntp.ix.netcom.com>...
> "Tim Behrendsen" <tim@airshields.com> wrote:
> > Mike Rubenstein <miker3@ix.netcom.com> wrote in article
> > <320bf032.7193774@nntp.ix.netcom.com>...
> > 
> > No, this is experienced programmer's disease.  It's not as if
> > I go around optimizing everything, I just do it automatically.
> > When you train yourself to think about efficiency, you naturally
> > do it the efficient way the *first time*.  The cumulative effect
> > of this is fast programs, and it doesn't cost any more effort.
> 
> I see.  Experienced programmers automatically optimize slightly
> inefficient, clear code to incorrect unclear code?  Guess I'll have to
> remain a novice.

Either solution is perfectly clear to me, and perhaps you
could share the secret of a mistake free life, since you appear
to not be able to forgive my one type?
 
> Perhaps you need to get some new experiences.
> 
> Changing correct clear code when there is no specific requirement is
> an assembly programmer's, not an experienced programmer's disease.
> Yes, I know that was just a typo (or several typos).  But that
> happens.  Only an assembly language programmer (and, frankly, not a
> very good one) would assume that efficiency was so important that
> clear code had to be changed and risk the problems.

As I said, I would not go back and change working code
unless there was a good reason.  If I was implementing it
the first time, I would do it efficiently the first time.

> > Yes, I agree.  Personally, they both seem equally clear to me,
> > but I could see how someone may prefer the recursive solution.
> > It is certainly the more "beautiful" of the two.
> 
> So, why did you change it when there was no clear requirement for
> better efficiency?  Even if one does not prefer that solution, it
> certainly was clear enough and correct.

Because I was making a point about recursion, not about GCD
implementations.
  
> > I'm not sure if that's good or not.  One of the famous ways to
> > show recursion is a factorial computation.  Does that mean we
> > actually *want* people to implement factorial that way?
> 
> In scheme (and some other languages) it certainly is the way to
> implement it.
>
> But that's not the point.  If one understands the algorithm, one can
> code it using whatever techniques are appropriate.  Recursion is not
> something to be avoided at all costs even in implmeentations where it
> is not efficient.

"Techniques are appropriate"  That's the issue, isn't it?  I would
say that anybody who implements factorial in C using recursion
qualifies as a bonehead and should have their programming license
revoked.

> Assembly language is not needed to understand
> algorityms or efficiency.

It's not a question of whether it's needed or not.  It's a
question of what's best, and what we're doing now is certainly
not working.  The level of incompetence that I see coming
out of CS schools is astounding to me.

I've asked this before; why do EE graduates seem so much
better prepared than CS graduates?  I think it's because they
start with the low level and work they their way up.
 
> For the record, I have extensive assembly language experience on IBM
> 360/370, 8080, Z80, and 80x86 and a little on IBM709x, Univac 110x, GE
> 425, Honeywell 6000, and DEC PDP 6/10.  I've outgrown it.

So who's arguing that assembly should be used in production
any more?  You have the benefit of all that background, yet
you argue that it's useless.  I think that it benefits you more
than you realize.

-- Tim Behrendsen (tim@airshields.com)

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

[Mike Rubenstein]

"Tim Behrendsen" <tim@airshields.com> wrote:

> Mike Rubenstein <miker3@ix.netcom.com> wrote in article
> <320f14e5.213196860@nntp.ix.netcom.com>...
> > "Tim Behrendsen" <tim@airshields.com> wrote:
> > > Mike Rubenstein <miker3@ix.netcom.com> wrote in article
> > > <320bf032.7193774@nntp.ix.netcom.com>...
> > > 
> > > No, this is experienced programmer's disease.  It's not as if
> > > I go around optimizing everything, I just do it automatically.
> > > When you train yourself to think about efficiency, you naturally
> > > do it the efficient way the *first time*.  The cumulative effect
> > > of this is fast programs, and it doesn't cost any more effort.
> > 
> > I see.  Experienced programmers automatically optimize slightly
> > inefficient, clear code to incorrect unclear code?  Guess I'll have to
> > remain a novice.
> 
> Either solution is perfectly clear to me, and perhaps you
> could share the secret of a mistake free life, since you appear
> to not be able to forgive my one type?

I certainly don't claim to be mistake free -- that's why I don't
change clear working code without reason.

>  
> > Perhaps you need to get some new experiences.
> > 
> > Changing correct clear code when there is no specific requirement is
> > an assembly programmer's, not an experienced programmer's disease.
> > Yes, I know that was just a typo (or several typos).  But that
> > happens.  Only an assembly language programmer (and, frankly, not a
> > very good one) would assume that efficiency was so important that
> > clear code had to be changed and risk the problems.
> 
> As I said, I would not go back and change working code
> unless there was a good reason.  If I was implementing it
> the first time, I would do it efficiently the first time.

But you did go back and change it.
 
> > > Yes, I agree.  Personally, they both seem equally clear to me,
> > > but I could see how someone may prefer the recursive solution.
> > > It is certainly the more "beautiful" of the two.
> > 
> > So, why did you change it when there was no clear requirement for
> > better efficiency?  Even if one does not prefer that solution, it
> > certainly was clear enough and correct.
> 
> Because I was making a point about recursion, not about GCD
> implementations.

If the point was that assembly language knowledge helps, I'm afraid
you blew it.

>   
> > > I'm not sure if that's good or not.  One of the famous ways to
> > > show recursion is a factorial computation.  Does that mean we
> > > actually *want* people to implement factorial that way?
> > 
> > In scheme (and some other languages) it certainly is the way to
> > implement it.
> >
> > But that's not the point.  If one understands the algorithm, one can
> > code it using whatever techniques are appropriate.  Recursion is not
> > something to be avoided at all costs even in implmeentations where it
> > is not efficient.
> 
> "Techniques are appropriate"  That's the issue, isn't it?  I would
> say that anybody who implements factorial in C using recursion
> qualifies as a bonehead and should have their programming license
> revoked.
> 
> > Assembly language is not needed to understand
> > algorityms or efficiency.
> 
> It's not a question of whether it's needed or not.  It's a
> question of what's best, and what we're doing now is certainly
> not working.  The level of incompetence that I see coming
> out of CS schools is astounding to me.
> 
> I've asked this before; why do EE graduates seem so much
> better prepared than CS graduates?  I think it's because they
> start with the low level and work they their way up.
>  
> > For the record, I have extensive assembly language experience on IBM
> > 360/370, 8080, Z80, and 80x86 and a little on IBM709x, Univac 110x, GE
> > 425, Honeywell 6000, and DEC PDP 6/10.  I've outgrown it.
> 
> So who's arguing that assembly should be used in production
> any more?  You have the benefit of all that background, yet
> you argue that it's useless.  I think that it benefits you more
> than you realize.

Or you less than you realize.  I, at least, would not have changed
Peter's code unless there was a specific reason.  That is one lesson
assembly language code has taught me.

I've probably been helped more by my knowledge of about 25 higer level
languages.

Obviously, all other things being equal, it is better to know assembly
language that to not know it.  But all other things are seldom equal.
I suspect that most beginning programmers would gain much more from
learning some different HLLs.  Given a choice, I'd strongly recommend
one learn LISP, APL, Icon, or any of a few dozen other languages to
learning assembly language.

Michael M Rubenstein

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

[Tim Behrendsen]

Mike Rubenstein <miker3@ix.netcom.com> wrote in article
<320fe7f4.7066811@nntp.ix.netcom.com>...
> I've probably been helped more by my knowledge of about 25 higer level
> languages.
> 
> Obviously, all other things being equal, it is better to know assembly
> language that to not know it.  But all other things are seldom equal.
> I suspect that most beginning programmers would gain much more from
> learning some different HLLs.  Given a choice, I'd strongly recommend
> one learn LISP, APL, Icon, or any of a few dozen other languages to
> learning assembly language.

We have the world that you want.  This is CS curriculum today; are
you happy with the level of expertise of the graduates?  I'm not,
based on my experience with trying to hire them.  If you're not
either, what do you think the reason is?

-- Tim Behrendsen (tim@airshields.com)

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

[Giuliano Carlini]

Tim Behrendsen wrote:
> 
> Mike Rubenstein <miker3@ix.netcom.com> wrote in article
> <320fe7f4.7066811@nntp.ix.netcom.com>...
> > I've probably been helped more by my knowledge of about 25 higer level
> > languages.
> >
> > Obviously, all other things being equal, it is better to know assembly
> > language that to not know it.  But all other things are seldom equal.
> > I suspect that most beginning programmers would gain much more from
> > learning some different HLLs.  Given a choice, I'd strongly recommend
> > one learn LISP, APL, Icon, or any of a few dozen other languages to
> > learning assembly language.

Every programmer should know assembler as their 2cnd or third language.
Okay, not recreational programmers, or those knocking together small
programs, but every one who puts together programs that are larger than
say 10K lines of code.

You don't need to write in it often, but you need it to be able to
debug competently.

There are far to many times I'm called in to help someone debug, when
it turned out to be a stupid compiler or system bug that a good
understanding of assembler would have spotted immediately.

There are times I need to dive into the compiler runtime, or into the
OS to debug my buggy code.

If you don't understand assembler, your reduced to trying one trivial
change to your program after another. When one finally works, you've
have no clue why. Then you can't document why some monstrous section
of code is the way it is. And that causes problems later on.

g

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

[Tim Behrendsen]

Giuliano Carlini <giuliano@ix.netcom.com> wrote in article
<32115234.7B0@ix.netcom.com>...
> Tim Behrendsen wrote:
> > 
> > Mike Rubenstein <miker3@ix.netcom.com> wrote in article
> > <320fe7f4.7066811@nntp.ix.netcom.com>...
> > > I've probably been helped more by my knowledge of about 25 higer
level
> > > languages.
> > >
> > > Obviously, all other things being equal, it is better to know
assembly
> > > language that to not know it.  But all other things are seldom equal.
> > > I suspect that most beginning programmers would gain much more from
> > > learning some different HLLs.  Given a choice, I'd strongly recommend
> > > one learn LISP, APL, Icon, or any of a few dozen other languages to
> > > learning assembly language.
> 
> Every programmer should know assembler as their 2cnd or third language.
> Okay, not recreational programmers, or those knocking together small
> programs, but every one who puts together programs that are larger than
> say 10K lines of code.
> 
> You don't need to write in it often, but you need it to be able to
> debug competently.
> 
> There are far to many times I'm called in to help someone debug, when
> it turned out to be a stupid compiler or system bug that a good
> understanding of assembler would have spotted immediately.
> 
> There are times I need to dive into the compiler runtime, or into the
> OS to debug my buggy code.
> 
> If you don't understand assembler, your reduced to trying one trivial
> change to your program after another. When one finally works, you've
> have no clue why. Then you can't document why some monstrous section
> of code is the way it is. And that causes problems later on.

Or heck, to examine a core dump in the field.  I list out the assembly all
the time to see what happened.  I'm one of the few people in my company
who can do a post-mortem without source-level debugging turned on,
and I don't even know the (RS/6000) assembly language!  I've just seen
enough of them to be able to feel my way around the instruction set.

-- Tim Behrendsen (tim@airshields.com)

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

[Mike Rubenstein]

"Tim Behrendsen" <tim@airshields.com> wrote:

> Mike Rubenstein <miker3@ix.netcom.com> wrote in article
> <320fe7f4.7066811@nntp.ix.netcom.com>...
> > I've probably been helped more by my knowledge of about 25 higer level
> > languages.
> > 
> > Obviously, all other things being equal, it is better to know assembly
> > language that to not know it.  But all other things are seldom equal.
> > I suspect that most beginning programmers would gain much more from
> > learning some different HLLs.  Given a choice, I'd strongly recommend
> > one learn LISP, APL, Icon, or any of a few dozen other languages to
> > learning assembly language.
> 
> We have the world that you want.  This is CS curriculum today; are
> you happy with the level of expertise of the graduates?  I'm not,
> based on my experience with trying to hire them.  If you're not
> either, what do you think the reason is?

I think that the main problem is too much emphasis on the language and
not enough on the problems and on general principles of programming.
It's certainly not lack of assembly language.

Michael M Rubenstein

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

[Peter Seebach]

In article <01bb8923$e1d34280$87ee6fce@timpent.airshields.com>,
Tim Behrendsen <tim@airshields.com> wrote:
>We have the world that you want.  This is CS curriculum today; are
>you happy with the level of expertise of the graduates?  I'm not,
>based on my experience with trying to hire them.  If you're not
>either, what do you think the reason is?

I don't know for sure what a CS curriculum is today.  If it's anything like
psych, the first problem is that students aren't taking enough philosophy and
math classes, and aren't learning basic analytic skills like decomposition.
If you can't take a problem and break it down into parts, you can't do
anything.

I don't see assembly as a better model than English for learning this.  I see
the problem as being a tendancy to focus on concrete problem solving in any
number of languages, and no real study to the art that unifies the languages.
A programmer taught in such a curriculum knows some languages and not others,
but would need a class to learn any new language.  This is probably not ideal.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

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

[Tim Behrendsen]

Peter Seebach <seebs@solutions.solon.com> wrote in article
<4urn70$dhi@solutions.solon.com>...
> In article <01bb8923$e1d34280$87ee6fce@timpent.airshields.com>,
> Tim Behrendsen <tim@airshields.com> wrote:
> >We have the world that you want.  This is CS curriculum today; are
> >you happy with the level of expertise of the graduates?  I'm not,
> >based on my experience with trying to hire them.  If you're not
> >either, what do you think the reason is?
> 
> I don't know for sure what a CS curriculum is today.  If it's anything
like
> psych, the first problem is that students aren't taking enough philosophy
and
> math classes, and aren't learning basic analytic skills like
decomposition.
> If you can't take a problem and break it down into parts, you can't do
> anything.
> 
> I don't see assembly as a better model than English for learning this.  I
see
> the problem as being a tendancy to focus on concrete problem solving in
any
> number of languages, and no real study to the art that unifies the
languages.
> A programmer taught in such a curriculum knows some languages and not
others,
> but would need a class to learn any new language.  This is probably not
ideal.

I think this is learning bias on your part; you appear to
learn more from an abstract, theoretical basis rather than
a "sit down and try it out" basis.  I would say the latter
is more typical when learning computers than the former.

But I agree with you; "the art that unifies the languages".  I
think this is what I mean when I say "learning to think like
a programmer".  The question is, how to convey this?  It just
seems to me that the more "pure" and undistracted you can make
it, the better.

-- Tim Behrendsen (tim@airshields.com)

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

[Peter Seebach]

In article <01bb89f2$de94b840$87ee6fce@timpent.airshields.com>,
Tim Behrendsen <tim@airshields.com> wrote:
>I think this is learning bias on your part; you appear to
>learn more from an abstract, theoretical basis rather than
>a "sit down and try it out" basis.  I would say the latter
>is more typical when learning computers than the former.

The latter is more typical when learning anything; it's the dominant
form of human learning.  I think it's poorly suited to computers and
math.

>But I agree with you; "the art that unifies the languages".  I
>think this is what I mean when I say "learning to think like
>a programmer".  The question is, how to convey this?  It just
>seems to me that the more "pure" and undistracted you can make
>it, the better.

I agree with this.  I just don't think assembly counts as pure and
undistracted.

Learning to program in assembly strikes me as like trying to learn what red is
by looking at fire trucks.  It'd be easier to comprehend by looking at a patch
of red fabric.

We often use "fire engine red" to name a specific kind of red, but I'm not
sure it's the best way to learn colors.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

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

[Mark Wooding]

Mike Rubenstein <miker3@ix.netcom.com> wrote:
> "Tim Behrendsen" <tim@airshields.com> wrote:
>
> > I'm not sure if that's good or not.  One of the famous ways to
> > show recursion is a factorial computation.  Does that mean we
> > actually *want* people to implement factorial that way?
> 
> In scheme (and some other languages) it certainly is the way to
> implement it.

Are we talking about implementing it the truly stupid way as a single
function, e.g.,

	(define (factorial n)
	  (if (zero? n)
	    1
	    (* n (factorial (- n 1)))))

or properly using another function which tail-recurses, e.g.,

	(define (factorial n) (fact-assist 1 n))
	(define (fact-assist a n)
	  (if (zero? n)
	    a
	    (fact-assist (* a n) (- n 1))))

If the former, then please report for re-education; if the latter, then
well and good: tail recursion is the functional-language equivalent of a
loop in a language like C.  The first version above is similar in style
(and in the sorts of problems it causes) to the traditional 

	int factorial(int n) { return (n ? n*factorial(n-1) : 1); }

recursive C implementation, while the second is similar in spirit to the
iterative version.

(My Scheme isn't terribly good: please don't moan at me about it if it's
wrong or nasty.  Also, all of the routines above assume they get valid
inputs, and will do really bad things if they don't: issues of input
checking aren't really relevant to the discussion in hand.)
-- 
[mdw]

`When our backs are against the wall, we shall turn and fight.'
		-- John Major

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

[Mike Rubenstein]

mdw@excessus.demon.co.uk (Mark Wooding) wrote:

> Mike Rubenstein <miker3@ix.netcom.com> wrote:
> > "Tim Behrendsen" <tim@airshields.com> wrote:
> >
> > > I'm not sure if that's good or not.  One of the famous ways to
> > > show recursion is a factorial computation.  Does that mean we
> > > actually *want* people to implement factorial that way?
> > 
> > In scheme (and some other languages) it certainly is the way to
> > implement it.
> 
> Are we talking about implementing it the truly stupid way as a single
> function, e.g.,
> 
> 	(define (factorial n)
> 	  (if (zero? n)
> 	    1
> 	    (* n (factorial (- n 1)))))
> 
> or properly using another function which tail-recurses, e.g.,
> 
> 	(define (factorial n) (fact-assist 1 n))
> 	(define (fact-assist a n)
> 	  (if (zero? n)
> 	    a
> 	    (fact-assist (* a n) (- n 1))))
> 
> If the former, then please report for re-education; if the latter, then
> well and good: tail recursion is the functional-language equivalent of a
> loop in a language like C.  The first version above is similar in style
> (and in the sorts of problems it causes) to the traditional 
> 
> 	int factorial(int n) { return (n ? n*factorial(n-1) : 1); }
> 
> recursive C implementation, while the second is similar in spirit to the
> iterative version.
> 
> (My Scheme isn't terribly good: please don't moan at me about it if it's
> wrong or nasty.  Also, all of the routines above assume they get valid
> inputs, and will do really bad things if they don't: issues of input
> checking aren't really relevant to the discussion in hand.)

Obviously, one should do it right.  Dybvig, for example, explains why
the tail recursive version is better without resorting to assembly
language :-)


Michael M Rubenstein

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

[Richard A. O'Keefe]

mdw@excessus.demon.co.uk (Mark Wooding) writes:
>Are we talking about implementing it the truly stupid way as a single
>function, e.g.,

>	(define (factorial n)
>	  (if (zero? n)
>	    1
>	    (* n (factorial (- n 1)))))

>or properly using another function which tail-recurses, e.g.,

>If the former, then please report for re-education;

Ahem.
(a) We have known at least since Burstall and Darlington's work in the 70s
    how to AUTOMATICALLY turn this kind of recursion into iteration.

    F(x) = if P(x) then T(x) else H(G(x), F(R(x)))

    under certain conditions on G and H.  The only thing that prevents most
    Scheme compilers doing it is that they can't be sure that you won't
    assign something different to * or - at run time; a compiler that
    prevents you changing the primitives or that analyses the whole program
    and finds that you _don't_ change them could quite easily transform
    this function to iterative form.  Doing it when H and G are user-defined
    is harder.

(b) In a Scheme system supporting the full numeric tower; this will spend
    much more time chomping away at bignum arithmetic thanit will on its
    own procedure calls.  To reduce that cost, you need to unroll, which
    can be done every bit as easily with the recursive form as the
    iterative:

    [substitute value of factorial] =>

	(define (factorial n)
	  (if (zero? n)
	    1
	    (* n ((lambda (n)
                    (if (zero? n)
                        1
                        (* n (factorial (- n 1))) ))
		  (- n 1)) )))
                         
    [Substitute actual parameter for formal in inner lambda] =>

	(define (factorial n)
	  (if (zero? n)
	    1
	    (* n (if (zero? (- n 1))
                     1
                     (* (- n 1) (factorial (- (- n 1) 1)) )) )))

    [Simplify arithmetic forms and distribute * over if]

	(define (factorial n)
	  (if (= n 0)
            1                         
            (if (= n 1)
              1	; was (* n 1) but we know n=1
              (* n (* (- n 1)) (factorial (- n 2)) )) ))

    [Reassociate multiplication to get
     (* (* fixnum fixnum) bignum)
     instead of
     (* fixnum (* fixnum bignum)); rewrite if as case for readability] =>

	(define (factorial n)
	  (case n
            ((0 1) 1)
            (else (* (* n (- n 1)) (factorial (- n 2)) )) ))

    Some measurements, using Gambit 2.2.2 on a Manintosh Centris 660AV.
    All times are in seconds to compute 100!

    recursive, naive:		0.21 sec
    recursive, unrolled:	0.11 sec
    iterative, naive:		0.25 sec (yes, SLOWER than the recursive one!)
    iterative, unrolled:	0.14 sec (yes, SLOWER than the recursive one!)

    The iterative versions were not tail recursifve; they used Scheme's
    direct equivalent of a while loop.  For example, the iterative, naive
    version was
	(define (f3 n)
	  (do ((f 1 (* i f))
	       (i n (- i 1)))
	      ((<= i 1) f)))

    We see in this case that anyone who was sent for "re-education" learned
    something false:  in this compiler on this machine, factorial coded as
    naive recursion is FASTER than factorial coded as a while loop.
    (Actually, the real reason is the order in which the multiplications
    are done.  The recursive version does ((((1*2)*3)*4)* ... n) which
    keeps the intermediate values small as long as possible, while the
    iterative version does (1* ... *(n-2 * (n-1 * n))) which overflows
    into bignum arithmetic earlier.)

    We also see something I first noticed when testing some bignum code in
    C a couple of years back:  replacing iteration by recursion or vice
    versa may save or cost you 10--20%, but unrolling the loop HALVES the
    work.  It would be foolish indeed to spend your time turning recursion
    into iteration in order to buy a 10% speedup (or with this compiler on
    this machine, in order to by a 20% slowdown!) when you could have
    spent the same time unrolling to get a 50% reduction in time.

    The point at issue here is that the use of recursion instead of
    iteration is fully consistent with the "loop unrolling" compiler
    optimisation technique, no less so than iteration.

    Another point is that _scheduling the order in which operations
    are performed_ may have a bigger effect than the control framework
    defining that order.  (The matrix product problem is a well known
    example of this; other examples include merging several lists,
    operating on several sets, &c).

    (I cannot perform this measurement in the current top-of-the-line
    Scheme compiler, Stalin, because Stalin doesn't support bignum
    arithmetic.)

(c) What if you haven't got bignum arithmetic?
    Then turning recursion into iteration won't help with the major problem
    with factorial, which is that 

	13! = 6227020800 > 4294967295 == 2**32 - 1
                         > 2147483647 = 2**31 - 1
                         
    so trying to compute factorials in fixnum (C: int, Ada: Integer)
    arithmetic isn't going to get you very far.  You can do exact integer
    addition, subtraction, comparison, and multiplication with IEEE doubles
    up to 2**53 - 1, which sounds like a lot, but

	19! = 121645100408832000 > 9007199254740991 = 2**53 - 1

    so even flonum (C: double, Ada: Long_Float) arithmetic won't get you
    very far with factorials.

    If you seriously want to compute factorials in a language without
    bignum arithmetic, what you _really_ want to compute is the gamma
    function, which requires completely different techniques and skills.

    What has this got to to with recursion -vs- iteration?
    Well, under a minute typing the naive recursive definition,
    followed by
	(let loop ((x (- (expt 2 31) 1)) (i 1))
	  (if (> (factorial i) x) i (loop x (+ i 1))))
    let me find out how far I could compute factorials using C or Ada
    without a bignum package.  Any time spent optimising the function
    for use (as opposed to optimising it for debate, which is what I've
    been doing) would have been wasted, because it doesn't matter _how_
    you compute the function, the results are too big.

    What matters here, then, is how long it takes you to find this out.
    If the recursive definition gets *you* to *understanding* quicker,
    it's a winner.

-- 
Australian citizen since 14 August 1996.  *Now* I can vote the xxxs out!
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

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

[Bob Kitzberger]

Tim Behrendsen (tim@airshields.com) wrote:

: No, this is experienced programmer's disease.  It's not as if
: I go around optimizing everything, I just do it automatically.
: When you train yourself to think about efficiency, you naturally
: do it the efficient way the *first time*.  The cumulative effect
: of this is fast programs, and it doesn't cost any more effort.

But efficiency is not the be-all and end-all.  You have to balance
efficiency with ease of use, ease of maintenance, etc.  The
fastest or most efficient solution is not always the "best"
solution.  


--
Bob Kitzberger	      Rational Software Corporation       rlk@rational.com
http://www.rational.com http://www.rational.com/pst/products/testmate.html

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

[Patrick Horgan]

In article <4uodcb$8hr@rational.rational.com>, rlk@rational.com (Bob Kitzberger) writes:

> 
> But efficiency is not the be-all and end-all.  You have to balance
> efficiency with ease of use, ease of maintenance, etc.  The
> fastest or most efficient solution is not always the "best"
> solution.  
>

That's true but Tim had a good point.  As the years have gone by I've found myself
searching more and more for (and hitting occasionally) elegant solutions.

I know that's an inexact term, but let me see if I can flounder around a bit
and make it more confusing.;)

When I find an elegant solution much of the code falls out.  The solution gets
simpler.  It seems to come from a better understanding of the problem.  An
elegant solution seems to arise out of the problem domain with a life of it's
own demanding to be implemented.  Its a best-fit solution.

When I find one (and I think years of thinking really hard and learning hard
lead to finding more of them), it almost always ends up being the best of
all worlds.

It's efficient.
It's easy to use.
It's clear and easy to maintain.

I don't think you get here without a lot of experience in good code and bad code,
good ideas and bad ideas, and I know that this will offend some, but really,
really, low level code like assembler code is one of the ingredients that
go into your palette to bring you to a place where you can do this.

Add in some intuition and some other right brain stuff, and you start getting
developers that are head and shoulders above the rest of the folks.  You
start getting people that come up with the elegant solutions.

I've seen some of them trying to communicate in this (too) long discussion and
being frustrated because people didn't understand what they were saying.

It seemed so obvious to them, but they were talking in some cases to people 
without the background to understand their arguments.

Most people in this discussion that said you needed to learn assembler didn't
mean that there was a particular reason that assembler led you to the holy
grail of development.

They meant that assembler, and object oriented design, and algorithms, and 
math, and poetry (too strange?;) and a lot of other stuff are the pieces from
which they're building their gestalts.  It's the things from which an elegant
design and resultant elegant implementation falls out.  It takes a lot of
knowledge and a lot of experience.

Sure, what you learn from becoming a good assembler programmer is only part of
the puzzle, and if that was all you had you wouldn't be a good developer over-
all.  It IS part of the puzzle though, and people that think it's not aren't as
good as they would be if they had the breadth of experience.

It all helps, it's all important.
-- 

   Patrick J. Horgan    patrick@broadvision.com   Have horse will ride.
   Opinions mine, not my employer's except by most bizarre coincidence.

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

[Steve Heller]

patrick@broadvision.com (Patrick Horgan) wrote:

>When I find an elegant solution much of the code falls out.  The solution gets
>simpler.  It seems to come from a better understanding of the problem.  An
>elegant solution seems to arise out of the problem domain with a life of it's
>own demanding to be implemented.  Its a best-fit solution.

>When I find one (and I think years of thinking really hard and learning hard
>lead to finding more of them), it almost always ends up being the best of
>all worlds.

>It's efficient.
>It's easy to use.
>It's clear and easy to maintain.

>I don't think you get here without a lot of experience in good code and bad code,
>good ideas and bad ideas, and I know that this will offend some, but really,
>really, low level code like assembler code is one of the ingredients that
>go into your palette to bring you to a place where you can do this.

>Add in some intuition and some other right brain stuff, and you start getting
>developers that are head and shoulders above the rest of the folks.  You
>start getting people that come up with the elegant solutions.

>I've seen some of them trying to communicate in this (too) long discussion and
>being frustrated because people didn't understand what they were saying.

>It seemed so obvious to them, but they were talking in some cases to people 
>without the background to understand their arguments.

  It's often very difficult for someone who knows a subject very well
to communicate their insights to those who are relatively
inexperienced. That's probably why good technical writers can make a
living (in some cases, a very good living) writing books that explain
such things clearly and simply.




Steve Heller, author and software engineer
http://ourworld.compuserve.com/homepages/steve_heller 

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

[Tanmoy Bhattacharya]

In article <slrn523tpg.ce.mdw@excessus.demon.co.uk>
mdw@excessus.demon.co.uk (Mark Wooding) writes:
<snip>
MW: locally allocated buffers.  If the buffer is not local to the function,
MW: there's no guarantee that (in an extreme case) its address hasn't been
MW: made available to a signal handler which maliciously changes the
MW: string's length.

In C, a signal handler is not allowed to change anything whose type
isn't volatile sigatomic_t. So, technically, a C compiler can ignore this
situation.

The problem with strlen actually is that any data type can be treated
as an array of character type. So, if you do 

if(strlen(a) > 0) { changed = 1; a[strlen(a)-1] = '\0'; }

the compiler has to make sure that a != (char*)&changed before it can
decide to call strlen only once. 

Cheers
Tanmoy
--
tanmoy@qcd.lanl.gov(128.165.23.46) DECNET: BETA::"tanmoy@lanl.gov"(1.218=1242)
Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: 1 (505) 665 3003   voice: 1 (505) 665 4733    [ Home: 1 (505) 662 5596 ]

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

[Robert I. Eachus]

    (I don't usually post this wide and not restrict followups, but
this seems to be a very general discussion of interest to all sorts of
software professionals.)

In article <503bq0$js@goanna.cs.rmit.edu.au> ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

  > You don't even BEGIN to know what world I want.
  > I can tell you for certain sure that we don't even begin to approach
  > hailing distance of the shadow of the world I want.
  > To start with, I would like students at entry...

  > I'm sorry, but it is FARCICAL to argue about whether students
  > should learn assembly code early on or not when I get students who
  > cannot divide 1000 by 10 without a calculator (this really
  > happened) and cannot spell their own name (this happened too).
  > And we don't get the worst university entrants here either, far
  > from it.

   We have all seen it happening and the slide is getting faster and
faster.  The world is rapidly dividing into those who try to
understand math, science, and technology, and those who have given up,
often at an early age.

   We joke about "McJobs" and read Dilbert, but the best reality we
can hope for is one where those who are willing to confront technology
on the terms it requires are allowed and encouraged to do so.

   Back to Richard for a second:

   > - to have a really thorough grasp of their native language
   >   (I could count the number of 1st year students here who can tell me
   >    the difference between a count noun and a mass noun on the fingers
   >    of one ear)

   > - to have an adequate grasp of English if that is not their
       native language 

   > - to take *pleasure* in reading

   I always used to complain about Snow's "Two Cultures" that he got
it fundamentally wrong.  The two classes are those who understand
logic and enjoy literature, and those who don't.  Science is a side
issue.  If you can't use your "mother tongue" as a tool, you can't
succeed at many things, including science, mathemathics, history,
medicine, literature, the performing arts, and politics.

   When I was in high school (in the early 60's), the National Science
Foundation had a number of summer programs for bright students.  I
went to one for Mathematics.  The real treat was that most of the
participants, from all sorts of backgrounds, could argue.  It didn't
matter what we were discussing, students framed their arguments
cogently, avoided ad hominem attacks, and graciously accepted facts
when introduced.

   My brother later took a college course which used one of the
textbooks from that summer.  (Absract Algebra by Andre'.)  After one
semester, the college moved it to from a lower-level (freshman) course
to an upper-level (Junior or Senior).  The reason? the students needed
much more exposure to non-mathmatical courses (read English and
Philosophy) as prerequisites.

   Can we fix the problem?  No, but we can do a lot to ameliorate it.
Human society is changing way to fast for human evolution (genetic and
social) to keep up.  We first have to reach the point where every
child and adult who has the intelligence and inclination to master the
"three R's" is given every bit of assistance and encouragement to do
so.  Then we can worry about the arrangement of courses when they
reach college, but we won't have to.  Once bright students have
mastered the three Rs, they will usually have dined on such an
eclectic smorgasbord of self selected material, that we can't pretend
to dictate an order of approach.  We have all run into (and been) such
students.  We desparately need to create more.

   If you can't think of anything else you can do to help.  Found, if
necessary, a debating club/team at your child's school, and help run
it.  Those kids may love computers, but they won't make it through
college and out into the workplace unless they learn to use language
as a tool. 

   I now take you back to your regularly scheduled newsgroup.
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

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

[Steve Heller]

eachus@spectre.mitre.org (Robert I. Eachus) wrote:

>   When I was in high school (in the early 60's), the National Science
>Foundation had a number of summer programs for bright students.  I
>went to one for Mathematics.  The real treat was that most of the
>participants, from all sorts of backgrounds, could argue.  It didn't
>matter what we were discussing, students framed their arguments
>cogently, avoided ad hominem attacks, and graciously accepted facts
>when introduced.
  I was also lucky enough to participate in that program, only mine
was in programming. I then went to Shimer College, which was very
similar except that it lasted 4 years (and they didn't have any
computers!) Most of the best friends I ever had were classmates of
mine at Shimer. By the way, if anyone is interested, I've written an
essay on that topic which is accessible via my home page.

>   If you can't think of anything else you can do to help.  Found, if
>necessary, a debating club/team at your child's school, and help run
>it.  Those kids may love computers, but they won't make it through
>college and out into the workplace unless they learn to use language
>as a tool. 
  Yes, I think I will do some of these things that you suggest. Thank
you for an important, well-written and obviously heartfelt post.


Steve Heller, author and software engineer
http://ourworld.compuserve.com/homepages/steve_heller 

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

[Tanmoy Bhattacharya]

In article <50650h$rek@goanna.cs.rmit.edu.au>
ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:
<snip>
RAO:  - a program that conforms to the C standard (we were talking about
RAO:    standard C, no?) may not legally set any variable external to the
RAO:    handler if that variable is not of type sig_atomic_t.  Now on _this_
RAO:    system, sig_atomic_t is int, so a *legal* signal handler, however
RAO:    malicious, may not change a char buffer.  (This obviously won't
RAO:    apply to systems in which sig_atomic_t is char, but it _does_
RAO:    apply to this system, and the compiler is entitled to rely on it.)

It can't change a variable declared `sig_atomic_t' either: it has to
be `volatile sig_atomic_t'. And, if your buffer is volatile, it can
change anyway: signal handler or no.

Cheers
Tanmoy
--
tanmoy@qcd.lanl.gov(128.165.23.46) DECNET: BETA::"tanmoy@lanl.gov"(1.218=1242)
Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: 1 (505) 665 3003   voice: 1 (505) 665 4733    [ Home: 1 (505) 662 5596 ]

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

[Jerone A. Bowers]

Tim Behrendsen (tim@airshields.com) wrote:

: 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.

: 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.

: 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.

	An algorithm is an algorithm.  An algorithm is ( or should be ) programming 
language independent.  It would seem that assembly would teach you more about a 
particular platform than about algorithms.  I agree about the lack of fundamentals 
being taught.  Perhaps just naked algorithm classes and data strutcure classes.
Perhaps we are concentrating too much on how something works and too little on
why it works.  
  

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

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

--
These thoughts are mine and mine alone.    I can say that, right?

EMAIL: jab@bowtech.erinet.com 		|  Our differences should not
SMAIL  9221 N Main St			    |  make us enemies, but should
Dayton, OH 45415-1126			    |  make us friends

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

[Dan Pop]

In <01bb8342$88cc6f40$32ee6fcf@timhome2> "Tim Behrendsen" <tim@airshields.com> writes:

>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.
>
>Now, you wouldn't want to *maintain* large systems of assembly,
>which is why HLLs have taken over the world, but it seems to
>me that assembly per se is just not that hard to use.

OK, try to implement the "hello world" program in assembly, so that it
works on x86, 68k, MIPS, SPARC, Alpha, PPC, PA-RISC machines and, why
not, a 3090, a Cray and a CM-5.  When you're done, you might get a clue 
about why assembly per se is a pain to use.  

Unix is what it is today because Thompson and Ritchie realized the
importance of having a kernel implemented almost exclusively in a HLL
and created a suitable HLL for that purpose.  Other people discovered
that that language was very well suited for other purposes, as well,
and the rest is history...

Dan
--
Dan Pop
CERN, CN Division
Email: Dan.Pop@cern.ch 
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland

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

[Tim Behrendsen]

Dan Pop <Dan.Pop@cern.ch> wrote in article
<danpop.839349197@news.cern.ch>...
> In <01bb8342$88cc6f40$32ee6fcf@timhome2> "Tim Behrendsen"
<tim@airshields.com> writes:
> 
> >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.
> >
> >Now, you wouldn't want to *maintain* large systems of assembly,
> >which is why HLLs have taken over the world, but it seems to
> >me that assembly per se is just not that hard to use.
> 
> OK, try to implement the "hello world" program in assembly, so that it
> works on x86, 68k, MIPS, SPARC, Alpha, PPC, PA-RISC machines and, why
> not, a 3090, a Cray and a CM-5.  When you're done, you might get a clue 
> about why assembly per se is a pain to use.  
> 
> Unix is what it is today because Thompson and Ritchie realized the
> importance of having a kernel implemented almost exclusively in a HLL
> and created a suitable HLL for that purpose.  Other people discovered
> that that language was very well suited for other purposes, as well,
> and the rest is history...

I think we've strayed away from the central point.  No one is
arguing a return to the days of assembly language.

The question is (or has since become), is it better to start a
student learning the fundamentals, i.e. assembly and the internals
of computers, and then move on to abstracts; or is it better to
start with abstractions such as C or C++ and perhaps never give
the fundamentals, since "compilers are so good nowadays that
it's useless to know assembly, and in fact, can be dangerous."

I say that based on my experiences testing people straight out of
college (BS, MS, or PhD, makes no difference), we are packing
their heads so full of abstractions that they are unable to think
anymore.  I think it's much better for students to learn pure
algorithmic analysis without all the abstraction distractions that
can be better learned later on, and learned easier.

Perhaps a better question is, which is more important: Learning
abstractions or algorithmic analysis?  I say that algorithmic
analysis is 10 to 1 more important than abstractions.

-- Tim Behrendsen (tim@airshields.com)

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

[Peter Seebach]

In article <01bb83cc$fb35e180$87ee6fce@timpent.airshields.com>,
Tim Behrendsen <tim@airshields.com> wrote:
>The question is (or has since become), is it better to start a
>student learning the fundamentals, i.e. assembly and the internals
>of computers, and then move on to abstracts; or is it better to
>start with abstractions such as C or C++ and perhaps never give
>the fundamentals, since "compilers are so good nowadays that
>it's useless to know assembly, and in fact, can be dangerous."

What makes you think assembly is a fundemental?  Abstraction is *the*
fundemental tool we have.  Assembly is not fundemental by any stretch
of the imagination.

Learning the principles of computing machines would be helpful.  Seeing them
demonstrated on a specific machine might be helpful.  But assembly is not the
only way, or the best, to teach these fundementals.

>I say that based on my experiences testing people straight out of
>college (BS, MS, or PhD, makes no difference), we are packing
>their heads so full of abstractions that they are unable to think
>anymore.  I think it's much better for students to learn pure
>algorithmic analysis without all the abstraction distractions that
>can be better learned later on, and learned easier.

What are you *talking* about?  Algorithmic analysis is fundementally an
abstraction.  Rather than looking at the *specific* costs of the algorithm, we
look at the *kinds* of costs.  N^2 vs. log(N) complexity is entirely an
abstraction.

>Perhaps a better question is, which is more important: Learning
>abstractions or algorithmic analysis?  I say that algorithmic
>analysis is 10 to 1 more important than abstractions.

"Learning English is 10 to 1 more important than learning any language."

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

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

[Tim Behrendsen]

Peter Seebach <seebs@solutions.solon.com> wrote in article
<4u8lff$3bs@solutions.solon.com>...
> In article <01bb83cc$fb35e180$87ee6fce@timpent.airshields.com>,
> Tim Behrendsen <tim@airshields.com> wrote:
> >The question is (or has since become), is it better to start a
> >student learning the fundamentals, i.e. assembly and the internals
> >of computers, and then move on to abstracts; or is it better to
> >start with abstractions such as C or C++ and perhaps never give
> >the fundamentals, since "compilers are so good nowadays that
> >it's useless to know assembly, and in fact, can be dangerous."
> 
> What makes you think assembly is a fundemental?  Abstraction is *the*
> fundemental tool we have.  Assembly is not fundemental by any stretch
> of the imagination.
> 
> Learning the principles of computing machines would be helpful.  Seeing
them
> demonstrated on a specific machine might be helpful.  But assembly is not
the
> only way, or the best, to teach these fundementals.

Not to get into a debate on the meaning of abstraction, but the
point is that there is very little hidden from the student when
they are learning assembly.  This allows them to better concentrate
on the basics of algorithms, because they are not distracted by syntax.

> >I say that based on my experiences testing people straight out of
> >college (BS, MS, or PhD, makes no difference), we are packing
> >their heads so full of abstractions that they are unable to think
> >anymore.  I think it's much better for students to learn pure
> >algorithmic analysis without all the abstraction distractions that
> >can be better learned later on, and learned easier.
> 
> What are you *talking* about?  Algorithmic analysis is fundementally an
> abstraction.  Rather than looking at the *specific* costs of the
algorithm, we
> look at the *kinds* of costs.  N^2 vs. log(N) complexity is entirely an
> abstraction.

Of course, but I'm talking about abstractions of assembly, i.e.,
HLLs.  Remember, C (or any HLL) does not really exist as far as
the computer knows.  Assembly is the direct raw instruction set of
the physical machine.  If the student is learning algorithms in
assembly, they are unquestionably learning the algorithm, and not
just some vague concept wrapped in 10 layers of wool.

The *reality* is, students graduating today are just not getting
it.

> >Perhaps a better question is, which is more important: Learning
> >abstractions or algorithmic analysis?  I say that algorithmic
> >analysis is 10 to 1 more important than abstractions.
> 
> "Learning English is 10 to 1 more important than learning any language."

True, but don't get me started on the English skills of some of
my applicants!

-- Tim Behrendsen (tim@airshields.com)

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

[James A. Squire]

Tim Behrendsen wrote:

> Of course, but I'm talking about abstractions of assembly, i.e.,
> HLLs.  Remember, C (or any HLL) does not really exist as far as
> the computer knows.  Assembly is the direct raw instruction set of
> the physical machine.  If the student is learning algorithms in
> assembly, they are unquestionably learning the algorithm, and not
> just some vague concept wrapped in 10 layers of wool.

Actually, Assembly doesn't exist either, as far as the computer knows.
Machine language is the direct raw instruction set of the physical
machine.

Plan on teaching your students to program in 1's and 0's soon?
-- 
James Squire                             mailto:ja_squire@csehp3.mdc.com
MDA Avionics Tools & Processes
McDonnell Douglas Aerospace              http://www.mdc.com/
Opinions expressed here are my own and NOT my company's
"My God. Whoever's piloting that shuttle's a madman!"
	-- Ivanova (about Londo), "A Voice in the Wilderness II"

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

[Peter Seebach]

In article <01bb846c$e51df220$87ee6fce@timpent.airshields.com>,
Tim Behrendsen <tim@airshields.com> wrote:
>Peter Seebach <seebs@solutions.solon.com> wrote in article
><4u8lff$3bs@solutions.solon.com>...

>Not to get into a debate on the meaning of abstraction, but the
>point is that there is very little hidden from the student when
>they are learning assembly.  This allows them to better concentrate
>on the basics of algorithms, because they are not distracted by syntax.

Huh?

The basics of algorithms are hidden from them, when they are sitting
around counting bytes and remembering the mnemonics for operations.

Assembly has more syntax per operation done than anything else.

>Of course, but I'm talking about abstractions of assembly, i.e.,
>HLLs.  Remember, C (or any HLL) does not really exist as far as
>the computer knows.  Assembly is the direct raw instruction set of
>the physical machine.  If the student is learning algorithms in
>assembly, they are unquestionably learning the algorithm, and not
>just some vague concept wrapped in 10 layers of wool.

No, they're learning assembly.  Assembly is relatively hard.  No amount
of abstraction in a language will hide the algorithm; the more abstract the
language, the more visible the algorithm, because there's less and less there.

The only real exception is when the language encapsulates an algorithm; using
qsort() does not teach you a sorting algorithm.  But writing a quicksort() in
C will teach you at least as much about quicksort as writing it in assembly.

>> >Perhaps a better question is, which is more important: Learning
>> >abstractions or algorithmic analysis?  I say that algorithmic
>> >analysis is 10 to 1 more important than abstractions.

>> "Learning English is 10 to 1 more important than learning any language."

>True, but don't get me started on the English skills of some of
>my applicants!

Huh?  The point of my statement is that English *is* a language.  Algorithmic
analysis cannot be more important than abstractions, because it's a subset of
abstractions.

I have to agree, though, I'm sick to death of native speakers of English who
don't get it.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

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

[Tim Behrendsen]

Peter Seebach <seebs@solutions.solon.com> wrote in article
<4uahfe$bao@solutions.solon.com>...
> In article <01bb846c$e51df220$87ee6fce@timpent.airshields.com>,
> Tim Behrendsen <tim@airshields.com> wrote:
> >Peter Seebach <seebs@solutions.solon.com> wrote in article
> ><4u8lff$3bs@solutions.solon.com>...
> 
> >Not to get into a debate on the meaning of abstraction, but the
> >point is that there is very little hidden from the student when
> >they are learning assembly.  This allows them to better concentrate
> >on the basics of algorithms, because they are not distracted by syntax.
> 
> Huh?
> The basics of algorithms are hidden from them, when they are sitting
> around counting bytes and remembering the mnemonics for operations.
> 
> Assembly has more syntax per operation done than anything else.

But the syntax is very straight forward and direct. There are
very few operations in assembly that need to be learned.

> >Of course, but I'm talking about abstractions of assembly, i.e.,
> >HLLs.  Remember, C (or any HLL) does not really exist as far as
> >the computer knows.  Assembly is the direct raw instruction set of
> >the physical machine.  If the student is learning algorithms in
> >assembly, they are unquestionably learning the algorithm, and not
> >just some vague concept wrapped in 10 layers of wool.
> 
> No, they're learning assembly.  Assembly is relatively hard.  No amount
> of abstraction in a language will hide the algorithm; the more abstract
the
> language, the more visible the algorithm, because there's less and less
there.
> 
> The only real exception is when the language encapsulates an algorithm;
using
> qsort() does not teach you a sorting algorithm.  But writing a
quicksort() in
> C will teach you at least as much about quicksort as writing it in
assembly.

Yes, but will it teach you as much about *computers*?  The reality
is that the computer does not execute C.

> >> >Perhaps a better question is, which is more important: Learning
> >> >abstractions or algorithmic analysis?  I say that algorithmic
> >> >analysis is 10 to 1 more important than abstractions.
> 
> >> "Learning English is 10 to 1 more important than learning any
language."
> 
> >True, but don't get me started on the English skills of some of
> >my applicants!
> 
> Huh?  The point of my statement is that English *is* a language. 
Algorithmic
> analysis cannot be more important than abstractions, because it's a
subset of
> abstractions.

That is simply not true!  That is like saying that thought is
a subset of language.  Thoughts are expressed in language,
but they are not dependent on a particular language.

I don't know about anybody else, but when I think about an
algorithm, I have a visualization of the data moving around
and going through transformations.  I get a feel for the
efficiency by thinking about how much work is involved in doing
the movement/transformations.  I want students learning these
concepts for the first time to get this same feel, without
vaguely memorizing algorithms, which is what I think happens
now.

I think one of the reasons algorithms get memorized rather
than learned is that they are protected too much by the
abstraction of arrays, rather than the reality of memory.

-- Tim Behrendsen (tim@airshields.com)

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

[Peter Seebach]

In article <01bb853c$be3b2620$87ee6fce@timpent.airshields.com>,
Tim Behrendsen <tim@airshields.com> wrote:
>Peter Seebach <seebs@solutions.solon.com> wrote in article
><4uahfe$bao@solutions.solon.com>...
>> Huh?
>> The basics of algorithms are hidden from them, when they are sitting
>> around counting bytes and remembering the mnemonics for operations.

>> Assembly has more syntax per operation done than anything else.

>But the syntax is very straight forward and direct. There are
>very few operations in assembly that need to be learned.

Fine.  Use scheme or lisp.  Or C.  I betcha C has fewer operators,
keywords, and standard library functions than most processors have
instructions.  :)

Sure, you don't need all of the instructions.  You also don't need about
80% of C for most teaching work.

>> C will teach you at least as much about quicksort as writing it in
>assembly.

>Yes, but will it teach you as much about *computers*?  The reality
>is that the computer does not execute C.

No, nor does it execute assembly.  It executes machine code.

One does not learn C, or any other language, to learn about computers.
If you want to learn about computers also, this is a good thing, and may
well help you.

Learning C is, IMHO, a better way to learn about computers than assembly.  It
shows you the operations, rather than the noise.

>Algorithmic
>> analysis cannot be more important than abstractions, because it's a
>subset of
>> abstractions.

>That is simply not true!  That is like saying that thought is
>a subset of language.  Thoughts are expressed in language,
>but they are not dependent on a particular language.

Not all thoughts are expressed in language.  If they were, thoughts would
be a kind of language, distinguished from other kinds by some set of traits.

All algorithmic analysis analyzes the *principles* of algorithms, not the
details of specific real implementations.

>I don't know about anybody else, but when I think about an
>algorithm, I have a visualization of the data moving around
>and going through transformations.  I get a feel for the
>efficiency by thinking about how much work is involved in doing
>the movement/transformations.  I want students learning these
>concepts for the first time to get this same feel, without
>vaguely memorizing algorithms, which is what I think happens
>now.

I haven't memorized an algorithm in my life.  If I want to do something, I
either think about how it would be done, or I copy it from a likely source and
ignore it.  Frequently, an understanding of the algorithm is not necessary to
what I need it to do.  I also don't understand the file system structures used
by any of my computers, nor do I understand the scheduling algorithms used by
any of them particularly well.

I tend to agree with you on this.  I just don't think that assembly is the
best way to teach these visualizations.

>I think one of the reasons algorithms get memorized rather
>than learned is that they are protected too much by the
>abstraction of arrays, rather than the reality of memory.

Memory is not a reality, it's an implementation.  A student's comprehension
of data had *better* not depend on memory, or that student will choke badly on
trying to implement merge sort on tapes.

Arrays are *one kind* of data structure.  The belief that data is always
conveniently available in some sort of table or memory is dangerous, too.
(For that matter, an elegant and efficient way to sort an array fails
miserably on a linked list, even though both may be stored in memory.)

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

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

[David Weller]

In article <01bb846c$e51df220$87ee6fce@timpent.airshields.com>,
Tim Behrendsen <tim@airshields.com> continues his long, and relatively
indefensible, arguments for teaching assembler instead of a high-level
language for CS1-type classes...:
>
>Not to get into a debate on the meaning of abstraction, but the
>point is that there is very little hidden from the student when
>they are learning assembly.  This allows them to better concentrate
>on the basics of algorithms, because they are not distracted by syntax.
>

Yeah, for loops are sooo much clearer when you write in
assembler...and so much less error-prone because everything is right
in front of you!

>> What are you *talking* about?  Algorithmic analysis is fundementally an
>> abstraction.  Rather than looking at the *specific* costs of the
>algorithm, we
>> look at the *kinds* of costs.  N^2 vs. log(N) complexity is entirely an
>> abstraction.
>
>Of course, but I'm talking about abstractions of assembly, i.e.,
>HLLs.  Remember, C (or any HLL) does not really exist as far as
>the computer knows.  Assembly is the direct raw instruction set of
>the physical machine.  If the student is learning algorithms in
>assembly, they are unquestionably learning the algorithm, and not
>just some vague concept wrapped in 10 layers of wool.
>
>The *reality* is, students graduating today are just not getting
>it.

Your experience with new employees/interviewees that "just don't get
it" provides 0% support to your claim that abstractions in assembly
will produce smarter students (which, from my recollection at the
beginning of this thread, is what you were claiming).

Please note: Followups have been redirected -- this argument has very
little to do with the newsgroups it originally started in, and this
thread is FAR more appropriate in comp.edu.

-- 
    Visit the Ada 95 Booch Components Homepage: www.ocsystems.com/booch
           This is not your father's Ada -- lglwww.epfl.ch/Ada

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

[Bob Gilbert]

In article <01bb846c$e51df220$87ee6fce@timpent.airshields.com>, "Tim Behrendsen" <tim@airshields.com> writes:
> 
> Not to get into a debate on the meaning of abstraction, but the
> point is that there is very little hidden from the student when
> they are learning assembly.  This allows them to better concentrate
> on the basics of algorithms, because they are not distracted by syntax.

Yeah, but they are distracted by learning the computer architecture.
When I was first introduced to programming in assembly, the learning
of algorithms was not the purpose of the course.  What was learned
from programming in assembly was the underlying architecture, what
registers were, how memory was addressed, etc.

> Of course, but I'm talking about abstractions of assembly, i.e.,
> HLLs.  Remember, C (or any HLL) does not really exist as far as
> the computer knows.  Assembly is the direct raw instruction set of
> the physical machine.  If the student is learning algorithms in
> assembly, they are unquestionably learning the algorithm, and not
> just some vague concept wrapped in 10 layers of wool.

I though assembly was an abstraction of the raw instruction set, not
exactly the raw instruction set.  After all, the assembler allows one
to abstract memory locations by assigning names or labels to them, it 
abstracts the instructions by assigning shorthand pneumonics to them, 
many allow the abstraction of code fragments which might perform some
higher level function by allowing the programmer to implement them as
macros, etc.

There were two or three concepts that were emphasised through the teaching
of assembly.  First was learning the underlying computer architecture, its
registers, how it addressed and used memory, how it executed the insructions.
Second was learning the purpose and usefulness of an assembler, and what an
assembler was.  We learned about one/two/and multi-pass assemblers, how 
assemblers made it easier to program a computer through abstraction (try 
generating the bit patterens to be stored in memory for a small program by
hand).  Our primary project for the class was to code in assembly a two pass
assembler which implemented a subset of the instructions for the machine 
(some Harris mini-computer the school had) we had.  The only specific 
algorithms we were taught dealt with some of specific design issues that 
came about when attempting to implement certain aspects of the assembler, 
such as hashing functions for storing/retreiving into a symbol table, etc.
Come to think of it, these algorithms were presented to us and studied using 
some higher level psuedo code.  While we did implement them in assembly, I 
really don't think that exercise helped us to understand the algorithms any
better.

-Bob

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

[Tim Behrendsen]

Bob Gilbert <rgilbert@unconfigured.xvnews.domain> wrote in article
<4ug4eh$qn8@zeus.orl.mmc.com>...
> In article <01bb846c$e51df220$87ee6fce@timpent.airshields.com>, "Tim
Behrendsen" <tim@airshields.com> writes:
> > 
> > Not to get into a debate on the meaning of abstraction, but the
> > point is that there is very little hidden from the student when
> > they are learning assembly.  This allows them to better concentrate
> > on the basics of algorithms, because they are not distracted by syntax.
> 
> Yeah, but they are distracted by learning the computer architecture.
> When I was first introduced to programming in assembly, the learning
> of algorithms was not the purpose of the course.  What was learned
> from programming in assembly was the underlying architecture, what
> registers were, how memory was addressed, etc.
> 
> > Of course, but I'm talking about abstractions of assembly, i.e.,
> > HLLs.  Remember, C (or any HLL) does not really exist as far as
> > the computer knows.  Assembly is the direct raw instruction set of
> > the physical machine.  If the student is learning algorithms in
> > assembly, they are unquestionably learning the algorithm, and not
> > just some vague concept wrapped in 10 layers of wool.
> 
> I though assembly was an abstraction of the raw instruction set, not
> exactly the raw instruction set.  After all, the assembler allows one
> to abstract memory locations by assigning names or labels to them, it 
> abstracts the instructions by assigning shorthand pneumonics to them, 
> many allow the abstraction of code fragments which might perform some
> higher level function by allowing the programmer to implement them as
> macros, etc.

Well, technically you're right but there is a one-to-one
correspondance between assembly mnemonics and machine language,
so there is no practical difference between the two, as far
as understanding the machine.

-- Tim Behrendsen (tim@airshields.com)

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

[Craig Franck]

"Tim Behrendsen" <tim@airshields.com> wrote:
>Bob Gilbert <rgilbert@unconfigured.xvnews.domain> wrote in article
>
>> I though assembly was an abstraction of the raw instruction set, not
>> exactly the raw instruction set.  After all, the assembler allows one
>> to abstract memory locations by assigning names or labels to them, it 
>> abstracts the instructions by assigning shorthand pneumonics to them, 
>> many allow the abstraction of code fragments which might perform some
>> higher level function by allowing the programmer to implement them as
>> macros, etc.
>
>Well, technically you're right but there is a one-to-one
>correspondance between assembly mnemonics and machine language,
>so there is no practical difference between the two, as far
>as understanding the machine.
>

Realy? Why stop there? With RISC microprocessors there is almost
a one to one correspondance between instructions and hardware, but
with CISC there is not. There are little programs written in 
microcode that run when machine language instructions are executed.
Linked lists were primatives to the old VAX archetecture. And why 
stop there, to really understand computers you need to understand 
digital electronics. NAND gates, flip flops, inverters, ect. To
understand them you need a background in electronics. You need
to understand how transistors work. My point to all this is you
reach a point of diminishing return. Starting a class on algorithms
with a discusion of Ohms law is ridiculous. Needing to know how
to move values into registers rather than just writing a = b + c;
is not as bad, but its still not needed. 


-- 

Craig
-----
clfranck@worldnet.att.net
Manchester, NH
There are no electrons...

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

[Tim Behrendsen]

Craig Franck <clfranck@worldnet.att.net> wrote in article
<4ujdus$7ph@mtinsc01-mgt.ops.worldnet.att.net>...
> "Tim Behrendsen" <tim@airshields.com> wrote:
> >Bob Gilbert <rgilbert@unconfigured.xvnews.domain> wrote in article
> >
> >> I though assembly was an abstraction of the raw instruction set, not
> >> exactly the raw instruction set.  After all, the assembler allows one
> >> to abstract memory locations by assigning names or labels to them, it 
> >> abstracts the instructions by assigning shorthand pneumonics to them, 
> >> many allow the abstraction of code fragments which might perform some
> >> higher level function by allowing the programmer to implement them as
> >> macros, etc.
> >
> >Well, technically you're right but there is a one-to-one
> >correspondance between assembly mnemonics and machine language,
> >so there is no practical difference between the two, as far
> >as understanding the machine.
> >
> 
> Realy? Why stop there? With RISC microprocessors there is almost
> a one to one correspondance between instructions and hardware, but
> with CISC there is not. There are little programs written in 
> microcode that run when machine language instructions are executed.
> Linked lists were primatives to the old VAX archetecture. And why 
> stop there, to really understand computers you need to understand 
> digital electronics. NAND gates, flip flops, inverters, ect. To
> understand them you need a background in electronics. You need
> to understand how transistors work. My point to all this is you
> reach a point of diminishing return. Starting a class on algorithms
> with a discusion of Ohms law is ridiculous. Needing to know how
> to move values into registers rather than just writing a = b + c;
> is not as bad, but its still not needed. 

To tell you the truth, I think we *should* teach more hardware theory
than we do.  Maybe then I wouldn't have people ask me if they need
to change the IP address on their X terminal with the monitor is changed
(Yes, this happened).

But to answer your question, the reason is that the microcode is not
programmable in any kind of general way by the compiler.

-- Tim Behrendsen (tim@airshields.com)

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

[Peter Seebach]

In article <01bb86f5$f7f8ae40$32ee6fce@timhome2>,
Tim Behrendsen <tim@airshields.com> wrote:
>Well, technically you're right but there is a one-to-one
>correspondance between assembly mnemonics and machine language,
>so there is no practical difference between the two, as far
>as understanding the machine.

Are you quite sure?  I'd assume that assemblers would let you enter constants
in at least the three commonly used bases, and I would be completely
unsurprised if there were occasionally two ways of spelling a given operation,
perhaps allowing for a distinction which no longer exists.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

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

[Tim Behrendsen]

Peter Seebach <seebs@solutions.solon.com> wrote in article
<4uk67k$ii2@solutions.solon.com>...
> In article <01bb86f5$f7f8ae40$32ee6fce@timhome2>,
> Tim Behrendsen <tim@airshields.com> wrote:
> >Well, technically you're right but there is a one-to-one
> >correspondance between assembly mnemonics and machine language,
> >so there is no practical difference between the two, as far
> >as understanding the machine.
> 
> Are you quite sure?  I'd assume that assemblers would let you enter
constants
> in at least the three commonly used bases, and I would be completely
> unsurprised if there were occasionally two ways of spelling a given
operation,
> perhaps allowing for a distinction which no longer exists.

Of course you can enter constants in different bases, but
that doesn't affect the code that's generated.  The entire
*point* of assembler is to be a 1-to-1 corresponence.  Otherwise,
it would be a HLL.

-- Tim Behrendsen (tim@airshields.com)

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

[Alf P. Steinbach]

Tim Behrendsen wrote:
> 
> Peter Seebach <seebs@solutions.solon.com> wrote in article
> > Are you quite sure?  I'd assume that assemblers would let you enter
> constants
> > in at least the three commonly used bases, and I would be completely
> > unsurprised if there were occasionally two ways of spelling a given
> operation,
> > perhaps allowing for a distinction which no longer exists.
> 
> Of course you can enter constants in different bases, but
> that doesn't affect the code that's generated.  The entire
> *point* of assembler is to be a 1-to-1 corresponence.  Otherwise,
> it would be a HLL.


Sorry to intrude again after I opted out when the discussion polarized
(I've been lurking in the shadows, though).  But this is sort of funny.
The assembler language I now know best is x86 for early x86 processors
(386).  Modern x86 assembly does *not* correspond 1-to-1 to machine
code, as P.S. correctly points out.  But for the wrong reasons!

Many high-level constructs and ideas have migrated down to assembler
languages, like the concepts of defining datatypes, symbolic constants,
routines with typed parameter lists, if-then-else and other flow-control
constructs, and so on, including direct support for OOP in Borland's
TASM assembler.  A modern assembler program has a syntactical structure
much the same as HLL program  --  however, the programmer is free to
write everything as one long, grey mass of pure instructions with the
structure embedded as jump instructions and so on, just as you can in C.
For the first fumbling steps, this gray mass is the relevant subset.

The differences from programming in a HLL are mainly (this is opinion):


  - Limited type-checking.  The student who has really crashed a
    machine a few times will probably understand the point of
    typechecking.  Likewise, he/she may gain a better understanding
    of things like bitsets, direct versus twos-complement form
    binary, and simple static datastructures in general.

  - The top level of the memory hierarchy  --  processor registers  --
    is exposed, and under the control of the program.  A high-level
    language hides the registers and allocates them automatically.
    This is good for understanding what "sequential" really means.

  - Memory addressing is exposed and naked to the eye, although some
    assemblers (esp. Micro$oft) try to be confusing about this.  This
    is very good for understanding (A) variables, (B) parameter passing,
    (C) pointers, in order from simple to difficult to the newbie.

  - You *can* have complete control over the instructions and other
    contents ending up in the executable/library/whatever.

  - You have access to absolutely everything the machine can do.  That
    is, you use assembler not for efficiency or code size but to achieve
    something impossible or completely impractical in a HLL.  This
    includes writing linkage stubs, interrupt handlers (esp. requiring
    indirect jumps), detecting 16/32-bit code segment, etc.


Now, as I've stated earlier, I think it's silly to try to keep
knowledge from students.  Anyone who does is not a real educator,
but rather the opposite.  On the other hand, I do not think
students should start learning only assembler.  One argument here
is that students are motivated by what they can achieve of
practical results.  For example, popping up a "Hello, world"
message box in Windows 3.1 required 40-50 lines of assembler,
and not exactly newbie assembler, but only 4 lines in Pascal.

- Alf

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

[Tim Behrendsen]

Alf P. Steinbach <alfps@online.no> wrote in article
<320E742A.7288@online.no>...
> Tim Behrendsen wrote:
> > 
> > Of course you can enter constants in different bases, but
> > that doesn't affect the code that's generated.  The entire
> > *point* of assembler is to be a 1-to-1 corresponence.  Otherwise,
> > it would be a HLL.
> 
> Sorry to intrude again after I opted out when the discussion polarized
> (I've been lurking in the shadows, though).  But this is sort of funny.
> The assembler language I now know best is x86 for early x86 processors
> (386).  Modern x86 assembly does *not* correspond 1-to-1 to machine
> code, as P.S. correctly points out.  But for the wrong reasons!
> 
> Many high-level constructs and ideas have migrated down to assembler
> languages, like the concepts of defining datatypes, symbolic constants,
> routines with typed parameter lists, if-then-else and other flow-control
> constructs, and so on, including direct support for OOP in Borland's
> TASM assembler.  A modern assembler program has a syntactical structure
> much the same as HLL program  --  however, the programmer is free to
> write everything as one long, grey mass of pure instructions with the
> structure embedded as jump instructions and so on, just as you can in C.
> For the first fumbling steps, this gray mass is the relevant subset.

Heck, 360 assembler had macros and pseudo-ops; the general point is
that the purpose of assembler is to code machine language without
having to actually look up the codes yourself.

-- Tim Behrendsen (tim@airshields.com)

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

[Szu-Wen Huang]

Tim Behrendsen (tim@airshields.com) wrote:

: Of course you can enter constants in different bases, but
: that doesn't affect the code that's generated.  The entire
: *point* of assembler is to be a 1-to-1 corresponence.  Otherwise,
: it would be a HLL.

An example is in order.  The 80x86 conditional branches are relative,
so it can't jump too far.  At least one x86 assembler will convert:

   ...
   JLE  somewhere_far    ; jump if less than or equal
   ...

into:

   ...
   JG   skip_next        ; jump if greater than
   JMP  somewhere_far
skip_next:
   ...

There goes your one-to-one correspondence, yet it is immensely useful
for the *assembly* language programmer.

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

[Mark Eissler]

In article <01bb83cc$fb35e180$87ee6fce@timpent.airshields.com>, "Tim
Behrendsen" <tim@airshields.com> wrote:

> 
> Perhaps a better question is, which is more important: Learning
> abstractions or algorithmic analysis?  I say that algorithmic
> analysis is 10 to 1 more important than abstractions.
> 

As someone that studied something other than CS in University...

I'd say that the ability to define an efficient algorithm is probably THE
most important thing in design. That's step one. The algorithm can then be
optimized according to CPU specs if one understands ASM. 

So figure it out. Code it. Tweak it. 

Obviously, someone that has no clue regarding things ASM won't be able to
tell you if a certain "for" loop may be better implemented as a "while." 

Or, you could do it the MicroSoft way: just write it and if it's slow
we'll make everyone upgrade their systems.

Although I've never written anything in Assembler, I do have a working
knowledge (waiting for the upgrade ;-} when prices come down) that allows
me to understand what's happening when I see it.

--
Mark Eissler                      | Now that my DNS is working...
tequila@interlog.com              | What will I do next weekend??
http://www.interlog.com/~tequila/ | --Configure SendMail!

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

[Peter Seebach]

In article <tequila-0708960947140001@tequila.interlog.com>,
Mark Eissler <tequila@interlog.com> wrote:
>Obviously, someone that has no clue regarding things ASM won't be able to
>tell you if a certain "for" loop may be better implemented as a "while." 

Well, in C anyway, their semantics are different enough that there exist cases
where one is clearly a better way to express an algorithm.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

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

[Robert I. Eachus]

In article <01bb87cf$97ae8e80$87ee6fce@timpent.airshields.com> "Tim Behrendsen" <tim@airshields.com> writes:

  > You call 25% a "marginal" increase?  It's attitudes like this
  > that give us the slow code world we have right now.  And how
  > is one less readable than the other?

   On one hard real time project, I went from 23 minutes to 9.7
milliseconds over six months of improving the algorithms.  On another
system, the initial tests showed that speed had to be improved by a
factor of sixty.  It was, but by system redesign, not by bit-fiddling
improvements.  A twenty-five percent improvement is in the noise.  It
may be necessary noise if you are at 110% of budget, but get the logs
out of your eye first.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

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

[Chris Sonnack]

Tim Behrendsen (tim@airshields.com) wrote:

> Let's try a thought experiment.  We take two students; Jane is taught
> assembly from day 1 for two years.  John is taught C for two years.
> Both are exposed to identical curriculums of algorithmic analysis,
> data structures, etc.
>
> Two years later, they switch roles.  Who will learn the other's skills
> the easiest?

Like many I started with BASIC. But then, starting with Knuth's MIX, I
spent years in various assemblies (Z80, 8086, etc). When I got to C, I
had no problems at all with pointers. In fact, one of my favorite things
about C is the pointers. And pointers to pointers. And pointers to ....
well, you get the idea.

Now I sometimes teach C, and I've observed time and time again that a
student with assembly background picks up the language //much// faster
than someone with, say, a BASIC (or even Pascal) background. A common
question the latter students ask is, "Why do I want pointers? What good
are they??" Those with assembler background already know the value and
utility of references.

Of course, it can be explained. Of course, in time, they'll get it.

But if you've "lived in the metal", I've found you'll understand the higher
level stuff much faster and surer than those who see it as a "black box".

--
Chris Sonnack  <cjsonnack@mmm.com>                  http://eishcq.mmm.com
Engineering Information Services/Information Technology/3M, St.Paul, Minn
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TODAY'S RULE: No Smoffing or Fnargling!

Opinions expressed herein are my own and may not represent those of my employer.

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

[Stephen M O'Shaughnessy]

In article <4u54so$m6i@dawn.mmm.com>, cjsonnack@mmm.com says...
>
>Tim Behrendsen (tim@airshields.com) wrote:
>
>> Let's try a thought experiment.  We take two students; Jane is taught
>> assembly from day 1 for two years.  John is taught C for two years.
>> Both are exposed to identical curriculums of algorithmic analysis,
>> data structures, etc.
>>
>> Two years later, they switch roles.  Who will learn the other's skills
>> the easiest?
>
>Like many I started with BASIC. But then, starting with Knuth's MIX, I
>spent years in various assemblies (Z80, 8086, etc). When I got to C, I
>had no problems at all with pointers. In fact, one of my favorite things
>about C is the pointers. And pointers to pointers. And pointers to ....
>well, you get the idea.
>
>Now I sometimes teach C, and I've observed time and time again that a
>student with assembly background picks up the language //much// faster
>than someone with, say, a BASIC (or even Pascal) background. A common
>question the latter students ask is, "Why do I want pointers? What good
>are they??" Those with assembler background already know the value and
>utility of references.
>
>Of course, it can be explained. Of course, in time, they'll get it.
>
>But if you've "lived in the metal", I've found you'll understand the higher
>level stuff much faster and surer than those who see it as a "black box".
>

This sounds like the experiment that was conducted many years ago when Apple
first introduced the a windows operating system.  The debates raged on which
was better, the mindless point and click of windows or the more cerebral
command line structure of DOS.  Researchers found that high school students 
that used DOS wrote better term papers than those that used Apple/Macs.  The 
results, on further study, revealed that it was NOT the operating system but
the quality of the PERSON.  In general it takes a sharper person to want to
use a command line style.  Today few high school students use command line
operating systems.  And, I venture to say, some are  still sharper than others.

In terms of learning programming, is assembly language/machine level issues a
necessary prerequisite or are people who know these things just more *involved*
in their craft?

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

[Henrik Wetterstrom]

In article <01bb8027$de0e9c80$96ee6fcf@timhome2>, "Tim Behrendsen" <tim@airshields.com> writes:
>
>Let's try a thought experiment.  We take two students; Jane is taught
>assembly from day 1 for two years.  John is taught C for two years.
>Both are exposed to identical curriculums of algorithmic analysis,
>data structures, etc.
>
>Two years later, they switch roles.  Who will learn the other's skills
>the easiest?  I say C will be the most obvious thing in the world to
>Jane, and within a few weeks she will out-code John by a longshot.
>She will instantly see what subroutines, automatic variables,
>static variables, pointers, argument passing, call-by-value v.s.
>call-by-reference, arrays, you name it, are all about.  She will
>already know the concepts; it's just a matter of learning the syntax.
>And if she's ever confused, she can always look at the assembly
>output.
>
>John will be hopelessly confused at first, because he will have
>absolutely no grounding in what the C syntax really means.  He will
>have to start completely from scratch.  His C syntactical experience
>will be almost useless in learning assembly, because the mechanisms
>behind the "magic" have been hidden to him.

I consider myself as an "instance" of Jane and agree completely.
I learned assembler years before any other highlevel language.
Ok, when programming in assembler is it hard to ignore C, since
many system resources are documented as C structures, so you
usually get small parts of C for free when learning assembler.

However, the problem comes when you go further. Assume both
John and Jane learned both assembler and C. It is time to
learn C++ (or any other object oriented langauge).
The higher level of abstraction in OO programming is a bit harder
for a lowlevel programmer to get used to. Virtual functions,
inheritance, garbage collection etc. will take time to learn, but
I believe John would learn it faster than Jane. At least that's
my own experience.

I guess it could be better to learn C++ before C. C programmers
who go C++ tend to still program C, but with a few C++ features.
Once you are unsecure about the C++, then you go C and eventually
end up with one class and 30 functions.

Still a good programmer should learn assembler, but when to
do it? I don't have a good answer...

There's no perfect solution to teaching computer programming.

/Henrik

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

[Chris Sonnack]

Arra Avakian (arra@inmet.com) wrote:

> I do recall being mystified and puzzled by the concept of how FORTRAN
> source code could "execute", but could readily "grok" how a dumb machine
> could blindly execute machine code. It wasn't until I understood the
> concepts behind a compiler that the mystery faded and I could accept
> the abstraction of FORTRAN. What is interesting in hindsight was that 
> the concept of an assembler did not cause any mystification - its role
> as a translator was "obvious", but the role of a compiler was definitely
> not obvious.

I had a similar experience in my first days (circa 1970). Early on, I
was able to write an assembler for the Z80 (using Z80 assembler!), but
it was years before I could have written a compiler. Compilers are, to
my mind, much harder than assemblers....for obvious reasons.

> I still to this day need to understand the execution model of an
> abstraction in order to "really" understand it. I guess my character
> is to be suspicious of the mystery, and not be able to take it on "faith".

My OVERWHELMING experience as a teacher is that most students learn a
thing (any thing) faster and better if they learn the "why" and "how"
that's behind it.

--
Chris Sonnack  <cjsonnack@mmm.com>                  http://eishcq.mmm.com
Engineering Information Services/Information Technology/3M, St.Paul, Minn
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As to those junk mailing lists: Death does not release you, you know.

Opinions expressed herein are my own and may not represent those of my employer.

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

[Steve Heller]

cjsonnack@mmm.com (Chris Sonnack) wrote:

>My OVERWHELMING experience as a teacher is that most students learn a
>thing (any thing) faster and better if they learn the "why" and "how"
>that's behind it.
  My experience as a teacher and author also supports this.


Steve Heller, author and software engineer
http://ourworld.compuserve.com/homepages/steve_heller 

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

[John Hobson]

Steve Heller wrote:
> cjsonnack@mmm.com (Chris Sonnack) wrote:
> >My OVERWHELMING experience as a teacher is that most students learn a
> >thing (any thing) faster and better if they learn the "why" and "how"
> >that's behind it.
>   My experience as a teacher and author also supports this.

"Lurgan taught him how the members of a certain caste ate or sat or
spat and, since the hows of this world matter little, why they did
them in that way." -- Rudyard Kipling, "Kim"

-- 
John Hobson             |Whenever someone says to me,
Unix Support Group      |"Have a nice day", I reply,
ComEd, Chicago, IL, USA |"Sorry, I've made other plans."
jhobson@ceco.ceco.com   |	-- Sir Peter Ustinov

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

[AJ Musgrove]

J. Christian Blanchette (jblanc@ivic.qc.ca) wrote:
: > >Assembly -> C [non-GUI] -> C-GUI -> C++

: This is really crazy!

: It's maybe interesting to understand how arguments are passed on the 
: stack, but i strongly believe that simple high-level languages must be 
: learned first, and more complex one after.  Since there is a performance 

In it's purest form, assembly is much simpler than C. Each instruction does
1 and only 1 thing (in general). If someone will spend the "blood, sweat,
and tears" to learn the basics, the rest will come easily. The first
alnguage I was TRULY profienct in was x86 Assembly. Then I went to Pascal,
then C, and I've learned some more since then (but still prefer C for it's
simple elegance).

I also recomend compiled with the "generate assembly" option when a
programmer first starts learning C, so really see what that codes becomes in
assembly. (option is -s on most unix systems).

: vs. simplicity tradeoff all along, the performance desire (usually for 
: graphical applications) makes people learn lower level languages.  I know 
: many people, including myself, who made the Basic/C step for 
: performances.
Uhh.. BASIC, I'm sorry.

: C must me learned before C++, that's a point since C++ is a really more 
: complex superset.
The first C++ "compilers" really only generated C code, and compiled it.
Most C compilers still really only generate assembly, then assemble it. They
don't do strait to binary/machine format.

: I see no reason why learning GUI programming before OOP: in my sense 
: they're not related at all.  I've never did any GUI app, but the concept 
: of multiple entry points is easy to understand, as well as that of 
: object-orientedness (which can be found even in C programs, although 
: C++/Java are more adequate).
Objects are easier to udnerstand from a graphical viewpoint. A Button is an
object, and Window is an object. After one fully understands that, it is
easy to see how a Databae Connection can be an object.

: Understanding the machine architecture is one thing, using assembly 
: languages is another.  There's no real interest in knowing all the 
: mnemonics of a peculiar assembly language for a C coder: knowing how 
: stacks work or how system calls are performed is enough to make efficient 
: C programs.
In the military, soldiers are taught how to disassemble guns.
Why? There are people who could do that for them. If one FULLY understands the
tools they are using, one can use them better. Period.

: Jas.


--
AJ Musgrove

----------------------------------------------------------------
My opinions do not necessarily reflect those of MFS, or anyone
else for that matter. O-
----------------------------------------------------------------

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

[Tim Hollebeek]

AJ Musgrove (amusgrov@varmm.com) wrote:

: I also recomend compiled with the "generate assembly" option when a
: programmer first starts learning C, so really see what that codes becomes in
: assembly. (option is -s on most unix systems).

Hmm, isn't it usually -S ?  Also, I wouldn't suggest showing this to
newbie programmers unless you force them to look at the output from at
least two different compilers on two different platforms.  Some of the
_worst_ C I've seen comes from attempts to write, for example, x86 ML
in C.

: : C must me learned before C++, that's a point since C++ is a really more 
: : complex superset.
: The first C++ "compilers" really only generated C code, and compiled it.
: Most C compilers still really only generate assembly, then assemble it. They
: don't do strait to binary/machine format.

Actually, if you're going to learn C++, I'd suggest avoiding C, and
going back to it later.  Many things that are necessary to write C
programs, while available in C++, can be completely avoided.  String
and output handling, for example, differs widely.

: : Understanding the machine architecture is one thing, using assembly 
: : languages is another.  There's no real interest in knowing all the 
: : mnemonics of a peculiar assembly language for a C coder: knowing how 
: : stacks work or how system calls are performed is enough to make efficient 
: : C programs.

I agree with this sentiment.

: In the military, soldiers are taught how to disassemble guns.
: Why? There are people who could do that for them. If one FULLY understands the
: tools they are using, one can use them better. Period.

That particular tool only, though.  Too much code is written with a
particular compiler in mind, instead of writing clear code that can
compiled well for _any_ platform.

For example:

x *= 16; /* will be compiled well by any decent compiler, probably
            generating a bitshift operation if available */

x <<= 4; /* Harder to read, and will generate _slower_ code on many
	    architectures which lack a multibit shift operation */

---------------------------------------------------------------------------
Tim Hollebeek         | Disclaimer :=> Everything above is a true statement,
Electron Psychologist |                for sufficiently false values of true.
Princeton University  | email: tim@wfn-shop.princeton.edu
----------------------| http://wfn-shop.princeton.edu/~tim (NEW! IMPROVED!)

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

[Ken Pizzini]

In article <4toc18$4j0@ns3.iamerica.net>,
AJ Musgrove <amusgrov@varmm.com> wrote:
>In it's purest form, assembly is much simpler than C. Each instruction does
>1 and only 1 thing (in general). If someone will spend the "blood, sweat,
>and tears" to learn the basics, the rest will come easily. The first
>alnguage I was TRULY profienct in was x86 Assembly. Then I went to Pascal,
>then C, and I've learned some more since then (but still prefer C for it's
>simple elegance).

I really didn't grok pointers until I learned assembly.

>I also recomend compiled with the "generate assembly" option when a
>programmer first starts learning C, so really see what that codes becomes in
>assembly. (option is -s on most unix systems).

Er, make that "-S"; "-s" strips symbols from the output file.


>: Understanding the machine architecture is one thing, using assembly 
>: languages is another.  There's no real interest in knowing all the 
>: mnemonics of a peculiar assembly language for a C coder: knowing how 
>: stacks work or how system calls are performed is enough to make efficient 
>: C programs.
>In the military, soldiers are taught how to disassemble guns.
>Why? There are people who could do that for them. If one FULLY understands the
>tools they are using, one can use them better. Period.

I stopped learning the idiosyncracies of various assembly
languages after my third, but I still find knowing the general
feel of assembly languages in general is useful.  Although I no
longer work with processors which I can write assembly for, I
sometimes find that I need to go to the assembly level during
debugging, either because I need to track down a bug in a
program whose source I don't have access to, or because I feel
that the source-code debugger is obscuring the details of a
critical instruction sequence.

That said, I would recommend that assembly be taught as
language number two.  I think that it is useful to learn the
general concepts of variables, flow control, and problem
decomposition with a language that is at a higher level of
abstraction.  If it were only more widespread I would suggest
the Turing programming language (not to be confused with Turing
machines) as a first language: it was designed to minimize the
incidence of peripheral errors that beginners would tend to
make (such as misplaced semicolon errors in Pascal, runtime
detection of the use of uninitialzed variables, etc.).  Of the
"popular" languages, I think they all have serious flaws when
considered as a first programming language.

Once the basic concepts are learned, then the choice of a third
language depends on external issues, mainly:  what kinds of
programs will you be writing, and who are you writing them
for?  While any Turing-complete language can compute anything
that is computable, given enough memory and time, different
languages really do have different strengths.  In the days
before Perl I had written some mildly complex sed programs, and
maintained even more complex sed programs, but I really would
rather not program a compiler in sed, thank you very much ;-).


		--Ken Pizzini

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

[Sam Harris]

AJ Musgrove wrote:

> In the military, soldiers are taught how to disassemble guns.
> Why? There are people who could do that for them. If one FULLY understands the
> tools they are using, one can use them better. Period.

In the field, there is no one else to strip and clean your weapon.
In fact, while in garrison, a soldier is held ultimately responsible
for his weapon from time of issuance until it is returned to the
armoury and is expected to do all the cleaning and stripping
personally. No one else does it because the soldier must know
how to quickly disassemble and clear or even repair the weapon
in a dark, wet hole in no man's land.

In addition to those hard realities of military life, knowing those
intimate details of the workings of the weapon does indeed enable
the soldier to use it to better effect. Military specs on performance
envelops are always conservative. A knowledgeble soldier with the
weapon in the hand knows better how far the performance can be pushed.

As to language order, I learned BASIC and Z80 assembler at about
the same time (ages ago) and matured my techiques in both in parallel.
If someone cannot deal with the level of detail and the span of
attention required to effectively program assembly, then that
individual may be in the wrong business. Best to find out early
so the student can make an informed choice about their potential
success in the field.

When I was an Air ROTC cadet, I wanted to be a pilot. In that program,
you got 7 hours of flight instruction, 1 hour for solo, 3 hours of
additional instruction including more solos. The 12th hour was a
flight test. The candidate was expected to perform at the level of
40 hours of flight instruction. The reasoning being, if the candidate
did not have the talent to "pick it up" that quickly, then performance
would never be acceptable at the Air Force level. As a personal note,
after 7 hours, I was a competant pilot as long as everything went
a-okay, but I was no where near ready for the flight test. Like
Dirty Harry said, "A man's got to know his limitations."

I believe teaching a higher-level language with constant feedback
with the produced assembler output is a good combination worth
serious consideration and trial. In my college days tutoring other
comp-sci students, I noticed a disheartening trend of students
competent in reasoning with their familiar language becoming
totally lost in the minutia of assembly. They just count map
their higher-level language constructs into the dozens of lines
of equivalent assmbly code. Once I show them how those contructs
worked in assembly, they now had another "brand name" collection
to go with their tool set and of they went.

-- 
Samuel T. Harris, Senior Engineer
Hughes Training, Inc. - Houston Operations
2224 Bay Area Blvd. Houston, TX 77058-2099
"If you can make it, We can fake it!"

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

[Eric W. Nikitin]

Sam Harris (s_harris@hso.link.com) wrote:
: In fact, while in garrison, a soldier is held ultimately responsible
: for his weapon from time of issuance until it is returned to the
: armoury and is expected to do all the cleaning and stripping
: personally. No one else does it because the soldier must know
: how to quickly disassemble and clear or even repair the weapon
: in a dark, wet hole in no man's land.

: In addition to those hard realities of military life, knowing those
: intimate details of the workings of the weapon does indeed enable
: the soldier to use it to better effect. Military specs on performance
: envelops are always conservative. A knowledgeble soldier with the
: weapon in the hand knows better how far the performance can be pushed.

: When I was an Air ROTC cadet, I wanted to be a pilot. In that program,
: you got 7 hours of flight instruction, 1 hour for solo, 3 hours of
: additional instruction including more solos. The 12th hour was a
: flight test. The candidate was expected to perform at the level of
: 40 hours of flight instruction. The reasoning being, if the candidate
: did not have the talent to "pick it up" that quickly, then performance
: would never be acceptable at the Air Force level. As a personal note,
: after 7 hours, I was a competant pilot as long as everything went
: a-okay, but I was no where near ready for the flight test. Like
: Dirty Harry said, "A man's got to know his limitations."

How many hours did you spend disassembling/reassembling/repairing the plane?

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

[Raffael Cavallaro]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1814 bytes --]


In article <4toc18$4j0@ns3.iamerica.net>, amusgrov@varmm.com (AJ Musgrove)
wrote:


> In the military, soldiers are taught how to disassemble guns.
> Why? There are people who could do that for them. If one FULLY understands the
> tools they are using, one can use them better. Period.

Soldiers don't take their weapons apart and reassemble them so they can
"fully" understand them. Most infantrymen are not too bright, and they
sure as hell don't "fully understand" how the blowback mechanism of an
automatic rifle functions. Soldiers are taught to disassemble guns for a
simple reason--in order to clean the parts and keep their weapons in
operating condition. In the field of battle, there aren't gun repair
shops, so you have to do it yourself.

 Unless you're planning to use your computer away from civilization (and
some people do--I used to when I did field archaeology) you don't need to
know how to take it apart and put it back together -- there are
professional technicians for that.

Of course, if you're writing software, it is advantageous to know how your
microprocessor works, what its instructions are, busses, registers etc. so
you can code for speed/low memory if you need to. Of course, if you're not
writing such software, you can remain blissfully ignorant of such things.
To this day I have no idea what the processor instructions or machine
architecture were on the system I first learned to program on, but it
didn't stop me from writing fully functional software. Of course, my
programs might have been a bit faster if I had known, but a decent
compiler often obviates the one time necessity to "get down to the metal."
This is only becoming *increasingly* true. As compiler technology
advances, assembly language programming is becoming less and less
necessary.

just my 2�

Raf

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

[Chris Sonnack]

Raffael Cavallaro (raffael@tiac.net) wrote:

>> In the military, soldiers are taught how to disassemble guns.
>> Why? There are people who could do that for them. If one FULLY understands
>> the tools they are using, one can use them better. Period.
>
> Soldiers don't take their weapons apart and reassemble them so they can
> "fully" understand them. Most infantrymen are not too bright, and they
> sure as hell don't "fully understand" how the blowback mechanism of an
> automatic rifle functions. Soldiers are taught to disassemble guns for a
> simple reason--in order to clean the parts and keep their weapons in
> operating condition. In the field of battle, there aren't gun repair
> shops, so you have to do it yourself.

Well, in this case, you're both right.

It's the old, "You don't have to know how a car works to use one" argument.

And that's basically true...as far as it goes.

BUT! You'll, I think, be a //better// driver if you DO know; and you'll be
in a FAR better position to help yourself when you break down and there's
no other help in sight.

--
Chris Sonnack  <cjsonnack@mmm.com>                  http://eishcq.mmm.com
Engineering Information Services/Information Technology/3M, St.Paul, Minn
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UNIX is a very user-friendly operating system ...
			... it's just picky about who it's friends with

Opinions expressed herein are my own and may not represent those of my employer.

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

[Patrick Horgan]

In article <31FBC584.4188@ivic.qc.ca>, "J. Christian Blanchette" <jblanc@ivic.qc.ca> writes:
> 
> C must me learned before C++, that's a point since C++ is a really more 
> complex superset.

Last year I taught a C++ for non-programmers class using Pohl's "Object Oriented
Programming Using C++".  The class went fine.


-- 

   Patrick J. Horgan    patrick@broadvision.com   Have horse will ride.
   Opinions mine, not my employer's except by most bizarre coincidence.

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

[William Clodius]

In article <01bb853b$ca4c8e00$87ee6fce@timpent.airshields.com> "Tim
Behrendsen" <tim@airshields.com> writes: 

   Peter Seebach <seebs@solutions.solon.com> wrote in article
   <4uah1k$b2o@solutions.solon.com>...
<snip>
   > 
   > But your concept of what the "fundemental operations" are is completely
   tied
   > up in how specific hardware you've seen operates.  Algorithms exist in
   terms
   > of abstract operations, not moves and branches.

   Please name me the hardware that does not use moves and branches.

Show me an algorithm, not an implementation of an algorithm, that uses
moves and branches. Your phrasing has been poor on this thread. When
you say you want students to learn algorithms you seem to be really
saying you want students to learn how to implement a given algorithm
efficiently. They are typically two different things. The proper
algorithm can save orders of magnitude in runtime, the proper
implementation smaller, but sometimes important, factors of two or
three. 

   > Something like CWEB might be a good language in which to learn
   algorithms.
   > Scheme might too.
   > 
   > Let's look at a specific algorithm; the infamous gcd(x, y).
   > 
   > In C, we write
   > 
   > 	int
   > 	gcd(int x, int y) {
   > 		if (y == 0)
   > 			return x;
   > 		return gcd(y, (x % y));
   > 	}
   > 
   > or something similar.
   > 
   > What's important here is not any theories people may have about where the
   x
   > and y are stored, or how a stack works, but the concept that you can
   define an
   > algorithm in terms of a previous case.  Learning that the if() may be
   > implemented with "a branch" does not help the student understand how the
   > *algorithm* works, it helps the student understand how the *compiler*
   works.
   > These are distinct things.

   This is an interesting case, because it is somewhat inefficently
   implemented.  If you're interested in speed, you would do...

   int gcd(int x, int y) {
       int z;
       while (y != 0)
	   z = y; y = x % y; x = z;
       return(y);
   }

   Using my AIX compiler, I get a nominal improvement of about
   10%, mostly because the speed of the modulo is much slower
   than the inefficiency of recursion.

   My point is that how does a C programmer know that recursive
   implementations are somewhat inefficient?  Recently the C/C++
   Users Journal had a little bite-sized article about a
   general looping algorithm, where you could specify the number
   of nested loops in a dynamic fashion.  It was implemented
   recursively.  I wrote a letter back reimplementing the
   algorithm non-recursively, and got like a 40% increase in
   speed.

Actually the efficiency of Peter's implementation depends on the
optimizing capability of the compiler. Many compilers recognize his
example as employing tail recursion and eliminate the recursion by
replacing the recursive calls with the appropriate iterations. This
capability is required for Scheme compilers for example. Did you try
full optimization on your AIX compiler? There are of course problems
for which recursive algorithms can not employ such an obviously
optimizable construction. 

   These sorts of issues are where code bloat comes from, and
   it comes from naive implementations of "valid C syntax".

Are there really significant differences in the resulting code sizes?
Myself, I believe that code bloat is primarilly due to feature bloat,
and old programs that are not completely rewritten to remove unneeded
code.

   > >If programming is reduced to fundamentals of move, arithmetic,
   > >test, branch, etc it prevents the student from leaning on the
   > >abstraction rather than truly understanding the solution to the
   > >problem.  In other words, if they can express it in the above
   > >terms, you *know* they understand the solution.
   > 
   > But it also prevents them from learning the abstraction, and truly
   > understanding the *principle* of the solution.

   If the C abstraction is good, more abstraction must be better
   then.  How about we teach everything in APL, where we can
   *really* abstract away the details?  No data types, full
   array operations.  Talk about easy quicksort!  I can write it
   in one line of code using a handful of operations (my APL
   is *really* rusty, so I can't give the example).

Sounds good to me, but J, NIAL, or NESL might be better. Or a higher
order language such as Scheme or Clean.

   The student learns Quicksort, there is no question about it.
   But what have they *really* learned?

They have the chance to implement Heapsort, and Insertion and find out
how all three scale with problem size and character. (Let them run a
simple heapsort on a previously sorted array, or a large number of
small arrays.)

   [snip]
   > Nonsense.  A well designed and considered abstraction will generally lend
   > itself to an efficient and elegant implementation.  An ill-considered
   > abstraction will spend more time on cruft than it will on solving the
   problem.

   Like recursive algorithms?

Wasn't it Knuth who said something like, "Premature optimization is
the root of all evil"? We should write code that, to the greatest
extent possible is self explanatory, does the job that is needed, and
where computationally intensive parts of the code are expected, an
appropriately chosen algorithm. Then if testing shows a performance
problem, identify the problem routines and clean them up.

<snip>

Followups directed to comp.edu
-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos National Laboratory	Email: wclodius@lanl.gov
Los Alamos, NM 87545

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

[William Clodius]

There is one special case of recursion, fortunately the most commonly
encountered case, where it is "ridiculously" easy for a compiler to
see that the recursion can be replaced by iteration. The recursive
code must call itself directly on only one branch of the control of
flow and is the last call before returning on that control of
flow. Conventionally it is placed on the last branch of the control of
flow for clarity, hence the name "tail" recursion.

Quoting the NEW Hackers dictionary

"tail recursion: n. If you aren't sick of it already, see tail
recursion." 

which is essentially equivalent to

tail recursion: n. while you aren't sick of it, read "tail recursion:
n. If you aren't sick of it already, see tail recursion."

There are other more subtle cases (where indirect recursion is invoked
(A calls B which calls A), multiple recursion (A calls A more than
once), etc.) where recursion elimination is possible, but significantly
more difficult to detect and implement. For example, B could be
inlined into A and result in tail recursion for the new version of
A. It is doubtfull that any compiler will recognize all special cases,
but there are several that can handle more than just tail recursion.

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos National Laboratory	Email: wclodius@lanl.gov
Los Alamos, NM 87545

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

[Fergus Henderson]

clodius@hotspec.lanl.gov (William Clodius) writes:

>There is one special case of recursion, fortunately the most commonly
>encountered case, where it is "ridiculously" easy for a compiler to
>see that the recursion can be replaced by iteration. The recursive
>code must call itself directly on only one branch of the control of
>flow and is the last call before returning on that control of
>flow. Conventionally it is placed on the last branch of the control of
>flow for clarity, hence the name "tail" recursion.

That isn't sufficient condition; in C, it's also necessary for the
compiler to check that the function not take the address of any local
variables.  (GNU C checks a slightly more general condition -- it only
does tail recursion optimization in functions which don't have any
variables stored on the stack at all.)

The requirement that it be only one branch of the control flow is
unnecessary.  In C, it should be just as "ridiculously" easy for the
compiler to optimize any `return' statements which return the result
of a recursive call to the containing function, regardless of the
control flow.  For example, in

	void f(int x) {
		if (x % 4 == 0) return f(x/3 - 1);
		if (x % 3 == 0) return f(x/2 - 1);
		...
	}

it should be easy enough to replace this with

	void f(int x) {
	entry:
		if (x % 4 == 0) { x = x/3 - 1; goto entry; }
		if (x % 3 == 0) { x = x/2 - 1; goto entry; }
		...
	}

The compiler doesn't need to check that there is only one flow
of control, it just needs to check that the function doesn't
take the address of any local variables (before the recursive tail call).

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

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

[Dik T. Winter]

In article <g1sp9xtkmd.fsf@hotspec.lanl.gov> clodius@hotspec.lanl.gov (William Clodius) writes:
 > There is one special case of recursion, fortunately the most commonly
 > encountered case, where it is "ridiculously" easy for a compiler to
 > see that the recursion can be replaced by iteration.
...
Etc.  An interesting thread, but I wish to add that I know of at least
one system were a recursive algorithm was *significantly faster* than
the equivalent one with tail recursion removed.

But talking about that "gcd" thingy.  I tested and found the following
on two different architectures (times are seconds for a complete program):

		recursive	non-recursive

arch1, non-opt	0.52		0.42
arch1, opt	0.43		0.41

arch2, non-opt	2.65		0.44
arch2, opt	0.39		0.42

Now, what does this prove?  Absolutely nothing (except that there is
something strange with the non-optimization on arch2).  And what are
we talking about anyway?  The call was:
	gcd(2971215073LU, 1836311903LU);
(and if you do not understand why I used those numbers, those are the
absolutely worst case for 32-bit numbers; Fibonacci, you know).
That was the call and it was executed 10,000 times.  So we are talking
about a routine taking some tens of microseconds.  If that would form
a large part of a total program (large enough to make a 10% improvement
worthwhile), I would bother more about the program.

Somebody used the word "microoptimization"; how right he/she was.
-- 
dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland, +31205924098
home: bovenover 215, 1025 jn  amsterdam, nederland; http://www.cwi.nl/~dik/

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

[Ole-Hjalmar Kristensen FOU.TD/DELAB]

I have some supporting data for your case. Consider the following
rather different programs which copy data as fast as possible:

::::::::::::::
duff.cc 
::::::::::::::

int from[1000000], to[1000000];

int   main(int ac, char **av)
{
    int count = sizeof(from) / sizeof(int);
    for (int i = 0; i < 100; i++) {
        int * s = from, *d = to;
        
        register int n = (count + 15) / 16;
        switch (count % 16)
            while (--n) {
            case 0: 
                *d++ = *s++; 
            case 15: 
                *d++ = *s++;
            case 14: 
                *d++ = *s++;
            case 13: 
                *d++ = *s++;
            case 12: 
                *d++ = *s++;
            case 11: 
                *d++ = *s++;
            case 10: 
                *d++ = *s++;
            case 9: 
                *d++ = *s++;
            case 8: 
                *d++ = *s++;
            case 7: 
                *d++ = *s++;
            case 6: 
                *d++ = *s++;
            case 5: 
                *d++ = *s++; 
            case 4: 
                *d++ = *s++; 
            case 3: 
                *d++ = *s++; 
            case 2: 
                *d++ = *s++; 
            case 1: 
                *d++ = *s++; 
            }
    }
    return 0;
}

::::::::::::::
loop.cc
::::::::::::::

int from[1000000], to[1000000];

int   main(int ac, char **av)
{
    int count = sizeof(from) / sizeof(int);
    for (int i = 0; i < 100; i++) {
        int * s = from, *d = to;
        for (int j = 0; j < count; j++) {
            *d++ = *s++;
        }
    }
    return 0;
}

::::::::::::::
loop2.cc
::::::::::::::

int from[1000000], to[1000000];

int   main(int ac, char **av)
{
    int count = sizeof(from) / sizeof(int);
    for (int i = 0; i < 100; i++) {
        for (int j = 0; j < 1000000; j++) {
            to[j] = from[j];
        }
    }
    return 0;
}

::::::::::::::
rloop.cc
::::::::::::::

struct buf {
    int i[1000000];
};

buf from;
buf to;

int   main(int ac, char **av)
{
    for (int i = 0; i < 100; i++) {
        to = from;
    }
    return 0;
}


::::::::::::::
mem.cc
::::::::::::::

int from[1000000], to[1000000];

int   main(int ac, char **av)
{

    int count = sizeof(from);
    for (int i = 0; i < 100; i++) {
        memcpy((char *) to, (char *) from,count);
    }
    return 0;
}

All programs are compiled with gcc on a SPARC.

No optimization:

time duff
       76.2 real        65.2 user         1.8 sys  
time loop
       96.0 real        77.1 user         1.7 sys  
time loop2
       89.6 real        72.1 user         1.9 sys  
time rloop
       42.2 real        23.7 user         2.2 sys  
time mem
       45.5 real        24.5 user         1.9 sys  


-O3:

time duff
       42.4 real        23.6 user         1.4 sys  
time loop
       43.5 real        26.0 user         1.8 sys  
time loop2
       40.9 real        24.1 user         1.8 sys  
time rloop
       40.8 real        24.1 user         1.8 sys  
time mem
       43.5 real        23.7 user         1.6 sys  


-O3 -funroll-loops:

time duff
       45.4 real        23.6 user         1.7 sys  
time loop
       45.0 real        23.0 user         1.7 sys  
time loop2
       46.0 real        23.4 user         1.9 sys  
time rloop
       44.3 real        24.3 user         1.9 sys  
time mem
       42.5 real        24.0 user         1.8 sys  


Conclusion: In this case, even manual loop unrolling does not buy you
very much if you are going to compile with an optimizing
compiler. (This example is probably too simple, although the first program
should be obfuscated enough...)

For a loop such as this, using arrays instead of pointers is
marginally faster, unless I turn on the -funroll-loops flag, for some reason.

It is interesting to note that using memcpy does not increase the
speed of copying. This may be different on other CPU's.

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

[Richard A. O'Keefe]

There's a debate full of sound and fury going on.
So far I haven't noticed anyone else make these points:

(a) I personally don't know any really good programmers who don't understand
    "assembler".  Understand != like; understand != can write large volumes
    of code; understand != normally uses assembly level concepts.

    What's really involved here is a grasp of computer _architecture_.
    8086, 68000, ns32000, HP-PA, SPARC, Power-PC, /370, PDP-11, even KA-10
    have a *heck* of a lot in common.  Having used a B6700 in my
    undergraduate years, these machines all look pretty much the same to
    me:  untagged byte addressed register machines with a linear address
    space (in the case of the 8086, there is a linear address space
    _there_ you just have to do strange things to get to it).  But even
    the B6700 fits into the general
	- linear physical address space
	- load, store, operate
	- fixed set of data sizes
	- approximate arithmetic uses (hardware or software) floating
	  point instead of any of the several alternatives that have
	  been proposed.
    mould, well described by the (abstract) RAM cost model within reasonable
    limits.

    People who say "but if you learn an assembler, you think in terms of
    that machine for the rest of your life" are not talking about *good*
    programmers; they are talking about the trained seals who will write
    C for the rest of their lives whatever programming language they use.
    A *good* programmer is no more limited by the first machine s/he learns
    (in my case I learned the IBM 650 from a book shortly before I learned
    the IBM /360 from another book; I have seen a 650 in a museum but never
    programmed one) than s/he is limited by the first programming language
    s/he learns (in my case, Fortran and Algol 60, more or less at the same
    time).

(b) To me, one of the main advantages of knowing about computer
    architecture is that I have rock-solid confidence that all these
    towers of abstraction actually bottom out in things I understand.
    Well, I've forgotten most of the semiconductor phsyics they taught
    me, but give me enough 74xx chips and I could build a computer if I
    had to.

    The point here is my psychology-of-learning:  I am comfortable with
    abstraction, but I have to know that there is something at the bottom.
    I'm quite happy to work with the lambda calculus, for example, but I
    know how to implement it on hardware that I understand, so I proceed
    in the *confidence* that it is something I could take apart in as much
    detail as I wanted, given time.  Similarly, I was able to learn Prolog
    fast, because I had previously written a theorem prover, in a lisp-
    like language that I had implemented myself.  So I *knew* for certain,
    without any worry, that this was the kind of thing that *could* be
    implemented on a computer.  I didn't have to understand how the Prolog
    system I was using actually worked to be sure that Prolog was the kind
    of thing that _could_ work.

    Let's face it:  how many of you were taught about integration (a
    high level abstraction) before you had some practice with counting
    rods (the natural numbers are an abstraction, but counting rods are
    solid wood that you can hold in your hands and *see* that 1+2 = 2+1 = 3).
    On of the problems with "New Math" was excessive talk about abstractions
    (commutativity and so on) before children had thoroughly mastered the
    concrete experiences (counting, addition) the abstractions are based on.

    So,
	- some people don't handle abstraction well,
	- some people handle abstraction very well, but require an
	  understanding of what's underneath the layers of abstraction
	  for comfort, even if they don't _use_ those layers whil
	  manipulating a particular abstraction
	- some people handle abstraction well, and don't mind not
	  understanding what's underneath the abstraction

    What proportion of the general population belongs to each group is an
    empirical question about which I have no information.

    What proportion of the population of presently or potentially good
    programmers is another empirical question about which I have only
    anecdotal information.  My personal experience has been that people
    in the first group do not become good programmers, and that people
    in the third group write papers, not programs.  But of course my
    experience is limited to a few hundred people from a narrow range
    of ages and cultures.

(c) The conclusion we draw from this is that different people are likely
    to require different approaches (most of the PC computer books are
    clearly aimed at people who have no ability with abstraction at all,
    in consequence I find them frustratingly unreadable) and this 
    includes different initial languages.  Some people will learn best by
    starting with Scheme.  Some people will learn best by starting with
    transistors, going on to gates and flip flops, moving on to ALUs, then
    learning say DEC-10 with its assembler, then Pascal, then Lisp, then ML.
    
    Me, I learned bottom up and I'm glad of it.
    (For the record, I use the highest level languages I can get my hands
    on.  But I still have to check assembly code from time to time.)

(d) The *real* problem we have trying to teach some of this stuff is that
    there just isn't enough *time*.  There are so *many* things out students
    "need" to know:  user interfaces, relational data bases, a couple of
    programming languages, software engineering basics, you name it.  RMIT
    actually has a reputation for graduating employable students, and I
    honestly don't know how we manage it when I think of all the knowledge
    I deploy in programming and the tiny fraction of it they get.  I am
    still rather unhappy about letting anyone use floating point arithmetic
    without a semester of numerical analysis so they at least know where
    the pitfalls are and when to call for help.

    There are no royal roads and there isn't enough time.


Now for something rather different.  I am cosupervising a masters student
who is trying to get a handle on *measuring* the effect of first year language.
This is actually part of RMIT's Quality Control program, and Dr Isaac Balbin
came up with the idea of getting someone to see if we could actually _measure_
whether selecting a particular first year language (in our case, Ada) is or
is not having the intended educational results.  The student has conducted a
literature survey, and has found a couple of survey papers, but they seem to
be weak on actually measuring *outcomes* (other than whether the students
_liked_ it or not, which is important, but not everything).

So can anyone point me to some empirical results, where someone has done
some before and after educational measurements, to see what effect a new
first year language (e.g. switching from Pascal to Miranda, or Fortran to
Modula-2, or whatever) has actually had?  Unpublished results would be fine.

-- 
Fifty years of programming language research, and we end up with C++ ???
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.

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

[Mark Eissler]

> "Tim Behrendsen" <tim@airshields.com> wrote:
> 
> >Mark Eissler <tequila@interlog.com> wrote in article
> ><tequila-2007961836190001@tequila.interlog.com>...
> >> Yes, but since just about everyone else has said something I'd say follow
> >> this path BASIC -> Pascal -> C -> C++ -> JAVA. 
> 
> >I think that is fine for the casual programmer.  If you want to be
> >a professional programmer, I think this is the *best* course, but
> >not the easiest ...
> 
> >Assembly -> C [non-GUI] -> C-GUI -> C++
> 
> >All the rest of the languages are variations on the same theme.

I would still argue that some form of BASIC should be taken as a
preliminary step to any programming. Going from nothing into Assembly is
suicidal. Something as simple as a loop tends to appear 8 billion times
more complicated than the same thing in BASIC. Not only that, but you
can't argue that ASM isn't more cryptic than any high level language. 

Although I've only dabbled in Assembly (I do intend to crack this beast!),
I don't think it's a great starting point. Possibly a next step. Structure
will be more clear learned from BASIC (writing sequentially executed
programs). ASM code looks like it jumps around an awful lot (because it
does).

I think it can be agreed, though, that learning to program is a
progression. You can't just pick up one book one day and expect to write
the next killer app the day after.

My first programming experiences began with a ZX-81 about 15 or 16 years
ago. I must have learned at least 4 or 5 different interpretations of
BASIC after that before moving on to dBASE, C (got confused), Pascal
(needed it to understand the developer docs. provided by Apple for the
Mac), C again (Pascal knowledge helped me real big with this), C++. I'm
still dealing with C++ right now. Plan to learn JAVA next (don't feel too
pressured though) and want to get back into learning ASM. I think I might
add Ada to my list of things to do. 

I guess there are arguments that you don't need to learn a billion
languages in order to learn how to program. Having spent a great deal of
time learning this  (without too much formal instruction -- 'cause I
really suck at the math courses they always make mandatory at
Universities) I think the progression from one language to the next has
only helped me.

--
Mark Eissler                      |  If something doesn't start
tequila@interlog.com              |  happening soon, I'm gonna    http://www.interlog.com/~tequila/ |  take up Yak farming!

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

[Robert Dewar]

Tim recommends

"Assembly -> C [non-GUI] -> C-GUI -> C++

All the rest of the languages are variations on the same theme.
Here's my rationale ...

Assembly:   Learn what's *really* going on.  The most important."


I strongly disagree. A student treading this path will have a hard time
learning what abstraction is all about. Teaching abstraction is the
biggest challenge in teaching at an elementary level. It is possible
to recover from a (mis)education that follows the path above, but
very difficult for most people.

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

[Tim Behrendsen]

Robert Dewar <dewar@cs.nyu.edu> wrote in article
<dewar.838609515@schonberg>...
> Tim recommends
> 
> "Assembly -> C [non-GUI] -> C-GUI -> C++
> 
> All the rest of the languages are variations on the same theme.
> Here's my rationale ...
> 
> Assembly:   Learn what's *really* going on.  The most important."
> 
> I strongly disagree. A student treading this path will have a hard time
> learning what abstraction is all about. Teaching abstraction is the
> biggest challenge in teaching at an elementary level. It is possible
> to recover from a (mis)education that follows the path above, but
> very difficult for most people.

I arrived at this conclusion based on the students that were coming
to me to be hired.  I give a standard test to all my applicants that
tests two primary attributes,

1) How well they understand what's *really* going on; the best
programmers have a solid foundation.
2) How well the can take a problem they've (probably) never seen
before and generate a solution.

I was shocked at the results.  I had people with Masters and
Doctorates who were completely incapable of creating new solutions
that they had never seen before.  I had people, with *degrees* now,
tell me "convert argument to binary" as one of the steps on a
logical operation problem!  The latter are people who are ground
in the "abstraction" of an integer, but are completely clueless
that the computer works in binary. How can a student get a
full-blown degree, and not understand a computer works in binary?
It's like graduating someone with a writing degree who is
illiterate.

This is what convinced me that our CS education is being done
completely wrong.  I've said this before [excuse my repetition];
it would be as if EE students were taught IC design in the first
course, and were only given resisters, capacitors, ohm's law,
etc. in their senior year, almost as an afterthought!

Bottom line, a student cannot fundamentally understand an
abstraction until they understand the abstraction
in terms of the fundamental components of programming; again:
Move, Arithmetic, Test, Branch, and Logicals.

CS is currently taught the way you describe.  Why do you think
it's so hard to teach abstractions at the elementary level?
It's because the students get so wrapped up in the fancy
terminology, they don't see that its really all smoke and
mirrors, and the concepts are very, very basic.  If it's
expressed in fundamental ways, it's very easy to see what
abstractions are really saying in *real* terms.

I have seen it!  Teaching CS the way you describe it is
producing brain damage of the highest degree.

-- Tim Behrendsen (tim@airshields.com)

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

[Paul Campbell]

>>>>>>
I was shocked at the results.  I had people with Masters and
Doctorates who were completely incapable of creating new solutions
that they had never seen before.  I had people, with *degrees* now,
tell me "convert argument to binary" as one of the steps on a
logical operation problem!  The latter are people who are ground
in the "abstraction" of an integer, but are completely clueless
that the computer works in binary. How can a student get a
full-blown degree, and not understand a computer works in binary?
It's like graduating someone with a writing degree who is
illiterate.
<<<<<<<

We have had CS students on placement here after 2 years of study who
didn't even understand hexedecimal !.

Paul C.
UK.

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

[Robert Dewar]

Paul said

"We have had CS students on placement here after 2 years of study who
didn't even understand hexedecimal !."

Perhaps they might have understood hexadecimal
                                      ^

yes, yes, I know, I make more spelling errors than most on newsgroup
posts because I type in furiously and do not bother to correct, but
this one was hard to resist :-)

I actually don't find it so terrible for CS students with two years
of study not to know hexadecimal notation. I would be more disturbed
if they did not know and understand what an abstract data type was,
or what call by reference means.

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

[Tim Behrendsen]

Robert Dewar <dewar@cs.nyu.edu> wrote in article
<dewar.838737842@schonberg>...
> Paul said
> 
> "We have had CS students on placement here after 2 years of study who
> didn't even understand hexedecimal !."
> 
> Perhaps they might have understood hexadecimal
>                                       ^
> 
> yes, yes, I know, I make more spelling errors than most on newsgroup
> posts because I type in furiously and do not bother to correct, but
> this one was hard to resist :-)
> 
> I actually don't find it so terrible for CS students with two years
> of study not to know hexadecimal notation. I would be more disturbed
> if they did not know and understand what an abstract data type was,
> or what call by reference means.

Yes, but if they don't even know what hexadecimal is (or by extension
the fundamentals), do they *really* understand what an abstract data
type is, or what call by reference means?  I'm sure they could quote
the book definition, but do they really *understand* it?

-- Tim Behrendsen (tim@airshields.com)

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

[Peter Seebach]

In article <01bb8023$4bfe7a80$96ee6fcf@timhome2>,
Tim Behrendsen <tim@airshields.com> wrote:
>Yes, but if they don't even know what hexadecimal is (or by extension
>the fundamentals), do they *really* understand what an abstract data
>type is, or what call by reference means?  I'm sure they could quote
>the book definition, but do they really *understand* it?

Certainly.  Knowing hex won't buy you anything WRT abstract data types.
Knowing the bottom half of the machine might help you understand the
*mechanics* of call by reference.  It would not help you understand the
*implications*.  You can explain the implications easily using metaphors,
and most students will quickly grasp why these operate differently.

-s


-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

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

[Alf P. Steinbach]

Peter Seebach wrote:
> 
> In article <01bb8023$4bfe7a80$96ee6fcf@timhome2>,
> Tim Behrendsen <tim@airshields.com> wrote:
> >Yes, but if they don't even know what hexadecimal is (or by extension
> >the fundamentals), do they *really* understand what an abstract data
> >type is, or what call by reference means?  I'm sure they could quote
> >the book definition, but do they really *understand* it?
> 
> Certainly.  Knowing hex won't buy you anything WRT abstract data types.

The question had nothing whatsoever with the benefits of knowing hex, but
with the absence of knowledge of such a fundamental matter.  Knowing that
a car needs gasoline won't buy you anything with respect to driving a
car (when this matter does not make itself important, as the matter of
hex numbers could make itself important, e.g. while designing iostreams).
However, I wouldn't entrust a car to a person not knowing about gasoline.


> Knowing the bottom half of the machine might help you understand the
> *mechanics* of call by reference.  It would not help you understand the
> *implications*.  You can explain the implications easily using metaphors,
> and most students will quickly grasp why these operate differently.


I have a really hard time understanding why students should *not* learn
about the physical machine.  If they're not able to grasp a simple thing
like hex and binary, then they most certainly will not be able to grasp
abstract datatypes (design, implementation and usage of).  Not for lack
of the fundamentals  --  as you've pointed out, it is possible to reason
at any given level of abstraction  --  but for lack of brains.  Any
reasonably intelligent student will understand hex & bin after just a
few minutes of explanation, and will understand conversion methods
after just an hour so of carrying out exercises.  If not, then the
person has nothing whatsoever to do studying C.Sc. or programming.

So, the cost of learning the fundamentals is very low, while the payoff
is great.  It's a simple & fundamental principle of teaching and learning:
build up from the known and concrete, instead of down from airy
abstractions.  And I expect you do the same (I do!):  when confronted with
some problem which seems too abstract and complicated, I always find it
beneficial to consider a simplified and more concrete version first.

Leaving out the fundamentals simply means the student will fill the
vacuum at the bottom with something out of fantasy and intuition.  I
can't see any good reason  --  or even any reason at all  --  for
actively suppressing / leaving out this information.


- Alf

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

[Peter Seebach]

In article <320433CE.6D5A@online.no>, Alf P. Steinbach <alfps@online.no> wrote:
>The question had nothing whatsoever with the benefits of knowing hex, but
>with the absence of knowledge of such a fundamental matter.  Knowing that
>a car needs gasoline won't buy you anything with respect to driving a
>car (when this matter does not make itself important, as the matter of
>hex numbers could make itself important, e.g. while designing iostreams).
>However, I wouldn't entrust a car to a person not knowing about gasoline.

Hex isn't a part of the operation of a computer; it's a possible interface
we can use, but we don't have to.  I would trust a car to someone who
hadn't seen automatic locks, because they don't generally need to know.

>I have a really hard time understanding why students should *not* learn
>about the physical machine.

Because it will incline them to assume that the physical machine is
a constant.  Beginners are constantly writing programs which assume
that you can treat a pointer to int as a pointer to char, and read the
bottom 8 bits of the integer out of it.

>If they're not able to grasp a simple thing
>like hex and binary, then they most certainly will not be able to grasp
>abstract datatypes (design, implementation and usage of).

Probably.  But similarly, no student who can't learn Chinese, Spanish, or
German is likely to be able to comprehend abstract data types.  This is *not*
sufficient reason to require students to learn these languages in the CS
major.

>Not for lack
>of the fundamentals  --  as you've pointed out, it is possible to reason
>at any given level of abstraction  --  but for lack of brains.  Any
>reasonably intelligent student will understand hex & bin after just a
>few minutes of explanation, and will understand conversion methods
>after just an hour so of carrying out exercises.  If not, then the
>person has nothing whatsoever to do studying C.Sc. or programming.

True.  I would actually be inclined to think that people should be exposed
to hex and binary, because these are, themselves, useful *abstractions*.
Especially hex.  Even binary is a useful abstraction.  Thinking about bits
is not necessarily bad, and may be helpful.  Believing you know where they
are is downright dangerous.

>So, the cost of learning the fundamentals is very low, while the payoff
>is great.  It's a simple & fundamental principle of teaching and learning:
>build up from the known and concrete, instead of down from airy
>abstractions.  And I expect you do the same (I do!):  when confronted with
>some problem which seems too abstract and complicated, I always find it
>beneficial to consider a simplified and more concrete version first.

Uhm.  I prefer to think of simplified and more abstract versions.  But then, I
was raised by mathemeticians; I consider the physical world to be a special
case.  :)

>Leaving out the fundamentals simply means the student will fill the
>vacuum at the bottom with something out of fantasy and intuition.  I
>can't see any good reason  --  or even any reason at all  --  for
>actively suppressing / leaving out this information.

I guess, I distinguish between the fundementals and *any* form of assembly.
The fundementals that are worth teaching are the fundementals of *all*
machines.  I think a study of a Turing machine would be a great thing for
students.  You could make a turing sim for them.  (Obviously, it would
only simulate finite machines...)

But studying a *specific* architecture, or even two, is very dangerous to
young programmers.  Young minds are impressionable, and people find it much
harder to unlearn than to learn.  It took me *years* to get out of some
of my early bad habits.

A lot of programmers used to habitually use a null pointer as a shortcut
for "" for string functions; you'd see
	if (strcmp(s, 0))
used like
	if (strcmp(s, ""))
because it worked on some machines.

For a concrete example, about a year ago someone was writing in about the
famed "null pointer assignment" message Borland C would emit after his
programs ran.  He didn't want to know what caused it; he *knew* what caused
it.

He wanted to turn it off.

See, he'd discovered that
	if (strcmp(gets(NULL), "hello"))
let him save a variable.

Students should be kept *away* from the kind of mindset that makes this seem
reasonable.  That feeling that, now that I know what's happening, I can take
advantage of it - heady, but ultimately dangerous.

Many books on C encourage beginners to experiment with expressions like
	a[i] = ++i;
and "see what happens".  The exercise is generally like "think about this.
What do you think will happen?  Write a test program to try it.  See what
really happens.  What does this tell you about ..."

Ugh!

(For those who don't know:  The expression is completely devoid of meaning
in standard C.  There are two obvious interpretations, but in fact, it's
not merely a bit odd, but *completely undefined*.  A compiler may end up
corrupting memory if you pull tricks like this.)

(And no, no combination of ()'s, or moving the ++ around, will make that
expression valid or meaningful C.)

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

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

[Jerry van Dijk]

Peter Seebach (seebs@solutions.solon.com) wrote:

: True.  I would actually be inclined to think that people should be exposed
: to hex and binary, because these are, themselves, useful *abstractions*.

I know, I shouldn't allow myself to be dragged into this, but...

I keep wondering if age/background might have something to do with the
positions taken. Me, I first learned about programming using a 4004
front panel system. And I tend to agree with the 'abstractions first'
school of thought.

Anyway, future student generations will be thankfull that we are programmers
not educators :-))  (Well, most of us :-)

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

[Tim Behrendsen]

Peter Seebach <seebs@solutions.solon.com> wrote in article
<4u1g29$hc0@solutions.solon.com>...
> In article <320433CE.6D5A@online.no>, Alf P. Steinbach <alfps@online.no>
wrote:
> 
> A lot of programmers used to habitually use a null pointer as a shortcut
> for "" for string functions; you'd see
> 	if (strcmp(s, 0))
> used like
> 	if (strcmp(s, ""))
> because it worked on some machines.

This completely makes the point.  Someone who knows assembly language
would *never* make that mistake, because it would be so obviously
wrong.  You cannot program in assembly and not understand a null
pointer v.s. a pointer to a zeroed memory location.

-- Tim Behrendsen (tim@airshields.com)

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

[Peter Seebach]

In article <01bb826a$b222f400$9bee6fce@timhome2>,
Tim Behrendsen <tim@airshields.com> wrote:
>Peter Seebach <seebs@solutions.solon.com> wrote in article
><4u1g29$hc0@solutions.solon.com>...
>> A lot of programmers used to habitually use a null pointer as a shortcut
>> for "" for string functions; you'd see
>> 	if (strcmp(s, 0))
>> used like
>> 	if (strcmp(s, ""))
>> because it worked on some machines.

>This completely makes the point.  Someone who knows assembly language
>would *never* make that mistake, because it would be so obviously
>wrong.

An interesting theory.  Unfortunately, I long since lost track of these
articles, but in the old "use the OS vs. bang the metal" flame wars in
comp.sys.amiga.programmer, the assembly people would always talk about
how the first instruction in their programs was always
	movel #0,0L
(Or however it is that you spell "write 4 bytes of 0 to address 0")...

A high-level programmer would never do that, because someone who has
learned only the abstract semantics would not think of a null pointer
as the address of any real memory.  It isn't; it's *guaranteed* that
no object has a null pointer as its address.

>You cannot program in assembly and not understand a null
>pointer v.s. a pointer to a zeroed memory location.

And you cannot program in abstract C and think of a null pointer as a pointer
to *any* memory location.  On many machines that I use, you can't read or
write to it; it certainly doesn't *act* like it's memory.

The people who did things like that were always assembler programmers relying
on their knowledge of what was "really" happening inside the machine.  The C
abstract semantics clearly forbid it; however, on the majority of common
architectures, the hardware doesn't forbid it, and the assumption holds.
(By chance, mostly.)

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

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

[Chris Sonnack]

Peter Seebach (seebs@solutions.solon.com) wrote:

>>> A lot of programmers used to habitually use a null pointer as a shortcut
>>> for "" for string functions; you'd see
>>> 	if (strcmp(s, 0))
>>> used like
>>> 	if (strcmp(s, ""))
>>> because it worked on some machines.
>>
>> This completely makes the point.  Someone who knows assembly language
>> would *never* make that mistake, because it would be so obviously
>> wrong.
>
> An interesting theory.

Not a theory. I've seen it personally.

Because I know what "" really is under the hood, I know it has nothing in
common with a NULL pointer. And I've seen a co-worker, a fellow professional
who's been doing this for a number of years, make the above mistake. Not
just once, but several times.

> comp.sys.amiga.programmer, the assembly people would always talk about
> how the first instruction in their programs was always
> 	movel #0,0L
>
> A high-level programmer would never do that, because someone who has
> learned only the abstract semantics would not think of a null pointer
> as the address of any real memory.  It isn't; it's *guaranteed* that
> no object has a null pointer as its address.

Yep. True. (Although, honestly, 90+% of all implementations define NULL
along the lines of: (void*)0) 

But that doesn't really change the point that's being made:

>> You cannot program in assembly and not understand a null
>> pointer v.s. a pointer to a zeroed memory location.

This is also true. The point is "" is a real object in memory, and any
assembly programmer would know that. What the NULL pointer is doesn't
matter here; the point is that "" ain't the NULL address.

--
Chris Sonnack  <cjsonnack@mmm.com>                  http://eishcq.mmm.com
Engineering Information Services/Information Technology/3M, St.Paul, Minn
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
How's my programming?  Call 1-800-DEV-NULL

Opinions expressed herein are my own and may not represent those of my employer.

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

[Peter Seebach]

In article <4u5682$qgs@dawn.mmm.com>, Chris Sonnack <cjsonnack@mmm.com> wrote:
>Peter Seebach (seebs@solutions.solon.com) wrote:
>>> This completely makes the point.  Someone who knows assembly language
>>> would *never* make that mistake, because it would be so obviously
>>> wrong.

>> An interesting theory.

>Not a theory. I've seen it personally.

A theory, and a false one, because I've seen an assembly programmer, not only
make that mistake, but attempt to justify it based on his "knowledge" of the
machine.

>Because I know what "" really is under the hood, I know it has nothing in
>common with a NULL pointer. And I've seen a co-worker, a fellow professional
>who's been doing this for a number of years, make the above mistake. Not
>just once, but several times.

With no concept at all of how "" really works, it's obvious that it has
nothing in common with a null pointer.  It's an object, or the address of an
object in some contexts, and is very unlikely to have any connection to the
null pointer.

>Yep. True. (Although, honestly, 90+% of all implementations define NULL
>along the lines of: (void*)0) 

Or just plain 0.  They are required to.  However, *THIS DOES NOT MEAN IT IS
THE ADDRESS 0*.

There is no reason to expect that
	(void *)0
and
	(void *) 0xFFFFFFFF
will not compare equal.

0 must convert to a null pointer.  This does *not* mean that a null pointer is
a 0.

>This is also true. The point is "" is a real object in memory, and any
>assembly programmer would know that. What the NULL pointer is doesn't
>matter here; the point is that "" ain't the NULL address.

But there's nothing wrong with the null address working as a "", and the
assumption visibly holds on many machines.

A *competent* assembly programmer would never make that mistake.  Neither woud
a *competent* C programmer.  (IMHO.)  I don't believe that either the assembly
or the non-assembly background grants any protection.  People who are inclined
to try things and assume that they'll continue to work are dangerous in any
language.

I would suspect that people who want to learn assembly are slightly more prone
to this weakness, but it's hard to be sure.

>How's my programming?  Call 1-800-DEV-NULL

Cute.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

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

[Tom Watson]

In article <4u5h81$ol@solutions.solon.com>, seebs@solon.com wrote:

> In article <4u5682$qgs@dawn.mmm.com>, Chris Sonnack <cjsonnack@mmm.com> wrote:
> 
> >How's my programming?  Call 1-800-DEV-NULL
> 
> Cute.
> 

Calling from California, it is a disconnected number!!

Just in case anybody's interested...

-- 
Tom Watson
tsw@3do.com         (Home: tsw@johana.com)

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

[Tim Hollebeek]

Chris Sonnack (cjsonnack@mmm.com) wrote:
: Peter Seebach (seebs@solutions.solon.com) wrote:

: >>> A lot of programmers used to habitually use a null pointer as a shortcut
: >>> for "" for string functions; you'd see
: >>> 	if (strcmp(s, 0))
: >>> used like
: >>> 	if (strcmp(s, ""))
: >>> because it worked on some machines.
: >>
: >> This completely makes the point.  Someone who knows assembly language
: >> would *never* make that mistake, because it would be so obviously
: >> wrong.
: >
: > An interesting theory.

: Not a theory. I've seen it personally.

: Because I know what "" really is under the hood, I know it has nothing in
: common with a NULL pointer. And I've seen a co-worker, a fellow professional
: who's been doing this for a number of years, make the above mistake. Not
: just once, but several times.

However I'd submit that knowing the difference between "" and NULL is
essential to good _C_ programming, and has no relation to whether they
know assembly or not.  It's a question of the distinction between zero
and pointer-to-zero, which one only needs the 'pointer' concept to
understand; one does not need to know the underlying machine language
constructs.  IMO if someone confuses X and pointer-to-X on a regular
basis, they don't know C, so you should teach them C instead of trying
to get them to misunderstand a new language.

: > comp.sys.amiga.programmer, the assembly people would always talk about
: > how the first instruction in their programs was always
: > 	movel #0,0L
: >
: > A high-level programmer would never do that, because someone who has
: > learned only the abstract semantics would not think of a null pointer
: > as the address of any real memory.  It isn't; it's *guaranteed* that
: > no object has a null pointer as its address.

: Yep. True. (Although, honestly, 90+% of all implementations define NULL
: along the lines of: (void*)0) 

: But that doesn't really change the point that's being made:

: >> You cannot program in assembly and not understand a null
: >> pointer v.s. a pointer to a zeroed memory location.

: This is also true. The point is "" is a real object in memory, and any
: assembly programmer would know that. What the NULL pointer is doesn't
: matter here; the point is that "" ain't the NULL address.

Any C programmer should know a string literal is a *POINTER TO* a real
object in memory.  I've seen tons of bad C code based on not
understanding this.  The famous 'if (x == "foo")' is just one example.

Now for my biggest objection to this bogus assembly language argument:
a C pointer need not be an address at all.  Yet you constantly refer
to pointers as 'addresses'.  Someone has missed a useful abstraction,
methinks.

---------------------------------------------------------------------------
Tim Hollebeek         | Disclaimer :=> Everything above is a true statement,
Electron Psychologist |                for sufficiently false values of true.
Princeton University  | email: tim@wfn-shop.princeton.edu
----------------------| http://wfn-shop.princeton.edu/~tim (NEW! IMPROVED!)

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

[Mike Rubenstein]

tim@franck (Tim Hollebeek) wrote:

> Any C programmer should know a string literal is a *POINTER TO* a real
> object in memory.  I've seen tons of bad C code based on not
> understanding this.  The famous 'if (x == "foo")' is just one example.

This is just not true.  A string literal is an array of char, not a
pointer.  In many situations it is converted to a pointer, but there
are some where it is not.  The "C programmer" who thinks a string
literal is a pointer is not going to understand why

	#include <stdio.h>

	int main(void)
	{
	  char* a;
	  a = "hello world";
	  if (sizeof a == sizeof "hello world")
	    printf("no\n");
	  else
	    printf("yes\n");
	  return 0;
	}

probably prints yes rather than no.

Michael M Rubenstein

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

[Tim Behrendsen]

Peter Seebach <seebs@solutions.solon.com> wrote in article
<4u3tt1$qub@solutions.solon.com>...
> In article <01bb826a$b222f400$9bee6fce@timhome2>,
> Tim Behrendsen <tim@airshields.com> wrote:
> >Peter Seebach <seebs@solutions.solon.com> wrote in article
> >[snip example of invalid usage of NULL pointer v.s. Null string]
> >This completely makes the point.  Someone who knows assembly language
> >would *never* make that mistake, because it would be so obviously
> >wrong.
> 
> An interesting theory.  Unfortunately, I long since lost track of these
> articles, but in the old "use the OS vs. bang the metal" flame wars in
> comp.sys.amiga.programmer, the assembly people would always talk about
> how the first instruction in their programs was always
> 	movel #0,0L
> (Or however it is that you spell "write 4 bytes of 0 to address 0")...
> 
> A high-level programmer would never do that, because someone who has
> learned only the abstract semantics would not think of a null pointer
> as the address of any real memory.  It isn't; it's *guaranteed* that
> no object has a null pointer as its address.
> 
> >You cannot program in assembly and not understand a null
> >pointer v.s. a pointer to a zeroed memory location.
> 
> And you cannot program in abstract C and think of a null pointer as a
pointer
> to *any* memory location.  On many machines that I use, you can't read or
> write to it; it certainly doesn't *act* like it's memory.
> 
> The people who did things like that were always assembler programmers
relying
> on their knowledge of what was "really" happening inside the machine. 
The C
> abstract semantics clearly forbid it; however, on the majority of common
> architectures, the hardware doesn't forbid it, and the assumption holds.
> (By chance, mostly.)

Both your points come down to the same thing; that if a programmer
makes use of non-portable hardware-specific operations, then the
code is not well-written C.  I completely agree with this.

Where I disagree with you is that you seem to be claiming that
it would be bad to teach people the low level mechanisms, because
then they would be tempted to use them.  This seems very short
sighted to me; certainly with knowledge comes responsibility, and
along with teach the fundamentals there needs to be taught the
portability skills.  The problem is that the schools are so
top heavy with the latter that the fundamentals are being
neglected, and we end with the code-bloated world that we're
living in now.

-- Tim Behrendsen (tim@airshields.com)

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

[Patrick Horgan]

I interviewed someone with a masters in CS and years of experience recently
that couldn't correctly code a strcmp() function.  He's been working with C++,
yet though a constructor returned something.  Things like this are not the
exception but the rule in the interviews I do...it's sad.  How do people stay
in the industry when they don't even know the basic use of their tools?



In article <31FDFB6C.2781E494@att.com>, Paul Campbell <Paul_Campbell__Mr@att.com> writes:
> >>>>>>
> I was shocked at the results.  I had people with Masters and
> Doctorates who were completely incapable of creating new solutions
> that they had never seen before.  I had people, with *degrees* now,
> tell me "convert argument to binary" as one of the steps on a
> logical operation problem!  The latter are people who are ground
> in the "abstraction" of an integer, but are completely clueless
> that the computer works in binary. How can a student get a
> full-blown degree, and not understand a computer works in binary?
> It's like graduating someone with a writing degree who is
> illiterate.
> <<<<<<<
> 
> We have had CS students on placement here after 2 years of study who
> didn't even understand hexedecimal !.
> 
> Paul C.
> UK.



-- 

   Patrick J. Horgan    patrick@broadvision.com   Have horse will ride.
   Opinions mine, not my employer's except by most bizarre coincidence.

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

[Kurt E. Huhner]

Patrick Horgan wrote:
> 
> I interviewed someone with a masters in CS and years of experience recently
> that couldn't correctly code a strcmp() function.  He's been working with C++,
> yet though a constructor returned something.  Things like this are not the
> exception but the rule in the interviews I do...it's sad.  How do people stay
> in the industry when they don't even know the basic use of their tools?

<DREAM>

I know!!! I have a Masters degree and roughly ten years of experiece.  I
am 
a GUI software engineer and extensive experience in my field, including
C.  It kills me (actually makes me laugh) when a customer comes to me a
asks for solid code and then moans over the rate @ $80/hr.

They need to go and find one of these guys...

> that couldn't correctly code a strcmp() function.

</DREAM>


-- 


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      Check out "How'd You Do That? X/Motif Tips & Tricks," 
         a monthly column written for The X Advisor at
         http://www.unx.com/DD/advisor/huhner/toc.shtml.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

============================================================================
Kurt E. Huhner, Software Consultant     MailTo:khuhner@ncs-ssc.com
Nation Computer Services, Inc.          http://www.ncs-ssc.com
Bldg. 9110, MSAAP                       Voice: (601)689-8100
Stennis Space Center, MS 39529          Fax:   (601)689-8130
============================================================================

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

[Arne W. Flones]

"Tim Behrendsen" <tim@airshields.com> wrote:
[snip]
>Why do you think
>it's so hard to teach abstractions at the elementary level?
>It's because the students get so wrapped up in the fancy
>terminology, they don't see that its really all smoke and
>mirrors, and the concepts are very, very basic.  If it's
>expressed in fundamental ways, it's very easy to see what
>abstractions are really saying in *real* terms.

I agree.  My first computer was one of those single board computers
that you programmed through a hexadecimal keypad.  The display was a 6
digit hexadecimal LED display.  It had all of 1024 bytes of memory and
a 2K monitor ROM.  I cut my teeth programming it in hexadecimal
machine language. (Who needs an assembler? :-)  That knowledge has
served me well for the two decades since.

Beneath the complexities of of a modern programming language is a very
simple thing--a CPU that doesn't do much, but does it very fast.  The
modern processor is more complex than those early ones, but not much.
It is extremely helpful to understand what the processor is going to
do when you, for instance, add two numbers together.

Computers are not magic.  They are very simple things that can be
easily understood.  When one realizes that all that happens inside a
computer is simple addition, subtraction, bit-shifts, bit-testing and
jumping, all suddenly becomes clear.

Regards,
Arne
flonesaw@netonecom.net

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

[David Wheeler]

Tim Behrendsen (tim@airshields.com) wrote:
: Robert Dewar <dewar@cs.nyu.edu> wrote in article
: <dewar.838609515@schonberg>...
: > Tim recommends
: > 
: > "Assembly -> C [non-GUI] -> C-GUI -> C++
: > 
: > Assembly:   Learn what's *really* going on.  The most important."
: > 
: > I strongly disagree. A student treading this path will have a hard time
: > learning what abstraction is all about.


: I arrived at this conclusion based on the students that were coming
: to me to be hired.  I give a standard test to all my applicants that
: tests two primary attributes,

: 1) How well they understand what's *really* going on; the best
: programmers have a solid foundation.
: 2) How well the can take a problem they've (probably) never seen
: before and generate a solution.

I strongly agree with points 1 and 2. The best programmers understand
how things really work, and are able to generate a solution from a
problem.  Makes sense to me.  We just disagree on how to get there.

: I was shocked at the results.  I had people with Masters and
: Doctorates who were completely incapable of creating new solutions
: that they had never seen before.

I also agree that many people are coming out of schools and are
incapable of creating new solutions.  I've met them myself.

The biggest problem I encounter is not that they don't understand the
first principles.  The problem is that they don't understand how to
break a problem into parts, and then solve the problem.  It's a problem
in _abstraction_, not in understanding how the pieces work.

: It's like graduating someone with a writing degree who is
: illiterate.

Continuing your analogy, what they really need is experience in writing
seriously-size software -- and a CRITIQUE of their work by good writers.
I haven't seen much in the way of critique in universities, and students
tend to work with tiny problems (because nobody wants to evaluate big
ones).  This is an area where things really break down; it's possible
to get a Master's or PhD and not write anything longer than a thousand
lines, and with no feedback from experienced people.

: I had people, with *degrees* now,
: tell me "convert argument to binary" as one of the steps on a
: logical operation problem!  The latter are people who are ground
: in the "abstraction" of an integer, but are completely clueless
: that the computer works in binary. How can a student get a
: full-blown degree, and not understand a computer works in binary?

That's pretty clueless.  However, depending on how well they
understood their programming language, they might still produce
a reasonable result.  Why?  Because, although they may not realize
that some of these "conversion" operations have no run time impact,
they may know how to combine the features of their language to
produce solutions.

And it's the solutions, not the knowledge, that you're paying for.

I agree with you, though, you don't want such clueless people working
for you. The clueless ones won't know how to write high-performance
software where it's needed.  You want people who understand the
underlying technology _AND_ how to apply it.  But don't assume that the
former implies the latter.  In fact, given someone who knows how to
apply the technology, I can quickly get them up to speed on how it works.


: Bottom line, a student cannot fundamentally understand an
: abstraction until they understand the abstraction
: in terms of the fundamental components of programming; again:
: Move, Arithmetic, Test, Branch, and Logicals.

Any professional developer must understand several assembly languages,
and how they work in general.  I think that goes without saying.  That
doesn't mean it should be their first language.  There are various
pedagogical approaches, and I haven't seen any strong evidence for this
approach.  I think assembly language is excessively difficult as a
first step, and it obfuscates other necessary skills (like learning how
to abstract things).  A short course in how they work might be okay,
but serious work starting with assembly would IMHO be a disservice.

The language you use also determines the amount of detail
you need to know about the underlying machine abstraction.
When you're using C or C++, you really need to know how the
underlying assembly language works. Why? Because pointer arithmetic
makes little sense if you don't, and tracking down rogue pointers
overwriting your local stack values and other nasties is impossible if
you don't understand how underlying machines work.  Most of the
basic C/C++ operations are defined as "whatever your local machine does",
so it's really part of the C/C++ definition.

A professional developer using other languages should still know this
level of detail, but it's frankly less important in Java, Ada 95, Eiffel,
and Smalltalk (among others).  Who cares that "if" becomes a branch
instruction? Unless you call outside the language, you won't even get
to see how some capabilities are implemented in some languages. The
result: the detail you need to know to solve a problem shrinks.  Thus,
you can concentrate on learning how to abstract - the real problem.

In the immortal words of managers everywhere: Who cares how the
underlying system works? When will the code be ready?


: CS is currently taught the way you describe.  Why do you think
: it's so hard to teach abstractions at the elementary level?

It's not clear it's REALLY taught that way.  Lots of schools just give
a quick intro to a programming languages or two, and then show other
people's abstractions (instead of teaching how to abstract).  Besides,
many students just "get by" instead of learning, and many people
find abstraction really hard to grasp.


: This is what convinced me that our CS education is being done
: completely wrong.  I've said this before [excuse my repetition];
: it would be as if EE students were taught IC design in the first
: course, and were only given resisters, capacitors, ohm's law,
: etc. in their senior year, almost as an afterthought!

But even you are suggesting that there be an abstraction for
software developers.  Computers use resistors and
capacitors, too. Why not require a full EE degree?
The answer: because you don't REALLY need to know that level of detail;
an abstraction of a computer is good enough.

I've got a EE and CS degree; given sand and enough time I could build
a computer, and then build an operating system and compiler on top of it.
But in most of my work I don't need that level of low-level
understanding.  What I do need to know is how to abstract a problem
into parts so I can solve it.  I agree with Mr. Dewar - abstraction
is most important, worry about that first.

Thus: If solving problems is the key skill, start with a high-level
language that lets you concentrate on learning how to solve problems.


--- David A. Wheeler
Net address: wheeler@ida.org

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

[Peter Seebach]

In article <4ttdlg$2pr@news.ida.org>,
David Wheeler <wheeler@aphrodite.csed.ida.org> wrote:
>That's pretty clueless.  However, depending on how well they
>understood their programming language, they might still produce
>a reasonable result.  Why?  Because, although they may not realize
>that some of these "conversion" operations have no run time impact,
>they may know how to combine the features of their language to
>produce solutions.

And, if their language doesn't specify a binary representation, they may get
an algorithm right on a weird machine that still uses BCD or decimal
internally.

>Any professional developer must understand several assembly languages,
>and how they work in general.

I think this is no longer true.  Understanding an assembler buys you nothing;
all it tells you is that at least one machine had a certain kind of semantics
inside it.  You *don't care*.  If you're writing a *solution* to a *problem*,
those are the only things you need to be working with.  If you try to make
sure your solution fits your imaginings of the underlying machine, you
constrain it unnaturally.  Leave the unnatural constraints for the rare
occasions when your code actually has a detectable performance problem that
can't be quickly traced to a broken algorithm.

>The language you use also determines the amount of detail
>you need to know about the underlying machine abstraction.

Quite true.

>When you're using C or C++, you really need to know how the
>underlying assembly language works.

Quite untrue.

>Why? Because pointer arithmetic
>makes little sense if you don't, and tracking down rogue pointers
>overwriting your local stack values and other nasties is impossible if
>you don't understand how underlying machines work. 

This is simply nonsense.  Professionals and competent engineers do not need to
be told how it is that rogue pointers work; they need to be told what kinds of
operations produce unpredictable results.

I have never even tried to understand an assembly language.  Yet, I am
mysteriously able to use pointer arithmetic correctly, and I have tracked down
any number of bugs involving rogue pointers.

Pointer arithmetic is defined in terms of objects in C.  You don't need to
know what the underlying processor is doing, because you never see it.  You
work in terms of sizeof() and you know that sizeof(char) is 1.  You know
that pointers move and increment by the size of the thing pointed to.

None of this depends on assembly. (conceptually.  It is often implemented in
machine code, but you don't need to know that to make it work, or to use it
correctly.)

>Most of the
>basic C/C++ operations are defined as "whatever your local machine does",
>so it's really part of the C/C++ definition.

Will you folks *please* stop discussing "C/C++"?  I'm discussing C here,
because C++ is a vastly different language, and I don't know it.

You have attained only the second level of enlightenment.

The newbie uses a machine, and to the newbie, that is all machines; the
newbie's code runs only on that machine.

The experienced programmer uses several machines, and has learned how each
behavies.  The experienced programmer's code runs on several machines.

The true programmer uses no machines, and uses the specifications granted by
the language.  The true programmer's code runs on any machine.

The C definition explicitly *DOES NOT* include the semantics of the local
machine; rather, it says that each implementation must document these things,
but a portable C program *can not use any of them*.

Further, it defines quite a few semantics explicitly.  For instance, unsigned
integers are handled modulo N, for some suitable N.  Always.  Everywhere.  No
C compiler may signal overflow on unsigned arithmetic.

When a program depends on the way the local machine handles a basic operation,
that C program is either OS or library code, or broken.

The semantics guaranteed by the language are quite strong enough for 99% of
most real projects.  The other 1% is why people ask what your experience is
specifically when hiring a programmer.

Many programmers seem to be able to push that number down, by finding more and
more ways to depend on things they don't need.  This is stupid.

>A professional developer using other languages should still know this
>level of detail, but it's frankly less important in Java, Ada 95, Eiffel,
>and Smalltalk (among others).  Who cares that "if" becomes a branch
>instruction? Unless you call outside the language, you won't even get
>to see how some capabilities are implemented in some languages. The
>result: the detail you need to know to solve a problem shrinks.  Thus,
>you can concentrate on learning how to abstract - the real problem.

A C programmer who cares whether an "if" becomes a branch or not is wasting
his own, and everyone else's, time.  That's not part of the language, nor
should it be.

>It's not clear it's REALLY taught that way.  Lots of schools just give
>a quick intro to a programming languages or two, and then show other
>people's abstractions (instead of teaching how to abstract).  Besides,
>many students just "get by" instead of learning, and many people
>find abstraction really hard to grasp.

Especially because unenlightened ones keep telling them that they should care
how or why their code works, rather than telling them to study the
specifications.  If I had a dollar for every student who's been burned, and
badly, by the infamous advice "try it on your compiler and see what happens",
I wouldn't need to work for a living.

>The answer: because you don't REALLY need to know that level of detail;
>an abstraction of a computer is good enough.

Empirically, the abstraction of "A C implementation" is good enough for most
code.

>What I do need to know is how to abstract a problem
>into parts so I can solve it.  I agree with Mr. Dewar - abstraction
>is most important, worry about that first.

This is quite true.

>Thus: If solving problems is the key skill, start with a high-level
>language that lets you concentrate on learning how to solve problems.

This is good advice.  I'm inclined to think that, properly taught, C can be
such a language.  However, I'd rather start people in Icon or perl, myself.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

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

[Gary M. Greenberg]

In article <4ttksk$9lt@solutions.solon.com>, seebs@solon.com wrote:

["Far snip;" ... is that the right `model' for that cut ;p]
 
>  The newbie uses a machine, and to the newbie, that is all machines; the
>  newbie's code runs only on that machine.

Whoa, vast generalization. Slow down. I've been at C* a bit over a
year; I'm still quite the neophyte. I _know_** what is ANSI-C and what
isn't. I know that what runs on my machine using extensions isn't what
runs everywhere.
    * My first computer language.
   ** there are many things about ANSI-C I still don't know, but what
     I know, I can distinguish between Standard and non-standard.

From day one, the code I wrote was keyed in one of three machines,
then copied to each of the other two to learn if and what made a
difference. The three OS'es are quite different:
(1) Macintosh; (2) BSD on an 386, since upgraded to an OS/2 box; and
(3) a Sun Sparc 20 running Solaris 2.4, recently upgraded to an
    Ultra running Solaris 2.5

Guess what. Today, there is a unix compressed tar archive of source
code for a GIS application I wrote sitting at:
    ftp://users.southeast.net/private/garyg

It's called mapbook. The code was originally written on the Mac,
tested on the BSD box, downloaded to the Sun, now Ultra and recompiled
without changing one line of code.
The program writes a program.
I venture to say that it will download and compile on _any_
platform (excepting that it is _no respecter_ of the 8.3
filename constraint).

This is just to say that there are some of us who can learn properly.
There are some of us who don't care about the machine, per se.
I had a task I wanted to automate; I figured out the steps to
automate it. I wrote the code within the contraints provided by
the language that I was learning to use. Over time, I added more and
more error checking, to protect the user from their own mistakes,
but I did it all by staying strictly conforming.

[snip]
>  The experienced programmer's code runs on several machines.
>  The true programmer uses no machines, and uses the specifications
>  granted by the language.  The true programmer's code runs on any
>  machine.

And, sometimes the apprentice's code does too. We ain't all ijits.

>  [snip] a portable C program *can not use any of them*.

   That's a key to reuse too.

[snip]
>  Many programmers seem to be able to push that number down,
>  by finding more and more ways to depend on things they don't need.
>  This is stupid.

    Bingo! Every problem that needs to be handled by the application
    should be evalutated with regard to the Standard library, and the
    functions provided within. If it's in the library, use it rather
    than an extension provided with the tools dejour.
    And, new programmers should check each function they use, to be
    sure they are using one that is, in fact, in the standard as
    opposed to an extension. Given a choice, use the Standard library
    functions.

[much to agree with clipped]
>  -- 
>  Peter Seebach - seebs@solon.com

FWIW: There is an awful lot of chaff to sift thru in c.l.c.
Some of us, while new to the language, have seen which shoulders
to stand on, yours included. Glad there are a few beacons out there.

Cheers,

gary    /* the Sorcerer's Apprentice */
       Contribute to the Randal Schwartz Legal Defense Fund.
           This URL hosts the C Programmers' Reference:
         http://users.southeast.net/~garyg/main_page.html

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

[Alf P. Steinbach]

Peter Seebach wrote:
> 
> In article <4ttdlg$2pr@news.ida.org>,
> David Wheeler <wheeler@aphrodite.csed.ida.org> wrote:
> >That's pretty clueless.  However, depending on how well they
> >understood their programming language, they might still produce
> >a reasonable result.  Why?  Because, although they may not realize
> >that some of these "conversion" operations have no run time impact,
> >they may know how to combine the features of their language to
> >produce solutions.
> 
> And, if their language doesn't specify a binary representation, they may get
> an algorithm right on a weird machine that still uses BCD or decimal
> internally.

Been to a museum lately?



(A)
> >Any professional developer must understand several assembly languages,
> >and how they work in general.
> 

(B)
> I think this is no longer true.  Understanding an assembler buys you nothing;
> all it tells you is that at least one machine had a certain kind of semantics
> inside it.  You *don't care*.  If you're writing a *solution* to a *problem*,
> those are the only things you need to be working with.

Pardon me, but this is utter bullshit, both (A) and the response (B).  That
(A) is untrue is not necessary to discuss.  (B) is more subtle, but builds on
several assumptions, which can be summed up as a "mathematicians" view of
programming:  only abstract semantics matter.  At least when discussing C,
the most popular high level assembler in existence, that argument is
clearly not valid.  Could be valid in other contexts, though.



> If you try to make sure your solution fits your imaginings of the underlying
> machine, you constrain it unnaturally.  Leave the unnatural constraints for
> the rare occasions when your code actually has a detectable performance
> problem that can't be quickly traced to a broken algorithm.

On the surface, this is good advice.  Like Knuth said, "Premature optimization
is the root of all evil" (or something on these lines).  But that's the surface.
The advice as sound advice assumes that the design is *already* guided by a
good understanding of the underlying machine.  The advice as misguiding advice
says something quite different:  disregard the machine completely.  That's
stupid.  When you build a house, you need both a good understanding of the plans 
(abstractions) and the physical materials and other resources.  Disregarding or
playing down the importance of one or the other leads to failure.


> You have attained only the second level of enlightenment.
> 
> The newbie uses a machine, and to the newbie, that is all machines; the
> newbie's code runs only on that machine.
> 
> The experienced programmer uses several machines, and has learned how each
> behavies.  The experienced programmer's code runs on several machines.
> 
> The true programmer uses no machines, and uses the specifications granted by
> the language.  The true programmer's code runs on any machine.

A very nice goal (getting paid for programming without using computers would
indeed be ideal).  Aber doch, porting isn't quite that easy... :-)



- Alf   (quite aware of the flame-inviting nature of this thread... :-) )

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

[Peter Seebach]

In article <3202876B.BC7@online.no>, Alf P. Steinbach <alfps@online.no> wrote:
>Peter Seebach wrote:
>> And, if their language doesn't specify a binary representation, they may get
>> an algorithm right on a weird machine that still uses BCD or decimal
>> internally.

>Been to a museum lately?

Well, I work for a large corporation... :)

Who says binary is here to stay?  C will always act like it's on a binary
machine, unless they change that aspect of the standard, but assuming that all
languages will act like that is silly.  Among other things, who does bignums
in binary?

>(A)
>> >Any professional developer must understand several assembly languages,
>> >and how they work in general.

>(B)
>> I think this is no longer true.  Understanding an assembler buys you nothing;
>> all it tells you is that at least one machine had a certain kind of semantics
>> inside it.  You *don't care*.  If you're writing a *solution* to a *problem*,
>> those are the only things you need to be working with.

>Pardon me, but this is utter bullshit, both (A) and the response (B).  That
>(A) is untrue is not necessary to discuss.  (B) is more subtle, but builds on
>several assumptions, which can be summed up as a "mathematicians" view of
>programming:  only abstract semantics matter.  At least when discussing C,
>the most popular high level assembler in existence, that argument is
>clearly not valid.  Could be valid in other contexts, though.

I would say it certainly *is* valid.  I have a tiny little 75k project I've
written over the last couple of weeks, and it doesn't depend in any way on
anything but the abstract semantics of the language.  It's not like you *need*
anything else for the majority of code.

I'm a reasonably active real-world programmer, and I concern myself
exclusively with the abstract semantics.  I believe this is called an
existance proof.

>The advice as misguiding advice
>says something quite different:  disregard the machine completely.  That's
>stupid.  When you build a house, you need both a good understanding of the
>plans (abstractions) and the physical materials and other resources. 
>Disregarding or playing down the importance of one or the other leads to
>failure.

It is a common mistake to assume that the machine is the building block of
code.  This is true only in device drivers.  In the majority of code, your
building materials can be, and *must* be, the abstract semantics of the
language.  To write good code, you generally have to ignore the machine
entirely, and leave the machine details to the compiler.

Anything else leads to code which is too tightly coupled to your understanding
of a given machine.

>A very nice goal (getting paid for programming without using computers would
>indeed be ideal).  Aber doch, porting isn't quite that easy... :-)

*I* always find porting easy.  Generally, 50% of my porting time is waiting
for the compile.  The other 50% is writing a makefile for a new platform.
Hmm.  As soon as I eliminate my current bug, I'll try to compile this program
under Borland C, MPW on the Mac, and SAS/C on the Amiga.  I betcha it all
compiles and runs without trouble.  This is about 75k of code, written over
about 3 weeks *exclusively* on BSD-derived Unix using gcc to compile.

Any bets?  :)

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

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

[Chris Sonnack]

Peter Seebach (seebs@solutions.solon.com) wrote:

>> Any professional developer must understand several assembly languages,
>> and how they work in general.

(That's, I think, an overstatement unless you're creating device drivers
or O/S for a living. But....)

> Understanding an assembler buys you nothing;
                                      ^^^^^^^
That's taking it too far the other way.

Understanding assembler //helps// you learn C faster. I've seen it with
my own eyes and experienced it personally (see previous post). I wouldn't
care to code assembly now; I don't think in terms of assembly when I write
C; and I sure as hell don't use the asm() feature of C. But knowing what
it is that I'm really turning out has been helpful.

And I've been able to troubleshoot some really bizarre problems FASTER by
either looking as the ASM output (via the -S switch most compilers support)
or by tracing code in a debugger at the ASM level. Not that I couldn't have
fixed the problem at a high level; I just did it //faster// at a low one.

>> The language you use also determines the amount of detail
>> you need to know about the underlying machine abstraction.
>
> Quite true.
>
>> When you're using C or C++, you really need to know how the
>> underlying assembly language works.
>
> Quite untrue.

Agree on both points. But, again, you're a more effective tool if you
DO know what's going on "under the hood".

> The newbie uses a machine, and to the newbie, that is all machines; the
> newbie's code runs only on that machine.
>
> The experienced programmer uses several machines, and has learned how each
> behavies.  The experienced programmer's code runs on several machines.
>
> The true programmer uses no machines, and uses the specifications granted
> by the language.  The true programmer's code runs on any machine.

Absolutely. Programming is about solving problems. A true programmer knows
how to analyze a problem and synthesize a solution. The language doesn't
matter; not really. The language is just the local way of expressing the
solution.

HOWEVER: it seems obvious to me that the more you know about your craft,
the better you will be at deriving the most effective solution. And the
better you'll be at dealing with problems along the path to that solution.

--
Chris Sonnack  <cjsonnack@mmm.com>                  http://eishcq.mmm.com
Engineering Information Services/Information Technology/3M, St.Paul, Minn
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chocolate will never replace sex....unless it's very good chocolate.

Opinions expressed herein are my own and may not represent those of my employer.

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

[Peter Seebach]

In article <4u55hu$o73@dawn.mmm.com>, Chris Sonnack <cjsonnack@mmm.com> wrote:
>Peter Seebach (seebs@solutions.solon.com) wrote:
>> Understanding an assembler buys you nothing;
>                                      ^^^^^^^
>That's taking it too far the other way.

Oh, my, I think my fanatacism is showing again.

>Understanding assembler //helps// you learn C faster. I've seen it with
>my own eyes and experienced it personally (see previous post). I wouldn't
>care to code assembly now; I don't think in terms of assembly when I write
>C; and I sure as hell don't use the asm() feature of C. But knowing what
>it is that I'm really turning out has been helpful.

C has no asm() feature.  There is no provision in the C language for inline
assembly.

A little knowledge is dangerous.  In the hands of an inexperienced programmer
learning C, assembly is like a Herb Schildt book - it gets you into a language
much faster.  Unfortunately, the language you learn isn't really C.  Assembly
tends to teach you a language in which the effects of overflow on signed
integers and floating point numbers are well defined, where address literals
are meaningful, and where you know all sorts of useful things about the layout
of memory.

An interesting language, but not C.

Some people manage to avoid this trap.  To them, assembly is powerful and
helpful, and exposes them to a good understanding of the underlying system.
But this is a good thing only when you can distinguish between a particular
underlying system, and the semantics of the C language.

>And I've been able to troubleshoot some really bizarre problems FASTER by
>either looking as the ASM output (via the -S switch most compilers support)
>or by tracing code in a debugger at the ASM level. Not that I couldn't have
>fixed the problem at a high level; I just did it //faster// at a low one.

I have a compiler where the ASM output is *NOT* used in normal compilation; it
may differ in internals or semantics from the normal compilation, which
compiles to an intermediate format, and then direct to object code.

>Agree on both points. But, again, you're a more effective tool if you
>DO know what's going on "under the hood".

If it's really going on, yes.  But it's *very* dangerous when you get confused
about what's really going on vs. what may have gone on once.

>Absolutely. Programming is about solving problems. A true programmer knows
>how to analyze a problem and synthesize a solution. The language doesn't
>matter; not really. The language is just the local way of expressing the
>solution.

I've written a couple of languages.  In my experience, you can tell whether a
language is complete or not by whether or not you can program in it.  If you
can find tasks you can't do, the language isn't finished yet.

>HOWEVER: it seems obvious to me that the more you know about your craft,
>the better you will be at deriving the most effective solution. And the
>better you'll be at dealing with problems along the path to that solution.

Probably.  I may eventually learn an assembly or two, out of curiousity.  But
I'm more likely to learn Icon, which I love but do not comprehend, and scheme,
first.  They'll teach me a lot more.  Assembly is just unportable, limited C,
without structures.  Why bother?  I know that model already.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

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

[Conrad Herrmann]

Alf P. Steinbach wrote:
> ....
> The argument against disregarding or hiding the concrete (levels n-1,
> n-2 etc. when you are learning about level n) is simply that the
> particular instance of a level n you're learning about was abstracted
> from the concrete levels, and your understanding of level n will be
> lacking if you don't know anything about the concrete, the *why*s of
> the solutions and abstractions at level n.  It's like saying "Do things
> this way, follow the cookbook recipes, but for God's sake don't try to
> understand it:  that will lead you into temptation and severe trouble".
> Likewise, disregarding higher level abstractions is just as silly.
> In many cases, solutions at a level n are guided by higher level
> abstractions  --  the "ideal"  --  and fit as best possible to n-1.
> 
> - Alf

To continue your analogy: Cookbook recipies are often a good way to start 
learning how to cook, since they describe a process that can actually be 
executed by someone who doesn't understand fully what they're doing.  
It would be terribly frustrating to have to start with sowing seeds, 
reaping the harvest, milling the wheat, etc. before you could graduate to 
the breadmaking class.

One of the things I enjoyed about the Joy Of Cooking is that it had a 
healthy dose of beginner's cooking theory in separate sections, but they 
didn't keep me from finishing the chocolate cake (yum).

Still, I'd say that one cannot learn programming without being able to 
break out of the "recipe" mentality and understand what's going on.  I 
started by copying Adventure listings out of Byte magazine (in Basic), 
but didn't stop there.

-- Conrad Herrmann
(Borland C++)

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

[Robert I. Eachus]

In article <3202876B.BC7@online.no> "Alf P. Steinbach" <alfps@online.no> writes:

 > ...several assumptions, which can be summed up as a "mathematicians" view of
 > programming:  only abstract semantics matter.  At least when discussing C,
 > the most popular high level assembler in existence, that argument is
 > clearly not valid.  Could be valid in other contexts, though.

   There are still CPU chips being manufactured which implement the
semantics of something close to assembler in a direct manner.  But I
doubt any are used in new designs...  In most modern CPU chips the
relation between the abstract machine API and the execution state of
the chip is tenuous at best.  So the distinction between C and
assembler is a distinction without a difference.  They both provide
incompletely specified virtual machines which programs can be written
against.  (And no, the hardware is NOT a specification for the
assembler.  Things left unspecified by the API are different in
different SPARC chipsets for example.)

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

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

[Alf P. Steinbach]

Robert I. Eachus wrote:
>    There are still CPU chips being manufactured which implement the
> semantics of something close to assembler in a direct manner.  But I
> doubt any are used in new designs...  In most modern CPU chips the
> relation between the abstract machine API and the execution state of
> the chip is tenuous at best.  So the distinction between C and
> assembler is a distinction without a difference.  They both provide
> incompletely specified virtual machines which programs can be written
> against.  (And no, the hardware is NOT a specification for the
> assembler.  Things left unspecified by the API are different in
> different SPARC chipsets for example.)

Either you're saying something I don't get, or you're not saying
anything at all.  There are at least three issues on the table:
(1) the header of the thread, now long forgotten;  (2) whether
students / beginning programmers are best off learning from the
bottom up, starting with the v.N. architecture, or from the top
down, starting with some suitably high-level language, or using
a gradient blending of the two (my view);  (3) a clarification of
what's meant by "abstract" and "concrete" in the context of
programming  --  which seems to be the issue of your posting.

Re issue (3), there are levels upon levels upon levels:  my point
here is that when you look from level n, "concrete" refers to
levels n-1, n-2 and so on (toward the physical world), whereas 
"abstract" refers to level n, n+1 and so on, of which there are
an infinity you can make up just as you want, and an infinity of
possible levels n+1 coexisting.  Of course these terms are relative.
Everything is relative to something.  For me, that's a truism.

The argument against disregarding or hiding the concrete (levels n-1,
n-2 etc. when you are learning about level n) is simply that the 
particular instance of a level n you're learning about was abstracted 
from the concrete levels, and your understanding of level n will be 
lacking if you don't know anything about the concrete, the *why*s of
the solutions and abstractions at level n.  It's like saying "Do things 
this way, follow the cookbook recipes, but for God's sake don't try to 
understand it:  that will lead you into temptation and severe trouble".
Likewise, disregarding higher level abstractions is just as silly.
In many cases, solutions at a level n are guided by higher level
abstractions  --  the "ideal"  --  and fit as best possible to n-1.

- Alf

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

[Byron B. Kauffman]

Tim Behrendsen wrote:

snip...
> 
> C:          Learn structured programming.  C is close enough
>             to assembly that a student can really *see* how the
>             compiler translates the code to assembly, and really
>             understand what languages are all about.
> 

Excuse me?  IMHO, 'C' and 'structured programming' in the same sentence
constitutes an oxymoron. I would think that in a learning environment,
you would want to teach the student good habits, not how to hack. Once
you've taught them something about structured programming (forget BASIC
and Pascal - use Ada - at least you can get a job using it), you can
THEN give them a look at the 'down and dirty' side of the business.

-- 
Byron Kauffman

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

[Alan Peake]

>it would be as if EE students were taught IC design in the first
>course, and were only given resisters, capacitors, ohm's law,
>etc. in their senior year, almost as an afterthought!

Well, it may be going that way. Most of the logic design in my department is 
now done in a Hardware Description Language;  no-one needs to know about 
gates and counters anymore. All they need to know about capacitors is what 
types to use for bypassing the gate array chips. This level of hardware 
abstraction is a bit like OO in programming. The class libraries will contain 
most functions that the programmer is likely to need in much the same way as 
the HDL elements are the building blocks for the array chip.

Sure, there is a need for a few people to understand the nuts and bolts, but 
these few will be writing the libraries and designing the silicon i.e., making 
the tools. As long as the rest of us can use the tools, what does it matter 
how they work?

Alan

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

[Tim Behrendsen]

Alan Peake <peake@dstos3.dsto.gov.au> wrote in article
<peake.206.002D549F@dstos3.dsto.gov.au>...
> >it would be as if EE students were taught IC design in the first
> >course, and were only given resisters, capacitors, ohm's law,
> >etc. in their senior year, almost as an afterthought!
> 
> Well, it may be going that way. Most of the logic design in my department
is 
> now done in a Hardware Description Language;  no-one needs to know about 
> gates and counters anymore. All they need to know about capacitors is
what 
> types to use for bypassing the gate array chips. This level of hardware 
> abstraction is a bit like OO in programming. The class libraries will
contain 
> most functions that the programmer is likely to need in much the same way
as 
> the HDL elements are the building blocks for the array chip.
> 
> Sure, there is a need for a few people to understand the nuts and bolts,
but 
> these few will be writing the libraries and designing the silicon i.e.,
making 
> the tools. As long as the rest of us can use the tools, what does it
matter 
> how they work?

Hmmm... the analogy I would use is the people who string together prefab
components are the programming equivalent of VB programmers, who string
together prefab dialogs and glue them together with some BASIC code.

The VB programmers are not going to be the compiler designers or O/S
builders (at that stage in their career, anyway) and the HDL people
are not going to be the Microprocessor designers. Certainly there is room
in the world for high level and low level people.

Also, software design is usually a much more difficult science, since the
"flow of execution" is much slower than the flow of electrons, so
inefficiency at the circuit level is not as critical.  If circuit
propagation times are important, a company will still need to call in the
nuts and bolts people to take care of business.

The latter BTW (off the subject) is my theory of why we have so many
standardized components in EE, but standardization has generally failed
for CS.  EEs have so much signal propagation bandwidth to play with,
they can afford to have very general components and not worry about
the loss of efficiency.  In CS, computer cycles are always important, and
thus its very difficult to make libraries that are efficient in a wide
variety of circumstances (generalization always costs in efficiency).

-- Tim Behrendsen (tim@airshields.com) 

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

[Stephen M O'Shaughnessy]

>
>
>>it would be as if EE students were taught IC design in the first
>>course, and were only given resisters, capacitors, ohm's law,
>>etc. in their senior year, almost as an afterthought!
>

You are misleading here.  Your analogy assumes EE don't need the basics, which
everyone knows to be absurd.  And you use that absurdity to prove IC design
should not be taught first.  But there is no link between one and the other.

By IC design do you mean the design of the ICs themselves or designing circuits
with ICs?

ICs are resistors, capacitors and semiconductors.  So designing ICs without
a knowledge of these basic elements would be impossible.  In this case you are
correct but have no point.

But if you are talking about designing with, say, logic ICs, I would argue that
it can easily be done without a knowlege of resistors, capacitors, transistors 
or even ohms law.  However, you would not be a student learning EE.  The 
point I am trying to make is that we must be careful about what basics are
necessary to learning a new skill.

I don't know much about Lady Lovelace (Namesake of the Ada programming
language).  I wonder how much of what we today call the basics did she
know and understand?  I don't think she understood bytes and bits.  I
am sure, with her math background, she knew about number bases but I
don't believe she had a working knowledge of hexidecimal numbers.  Yet
she was able to conceive a *computer* language of sorts and use it
to solve real world problems on a machine that did not then, nor did
it ever exist.  She is purported to be the first programmer. Start with the 
abstract.

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

[Tim Behrendsen]

On Wed, 31 Jul 1996, Stephen M O'Shaughnessy wrote:
> 
> But if you are talking about designing with, say, logic ICs, I would argue that
> it can easily be done without a knowlege of resistors, capacitors, transistors 
> or even ohms law.  However, you would not be a student learning EE.  The 
> point I am trying to make is that we must be careful about what basics are
> necessary to learning a new skill.

This is what I meant, and I agree with you.  Just as a CS student is not
learning programming without assembly skills.

> I don't know much about Lady Lovelace (Namesake of the Ada programming
> language).  I wonder how much of what we today call the basics did she
> know and understand?  I don't think she understood bytes and bits.  I
> am sure, with her math background, she knew about number bases but I
> don't believe she had a working knowledge of hexidecimal numbers.  Yet
> she was able to conceive a *computer* language of sorts and use it
> to solve real world problems on a machine that did not then, nor did
> it ever exist.  She is purported to be the first programmer. Start with the 
> abstract.

Wait ... this would be like saying that since Newton invented calculus,
(Let's not start the age-old Leibnitz argument, BTW! :) ) we shouldn't
teach calculus because Newton didn't need it!  And if that was good enough
for ol' Isaac ...

Come to think of it, that's an interesing analogy. Maybe we should start
math students off with the "abstraction" of calculus, and fill in the
algebra/arithmetic details later!

-- Tim Behrendsen (tim@airshields.com)

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

[Mark McKinney]

Tim Behrendsen wrote
>
>Come to think of it, that's an interesing analogy. Maybe we should start
>math students off with the "abstraction" of calculus, and fill in the
>algebra/arithmetic details later!
>

The idea 1 is an abstact Idea. 1+1=2 is even more abstract. Yet we 
believe and yes claim to know these to be true. Numbers and all math for 
that matter is based on an abstract concept. We apply these concepts to 
the real world and find that they work. Calculus is itself an abstaction 
as with algebra/arithetic etc. The only way to learn these discipline is 
through abstraction because they do not exist in the physical world. What 
does 1 sound like, taste like, feel like, look like .. (not the symbol or 
name the actual number) No it is not a bit pattern store in a register. 
That is a physical implementation of the abstraction the number.

  I'll bet you think far more abstractly than you're willing to admit.

  Some Food for though.                   

                                MArk McKinney



 

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

[Mark McKinney]

Tim Behrendsen wrote
>
>Come to think of it, that's an interesing analogy. Maybe we should start
>math students off with the "abstraction" of calculus, and fill in the
>algebra/arithmetic details later!
>

The idea 1 is an abstact Idea. 1+1=2 is even more abstract. Yet we 
believe and yes claim to know these to be true. Numbers and all math for 
that matter is based on an abstract concept. We apply these concepts to 
the real world and find that they work. Calculus is itself an abstaction 
as with algebra/arithetic etc. The only way to learn these discipline is 
through abstraction because they do not exist in the physical world. What 
does 1 sound like, taste like, feel like, look like .. (not the symbol or 
name the actual number) No it is not a bit pattern store in a register. 
That is a physical implementation of the abstraction the number.

  I'll bet you think far more abstractly than you're willing to admit.

  Some Food for though.                   

                                MArk McKinney



 

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

[Mark McKinney]

Tim Behrendsen wrote
>
>Come to think of it, that's an interesing analogy. Maybe we should start
>math students off with the "abstraction" of calculus, and fill in the
>algebra/arithmetic details later!
>

The idea 1 is an abstact Idea. 1+1=2 is even more abstract. Yet we 
believe and yes claim to know these to be true. Numbers and all math for 
that matter is based on an abstract concept. We apply these concepts to 
the real world and find that they work. Calculus is itself an abstaction 
as with algebra/arithetic etc. The only way to learn these discipline is 
through abstraction because they do not exist in the physical world. What 
does 1 sound like, taste like, feel like, look like .. (not the symbol or 
name the actual number) No it is not a bit pattern store in a register. 
That is a physical implementation of the abstraction the number.

  I'll bet you think far more abstractly than you're willing to admit.

  Some Food for though.                   

                                MArk McKinney



 

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

[P. Cnudde VH14 (8218)]

Alan Peake wrote:
> 
> >it would be as if EE students were taught IC design in the first
> >course, and were only given resisters, capacitors, ohm's law,
> >etc. in their senior year, almost as an afterthought!
> 
> Well, it may be going that way. Most of the logic design in my department is
> now done in a Hardware Description Language;  no-one needs to know about
> gates and counters anymore. All they need to know about capacitors is what
> types to use for bypassing the gate array chips. This level of hardware
> abstraction is a bit like OO in programming. The class libraries will contain
> most functions that the programmer is likely to need in much the same way as
> the HDL elements are the building blocks for the array chip.
> 
> Sure, there is a need for a few people to understand the nuts and bolts, but
> these few will be writing the libraries and designing the silicon i.e., making
> the tools. As long as the rest of us can use the tools, what does it matter
> how they work?
> 
> Alan

As a project leader in IC design at Alcatel, I agree fully with Alan.

Software knowledge is being considered more valuable than knowing how a 
transistor works. This will even become more and more the case in the 
future. And I see no problem in giving first a course in IC design
and only later going to transistors. Abstraction is the point which
is difficult to learn. When we design a new asic we almost never think
about resistors etc, understanding the behaviour of the chip is where the
real problem is. To my oppionion the same holds for software design. Assembly
language is no longer really needed. If you have the knowledge it can be usefull,
but is it really worth the effort ?
 


-- 


   ____________          Peter Cnudde
   \          /          Alcatel Telecom
    \ ALCATEL/           Switching Systems Division 
     \ BELL /            Microelectronics Design Center
      \    /             
       \  /              F. Wellesplein 1, B-2018 Antwerp
        \/                                        BELGIUM
                         e-mail  : cnuddep@sh.bel.alcatel.be
                         Phone   : +32 3 240 82 18
                         Fax     : +32 3 240 99 47

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

[Nicolas Devillard]

P. Cnudde VH14 (8218) wrote:
> As a project leader in IC design at Alcatel, I agree fully with Alan.
> 
> Software knowledge is being considered more valuable than knowing how a
> transistor works. This will even become more and more the case in the
> future. And I see no problem in giving first a course in IC design
> and only later going to transistors. Abstraction is the point which
> is difficult to learn. When we design a new asic we almost never think
> about resistors etc, understanding the behaviour of the chip is where the
> real problem is. To my oppionion the same holds for software design. Assembly
> language is no longer really needed. If you have the knowledge it can be usefull,
> but is it really worth the effort ?

Software design, whatever it is, should at one moment
be aware of hardware constraints. These constraints
can only be understood by knowing what computer guts look
like.
You can stay at a very high-level of abstraction,
accumulating underlying layers of software, and
eventually you will end up with monsters such as MS
Word, a gigantic, slow, buggy code needing a powerful
workstation just for word processing... Or even worse:
you will only think in terms of abstract functionalities,
reuse an old piece of software library, and when you
realize the hardware constraints are not the same,
Ariane 5 already exploded.

Designing software without knowledge of computer
electronics at all is like architecture without
knowledge of structure mechanics. You can dream
a lot when designing, but many constraints bring
you back to reality, and among them you should be
able to understand hardware ones to take them into
account.
Furthermore, learning how ASIC's and microprocessors
work is quite fast, easy, and does not require much
knowledge. It is in majority a question of conventions.

My 5 cents opinion, though, certainly not a definitive
view. ;)

--Nicolas

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

[Matt Austern]

smosha@most.fw.hac.com (Stephen M O'Shaughnessy) writes:

> >Except, IMO assembly should be used *exclusively* for the first 
> two
> >years of a CS degree.  The first two years is usually all 
> algorithmic
> >analysis, anyway.  There's nothing you can't learn about 
> algorithms
> >that you can't learn and learn it better doing it in assembly.
> 
> Learn sorting algorithms in assembly?  Are you serious!?

Why not?  Volume 3 of Knuth is all about sorting algorithms, and
every program in it is written in MIX assembly language.

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

[Lawrence Kirby]

In article <fxtpw59ybul.fsf@isolde.mti.sgi.com>
           austern@isolde.mti.sgi.com "Matt Austern" writes:

>smosha@most.fw.hac.com (Stephen M O'Shaughnessy) writes:
>
>> >Except, IMO assembly should be used *exclusively* for the first 
>> two
>> >years of a CS degree.  The first two years is usually all 
>> algorithmic
>> >analysis, anyway.  There's nothing you can't learn about 
>> algorithms
>> >that you can't learn and learn it better doing it in assembly.
>> 
>> Learn sorting algorithms in assembly?  Are you serious!?
>
>Why not?  Volume 3 of Knuth is all about sorting algorithms, and
>every program in it is written in MIX assembly language.

Knuth doesn't use MIX to describe the algorithms (it is pretty much
useless for that purpose). Rather after describing the algorithms in
text and action sequences he uses MIX to show an example implementation
which he then uses for quantitative timing analysis.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------

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

[Darin Johnson]

> To my oppionion the same holds for software design. Assembly
> language is no longer really needed. If you have the knowledge it can be usefull,
> but is it really worth the effort ?

The effort is already minimal.  One lousy class.  And assembler is
constantly showing up in the workplace still, sorry.  Sure, maybe your
employees have no need of assembler, but other employees elsewhere may
run across it.  I see too often employers trying to convince schools
that every student should be customized to their particular needs, and
it ends up with conflicting requirements by the prospective employers.
Almost everything in CS is considered useless by at least one person
on the outside - architecture, assembler, theory, algorithms, ai,
mathematics, software engineering, operating systems, and every single
language, including C and C++.

The other common complaint I see all the time is the "I personally
don't use XXX, therefore no one needs to use XXX".  This common
attitude needs no further arguments to strike it down...

The most common systems out there are Windows 3.1 and MVS.  MVS needs
assembler, and Windows 3.1 programming is difficult to understand
without understanding architectural details.  Find your best
programmers and chances are they are somewhat familiar with some form
of assembler.

Sheesh, one class in 5 years covering *basics*, and you think it's not
worth the effort...  I suppose you thought calculus and history were
useful but not worth the effort too.
-- 
Darin Johnson
djohnson@ucsd.edu	O-
	My shoes are too tight, and I have forgotten how to dance - Babylon 5

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

[Tim Behrendsen]

Darin Johnson <djohnson@tartarus.ucsd.edu> wrote in article
<qqg268at31.fsf@tartarus.ucsd.edu>...
> > To my oppionion the same holds for software design. Assembly
> > language is no longer really needed. If you have the knowledge it can
be usefull,
> > but is it really worth the effort ?
> 
> The effort is already minimal.  One lousy class.  And assembler is

Except, IMO assembly should be used *exclusively* for the first two
years of a CS degree.  The first two years is usually all algorithmic
analysis, anyway.  There's nothing you can't learn about algorithms
that you can't learn and learn it better doing it in assembly.

-- Tim Behrendsen (tim@airshields.com)

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

[Stephen M O'Shaughnessy]

In article <01bb7fcc$c5a98de0$87ee6fce@timpent.airshields.com>, 
tim@airshields.com says...
>
>Darin Johnson <djohnson@tartarus.ucsd.edu> wrote in article
><qqg268at31.fsf@tartarus.ucsd.edu>...
>> > To my oppionion the same holds for software design. Assembly
>> > language is no longer really needed. If you have the 
knowledge it can
>be usefull,
>> > but is it really worth the effort ?
>> 
>> The effort is already minimal.  One lousy class.  And 
assembler is
>
>Except, IMO assembly should be used *exclusively* for the first 
two
>years of a CS degree.  The first two years is usually all 
algorithmic
>analysis, anyway.  There's nothing you can't learn about 
algorithms
>that you can't learn and learn it better doing it in assembly.
>
>-- Tim Behrendsen (tim@airshields.com)

Learn sorting algorithms in assembly?  Are you serious!?

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

[Tim Behrendsen]

Stephen M O'Shaughnessy <smosha@most.fw.hac.com> wrote in article
<DvH2MI.n40@most.fw.hac.com>...
> In article <01bb7fcc$c5a98de0$87ee6fce@timpent.airshields.com>, 
> tim@airshields.com says...
> Learn sorting algorithms in assembly?  Are you serious!?

Quite serious, but why would think sorting algorithms are
especially hard?  That class of algorithm would have identical
difficult in C or Asm.

-- Tim Behrendsen (tim@airshields.com)

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

[Stephen M O'Shaughnessy]

In article <01bb80f6$e02d5cc0$9cee6fce@timhome2>, tim@airshields.com says...
>
>Stephen M O'Shaughnessy <smosha@most.fw.hac.com> wrote in article
><DvH2MI.n40@most.fw.hac.com>...
>> In article <01bb7fcc$c5a98de0$87ee6fce@timpent.airshields.com>, 
>> tim@airshields.com says...
>> Learn sorting algorithms in assembly?  Are you serious!?
>
>Quite serious, but why would think sorting algorithms are
>especially hard?  That class of algorithm would have identical
>difficult in C or Asm.
>
>-- Tim Behrendsen (tim@airshields.com)

I don't think sorting is hard.  When I learned sorting, I sorted a deck of
cards.  I would not want to create an abstract data type in assembler.  I
have not done it, but I can't imagine it would be fun. 

The basic alog. might be the same in any language, the theory, but I doubt
that the actual implementation of a real world sorting problem would be 
the same.

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

[Patrick Horgan]

In article <01bb7fcc$c5a98de0$87ee6fce@timpent.airshields.com>, "Tim Behrendsen" <tim@airshields.com> writes:
> Except, IMO assembly should be used *exclusively* for the first two
> years of a CS degree.  The first two years is usually all algorithmic
> analysis, anyway.  There's nothing you can't learn about algorithms
> that you can't learn and learn it better doing it in assembly.

Good point Tim!  It's sure a lot easier counting cycles in assembler.
Unfortunately, a lot of schools aren't teaching algorithmic analysis
anymore.

-- 

   Patrick J. Horgan    patrick@broadvision.com   Have horse will ride.
   Opinions mine, not my employer's except by most bizarre coincidence.

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

[Szu-Wen Huang]

[i feel the need, but i don't know which groups to trim.]

Patrick Horgan (patrick@broadvision.com) wrote:
: In article <01bb7fcc$c5a98de0$87ee6fce@timpent.airshields.com>, "Tim Behrendsen" <tim@airshields.com> writes:
: > Except, IMO assembly should be used *exclusively* for the first two
: > years of a CS degree.  The first two years is usually all algorithmic
: > analysis, anyway.  There's nothing you can't learn about algorithms
: > that you can't learn and learn it better doing it in assembly.

: Good point Tim!  It's sure a lot easier counting cycles in assembler.
: Unfortunately, a lot of schools aren't teaching algorithmic analysis
: anymore.

Counting cycles is not analysis of algorithms.  Knowing that a specific
implementation runs in 145 cycles on a 68HC11 buys you nothing if you
happen to develop for an 80486.  We study (generally) the time and
space complexities of algorithms using platform-independent notations
such as O() in their best, average, and worst cases (and whatever case
turns out interesting).

As for assembly, it has about the merit of BASIC when teaching
programming.  It's usually impossible to abstract the OS, and
unnecessarily forces novice programmers to learn quite a bit about
a specific platform before being able to do anything useful.  Assembly
enforces no structure, so just like BASIC it is easy to form students
that write spaghetti code.

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

[Dan Pop]

In <4u5rqe$9gv@ns.broadvision.com> patrick@broadvision.com (Patrick Horgan) writes:

>In article <01bb7fcc$c5a98de0$87ee6fce@timpent.airshields.com>, "Tim Behrendsen" <tim@airshields.com> writes:
>> Except, IMO assembly should be used *exclusively* for the first two
>> years of a CS degree.  The first two years is usually all algorithmic
>> analysis, anyway.  There's nothing you can't learn about algorithms
>> that you can't learn and learn it better doing it in assembly.
>
>Good point Tim!  It's sure a lot easier counting cycles in assembler.

Yeah, predicting cache misses and pipe stalls is a piece of cake.
The superpipelined processors make the problem even easier.

>Unfortunately, a lot of schools aren't teaching algorithmic analysis
>anymore.

If there is any connection between algorithm analysis and cycle counting,
I definitely missed it.

Dan
--
Dan Pop
CERN, CN Division
Email: Dan.Pop@cern.ch 
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland

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

[steidl]

In <danpop.839353428@news.cern.ch>, Dan.Pop@cern.ch (Dan Pop) writes:
>In <4u5rqe$9gv@ns.broadvision.com> patrick@broadvision.com (Patrick Horgan) writes:
>
>>In article <01bb7fcc$c5a98de0$87ee6fce@timpent.airshields.com>, "Tim Behrendsen" <tim@airshields.com> writes:
>>> Except, IMO assembly should be used *exclusively* for the first two
>>> years of a CS degree.  The first two years is usually all algorithmic
>>> analysis, anyway.  There's nothing you can't learn about algorithms
>>> that you can't learn and learn it better doing it in assembly.
>>
>>Good point Tim!  It's sure a lot easier counting cycles in assembler.
>
>Yeah, predicting cache misses and pipe stalls is a piece of cake.
>The superpipelined processors make the problem even easier.

That's why I loved programming my CoCos (6809) - no cache misses (no
cache), no pipeline stalls (no pipeline), no complex instruction
interactions (no superscaler capabilities), no wait states (memory was
several times *faster* than the CPU :-).  But I don't live in dispair,
maybe those days will return... (as in "ha ha, only serious")

>>Unfortunately, a lot of schools aren't teaching algorithmic analysis
>>anymore.
>
>If there is any connection between algorithm analysis and cycle counting,
>I definitely missed it.

Well, "way back then" I could do a quick sanity check on any given
algorithm analysis by plugging the cycles into the formula and pulling
out the old stopwatch.  Granted, doing so was typically not necessary,
but it was often-times still gratifying.  [OK, so shaving off a few
hundreths of a second fed my ego -- I'm much better now, really! ;-)]


-Jeff

steidl@centuryinter.net - http://www.dont.i.wish.com/
All opinions are my own, and are subject to change without notice.

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

[Darin Johnson]

> >it would be as if EE students were taught IC design in the first
> >course, and were only given resisters, capacitors, ohm's law,
> >etc. in their senior year, almost as an afterthought!
> 
> Well, it may be going that way. Most of the logic design in my department is 
> now done in a Hardware Description Language;

Is that an EE class though?  I doubt an *EE* class would get to the
point where resisters/capacitors/etc are only taught as an
afterthought (unless of course, the students are expected to already
know this from physics classes).  Most EE students don't even get to
do IC design, or even get jobs doing IC design.

> Sure, there is a need for a few people to understand the nuts and
> bolts, but these few will be writing the libraries and designing the
> silicon i.e., making the tools. As long as the rest of us can use
> the tools, what does it matter how they work? 

Then the "rest of us" don't need to go to universities.  We're not
talking about how to use tools, we're talking about learning at the
university level.  Why bother even learning programming if "the rest
of us" are only going to use the end-products?  Do you advocate that
arithmetic need not be taught, because "the rest of us" can just buy
calculators?  If that's all you want from programming, then don't go
to a university, there are plenty of 2-bit tradeschools, 4-bit
tradeschools, and even some excellent tradeschools.  (however, most EE
oriented tradeschools will teach capacitors, resistors, and Ohm's law,
even if they never get around to Fourier or Laplace transforms)  If
you don't like CS, then don't get a degree in CS, it's that simple.
If you're in a CS program, the university can only assume you want to
learn CS; even if they have a programming focus available, it surely
won't be a "learn the minimum only" sort of degree.  If you don't want
to learn, you don't have to, just don't spread your anti-learning
philosophy to others.

Yes, today at this moment, if you only know C++ you can get a job.
But in the past, and hopefully in the future again, you're not going
to get and keep a job if you aren't adaptable and flexible and able to
pick up a new OS or language or programming technique or whatever.
This field is not static.  Few fields are static.  You always need to
learn new things and do things differently and use new tools, even if
you're not the one designing the new things.  What good is your CNE
going to do you when no one uses Novell anymore?  What about when
TCP/IP never gets used anymore?  Or C, C++, or Ada?  Do you think the
standard state of affairs should be to require massive retraining
whenever the industry changes?
-- 
Darin Johnson
djohnson@ucsd.edu	O-
	The trouble with conspiracy theories are that they assume
	the government is organized.

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

[Alan Peake]

>> silicon i.e., making the tools. As long as the rest of us can use
>> the tools, what does it matter how they work? 

>Then the "rest of us" don't need to go to universities.  We're not
>talking about how to use tools, we're talking about learning at the
>university level.  Why bother even learning programming if "the rest
>of us" are only going to use the end-products? 

You still need to learn programming but use the tools that were made by an 
earlier generation to create something more advanced than the earlier 
generation were able to create with the tools that they inherited. There is 
only so much you can stuff into the head of a student in 4 or 5 years at Uni. 
Technology is expanding at such a rate that while it may be nice to 
understand programming from assembler up, you have to put your effort into 
where it will be most useful so if that entails starting at a higher level of 
abstraction, then so be it. There is a very interesting article by Andrew 
Koenig in the June '96 issue of the Journal of Object-Oriented 
Programming, advocating C++ as a first language - worth a read.


>This field is not static.  Few fields are static.  You always need to
>learn new things and do things differently and use new tools, even if
>you're not the one designing the new things.

Quite so.

> Do you think the
>standard state of affairs should be to require massive retraining
>whenever the industry changes?

Well, if you look at universities as training grounds for industry then that 
is what happens; not massively but progressively at any rate. 

Alan

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

[Andy Hardy]

In article <qqg268at31.fsf@tartarus.ucsd.edu>, Darin Johnson
<djohnson@tartarus.ucsd.edu> writes
[snip]
>  MVS needs assembler

Pardon?

Andy

Andy Hardy (Internet: aph@ahardy.demon.co.uk, CIS: 100015,2603)
PGP key available on request
===============================================================
Acid absorbs 47 times it's weight in excess Reality.

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

[Stefan 'Stetson' Skoglund]

How do we write complex software such as air-traffic control
systems, engine control systems, big-time banking systems
and so on without abstracting away from the computer hardware ?

How do we design such beasts ??
-- 
---------------------------------------------------------------------
Stefan 'Stetson' Skoglund          I               |
sp2stes1@ida.his.se                I               |
<http://www.his.se/ida/~sp2stes1/> I         _____/0\_____
                                   I ____________O(.)O___________
H\"ogskolan i Sk\"ovde, Sverige    I      I-+-I    O    I-+-I
                                   I
                                   I      Viggen with two Rb04
---------------------------------------------------------------------

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

[Stephen M O'Shaughnessy]

My response to an E-mail from Patrick Horgan

Pat, 
 I tried to e-mail this back to you and it bounced, so I am posting it here on CLA

At 04:41 PM 8/4/96 -0700, you wrote:

>
>I think you and most of the people in this discussion err in thinking that
>there's this artificial dichotomy between specific and abstract knowledge,
>and that there's some reason one is better to learn first.  In the real
>world both are learned together, watch any kids.  We're always learning
>specifics and abstracting generalities.

I disagree.  I think we learn generalities and as we continue learning we 
pick up the specifics.  Continued learning is the learning of the specifics.

>
>> tie our shoes without knowledge of knot theory.  We learn to read
>> without a knowledge of grammer. We learn addition, subtraction, multi.
>> and division without any formal mathmatical proofs.  In fact learning basic 
>> arithmetic is an abstraction as most school children learn by counting
>> pennies and dimes.  This prepares us for 90% or more of the problems we
>
>Apparently you haven't heard of the research work of Dr. Maria Dominguez of
>Venezuela.  She felt that mathematics was taught all wrong starting with
>concrete seeming pieces and eventually learning enough abstractions at the
>college level (if you stuck it out that far) to understand the whys and hows
>of math.  She taught what was essentially an Abstract Algebra course to
>preschool children and then built up through a ten year study.  She ended
>up with kids at the eighth grade level that were handling doctoral level
>mathematics...not just a few of the bright kids, but almost all of the kids.
>It seemed that understanding a conceptual framework to fit math in instead
>of memorizing rules made it easier for them...go figure:)
>

Though I am not familiar with this research, your brief description sounds like
support for my assertions.  We do not teach children number theory, we teach
them to count.  And not count numbers, they count apples and oranges and fish.
"One fish, Two fish; Red fish, Blue fish".  When we teach math we step back
from the details (concrete) to a higher level, a set of apples in front of the 
student.  Memorizing rules is not an abstraction, that is the concrete.  Applying
those rules to every day situations, without direct reference to those rules,
is the abstraction.


>> you encounter. (I do not consider assembly as a language. Despite it's title
>> of assembly *language* it is a code not far enough removed (i.e. abstracted)
>> from the underlying hardware).

>
>That's a bit arbitrary;)  Most machine code is abstracted from the hardware
>at least a level or two through microcoding.  

You support my point.  We don't agree on how much abstraction is desirable, but
machine code is abstracted from hardware through microcode; to which I add 
assembly code is abstracted from  machine code and higher level languages are
abstracted from assembly code.  It is at this higher level of abstraction that
I believe is the best place to start with learning programming.


>> I am not saying that the basic principles are not important.  If one is going
>> to make a career of programming these principles are crucial.  But I don't
>> believe one can recognize the underlying principles without the *shroud* of
>> abstractions to frame them.
>
>Eh?  I thought the basic principles were the abstractions and their expression
>in a language was the concrete?  I'm completely unclear what you mean here.

No, basic principles of hardware, microcode, machine code (assembly) are the
concrete that I was refering to.  In the real world it is electron moving 
through circuits that is taking place at the most basic level.  It is from here
that we must abstract to higher levels to solve real world problems.

In looking at the problem space, yes the language that we express the problem
with is less abstract, more concrete.  I was responding to other posters who 
claimed that a fundamental understanding of the hardware, microcode, assembly
language was necessary for a *first* understanding of the problem.  I was coming
from the other direction: abstracting up from the hardware to the problem space,
not, as I think you are doing, moving from an abstract problem to a more
concrete solution.  I feel we are both correct, just arguing different points.

>> 
>> problem: Add two numbers
>> Q: How?
>> A: Put them in registers A and R5 then do ADD A,R5
>> Q: What is a register? 
>> A: A place to hold data. 
>> Q: What is data?
>> A: A collection of 8 bit bytes.
>> Q: What is a bit/Byte?
>> A: ...
>> 
>> OR
>> 
>> problem: Add two numbers
>> Q: How?
>> A: C := A + B
>
>You forgot to ask all the questions for this one.  If you did it would go much
>farther and be a lot more complicated.  General numeric expressions are much
>more complicated than hardware level expressions of them.
>Q: What's a number
>Q: What's add
>Q: What's =

These are valid questions.  I left them out because they apply to both situations.
My point was that if I need to add the sales tax on a purchase total, I really
don't care what register the result is stored in or how many bits it takes.  I
want to abstract away from those details.  A some point in my career I will need
to know more detail about data types, but for the beginning student that level
of detail is unnecessary 

From the book "Programming in Ada" by J. G. P. Barnes, pg 3:
"The first advance occured in the early 1950s with high level languages such
as FORTRAN and Autocode which introduced 'expression abstraction'.  It 
thus became possible to write statements such as

    X=A + B(I)

so that the use of machine registers to evaluate the expression was completely
hidden from the programmer."

>
>> So first teach them to express these problems with a computer language.  Ada,
>> with it's strong typing, maps very well to real world objects.  Strong typing
>> is about abstraction and that enables the hiding of irrelevant details.
>
>This just isn't true, strong typing has nothing to do with abstraction.

We are obvioulsy not in agreement about the definition of abstraction, or
perhaps we are applying it differently.

"The brightest highlights of Ada95 are its inherent reliability and its
ability to provide ABSTRACTION through the package and PRIVATE TYPE"
Ada95 Rational, Introduction, pg II-1 first paragraph, first sentance.
(Emphasis are mine)

"The emphasis on high performance in Ada applications, and the requirement to
support interfacing to special hardware devices, mean that Ada programmers
must be able to engineer the low-level mapping of algorithms and data 
structures onto physical hardware.  On the other hand, to build large systems,
programmers must operate at a high level of ABSTRACTION and compose systems
from understandable building blocks.  The Ada TYPE system and facilities for
separate compilation are ideally suited to reconciling these seemingly conflicting
requirements."
Ada95 Rational, Overview of the Ada Language para. III.1.5

"The Ada language goes further, providing for the definition of TYPEs
that can only be manipulated according to the type's abstract operations.
Thus the Ada language provides direct support for the idea of an abstract
data type."
Norman H. Cohen, Ada as a Second Language, pg 64.

Patrick, typing has everything to do with abstraction.

>> This is so important when we are trying to learn something.  (That something
>> we are trying to learn is how to solve real world problems with a computer, 
>> not how a computer works).
>
>No, learn both, learn everything, don't be prejudiced against some types of
>learning.  You don't know what you're missing.  Understanding things from 
>both the top down and the bottom up adds a richness to your ability to 
>deal with abstract concepts in your head, and figure out some concrete (i.e.
>programatic) expression of an abstract solution.
>
I agree with you.
I said we must learn both.  My point is that we can't learn both at the same
time.  I believe it is best to start with the higher level to get a good feel
for what the problems are and how to solve then, then work our way down to more
basic levels of the *machine*  to see if there might be better ways to solve
specific problems on specific machines.

With all do respect to Dr. Dominguez, I don't believe you can teach phd level
mathmatics without first teaching them to count.  From my point of view, counting,
while a basic math skill, is an abstraction away from the details that phd
level students study.  Perhaps counting, because it is so basic, is a poor
example.  But I hope you see my point.  In the realm of mathematics, counting abstracts 
away number bases, number theory, addition, etc.  When the child has
a firm grasp of this, then we can show her more of the details such as addition 
is counting by one, that zero is just a place holder, that multiplication is 
addition with fixed steps (i.e. 2*2 is 2+2, 2*3 is 2+2+2, 2*4 is 2+2+2+2 ...)

We are not in agreement as to where the abstraction is taking place and 
where assumtions about a solution are being made.
 
>> No. Learn Ada
>
>No, it just doesn't really matter compared to the real issue...just keep learning:)
>
>Most people aren't going to learn a number of languages though, and the original
>question was specifically about what would make him marketable.  Ada won't cut
>it since it's not used outside of the defense industry and the pay scale in
>defense is low and the work environment is fraught with risk.
>
You are correct in recommending C for the most job choices.  You are wrong is
assuming Ada is niche language with no future.  More than half the project
being written in Ada today are outside the defense industry.  As a result
of many of it's side benefits, such as readablity, maintainablity, as well
as things like it is the only recognized, standardized object oriented language,
Ada is rapidly becomming a language of choice for large projects.

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

[Bob Gilbert]

In article <Dvo8Cz.G39@most.fw.hac.com>, smosha@most.fw.hac.com (Stephen M O'Shaughnessy) writes:
> >
> >No, learn both, learn everything, don't be prejudiced against some types of
> >learning.  You don't know what you're missing.  Understanding things from 
> >both the top down and the bottom up adds a richness to your ability to 
> >deal with abstract concepts in your head, and figure out some concrete (i.e.
> >programatic) expression of an abstract solution.
> >
> I agree with you.
> I said we must learn both.  My point is that we can't learn both at the same
> time.  I believe it is best to start with the higher level to get a good feel
> for what the problems are and how to solve then, then work our way down to more
> basic levels of the *machine*  to see if there might be better ways to solve
> specific problems on specific machines.

Why can't we learn both at the same time?  

When it came to learning computer science I think I tended to learn
both at the same time.  I took basic EE courses and learned about
operating transistors in saturation, how to build flip-flop circuits,
and how to implement logic using these circuits, and finally how to
design a computer architecture using these circuits (including micro-
code design).  At the same time I was learning PL/I programming, how
to write bubble sorts, learning about the merits of structured 
programming, top-down design methods, various data structures, data 
base design, discrete mathmatics, ect.  This was overlapped and 
followed with learning assembly, state machine theory, Turing machines,
general compiler (language) theory, and so forth.  Somewhere in my 
second senior year it all started to come together and make sense, 
not necessarily with a sudden turning on of the light of understanding,
but a gradual turning up of the dimmer switch.

Everybody is different, some learn better one way than the other, but
I am a definite believer in the "burn the candle at both ends" method.
At least that way you cover both bases.

-Bob

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

[Stephen M O'Shaughnessy]

In article <4u7fol$26s@zeus.orl.mmc.com>, rgilbert@unconfigured.xvnews.domain says...
>
>Why can't we learn both at the same time?  
>
>When it came to learning computer science I think I tended to learn
>both at the same time.  I took basic EE courses and learned about
>operating transistors in saturation, how to build flip-flop circuits,
>and how to implement logic using these circuits, and finally how to
>design a computer architecture using these circuits (including micro-
>code design).  At the same time I was learning PL/I programming, how
>to write bubble sorts, learning about the merits of structured 
>programming, top-down design methods, various data structures, data 
>base design, discrete mathmatics, ect.  This was overlapped and 
>followed with learning assembly, state machine theory, Turing machines,
>general compiler (language) theory, and so forth.  Somewhere in my 
>second senior year it all started to come together and make sense, 
>not necessarily with a sudden turning on of the light of understanding,
>but a gradual turning up of the dimmer switch.
>
That must have been one hell of a lecture.  By *same time* I meant SAME TIME.  Some
of your above mentioned topics must have been learned, and mastered, before the
others.  Care to comment on what you mean by second senior year?

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

[Bob Gilbert]

In article <Dvro5K.MKo@most.fw.hac.com>, smosha@most.fw.hac.com (Stephen M O'Shaughnessy) writes:
> In article <4u7fol$26s@zeus.orl.mmc.com>, rgilbert@unconfigured.xvnews.domain says...
> >
> >Why can't we learn both at the same time?  
> >
> >When it came to learning computer science I think I tended to learn
> >both at the same time.  I took basic EE courses and learned about
> >operating transistors in saturation, how to build flip-flop circuits,
> >and how to implement logic using these circuits, and finally how to
> >design a computer architecture using these circuits (including micro-
> >code design).  At the same time I was learning PL/I programming, how
> >to write bubble sorts, learning about the merits of structured 
> >programming, top-down design methods, various data structures, data 
> >base design, discrete mathmatics, ect.  This was overlapped and 
> >followed with learning assembly, state machine theory, Turing machines,
> >general compiler (language) theory, and so forth.  Somewhere in my 
> >second senior year it all started to come together and make sense, 
> >not necessarily with a sudden turning on of the light of understanding,
> >but a gradual turning up of the dimmer switch.
> >
> That must have been one hell of a lecture.  By *same time* I meant SAME TIME.  Some
> of your above mentioned topics must have been learned, and mastered, before the
> others. 

As I reflect back on the required course work, is seems that there were
probably as many as three distinct threads to be pursued in parallel 
(looking at the upper-level courses).  One started from the hardware 
(EE) viewpoint and worked it's way up (transistors, flip-flops, logic
circuits, computer architecture, micro-code, assembly), one started at 
a high (more abstract) level and worked down (PL/I programming, structured
design, data structures, data base design, etc.), and one started somewhere
in the middle and worked out (assembly, Turing machines, compiler design,
language theory, etc..  The point is, the curriculum was providing both 
top down and bottom up (and maybe some other, shotgun?) approaches to 
teaching the entire subject matter.  Certainly some courses required that
certain prerequisites be met, but my definition of "same time" is that I was 
taking introductory PL/I programming courses in the same semester that I
was taking digital design courses, the following semester might include 
courses in computer architecture concurrent with a data structures class,
and so on.  In one path you learned about roots, bark, and leaves, and these
came together to make up trees, and you can then take a bunch of trees and 
make a forest.  The other path started out teaching you about the forest 
and showed that it was made up of a bunch of trees.....  Both paths were
pursued in parallel.
 
> Care to comment on what you mean by second senior year?

It could be that there are those of us whose dedication to the pursuit of
higher learning and obtaining a professional degree is not all that great
(or at least wasn't when we were young and easily distracted) or we lacked
the necessary motivation to complete a degree program in the usual time 
frame, or.....  we unwittingly pursued other degrees, like mechanical 
engineering, before discovering our preference for computer science and 
thus spent extra time taking additional course work not required for a 
computer science degree.  I'm not telling which, if either, it is :-) .

-Bob

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

[Patrick Horgan]

In article <y9yd91bw9bx.fsf@august.ida.his.se>, Stefan 'Stetson' Skoglund <sp2stes1@ida.his.se> writes:
> How do we write complex software such as air-traffic control
> systems, engine control systems, big-time banking systems
> and so on without abstracting away from the computer hardware ?
> 
> How do we design such beasts ??

Why?  Is someone asking you to do this?  I think the questions were in the wrong
order anyway...I'd hope that you at least had some idea of the high level systems
before you started writing software.

In this whole discussion I haven't seen anyone state nor imply that learning
high-level abstractions wasn't required.

-- 

   Patrick J. Horgan    patrick@broadvision.com   Have horse will ride.
   Opinions mine, not my employer's except by most bizarre coincidence.

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

[Fergus Henderson]

"Tim Behrendsen" <tim@airshields.com> writes:

>Fergus Henderson <fjh@mundook.cs.mu.OZ.AU> wrote in article
>> N lines of assembler is not much more difficult to understand
>> or to code than N lines of C.  But if you want the students to
>> understand say quicksort, it's a lot easier showing them 20 lines
>> of C than 100 lines of assembler.
>
>Who's talking about showing them?  I would suggest that if
>they wrote a quicksort in assembler, they will have a much
>better "feel" for the algorithm, than if they wrote it in C.

So which is better use of a student's time, writing 100 lines of
quicksort in assembler, or using C and writing 20 lines of quicksort,
10 lines of insertion sort, 20 lines of heap sort, 20 lines of
merge sort, and 30 lines of glue to test them all out?

Which will give them more practice in choosing meaningful variable
names?  Which will give them understanding of a range of different
sorting algorithms?  Which will give them experience of the idea of
having multiple implementations of the same interface?  Which will
teach them how to write portable code?  Which will give them more
experience with the sort of software engineering problems they are
likely to encounter in the Real World [tm]?

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

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

[Tim Behrendsen]

Fergus Henderson <fjh@mundook.cs.mu.OZ.AU> wrote in article
<4uaqqg$203@mulga.cs.mu.OZ.AU>...
> "Tim Behrendsen" <tim@airshields.com> writes:
> >Who's talking about showing them?  I would suggest that if
> >they wrote a quicksort in assembler, they will have a much
> >better "feel" for the algorithm, than if they wrote it in C.
> 
> So which is better use of a student's time, writing 100 lines of
> quicksort in assembler, or using C and writing 20 lines of quicksort,
> 10 lines of insertion sort, 20 lines of heap sort, 20 lines of
> merge sort, and 30 lines of glue to test them all out?

I think it's more valuable to truly understand one or two algorithms,
than to vaguely understand 5 algorithms.

> Which will give them more practice in choosing meaningful variable
> names?
> Which will give them experience of the idea of
> having multiple implementations of the same interface?  Which will
> teach them how to write portable code?  Which will give them more
> experience with the sort of software engineering problems they are
> likely to encounter in the Real World [tm]?

Easily learned. Later. More important to understand the
procedural nature of the computer at first.

> Which will give them understanding of a range of different
> sorting algorithms?

I would rather they have a better fundamental understanding
of algorithms in general.

If I may extend a famous quote,

"Teach a man an algorithm, and you have given him one solution.
Teach a man to think, and you have given him all solutions."

[Hey!  I like that... anybody want to quote me in their next
book? ;-> ]

-- Tim Behrendsen (tim@airshields.com)

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

[Szu-Wen Huang]

Tim Behrendsen (tim@airshields.com) wrote:
: Fergus Henderson <fjh@mundook.cs.mu.OZ.AU> wrote in article
: <4uaqqg$203@mulga.cs.mu.OZ.AU>...

: > So which is better use of a student's time, writing 100 lines of
: > quicksort in assembler, or using C and writing 20 lines of quicksort,
: > 10 lines of insertion sort, 20 lines of heap sort, 20 lines of
: > merge sort, and 30 lines of glue to test them all out?

: I think it's more valuable to truly understand one or two algorithms,
: than to vaguely understand 5 algorithms.

1.  Being able to write algorithm X in assembly doesn't make you
    understand the algorithm better.  It makes you understand whatever
    platform du jour your school uses better.
2.  Vaguely understanding 5 algorithms is far better than understanding
    one or two fully.  The primary objective of algorithms courses is
    to produce students that can *choose* which algorithm to use,
    not to produce students who can memorize one or two algorithms.
    In fact, there's rarely a programmer more dangerous than one that
    has no broad knowledge of algorithms.

[snip]
: > Which will give them experience of the idea of
: > having multiple implementations of the same interface?  Which will
: > teach them how to write portable code?  Which will give them more
: > experience with the sort of software engineering problems they are
: > likely to encounter in the Real World [tm]?

: Easily learned. Later. More important to understand the
: procedural nature of the computer at first.

If you think software engineering is easily learned, you obviously
haven't been in the real world.

: > Which will give them understanding of a range of different
: > sorting algorithms?

: I would rather they have a better fundamental understanding
: of algorithms in general.

I thought you just said it was better to "truly understand one or
two algorithms"?  Make up your mind.  General knowledge, or specific
knowledge?

: If I may extend a famous quote,

: "Teach a man an algorithm, and you have given him one solution.
: Teach a man to think, and you have given him all solutions."
[snip]

Teach a man an algorithm and some I/O routines to enter the input
and display the output, then some routines to set up the stack,
then some routines to initialize data, then some reasons why
instruction X cannot follow instruction Y, then some reasons why
a small memory model isn't enough, and you confuse the man for
life.

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

[Tim Behrendsen]

Szu-Wen Huang <huang@mnsinc.com> wrote in article
<4ubnhr$714@news1.mnsinc.com>...
> Tim Behrendsen (tim@airshields.com) wrote:
> 
> : I think it's more valuable to truly understand one or two algorithms,
> : than to vaguely understand 5 algorithms.
> 
> 1.  Being able to write algorithm X in assembly doesn't make you
>     understand the algorithm better.  It makes you understand whatever
>     platform du jour your school uses better.
> 2.  Vaguely understanding 5 algorithms is far better than understanding
>     one or two fully.  The primary objective of algorithms courses is
>     to produce students that can *choose* which algorithm to use,
>     not to produce students who can memorize one or two algorithms.
>     In fact, there's rarely a programmer more dangerous than one that
>     has no broad knowledge of algorithms.

My point is someone who has "vaguely" learned five algorithms has
simply memorized them, and learned nothing about the general
principles of how algorithms are created.

Someone who has "the feel" for two algorithms very strongly are
more likely to be able to extend that knowledge to creating new
algorithms.

Computer Science is one of the few, if not only, sciences where a
student can derive all of it just by thinking.

> [snip]
> : > Which will give them experience of the idea of
> : > having multiple implementations of the same interface?  Which will
> : > teach them how to write portable code?  Which will give them more
> : > experience with the sort of software engineering problems they are
> : > likely to encounter in the Real World [tm]?
> 
> : Easily learned. Later. More important to understand the
> : procedural nature of the computer at first.
> 
> If you think software engineering is easily learned, you obviously
> haven't been in the real world.

I live lame software engineering every day, believe me I
understand the level of general ignorance.  You can always
fix someone's style, but you must plant the seed of thought
early on.

> : > Which will give them understanding of a range of different
> : > sorting algorithms?
> 
> : I would rather they have a better fundamental understanding
> : of algorithms in general.
> 
> I thought you just said it was better to "truly understand one or
> two algorithms"?  Make up your mind.  General knowledge, or specific
> knowledge?

Truly understanding two algorithms is better than memorizing five
algorithms, because that is what *gives" the fundamental
understanding.

> : If I may extend a famous quote,
> 
> : "Teach a man an algorithm, and you have given him one solution.
> : Teach a man to think, and you have given him all solutions."
> [snip]
> 
> Teach a man an algorithm and some I/O routines to enter the input
> and display the output, then some routines to set up the stack,
> then some routines to initialize data,

Yes, and wouldn't they truly understand I/O routines and stacks
after that?

> then some reasons why
> instruction X cannot follow instruction Y, then some reasons why
> a small memory model isn't enough, and you confuse the man for
> life.

Yes, if your model is the brain-damaged 8086 model.  I personally
would use a 68000 to teach on because it's a nice straight-forward
orthogonal instruction set.

-- Tim Behrendsen

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

[Christopher R Volpe]

Tim Behrendsen wrote:
> 
> 
> My point is someone who has "vaguely" learned five algorithms has
> simply memorized them, and learned nothing about the general
> principles of how algorithms are created.
> 
> Someone who has "the feel" for two algorithms very strongly are
> more likely to be able to extend that knowledge to creating new
> algorithms.

Just to throw in my $.02 worth, trying to understand an algorithm by
writing/reading it in assembler is like trying to debug an algorithm by
hooking the CPU up to an oscilloscope. There's a reason that algorithms
texts present algorithms in pseudo-code. And the fact that pseudo-code
resembles high-level languages more than assembler is not a coincidence.

> > I thought you just said it was better to "truly understand one or
> > two algorithms"?  Make up your mind.  General knowledge, or specific
> > knowledge?
> 
> Truly understanding two algorithms is better than memorizing five
> algorithms, because that is what *gives" the fundamental
> understanding.
> 

I would say that truly understanding X algorithms is better than
memorizing Y algorithms for all positive values of X and Y. I think the
issue here is whether you can get a better grasp of an algorithm while
being bogged down in the details of assembler.

> > Teach a man an algorithm and some I/O routines to enter the input
> > and display the output, then some routines to set up the stack,
> > then some routines to initialize data,
> 
> Yes, and wouldn't they truly understand I/O routines and stacks
> after that?

Sure, if that's the intent. It doesn't help me understand quicksort,
though.

> 
> > then some reasons why
> > instruction X cannot follow instruction Y, then some reasons why
> > a small memory model isn't enough, and you confuse the man for
> > life.
> 
> Yes, if your model is the brain-damaged 8086 model.  I personally
> would use a 68000 to teach on because it's a nice straight-forward
> orthogonal instruction set.

So, what you're saying is, a simpler expression of an algorithm is
better? Hmmm, interesting :-)

--

Chris Volpe			Phone: (518) 387-7766 
GE Corporate R&D		Fax:   (518) 387-6560
PO Box 8 			Email: volpecr@crd.ge.com
Schenectady, NY 12301		Web:   http://www.crd.ge.com/~volpecr

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

[Peter Seebach]

In article <01bb8536$892ee260$87ee6fce@timpent.airshields.com>,
Tim Behrendsen <tim@airshields.com> wrote:
>My point is someone who has "vaguely" learned five algorithms has
>simply memorized them, and learned nothing about the general
>principles of how algorithms are created.

Which is exactly what will happen if they code them in assembly; they
can't possibly be learning how algorithms are created if they start with
implementing them in a low level language.  Algorithms are generally written
in natural languages, and written on napkins.

The details of which bytes move where are *not* part of the algorithm itself.

>I live lame software engineering every day, believe me I
>understand the level of general ignorance.  You can always
>fix someone's style, but you must plant the seed of thought
>early on.

Yes.

>Truly understanding two algorithms is better than memorizing five
>algorithms, because that is what *gives" the fundamental
>understanding.

But experimenting with the five algorithms, and comparing them, is a better
way to truly understand them than implementing them in a difficult language.

>> Teach a man an algorithm and some I/O routines to enter the input
>> and display the output, then some routines to set up the stack,
>> then some routines to initialize data,

>Yes, and wouldn't they truly understand I/O routines and stacks
>after that?

Sure.  Implementing I/O routines and stacks, *in any language*, is a good way
to learn about I/O routines and stacks.  It's a crappy way to learn about
sorting.

Further, learning about stacks is bad way to learn about computing; stacks are
not a universal implementation of computers.  Students who learn about stacks
early on may start assuming that that's somehow a basic truth of computing.
They may do things like assert that the addresses of local variables in one
function are always lower than the addresses of local variables in a function
"above" it on the stack.  Or maybe that should be higher; both kinds exist.

Being aware of a *conceptual* stack is different.

>Yes, if your model is the brain-damaged 8086 model.  I personally
>would use a 68000 to teach on because it's a nice straight-forward
>orthogonal instruction set.

But not nearly as straightforward as C or lisp.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

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

[Tim Behrendsen]

Peter Seebach <seebs@solutions.solon.com> wrote in article
<4ud8oo$61t@solutions.solon.com>...
> In article <01bb8536$892ee260$87ee6fce@timpent.airshields.com>,
> Tim Behrendsen <tim@airshields.com> wrote:
> >My point is someone who has "vaguely" learned five algorithms has
> >simply memorized them, and learned nothing about the general
> >principles of how algorithms are created.
> 
> Which is exactly what will happen if they code them in assembly; they
> can't possibly be learning how algorithms are created if they start with
> implementing them in a low level language.  Algorithms are generally
written
> in natural languages, and written on napkins.

What? I guess before HLLs nobody "possibly" learned anything.

I don't know about you, but I think about algorithms in terms of
data flow and manipulation.  HLLs or Assembly don't enter into
either.


> The details of which bytes move where are *not* part of the algorithm
itself.

What What?  That's what algorithms *are*!  What are algorithms
if they aren't black boxes that describe a particular output for
a particular input?  I don't know about your I/O, but mine are
in bytes.

> >Truly understanding two algorithms is better than memorizing five
> >algorithms, because that is what *gives" the fundamental
> >understanding.
> 
> But experimenting with the five algorithms, and comparing them, is a
better
> way to truly understand them than implementing them in a difficult
language.

I agree that I would rather have the student experiment with
*anything* rather than just crank out homework assignments with
no thought involved.

We disagree however on the difficulty of assembly.  I think it
is *much* easier, albeit more tedious, than a HLL.

> Sure.  Implementing I/O routines and stacks, *in any language*, is a good
way
> to learn about I/O routines and stacks.  It's a crappy way to learn about
> sorting.
> 
> Further, learning about stacks is bad way to learn about computing;
stacks are
> not a universal implementation of computers.  Students who learn about
stacks
> early on may start assuming that that's somehow a basic truth of
computing.
> They may do things like assert that the addresses of local variables in
one
> function are always lower than the addresses of local variables in a
function
> "above" it on the stack.  Or maybe that should be higher; both kinds
exist.

But that contradicts the C standard.  You're saying that total
ignorance is better than partial ignorance, and I might
even agree with that.  But I don't think it's reasonable to
argue that total ignorance is better than adequate knowledge.

In fact, I might even argue it's better to expose those
mistakes early on, rather than graduate them completely innocent
of these issues, and then when they need to do some assembly,
they pick up the bad habits.

-- Tim Behrendsen (tim@airshields.com)

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

[Peter Seebach]

In article <01bb8567$4adddbc0$87ee6fce@timpent.airshields.com>,
Tim Behrendsen <tim@airshields.com> wrote:
>Peter Seebach <seebs@solutions.solon.com> wrote in article
><4ud8oo$61t@solutions.solon.com>...
>> Which is exactly what will happen if they code them in assembly; they
>> can't possibly be learning how algorithms are created if they start with
>> implementing them in a low level language.  Algorithms are generally
>> written in natural languages, and written on napkins.

>What? I guess before HLLs nobody "possibly" learned anything.

Probably not.  We have *no* evidence that people learned or comprehended *any*
algorithms before we developed HLL's.  The one I use for more than 90% of my
discussion and analysis of algorithms is called "English", though this is
arguably a misnomer, as I'm not.

>I don't know about you, but I think about algorithms in terms of
>data flow and manipulation.  HLLs or Assembly don't enter into
>either.

I think about them in terms of descriptions of rules for behavior.

Cantor's diagonal proof is an algorithm.  It's trivially unimplementable;
however, it's a brilliant algorithm for generating a result from an input,
despite the fact that neither the input nor the result could possibly be
stored anywhere.

>> The details of which bytes move where are *not* part of the algorithm
>> itself.

>What What?  That's what algorithms *are*!  What are algorithms
>if they aren't black boxes that describe a particular output for
>a particular input?  I don't know about your I/O, but mine are
>in bytes.

Exactly.  You're thinking of the *implementation*.  When you say "swap a and
b", it doesn't *MATTER*, in terms of what swapping does, whether this is
implemented by 3 xor's, by 3 assigns with a temporary, or by leaving the
values where they are and swapping the names of a and b.

>I agree that I would rather have the student experiment with
>*anything* rather than just crank out homework assignments with
>no thought involved.

*stunned silence*

We agree on something?  Someone say the H word, this thread is nearly gone.

>We disagree however on the difficulty of assembly.  I think it
>is *much* easier, albeit more tedious, than a HLL.

Huh.  Well, see, you're probably comfortable with it.  I can't *imagine* being
able to keep track of all of that.

>> Further, learning about stacks is bad way to learn about computing;
>stacks are
>> not a universal implementation of computers.  Students who learn about
>stacks
>> early on may start assuming that that's somehow a basic truth of
>computing.
>> They may do things like assert that the addresses of local variables in
>one
>> function are always lower than the addresses of local variables in a
>function
>> "above" it on the stack.  Or maybe that should be higher; both kinds
>exist.

>But that contradicts the C standard.

What does?  C can be implemented on stack-free machines.  Remember, there's no
guarantee that the relationals (lt, gt, lte, gte) are meaningful *at all* to
pointers not into (or just past the end of) a single object.

>You're saying that total
>ignorance is better than partial ignorance, and I might
>even agree with that.  But I don't think it's reasonable to
>argue that total ignorance is better than adequate knowledge.

No.  I just have *very* high standards for the adequate knowledge that makes
it safe for a programmer in a high level language to have beliefs about an
alleged understanding of "what really happens".

>In fact, I might even argue it's better to expose those
>mistakes early on, rather than graduate them completely innocent
>of these issues, and then when they need to do some assembly,
>they pick up the bad habits.

If they've been taught well, they'll see how the operations they already
understand are happening, rather than use the assembly to fill in holes in an
incomplete understanding.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

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

[Tim Behrendsen]

Peter Seebach <seebs@solutions.solon.com> wrote in article
<4ue7tm$onn@solutions.solon.com>...
> In article <01bb8567$4adddbc0$87ee6fce@timpent.airshields.com>,
> Tim Behrendsen <tim@airshields.com> wrote:
> >Peter Seebach <seebs@solutions.solon.com> wrote in article
> ><4ud8oo$61t@solutions.solon.com>...
> >> Which is exactly what will happen if they code them in assembly; they
> >> can't possibly be learning how algorithms are created if they start
with
> >> implementing them in a low level language.  Algorithms are generally
> >> written in natural languages, and written on napkins.
> 
> >What? I guess before HLLs nobody "possibly" learned anything.
> 
> Probably not.  We have *no* evidence that people learned or comprehended
*any*
> algorithms before we developed HLL's.  The one I use for more than 90% of
my
> discussion and analysis of algorithms is called "English", though this is
> arguably a misnomer, as I'm not.

Well, now you're being silly, especially considering Knuth
expressed his books in MIX.

> >I don't know about you, but I think about algorithms in terms of
> >data flow and manipulation.  HLLs or Assembly don't enter into
> >either.
> 
> I think about them in terms of descriptions of rules for behavior.

At first, but what about when you're ready to implement them?

> >We disagree however on the difficulty of assembly.  I think it
> >is *much* easier, albeit more tedious, than a HLL.
> 
> Huh.  Well, see, you're probably comfortable with it.  I can't *imagine*
being
> able to keep track of all of that.

I have full confidence in your abilities. :-)

-- Tim Behrendsen (tim@airshields.com)

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

[Peter Seebach]

In article <01bb8608$9a12bc00$87ee6fce@timpent.airshields.com>,
Tim Behrendsen <tim@airshields.com> wrote:
>Peter Seebach <seebs@solutions.solon.com> wrote in article
><4ue7tm$onn@solutions.solon.com>...
>> Probably not.  We have *no* evidence that people learned or comprehended
>*any*
>> algorithms before we developed HLL's.  The one I use for more than 90% of
>my
>> discussion and analysis of algorithms is called "English", though this is
>> arguably a misnomer, as I'm not.

>Well, now you're being silly, especially considering Knuth
>expressed his books in MIX.

No, he expressed them in English, then used MIX to show a possible
implementation.  Since then, he's mostly moved to a family of "web" languages
(no relation) in which the source *is* the English text of the documentation,
and the "source code" used by the compiler is generated from small code
fragments which are essentially figures referred to in the text.

Despite the fact that I can't read Pascal (I try, but I always misunderstand
things), I can read a WEB program using pascal as the "base language" easily
and comfortably.  At the end, I have a *solid* understanding of what the
algorithm does in principle, even if I'm not sure I follow the implementation.

I end up knowing it well enough that I could write my own implementation,
despite not having really seen the implementation or tried to understand it.

>At first, but what about when you're ready to implement them?

Generally, I test them out by writing the algorithm in English, and drawing
pictures, and following the rules myself.  I occasionally use C for
complicated ones.  Or perl.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

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

[James_Rogers]

Peter Seebach wrote:
> Tim Behrendsen <tim@airshields.com> wrote:
>>>>int a[50000],b[50000],c[50000],d[50000],e[50000];

>>>>void test1()
>>>>{
>>>>  int i,j;
>>>>  for (j=0;j<10;++j){
>>>>    for (i=0;i<50000;++i){
>>>>      ++a[i];++b[i];++c[i];++d[i];++e[i];
>>>>    }
>>>>  }
>>>>}

>>>>void test2()
>>>>{
>>>>  int i,j;
>>>>  for (j=0;j<10;++j){
>>>>    for (i=0;i<50000;++i) ++a[i];
>>>>    for (i=0;i<50000;++i) ++b[i];
>>>>    for (i=0;i<50000;++i) ++c[i];
>>>>    for (i=0;i<50000;++i) ++d[i];
>>>>    for (i=0;i<50000;++i) ++e[i];
>>>>  }
>>>>}

This example also behaves differently than predicted by
Mr Behrendsen when implemented in Ada 95 using the GNAT
compiler on a SPARC 20.

I translated the above functions into Ada as follows:
   procedure test1 is
   begin
      for J in 1..10 loop
         for I in index_type loop
            a(I) := a(I) + 1;
            b(I) := b(I) + 1;
            c(I) := c(I) + 1;
            d(I) := d(I) + 1;
            e(I) := e(I) + 1;
         end loop;
      end loop;
  end test1;
  
  procedure test2 is
  begin
     for J in 1..10 loop
        for I in index_type loop
           a(I) := a(I) + 1;
        end loop;
        for I in index_type loop
           b(I) := b(I) + 1;
        end loop;
        for I in index_type loop
           c(I) := c(I) + 1;
        end loop;
        for I in index_type loop
           d(I) := d(I) + 1;
        end loop;
        for I in index_type loop
           e(I) := e(I) + 1;
        end loop;
     end loop;
  end test2;

Each of the above loops was run 10 times.  The
timings are given below.

The resulting timings with no optimization are:
Test1 execution time:          12.2815
Test2 execution time:          16.0227

With full optimization and inlining of procedures the 
results are:
Test1 execution time:           4.6333
Test2 execution time:           5.2464

Using Ada the performance is quite comperable to Mr Seebach's
C results using gcc.  The Ada results also do not support Mr
Behrendsen's position.

-- 
Jim Rogers
*************************************************************
Celebrate Diplomacy

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

[Tim Behrendsen]

James_Rogers <jrogers@velveeta.apdev.cs.mci.com> wrote in article
<32134490.41C6@velveeta.apdev.cs.mci.com>...
> Peter Seebach wrote:
> > Tim Behrendsen <tim@airshields.com> wrote:
> >>>>int a[50000],b[50000],c[50000],d[50000],e[50000];
> 
> >>>>void test1()
> >>>>{
> >>>>  int i,j;
> >>>>  for (j=0;j<10;++j){
> >>>>    for (i=0;i<50000;++i){
> >>>>      ++a[i];++b[i];++c[i];++d[i];++e[i];
> >>>>    }
> >>>>  }
> >>>>}
> 
> >>>>void test2()
> >>>>{
> >>>>  int i,j;
> >>>>  for (j=0;j<10;++j){
> >>>>    for (i=0;i<50000;++i) ++a[i];
> >>>>    for (i=0;i<50000;++i) ++b[i];
> >>>>    for (i=0;i<50000;++i) ++c[i];
> >>>>    for (i=0;i<50000;++i) ++d[i];
> >>>>    for (i=0;i<50000;++i) ++e[i];
> >>>>  }
> >>>>}
> 
> This example also behaves differently than predicted by
> Mr Behrendsen when implemented in Ada 95 using the GNAT
> compiler on a SPARC 20.
> 
> I translated the above functions into Ada as follows:
>    procedure test1 is
>    begin
>       for J in 1..10 loop
>          for I in index_type loop
>             a(I) := a(I) + 1;
>             b(I) := b(I) + 1;
>             c(I) := c(I) + 1;
>             d(I) := d(I) + 1;
>             e(I) := e(I) + 1;
>          end loop;
>       end loop;
>   end test1;
>   
>   procedure test2 is
>   begin
>      for J in 1..10 loop
>         for I in index_type loop
>            a(I) := a(I) + 1;
>         end loop;
>         for I in index_type loop
>            b(I) := b(I) + 1;
>         end loop;
>         for I in index_type loop
>            c(I) := c(I) + 1;
>         end loop;
>         for I in index_type loop
>            d(I) := d(I) + 1;
>         end loop;
>         for I in index_type loop
>            e(I) := e(I) + 1;
>         end loop;
>      end loop;
>   end test2;
> 
> Each of the above loops was run 10 times.  The
> timings are given below.
> 
> The resulting timings with no optimization are:
> Test1 execution time:          12.2815
> Test2 execution time:          16.0227
> 
> With full optimization and inlining of procedures the 
> results are:
> Test1 execution time:           4.6333
> Test2 execution time:           5.2464
> 
> Using Ada the performance is quite comperable to Mr Seebach's
> C results using gcc.  The Ada results also do not support Mr
> Behrendsen's position.

My original timings where off by a factor of 10, BTW.  The
original implementation I ran used 100 for the outer loop,
not 10.

But this *is* interesting; that implies to me that the ADA
compiler is not using pointer arithmetic when optimizing, and
is calculating the indexes every time.  This would make the
overhead of the extra looping constructs overwhelm the
gain in page locality.

Just for some ADA to C performance comparison, it would be
interesting to compile the C code on your SPARC 20 and see
what the difference is.  Since ADA has runtime array boundary
checking, it makes we wonder if the optimizer is smart enough
to know to get rid of the boundary checking when it's within
a known loop like this.

-- Tim Behrendsen (tim@airshields.com)

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

[Mike Rubenstein]

seebs@solutions.solon.com (Peter Seebach) wrote:

> In article <01bb8536$892ee260$87ee6fce@timpent.airshields.com>,
> Tim Behrendsen <tim@airshields.com> wrote:
> >My point is someone who has "vaguely" learned five algorithms has
> >simply memorized them, and learned nothing about the general
> >principles of how algorithms are created.
> 
> Which is exactly what will happen if they code them in assembly; they
> can't possibly be learning how algorithms are created if they start with
> implementing them in a low level language.  Algorithms are generally written
> in natural languages, and written on napkins.

Are you suggesting that the guy who invented the GCD algorithm you
used didn't know assembly language? :-)


Michael M Rubenstein

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

[Peter Seebach]

In article <320bf84e.9269979@nntp.ix.netcom.com>,
Mike Rubenstein <miker3@ix.netcom.com> wrote:
>Are you suggesting that the guy who invented the GCD algorithm you
>used didn't know assembly language? :-)

Actually, the Greeks had an unfair advantage, in that they learned math as
children.  In fact, *all* of their texts are math texts, consisting of
sequences of variables being multiplied.  At least, that's what I see when
I try to read 'em.  Not sure *why* they never use anything but the sorta
weird ones, but I guess it works for them.  I woulda used more x's and
n's, but hey.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.

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

[Craig Franck]

miker3@ix.netcom.com (Mike Rubenstein) wrote:
>seebs@solutions.solon.com (Peter Seebach) wrote:
>
>> In article <01bb8536$892ee260$87ee6fce@timpent.airshields.com>,
>> Tim Behrendsen <tim@airshields.com> wrote:
>> >My point is someone who has "vaguely" learned five algorithms has
>> >simply memorized them, and learned nothing about the general
>> >principles of how algorithms are created.
>> 
>> Which is exactly what will happen if they code them in assembly; they
>> can't possibly be learning how algorithms are created if they start with
>> implementing them in a low level language.  Algorithms are generally written
>> in natural languages, and written on napkins.
>
>Are you suggesting that the guy who invented the GCD algorithm you
>used didn't know assembly language? :-)

Euclid was a mathmetician, not a programmer :-)

I think why you should write algorithms in a natural language or even
psudo-code (whether on a napkin or not) is that an algorithm is not 
tied to any language. You implement the algorithm in a language, but
the algorithm itself has nothing to do with any one language. Our friend 
Euclid would probably think it existed in the "realm of idea's" A lot
of books use sort of a pidgeon pascal to discribe algorithms. Ideally
you could descibe it in math, but of course the concept of an iterative
construct is very week in mathmatics. To understand the creation of
algorithms you need to learn structured reasoning, critical thinking
skills, and get alot of simple algoithms under your belt before tackling
big ones. Figuring out how to print centered text on a monitor has
nothing to do with assembly language even though you can code as such.

-- 

Craig
-----
clfranck@worldnet.att.net
Manchester, NH
There are no electrons...

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

[Szu-Wen Huang]

Tim Behrendsen (tim@airshields.com) wrote:
: Szu-Wen Huang <huang@mnsinc.com> wrote in article
: <4ubnhr$714@news1.mnsinc.com>...

: > 1.  Being able to write algorithm X in assembly doesn't make you
: >     understand the algorithm better.  It makes you understand whatever
: >     platform du jour your school uses better.
: > 2.  Vaguely understanding 5 algorithms is far better than understanding
: >     one or two fully.  The primary objective of algorithms courses is
: >     to produce students that can *choose* which algorithm to use,
: >     not to produce students who can memorize one or two algorithms.
: >     In fact, there's rarely a programmer more dangerous than one that
: >     has no broad knowledge of algorithms.

: My point is someone who has "vaguely" learned five algorithms has
: simply memorized them, and learned nothing about the general
: principles of how algorithms are created.

No, your point was writing an algorithm in assembly helps to understand
it fully.  I'll be my own case in point.  I remember most sorting
algorithms vaguely, and I probably could not implement all of them
off the top of my head.  Does that hamper me?  No, because I know
which book to look them up in, and that's exactly what books are for.
The important thing, however, is that I remember that O(n^2) is bad
for a sorting algorithm, and O(n lg n) is pretty good.

Now, what about your student that knows *one* algorithm?

: Someone who has "the feel" for two algorithms very strongly are
: more likely to be able to extend that knowledge to creating new
: algorithms.

Uhm, theoretically.  Somebody with only in-depth knowledge of run-
length encoding is not very likely to come up spontaneously with
Huffman or arithmetic compression.

: Computer Science is one of the few, if not only, sciences where a
: student can derive all of it just by thinking.

Assuming the student doesn't have a deadline and all day to think for
40 years.  Many algorithms are obvious.  Insertion sort, for example,
is what a human would do (if somewhat parallelized).  Quicksort, on
the other hand, is nowhere near intuitive.  Be realistic.

: > [snip]
: > If you think software engineering is easily learned, you obviously
: > haven't been in the real world.

: I live lame software engineering every day, believe me I
: understand the level of general ignorance.  You can always
: fix someone's style, but you must plant the seed of thought
: early on.

Are you asserting that teaching software engineering instead of assembly
language will somehow make the student unable to think?  Assembly
language is a powerful tool best used by experts, not beginners.
Beginners do not have the knowledge to use them properly, and tend
to get caught in details and miss the big picture.  If you give an
assignment of "implement quicksort in PC assembly", how much effort
is spent in:

1.  the algorithm
2.  I/O
3.  OS/platform intricacies
4.  debugging

?  I would imagine your goal would be to maximize #1, which is why
a HLL is better for the purpose.

: > I thought you just said it was better to "truly understand one or
: > two algorithms"?  Make up your mind.  General knowledge, or specific
: > knowledge?

: Truly understanding two algorithms is better than memorizing five
: algorithms, because that is what *gives" the fundamental
: understanding.

Fundamental understanding of RLE has little, if not nothing, to do
with Huffman compression.  Fundamental understanding of quicksort
has nothing to do with heapsort either.

: > Teach a man an algorithm and some I/O routines to enter the input
: > and display the output, then some routines to set up the stack,
: > then some routines to initialize data,

: Yes, and wouldn't they truly understand I/O routines and stacks
: after that?

They would, but would they understand the algorithm?

: > then some reasons why
: > instruction X cannot follow instruction Y, then some reasons why
: > a small memory model isn't enough, and you confuse the man for
: > life.

: Yes, if your model is the brain-damaged 8086 model.  I personally
: would use a 68000 to teach on because it's a nice straight-forward
: orthogonal instruction set.

It doesn't matter.  You are burdening beginners with details that
you could've avoided by using an HLL.  My school was contemplating
teaching one freshman class Prolog as a first language and another
Pascal, then switch in their second year to observe which was more
effective.  It's too bad the experiment has practical problems,
because it would be interesting to see if it's easier for a "recursive-
minded" student to study iteration or the reverse.  In any case,
you want to train students in problem solving, not why the OS requires
value X in register Y.

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

[Tim Behrendsen]

Szu-Wen Huang <huang@mnsinc.com> wrote in article
<4ud8m5$ka5@news1.mnsinc.com>...
> Tim Behrendsen (tim@airshields.com) wrote:

> : My point is someone who has "vaguely" learned five algorithms has
> : simply memorized them, and learned nothing about the general
> : principles of how algorithms are created.
> 
> No, your point was writing an algorithm in assembly helps to understand
> it fully.  I'll be my own case in point.  I remember most sorting
> algorithms vaguely, and I probably could not implement all of them
> off the top of my head.  Does that hamper me?  No, because I know
> which book to look them up in, and that's exactly what books are for.
> The important thing, however, is that I remember that O(n^2) is bad
> for a sorting algorithm, and O(n lg n) is pretty good.
> 
> Now, what about your student that knows *one* algorithm?

That's fine, anybody can look something up in a book.  I want
people working for me that can *think*, not just look it
up in the book.  Otherwise, how do you know when a
particular algorithm is appropriate for a particular problem?

When doing large projects, it's not just a matter of reaching
into the bag o' algorithms and pulling it out.  It takes
careful analysis, and the best way a student learns *that*
is to really go through the process of taking a problem and
seeing how the problem translates into data movement, etc.

What we're doing now is *sure* not working.

> : Someone who has "the feel" for two algorithms very strongly are
> : more likely to be able to extend that knowledge to creating new
> : algorithms.
> 
> Uhm, theoretically.  Somebody with only in-depth knowledge of run-
> length encoding is not very likely to come up spontaneously with
> Huffman or arithmetic compression.

Perhaps not "spontaneously", but you have them thinking about
compression issues.  "Thinking" is the key word, not just
memorizing an algorithm that they will forget after the final.

> : Computer Science is one of the few, if not only, sciences where a
> : student can derive all of it just by thinking.
> 
> Assuming the student doesn't have a deadline and all day to think for
> 40 years.  Many algorithms are obvious.  Insertion sort, for example,
> is what a human would do (if somewhat parallelized).  Quicksort, on
> the other hand, is nowhere near intuitive.  Be realistic.

I'm not saying everyone *does* derive all of it, but the
best programmers, even if they can't remember the exact
details of an algorithm, can rederive it by thinking
about the problem.

And I wouldn't say Quicksort is not intuitive, it is a logical
extension of recursive tree algorithms.  Not obvious, but
not unintuitive.  Lempel-Ziv or even the 'diff' algorithm
I might agree.

> Are you asserting that teaching software engineering instead of assembly
> language will somehow make the student unable to think?  Assembly
> language is a powerful tool best used by experts, not beginners.
> Beginners do not have the knowledge to use them properly, and tend
> to get caught in details and miss the big picture.  If you give an
> assignment of "implement quicksort in PC assembly", how much effort
> is spent in:
> 
> 1.  the algorithm
> 2.  I/O
> 3.  OS/platform intricacies
> 4.  debugging
> 
> ?  I would imagine your goal would be to maximize #1, which is why
> a HLL is better for the purpose.

Not only am I asserting, let me say in the strongest possible
terms that students are being graduated with CS degrees
that are unable to think.  I hate to keep harping on my
test, but on one particular hiring cycle, out of 50 applicants
49 were unable to create an algorithm for a problem they had
not seen before.  I hired the one guy, and he has been a great
success.

> : Truly understanding two algorithms is better than memorizing five
> : algorithms, because that is what *gives" the fundamental
> : understanding.
> 
> Fundamental understanding of RLE has little, if not nothing, to do
> with Huffman compression.  Fundamental understanding of quicksort
> has nothing to do with heapsort either.

That is simply not true.  Taking compression; if have done
thorough analysis of RLE, and understand the issues involved
in finding patterns (sequences of common bytes) and replacing
them with another encoded value, that is the basis for
more complex pattern matching/replacement.  If the student
is thinking, they will see that a large majority of the
input data is not being compressed, and this leads to wondering
if there is a general way to find more complex patterns in the
data.
 
> : > Teach a man an algorithm and some I/O routines to enter the input
> : > and display the output, then some routines to set up the stack,
> : > then some routines to initialize data,
> 
> : Yes, and wouldn't they truly understand I/O routines and stacks
> : after that?
> 
> They would, but would they understand the algorithm?

Sure; how much time do you think it takes to make one library
call to output data?  Push the parameters on the stack and
call 'printf'.  Big deal.

> : Yes, if your model is the brain-damaged 8086 model.  I personally
> : would use a 68000 to teach on because it's a nice straight-forward
> : orthogonal instruction set.
> 
> It doesn't matter.  You are burdening beginners with details that
> you could've avoided by using an HLL.  My school was contemplating
> teaching one freshman class Prolog as a first language and another
> Pascal, then switch in their second year to observe which was more
> effective.  It's too bad the experiment has practical problems,
> because it would be interesting to see if it's easier for a "recursive-
> minded" student to study iteration or the reverse.  In any case,
> you want to train students in problem solving, not why the OS requires
> value X in register Y.

I think you exaggerate the complexity of assembly.  This is like
saying "we want to train students in problem solving, not where
the commas go in the syntax."

-- Tim Behrendsen (tim@airshields.com)

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

[Szu-Wen Huang]

Tim Behrendsen (tim@airshields.com) wrote:

: That's fine, anybody can look something up in a book.  I want
: people working for me that can *think*, not just look it
: up in the book.  Otherwise, how do you know when a
: particular algorithm is appropriate for a particular problem?

Because I know the range of performance I can expect from a
class of algorithms, expressed in time complexities.  In fact,
I also know what problems have polynomial-time solutions, and
what *don't*.  None of the above comes from my expert knowledge
of assembly.  Are you saying if I don't know assembly I can't
pick an algorithm?

: When doing large projects, it's not just a matter of reaching
: into the bag o' algorithms and pulling it out.

Really?  When you want a sorting algorithm, I suppose you spend
a few weeks thinking about it first?  When you want compression,
surely you meditate in the mountains?  The industry has many
many solved problems, some free, some not free.  It *is*, as
a matter of fact, just a matter of knowing where to look - and
when to stop looking.  Again, none of these have to do with
assembly language.

: It takes
: careful analysis, and the best way a student learns *that*
: is to really go through the process of taking a problem and
: seeing how the problem translates into data movement, etc.

Data movement, sir, is not restricted to assembly language.
Assembly language, in fact, impedes the understanding of data
movement because of all the extraneous things that have to be
done to make the program work.

: What we're doing now is *sure* not working.

Because some students graduate without understanding algorithm
complexity, not because they graduate without learning assembly
language.

: > Uhm, theoretically.  Somebody with only in-depth knowledge of run-
: > length encoding is not very likely to come up spontaneously with
: > Huffman or arithmetic compression.

: Perhaps not "spontaneously", but you have them thinking about
: compression issues.  "Thinking" is the key word, not just
: memorizing an algorithm that they will forget after the final.

I never said anything about a student that forgot everything after
an exam.  I said, it is better to have *general* knowledge than
specific knowledge in intermediate levels.  My student would've
remembered that he was taught Huffman, which compressed better
than RLE.  Now, how Huffman works he may not immediately remember,
but he would know where to look it up, and that's all he needs.
This student with general knowledge can use books to his advantage,
while your RLE expert sits in a cubicle and tries to reinvent the
wheel.

: > Assuming the student doesn't have a deadline and all day to think for
: > 40 years.  Many algorithms are obvious.  Insertion sort, for example,
: > is what a human would do (if somewhat parallelized).  Quicksort, on
: > the other hand, is nowhere near intuitive.  Be realistic.

: I'm not saying everyone *does* derive all of it, but the
: best programmers, even if they can't remember the exact
: details of an algorithm, can rederive it by thinking
: about the problem.

Of course, but we're not talking about the best programmers.  We're
talking about beginners and intermediates.  The best programmers are
probably experts in several related fields - the language, the
platform, the algorithms, and the tools.  Now, without comprehensive
knowledge, it is better to be general than specific.

: And I wouldn't say Quicksort is not intuitive, it is a logical
: extension of recursive tree algorithms.  Not obvious, but
: not unintuitive.  Lempel-Ziv or even the 'diff' algorithm
: I might agree.

How long did it take you to come up with Quicksort armed with
the knowledge from implementing bubblesort in assembly?

: Not only am I asserting, let me say in the strongest possible
: terms that students are being graduated with CS degrees
: that are unable to think.

I don't disagree.  In fact, I'll give you an example.  My students
in introductory Pascal courses started programming with Turbo
Pascal.  If you learned programming earlier, you'll probably be
the kind that thinks hard about a problem, goes "eureka" one day
in the shower, and then sits down to type.  This generation, on
the other hand, sits right down and types away and turns in some
truly embarrassing solutions to simple problems.

I tend to blame the TV.  Point, however, is on my side.  The
students were given tools they could not use properly.  The
debugger that was so convenient for an expert actually destroyed
their will to think about a problem ahead of implementation.  Now
they just hack together some code and trace through it until they
get it right.  Assembly will have the same ills.  Firstly, they
distract the students and force them to implementation details
specific to the platform, and secondly is simply too powerful for
beginners to use properly.

: I hate to keep harping on my
: test, but on one particular hiring cycle, out of 50 applicants
: 49 were unable to create an algorithm for a problem they had
: not seen before.  I hired the one guy, and he has been a great
: success.

I gave the Vernier encoding as a hands-on exam.  You are of course
familiar with the:

   A B C D E F G ... Z
 A A B C D E F G ... Z
 B B C D E F G H ... A
 C C D E F G H I ... B
 .
 Z Z A B C D E F ... Y

table, wherein you ask for a plaintext string and a cipher key, then
index the row with plaintext and the column with the key to get the
ciphertext.

Trivial?  None of the ten or so students considered the fact that
the table can be expressed as a formula.  *All* of them stored this
table somewhere.  One particularly creative one even read the table
from a textfile.

I don't think this phenomenon was due to the fact that they didn't
know assembly.

: > Fundamental understanding of RLE has little, if not nothing, to do
: > with Huffman compression.  Fundamental understanding of quicksort
: > has nothing to do with heapsort either.

: That is simply not true.  Taking compression; if have done
: thorough analysis of RLE, and understand the issues involved
: in finding patterns (sequences of common bytes) and replacing
: them with another encoded value, that is the basis for
: more complex pattern matching/replacement.  If the student
: is thinking, they will see that a large majority of the
: input data is not being compressed, and this leads to wondering
: if there is a general way to find more complex patterns in the
: data.

Even if what you say is true (it's difficult, at best), I still don't
see how this student can be a more effective engineer than one who
has vague knowledge of both, but distinctly know that something *is*
better than RLE.

: > : > Teach a man an algorithm and some I/O routines to enter the input
: > : > and display the output, then some routines to set up the stack,
: > : > then some routines to initialize data,

: > : Yes, and wouldn't they truly understand I/O routines and stacks
: > : after that?

: > They would, but would they understand the algorithm?

: Sure; how much time do you think it takes to make one library
: call to output data?  Push the parameters on the stack and
: call 'printf'.  Big deal.

Then why not use C instead?  Realize that you are the one trying to
prove that assembly is better for teaching algorithms.  If you're
going to use library functions extensively, what's wrong with C
then?

: > It doesn't matter.  You are burdening beginners with details that
: > you could've avoided by using an HLL.  My school was contemplating
: > teaching one freshman class Prolog as a first language and another
: > Pascal, then switch in their second year to observe which was more
: > effective.  It's too bad the experiment has practical problems,
: > because it would be interesting to see if it's easier for a "recursive-
: > minded" student to study iteration or the reverse.  In any case,
: > you want to train students in problem solving, not why the OS requires
: > value X in register Y.

: I think you exaggerate the complexity of assembly.  This is like
: saying "we want to train students in problem solving, not where
: the commas go in the syntax."

Where the commas go is important, because it is a prerequisite to a
correct solution.  If we one day can build computer languages that
can understand humans better, perhaps we will not care where we
put commas.  Assembly is not complex per se, but is more complex
than HLLs to learn and read, and as such is counterproductive when
used as a tool to teach algorithms.

You still haven't proven why assembly is necessary, or at least
better.

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

[Tim Behrendsen]

Szu-Wen Huang <huang@mnsinc.com> wrote in article
<4ue5l3$frr@news1.mnsinc.com>...
> Tim Behrendsen (tim@airshields.com) wrote:
> 
> : That's fine, anybody can look something up in a book.  I want
> : people working for me that can *think*, not just look it
> : up in the book.  Otherwise, how do you know when a
> : particular algorithm is appropriate for a particular problem?
> 
> Because I know the range of performance I can expect from a
> class of algorithms, expressed in time complexities.  In fact,
> I also know what problems have polynomial-time solutions, and
> what *don't*.  None of the above comes from my expert knowledge
> of assembly.  Are you saying if I don't know assembly I can't
> pick an algorithm?

It's not a question of "knowing assembly" or not, it's a
question of understanding algorithms.  There's more to writing
programs than just knowing an algorithm is O(log n).  It
has to implemented efficiently.

> : When doing large projects, it's not just a matter of reaching
> : into the bag o' algorithms and pulling it out.
> 
> Really?  When you want a sorting algorithm, I suppose you spend
> a few weeks thinking about it first?  When you want compression,
> surely you meditate in the mountains?  The industry has many
> many solved problems, some free, some not free.  It *is*, as
> a matter of fact, just a matter of knowing where to look - and
> when to stop looking.  Again, none of these have to do with
> assembly language.

Maybe you're paid to sit and write sorting algorithms all day,
but where I sit, the world is not that simple.  Algorithms
have to fit into a cohesive whole, and it's often the case
that some algorithms are more appropriate in certain cases
than others.  Otherwise, everyone would always use Quicksort.

But, you're right that this has nothing to do with assembly.
The question is how to have students get a feel for how
algorithms actually work in the real world, and there is no
substitute for working with the real computer.

> : It takes
> : careful analysis, and the best way a student learns *that*
> : is to really go through the process of taking a problem and
> : seeing how the problem translates into data movement, etc.
> 
> Data movement, sir, is not restricted to assembly language.
> Assembly language, in fact, impedes the understanding of data
> movement because of all the extraneous things that have to be
> done to make the program work.

What extraneous things?  I don't understand why you think it's
so enormously complicated to use assembly.  Programmers used
to do it all the time, and they somehow managed to write
programs without suffering mental breakdowns.

> : What we're doing now is *sure* not working.
> 
> Because some students graduate without understanding algorithm
> complexity, not because they graduate without learning assembly
> language.

I agree with the first, but the reason they are not "getting"
algorithm complexity is because we're shrouding it in all
this abstract mystery.

> : > Uhm, theoretically.  Somebody with only in-depth knowledge of run-
> : > length encoding is not very likely to come up spontaneously with
> : > Huffman or arithmetic compression.
> 
> : Perhaps not "spontaneously", but you have them thinking about
> : compression issues.  "Thinking" is the key word, not just
> : memorizing an algorithm that they will forget after the final.
> 
> I never said anything about a student that forgot everything after
> an exam.  I said, it is better to have *general* knowledge than
> specific knowledge in intermediate levels.  My student would've
> remembered that he was taught Huffman, which compressed better
> than RLE.  Now, how Huffman works he may not immediately remember,
> but he would know where to look it up, and that's all he needs.
> This student with general knowledge can use books to his advantage,
> while your RLE expert sits in a cubicle and tries to reinvent the
> wheel.

You're making the assumption that we teach them RLE, and then
hide all the books from him.  My point is that packing
algorithms into their heads is not necessarily going to
teach them how to invent algorithms when they need them.

> : I'm not saying everyone *does* derive all of it, but the
> : best programmers, even if they can't remember the exact
> : details of an algorithm, can rederive it by thinking
> : about the problem.
> 
> Of course, but we're not talking about the best programmers.  We're
> talking about beginners and intermediates.  The best programmers are
> probably experts in several related fields - the language, the
> platform, the algorithms, and the tools.  Now, without comprehensive
> knowledge, it is better to be general than specific.

But we can learn from the best programmers about how their
thought processes work.  Again, the most important thing is
to get the students "thinking like programmers".

> : And I wouldn't say Quicksort is not intuitive, it is a logical
> : extension of recursive tree algorithms.  Not obvious, but
> : not unintuitive.  Lempel-Ziv or even the 'diff' algorithm
> : I might agree.
> 
> How long did it take you to come up with Quicksort armed with
> the knowledge from implementing bubblesort in assembly?

I was introduced to Quicksort before I had the chance to
invent it myself. :)

> : Not only am I asserting, let me say in the strongest possible
> : terms that students are being graduated with CS degrees
> : that are unable to think.
> 
> [snip]
> I tend to blame the TV.  Point, however, is on my side.  The
> students were given tools they could not use properly.  The
> debugger that was so convenient for an expert actually destroyed
> their will to think about a problem ahead of implementation.  Now
> they just hack together some code and trace through it until they
> get it right.  Assembly will have the same ills.  Firstly, they
> distract the students and force them to implementation details
> specific to the platform, and secondly is simply too powerful for
> beginners to use properly.

Don't get me started about debuggers... I think in certain
ways debuggers have lowered productivity rather than
raised it.

>[snip]
> Trivial?  None of the ten or so students considered the fact that
> the table can be expressed as a formula.  *All* of them stored this
> table somewhere.  One particularly creative one even read the table
> from a textfile.
> 
> I don't think this phenomenon was due to the fact that they didn't
> know assembly.

Look, it's not so much that I love assembly so much, but I
think a much more basic step-by-step approach works better
than the overly-abstracted approach that's currently in vogue.
Assembly just seems to be most straightforward method at
getting to the fundamentals of going on.  I wouldn't be completely
opposed to an "idealized" assembly that was interpreted or
something.

I just want students to get a better feel for what the computer
really does.

> : > Fundamental understanding of RLE has little, if not nothing, to do
> : > with Huffman compression.  Fundamental understanding of quicksort
> : > has nothing to do with heapsort either.
> 
> : That is simply not true.  Taking compression; if have done
> : thorough analysis of RLE, and understand the issues involved
> : in finding patterns (sequences of common bytes) and replacing
> : them with another encoded value, that is the basis for
> : more complex pattern matching/replacement.  If the student
> : is thinking, they will see that a large majority of the
> : input data is not being compressed, and this leads to wondering
> : if there is a general way to find more complex patterns in the
> : data.
> 
> Even if what you say is true (it's difficult, at best), I still don't
> see how this student can be a more effective engineer than one who
> has vague knowledge of both, but distinctly know that something *is*
> better than RLE.

Because the student is thinking about compression, rather than
being spoon-fed the information from a book or the teacher.
When the get into the real world, this thought process will
stay with them when they begin to need to break down much
more complex problems into algorithms.

> : Sure; how much time do you think it takes to make one library
> : call to output data?  Push the parameters on the stack and
> : call 'printf'.  Big deal.
> 
> Then why not use C instead?  Realize that you are the one trying to
> prove that assembly is better for teaching algorithms.  If you're
> going to use library functions extensively, what's wrong with C
> then?

Using library routines to do simple I/O tasks does not take
away from the learning experience of the algorithm.  Somehow
input and output have to happen, and I see no reason to burden
the student with problems that are not relevent to what they
are trying to learn.

> : I think you exaggerate the complexity of assembly.  This is like
> : saying "we want to train students in problem solving, not where
> : the commas go in the syntax."
> 
> Where the commas go is important, because it is a prerequisite to a
> correct solution.  If we one day can build computer languages that
> can understand humans better, perhaps we will not care where we
> put commas.  Assembly is not complex per se, but is more complex
> than HLLs to learn and read, and as such is counterproductive when
> used as a tool to teach algorithms.
> 
> You still haven't proven why assembly is necessary, or at least
> better.

Again, I go back to the fact that what we're doing now is
not working, based on my experience (and you admitted to
above).  What are we doing now?  We are teaching students at
an extremely high level of abstraction.

Since this does not seem to be giving the students the
critical thinking capabilities, what would?  I think that
more emphasis on the "fetch-and-execute" fundamentals would
force the students to think more procedurally and less
abstractly.

Not to be repetitious with this example, but I look at how EEs
are taught.  They begin by learning the fundamental components;
resisters, capacitors, ohm's law, etc.  They seem to me to be
much better prepared to do real work than CS graduates, and I
think it's because of the early emphasis on the fundamentals.

-- Tim Behrendsen (tim@airshields.com)

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

[Szu-Wen Huang]

Tim Behrendsen (tim@airshields.com) wrote:
[snip]
: But, you're right that this has nothing to do with assembly.
: The question is how to have students get a feel for how
: algorithms actually work in the real world, and there is no
: substitute for working with the real computer.

Maybe we could just short-circuit this prolonged discussion to why
HLLs cannot help you teach students and why assembly is necessary.

: > Data movement, sir, is not restricted to assembly language.
: > Assembly language, in fact, impedes the understanding of data
: > movement because of all the extraneous things that have to be
: > done to make the program work.

: What extraneous things?  I don't understand why you think it's
: so enormously complicated to use assembly.  Programmers used
: to do it all the time, and they somehow managed to write
: programs without suffering mental breakdowns.

I didn't say "enormously complicated".  I said, "extraneous".
Knowledge a beginner does not *need* is likely to confuse and
impede more than help.

: > : What we're doing now is *sure* not working.

: > Because some students graduate without understanding algorithm
: > complexity, not because they graduate without learning assembly
: > language.

: I agree with the first, but the reason they are not "getting"
: algorithm complexity is because we're shrouding it in all
: this abstract mystery.

That's your assertion.  An equally valid one is as I explained,
that the least experienced instructors get assigned to beginners.

[snip]
: But we can learn from the best programmers about how their
: thought processes work.  Again, the most important thing is
: to get the students "thinking like programmers".

An expert programmer knows when rules can be broken.  Beginners
do not have the knowledge to make that decision.  You simply cannot
think like an expert until you are one.

[snip]
: Don't get me started about debuggers... I think in certain
: ways debuggers have lowered productivity rather than
: raised it.

Precisely.  Giving the beginner too much impedes them rather than
develops them.

[snip]
: I just want students to get a better feel for what the computer
: really does.

And the risk, as we pointed out, is that the percentage of
attention they spend on the algorithm itself is actually lowered.

: Because the student is thinking about compression, rather than
: being spoon-fed the information from a book or the teacher.
: When the get into the real world, this thought process will
: stay with them when they begin to need to break down much
: more complex problems into algorithms.

Babies are spoon-fed for a very good reason, and that is because
they don't know what to eat.  We don't send babies into the real
world, just as we don't (hopefully) send beginners into the real
world.  A 15 year old might be advised that premarital sex is
"bad" because of responsibilities, diseases, et al, but an 8 year
old that asked is probably just answered with "it's bad."  You
confuse the 8 year old when you start talking about AIDS.

[snip]
: Using library routines to do simple I/O tasks does not take
: away from the learning experience of the algorithm.  Somehow
: input and output have to happen, and I see no reason to burden
: the student with problems that are not relevent to what they
: are trying to learn.

Precisely the reason to stay away from assembly.

[snip]
: > You still haven't proven why assembly is necessary, or at least
: > better.

: Again, I go back to the fact that what we're doing now is
: not working, based on my experience (and you admitted to
: above).  What are we doing now?  We are teaching students at
: an extremely high level of abstraction.

That's false dichotomy.  Ineffective teaching of HLL does not
prove that assembly will be effective.

[snip]
: Not to be repetitious with this example, but I look at how EEs
: are taught.  They begin by learning the fundamental components;
: resisters, capacitors, ohm's law, etc.  They seem to me to be
: much better prepared to do real work than CS graduates, and I
: think it's because of the early emphasis on the fundamentals.

Another false example.  I had two EE courses as a CS undergrad,
and we skipped most of that without hampering my ability to do
logic design.  In fact, my CS education was far more useful to
me when working with gates than my EE education.  I didn't need
to know how transistors made up a gate in order to assembly
several gates into an adder.  In fact, I had forgotten totally
how transistors work, yet I can still build an adder if you tell
me which symbol means NAND and NOR (the fundamentals).

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

[Tim Behrendsen]

Szu-Wen Huang <huang@mnsinc.com> wrote in article
<4uioj0$ptn@news1.mnsinc.com>...
> Tim Behrendsen (tim@airshields.com) wrote:
> [snip]
> 
> : > Because some students graduate without understanding algorithm
> : > complexity, not because they graduate without learning assembly
> : > language.
> 
> : I agree with the first, but the reason they are not "getting"
> : algorithm complexity is because we're shrouding it in all
> : this abstract mystery.
> 
> That's your assertion.  An equally valid one is as I explained,
> that the least experienced instructors get assigned to beginners.

So, given this theory, what do EE students seem so much better
prepared than CS students?  I just don't see the same level of
mediocrity being complained about from the EE community.

I think it's because EE students are taught exactly the way that
I've been describing, and in fact, most subjects are taught the way
I've describing.

-- Tim Behrendsen (tim@airshields.com)

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

[some days weren't there at all]

Szu-Wen Huang wrote:
[speaking about the benefit of knowing one/two algorithms deeply
vs. knowing five/six more generally]
>  No, because I know
> which book to look them up in, and that's exactly what books are for.
> The important thing, however, is that I remember that O(n^2) is bad
> for a sorting algorithm, and O(n lg n) is pretty good.
> 
> Now, what about your student that knows *one* algorithm?
	This touches on an interesting point..I'm inclined to believe 
that the _mathmatical_/theoretical training behind the coding exercises 
might make a bit of a difference in how much is retained or understood. 
It doesn't matter how many sorting algorithms I can code, or how many 
different times I can memorize if I don't know where they 'fit' in the 
overall picture. This sort of training should be language-independent.
	I'm taking a CS class now; freshman-level stuff(I hope). The 
professor showed us today _why_ a comparison-based sorting algorithm 
can't take fewer than O(n log n) steps. Maybe I'm a twisted, 
academic-inclined person, but I acutally found the proof interesting. 
Maybe I would go so far as to say _beautiful_. He managed to present it 
in a straightforward way, w/o needing mathmatical notation, in such a 
way that it became obviously correct. That's independent of language.
	 
 
[responding to comment about all of CS being 'intuitive']
>  Many algorithms are obvious.  Insertion sort, for example,
> is what a human would do (if somewhat parallelized).  Quicksort, on
> the other hand, is nowhere near intuitive.  Be realistic.
	I would submit that recursive solutions require a different sort 
of intuition than the normal. At least it seems that way to me. If I'm 
looking to solve a problem recursively, I'll (now) naturally think about 
ways to split the problem set in half to minimize work. Why? Because 
I've been exposed to the idea.
	It seems to me that this kind of intuition can be developed. In 
my own case, early experience with Scheme (thank you, Mr. Grillmeyer), 
has led to a _much_ better grasp of recursion and recursive tree 
structures. I honestly think it was one of the best preparations I could 
have had...although I am the first to admit that I can't really back up 
that statement. :-)
	In any case, building/reinforcing these patterns of thought 
should be very important. I want to get to the point where QuickSort 
*is* intuitive, simply because, well, "it has to be that way". It's that 
kind of visceral understanding, coupled with the ability (when 
necessary) to back it up by referring to sound justification, which 
helps on the programming projects I am compelled to do. When I can't 
produce it, I flounder. 
	
[apologies for cutting the previous poster out of this post]
[back-and-forth about assembler vs. HLL]
> It doesn't matter.  You are burdening beginners with details that
> you could've avoided by using an HLL.  
	Um, just as an aside, I do not know assembler, and I do not 
presume to comment on its complexity or suitability for CS instruction, 
but many thanks to whomever posted the gcc -S switch. I tried it on one 
of my current C++ source files, and the result was, well, interesting. I 
understood little of it, but I spent a very small amount of time, and am 
unfamiliar with the conventions of the language (what's an .fstab? file 
system table?).
	At least I can look at the assembler output now. Never knew I 
could do that before. Thanks.

>My school was contemplating
> teaching one freshman class Prolog as a first language and another
> Pascal, then switch in their second year to observe which was more
> effective.  
	Out of curiosity, why Prolog? I was taught that it represents a 
different paradigm/model/whatever from both functional and imperative 
programming; sort of "off by itself". It's not a language I know much 
about. One more thing to do in the next couple years, I guess. :-)
	  	

>It's too bad the experiment has practical problems,
> because it would be interesting to see if it's easier for a "recursive-
> minded" student to study iteration or the reverse. 
	Personally, I think the form/paradigm of the language being 
studied, as well as what can and cannot be expressed, would have a much 
deeper effect on coding style and programming practice. The first 
language I studied academically (I refuse to count BASIC as my 'first 
language'!) was Scheme. It's a wondefully expressive and functional way 
to do things, or at least it _appears this way to me_ because I learned 
the concepts of programming by working with it. I know it has had a 
profound effect upon my understanding of recursion, and undoubtedly an 
influence on my coding style.
	I've gone on to Pascal, and now C++, and have had to adjust 
accordingly. Making the transition to Pascal was more than just studying 
iteration (actually, there's a (do construct in Scheme...not 
reccomended, but it works) - it required a complete change in 
understanding of what a function is and how it works. I remember one 
project when I tried to pass functions as arguments...and did not get 
particularly far. Of course, now, with C++, I can do this. I also have 
operator overloading. However, I'm trying to be a good C++ citizen and 
concentrate on this funny objet-oriented concept. :-) 
	
> In any case,
> you want to train students in problem solving, not why the OS requires
> value X in register Y.
	Any programming assignment in any language will require a great 
degree of problem solving. I spent/am spending far, far, far too much 
time tracking down and squashing bugs, no matter what language I have/am 
program(ming) in. Some of these are syntax errors, but far more are 
simply not thinking out my algorithm completely enough. Garbage in, 
garbage out...
	Again, I do not have the pleasure of being acquainted with 
assembler, but it seems that a student will simply adapt to the 
landscape of whatever language is his/her first and then use that to 
solve any proceeding problems. The question of "What language to learn 
first?" then becomes "What do you want your mind to look like?" If 
you've got a hammer...

-David Molnar

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

[Mike Rubenstein]

huang@mnsinc.com (Szu-Wen Huang) wrote:

> Tim Behrendsen (tim@airshields.com) wrote:
> : Szu-Wen Huang <huang@mnsinc.com> wrote in article
> : <4ubnhr$714@news1.mnsinc.com>...
> 
> : > 1.  Being able to write algorithm X in assembly doesn't make you
> : >     understand the algorithm better.  It makes you understand whatever
> : >     platform du jour your school uses better.
> : > 2.  Vaguely understanding 5 algorithms is far better than understanding
> : >     one or two fully.  The primary objective of algorithms courses is
> : >     to produce students that can *choose* which algorithm to use,
> : >     not to produce students who can memorize one or two algorithms.
> : >     In fact, there's rarely a programmer more dangerous than one that
> : >     has no broad knowledge of algorithms.
> 
> : My point is someone who has "vaguely" learned five algorithms has
> : simply memorized them, and learned nothing about the general
> : principles of how algorithms are created.
> 
> No, your point was writing an algorithm in assembly helps to understand
> it fully.  I'll be my own case in point.  I remember most sorting
> algorithms vaguely, and I probably could not implement all of them
> off the top of my head.  Does that hamper me?  No, because I know
> which book to look them up in, and that's exactly what books are for.
> The important thing, however, is that I remember that O(n^2) is bad
> for a sorting algorithm, and O(n lg n) is pretty good.

But that is not always true.

A number of years ago I developed a program that had to do a large
number of sorts with the following characteristics:

	1.  The mean number of items to be sorted was about 5.  In a 
	    test sample of a million cases, the larges number of items
	    to be sorted was 35.

	2.  The items were usually in order.  In the test sample, 90% 
	    were in order, and most of the rest were in order except 
	    for a single interchange of adjacent items.  Only 8 were 
	    out of order by more than three interchanges or required 
	    interchanges of nonadjacent items.

Care to try this with quicksort?  or heapsort?  A good old O(n^2)
insertion sort works quite nicely.


Michael M Rubenstein

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

[Szu-Wen Huang]

Mike Rubenstein (miker3@ix.netcom.com) wrote:
: huang@mnsinc.com (Szu-Wen Huang) wrote:
[snip]
: > The important thing, however, is that I remember that O(n^2) is bad
: > for a sorting algorithm, and O(n lg n) is pretty good.

: But that is not always true.

Of course not, that's why we study best case, average case, and
worst case performances of both time and space of each algorithm.

: A number of years ago I developed a program that had to do a large
: number of sorts with the following characteristics:
[snip]
: Care to try this with quicksort?  or heapsort?  A good old O(n^2)
: insertion sort works quite nicely.

Which is why we examine what causes best- and worst-case behaviors
of each algorithm.  Without assumption on the inputs (and that is
frequently the case), the general knowledge that "quicksort is
better than insertion sort" holds valid.  With additional information
(such as your mostly partially sorted data), what we know about the
best case of insertion sort *and* what we know about how quicksort
performs on sorted input leads us to the correct solution.  In fact,
the general knowledge that many practical quicksort algorithms
switch to insertion sort when partitions are small is already a
most obvious hint to help arrive at the proper solution.

All this to say, assembly language still isn't necessary to understand
algorithms.

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

[Richard Chiu]

miker3@ix.netcom.com (Mike Rubenstein) writes:
>But that is not always true.

>A number of years ago I developed a program that had to do a large
>number of sorts with the following characteristics:

>	1.  The mean number of items to be sorted was about 5.  In a 
>	    test sample of a million cases, the larges number of items
>	    to be sorted was 35.

>	2.  The items were usually in order.  In the test sample, 90% 
>	    were in order, and most of the rest were in order except 
>	    for a single interchange of adjacent items.  Only 8 were 
>	    out of order by more than three interchanges or required 
>	    interchanges of nonadjacent items.

>Care to try this with quicksort?  or heapsort?  A good old O(n^2)
>insertion sort works quite nicely.

By the same thread of reasoning, a program that does nothing but
reture the inputs will be the best algorithm for sorting if the 
numbers are already sorted. (Which is true!)

Richard

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

[Lawrence Kirby]

In article <rchiu.840255046@popeye.cs.iastate.edu>
           rchiu@cs.iastate.edu "Richard Chiu" writes:

>miker3@ix.netcom.com (Mike Rubenstein) writes:
>>But that is not always true.
>
>>A number of years ago I developed a program that had to do a large
>>number of sorts with the following characteristics:
>
>>       1.  The mean number of items to be sorted was about 5.  In a 
>>           test sample of a million cases, the larges number of items
>>           to be sorted was 35.
>
>>       2.  The items were usually in order.  In the test sample, 90% 
>>           were in order, and most of the rest were in order except 
>>           for a single interchange of adjacent items.  Only 8 were 
>>           out of order by more than three interchanges or required 
>>           interchanges of nonadjacent items.
>
>>Care to try this with quicksort?  or heapsort?  A good old O(n^2)
>>insertion sort works quite nicely.
>
>By the same thread of reasoning, a program that does nothing but
>reture the inputs will be the best algorithm for sorting if the 
>numbers are already sorted. (Which is true!)

However it wasn't stated that the numbers were already in order, just
*usually* in order. It may also mean that in cases where items aren't
exactly in order they are still nearly ordered.

-- 
-----------------------------------------
Lawrence Kirby | fred@genesis.demon.co.uk
Wilts, England | 70734.126@compuserve.com
-----------------------------------------