Iteration vs. Recursion

[blmblm]

(e-mail address removed) said:


If CS grads at least knew a bit of CS, that would be a start.

(I accept that my sample set is probably statistically insignificant, but
they were *all* useless, and 100% is 100% in anybody's language!)

They're useless for your purposes, and they don't know any CS either?
That would *really* be a sad commentary on those bits of paper.

War stories of their uselessness appreciated, too, especially
if your comment extends to people with undergrad CS degrees.
I teach undergrad CS, and while I don't think every last one of our
graduates should be a good fit in a programming job, still, *some*
of them should be.

 

[Richard Heathfield]

(e-mail address removed) said:

War stories of their uselessness appreciated, too, especially
if your comment extends to people with undergrad CS degrees.
I teach undergrad CS, and while I don't think every last one of our
graduates should be a good fit in a programming job, still, *some*
of them should be.

I'm sure your crop is better than average, as they have you to teach them.
And of course I know there are plenty of bright CS bunnies out there
generally. It's just that I hardly ever seem to run into them myself -
except here on Usenet, of course.

Maybe the bright ones are bright enough to know to avoid me.

 

[blmblm]

(e-mail address removed) said:

I'm sure your crop is better than average, as they have you to teach them.

Actually I think they are a bit better than average, though I doubt
I can claim much if any of the credit for that -- we get some pretty
bright ones coming in. Some of them, by the time they graduate,
are pretty competent programmers, by the standards of an academic
anyway. Others -- well, we sometimes wonder how they managed to
forget so much of what they presumably learned in order to pass the
introductory programming classes. And don't get me started on the
range of mathematical backgrounds/skills ....

Possibly, though, I wasn't clear -- I wasn't so much claiming that
we *do* turn out a few who might be useful (though I hope that's
true) as saying that we *should* turn out a few such, and asking
for stories that would make it clearer what to avoid.

And of course I know there are plenty of bright CS bunnies out there
generally. It's just that I hardly ever seem to run into them myself -
except here on Usenet, of course.

Maybe the bright ones are bright enough to know to avoid me.

Anything's possible, but I'd claim that the bright ones are smart
enough to recognize the value of hanging around someone knowledgeable
if irascible.

 

[Richard Heathfield]

(e-mail address removed) said:

Possibly, though, I wasn't clear -- I wasn't so much claiming that
we *do* turn out a few who might be useful (though I hope that's
true) as saying that we *should* turn out a few such, and asking
for stories that would make it clearer what to avoid.

Well, for starters, either teach them how to program or tell them not to
apply for programming jobs.

Seriously, it's not my place to teach you how to teach. But IF IT WERE, then
I'd suggest the following:

Make sure they have a thorough understanding of an abstract machine, to the
extent that they can write non-trivial machine code programs in it. An
8-bit machine will be fine - 256 bytes of RAM ought to be enough for
anybody. 16 bits if you're feeling astoundingly generous. Make sure it has
a weird character collating sequence. I mean /really/ weird. (But keep '0'
through '9' contiguous and ascending.) If you're feeling really pleasant,
make it a two-byte machine with 11-bit bytes! Let them learn the meaning of
the word "architecture" (or "agriculture", as we read in clc recently!).

Set one of the really bright ones to write the machine code interpreter in
something like C or C++; then make sure it works, fix it if need be, and
use it forever afterwards for students to test their machine code programs
on. Then get someone else bright to write an assembler and debugger for it.

You're now in a position to teach programming at the dirty end - so make
sure they all understand about stacks and heaps and how memory works and
procedure calls, and so on ad nauseam. (Make sure they write enough machine
code programs to get the idea, before you let them graduate to assembly
language.)

This doesn't have to be hugely in-depth, but I am sick and tired of teaching
people what a pointer is, when they ought to KNOW what a pointer is. "Look,
you want this function to update the pointer, right? So you ought to be
passing a pointer-to-the-pointer into the function" + blank look = recipe
for a police caution.

Then, once they know all that, teach them programming from the clean end.
High level, in other words. You should find that they pick it up rather
easily, because they understand what's going on underneath.

 

[Charles Richmond]

Point taken, but ....

Do PhD programs in CS even claim to be producing good programmers?
I mean, I can easily imagine legitimate dissertation research that
involves no programming at all, and while you could argue that the
degree program should include a breadth requirement that includes
programming skills, hm .... No, I don't think I would (argue that,
beyond a minimal level that I suspect would still leave the person
in a state in which you would have to "teach 'em to program").

This reminds me of this math professor that a friend and I took
numerical analysis from in college. This sadistic prof did *not*
provide the students with computer accounts. Instead, you had to
"play" the computer and do all the iterative calculations by hand.
This required a *lot* of writing and created quite a pile of notebook
paper.

ISTM that using the computer is part of the point of such a course.

Fortunately, I had the good sense to drop the class...

 

[Jonathan Bartlett]

Nice article. I sent feedback. I don't agree that you should

keep variables constant throughout a program. That's what a
CONSTANT is for.

Constants don't work for such a thing. Constants must be (1) global and
(2) known at compile-time.

The point is not "constancy" as much as "single assignment only". There
is a subtle difference. A variable can get a new value, but only if it
is a new instance of that variable (i.e. from a new activation record).
Single assignment allows you to keep better control over your loops.
That way, at all times the derivation of any variable is easily
determinable.

Jon

 

[Jonathan Bartlett]

You're now in a position to teach programming at the dirty end - so make

sure they all understand about stacks and heaps and how memory works and
procedure calls, and so on ad nauseam. (Make sure they write enough machine
code programs to get the idea, before you let them graduate to assembly
language.)

This doesn't have to be hugely in-depth, but I am sick and tired of teaching
people what a pointer is, when they ought to KNOW what a pointer is. "Look,
you want this function to update the pointer, right? So you ought to be
passing a pointer-to-the-pointer into the function" + blank look = recipe
for a police caution.

Wow. This sounds exactly like what my book was intended to teach. This
is a shameless plug, but since you essentially stated the purpose and
outline of my book I thought it might be appropriate:

Programming from the Ground Up
http://www.cafeshops.com/bartlettpublish.8640017

It doesn't do machine code, but it covers a lot. However, when I teach
intro to programming at the local junior college, I have a "Machine
Language Game" to teach people how the computer works. I have a 16x16
board representing RAM, a whiteboard segmented into registers, a
one-line card for the display, and a stack of papers which tell how to
execute different command codes. I have one student be the data bus,
one student be the ALU, and one student be the instruction handler, and
one student be the graphics card. The instruction handler tells the
data bus to grab the next instruction. The data bus reads it from RAM
and comes back with the instruction and the next two bytes. The
instruction handler then looks up the first number in the instruction
code manual, and does what the manual says. The ALU does what the
instruction handler says, and the graphics card just watches some memory
and updates his output whenever it changes, based on the ASCII codes.

It really helps students figure out how the computer really works
underneath.

Jon

 

[Bradley K. Sherman]

code manual, and does what the manual says. The ALU does what the
instruction handler says, and the graphics card just watches some memory
and updates his output whenever it changes, based on the ASCII codes.

It really helps students figure out how the computer really works
underneath.

Which is why students should be learning C not Java in High School
AP courses.

--bks

 

[Andrew Poelstra]

Which is why students should be learning C not Java in High School
AP courses.

Java? In my school they teach VB. *shudder* I had to transfer to a digital
graphics course and learn Flash to avoid that. And according to the
curriculum, the most advanced topic they reached was array manipulation. In
a /grade 12/ cs course.

I have never seen anyone who learned how to program in school; good
programmers are the ones who read books.

 

[Andrew Poelstra]

Make sure they have a thorough understanding of an abstract machine, to the
extent that they can write non-trivial machine code programs in it. An
8-bit machine will be fine - 256 bytes of RAM ought to be enough for
anybody. 16 bits if you're feeling astoundingly generous. Make sure it has
a weird character collating sequence. I mean /really/ weird. (But keep '0'
through '9' contiguous and ascending.) If you're feeling really pleasant,
make it a two-byte machine with 11-bit bytes! Let them learn the meaning of
the word "architecture" (or "agriculture", as we read in clc recently!).

One weeks in clc is enough to figure that out. I personally think that no
computer programming class should have machines built in the past 15 years.
No, make that 20. Learning to code on a 8086 will teach people the meaning
of portability.

You're now in a position to teach programming at the dirty end - so make
sure they all understand about stacks and heaps and how memory works and
procedure calls, and so on ad nauseam. (Make sure they write enough machine
code programs to get the idea, before you let them graduate to assembly
language.)

I agree entirely. Any decent programmer should have some idea of how to
write machine code, or at least understand how it works in principle.

This doesn't have to be hugely in-depth, but I am sick and tired of teaching
people what a pointer is, when they ought to KNOW what a pointer is. "Look,
you want this function to update the pointer, right? So you ought to be
passing a pointer-to-the-pointer into the function" + blank look = recipe
for a police caution.

I spent a year working entirely in x86 assembler. I have never, ever, had
a problem figuring pointers out since. Machine language probably isn't
necessary.

Of course, if you are going to teach them Java, you might as well explain
that fairies memorize the contents of your variables so that you don't need
memory.

 

[CBFalconer]

(e-mail address removed) said:


Well, for starters, either teach them how to program or tell them
not to apply for programming jobs.

Seriously, it's not my place to teach you how to teach. But IF IT
WERE, then I'd suggest the following:

Make sure they have a thorough understanding of an abstract machine, to the
extent that they can write non-trivial machine code programs in it. An
8-bit machine will be fine - 256 bytes of RAM ought to be enough for
anybody. 16 bits if you're feeling astoundingly generous. Make sure it has
a weird character collating sequence. I mean /really/ weird. (But keep '0'
through '9' contiguous and ascending.) If you're feeling really pleasant,
make it a two-byte machine with 11-bit bytes! Let them learn the meaning of
the word "architecture" (or "agriculture", as we read in clc recently!).

Set one of the really bright ones to write the machine code interpreter in
something like C or C++; then make sure it works, fix it if need be, and
use it forever afterwards for students to test their machine code programs
on. Then get someone else bright to write an assembler and debugger for it.

You're now in a position to teach programming at the dirty end - so make
sure they all understand about stacks and heaps and how memory works and
procedure calls, and so on ad nauseam. (Make sure they write enough machine
code programs to get the idea, before you let them graduate to assembly
language.)

This doesn't have to be hugely in-depth, but I am sick and tired of teaching
people what a pointer is, when they ought to KNOW what a pointer is. "Look,
you want this function to update the pointer, right? So you ought to be
passing a pointer-to-the-pointer into the function" + blank look = recipe
for a police caution.

Then, once they know all that, teach them programming from the clean end.
High level, in other words. You should find that they pick it up rather
easily, because they understand what's going on underneath.

But you would clutter their pristine young minds with all this
detail, when all they need to know is the abstract properties of an
operation! Something like teaching the basic definitions of a
limit (difference arbitrarily small as things approach arbitrarily
near, or we can find an epsilon such that, etc.) to budding
mathematicians. Or even that hot gases expand and urge pistons or
other things to move to budding automotive engineers.

In all seriousness though, the fundamental teaching problem is when
and where to draw the line between detail and abstraction, and
persuade the student to choose the appropriate view. The lack
today of simple but complete systems, such as were built around the
8080, is a drawback. A stack is a detail, automatic storage is an
abstraction.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

 

[Ben Pfaff]

(e-mail address removed) said:


If CS grads at least knew a bit of CS, that would be a start.

I know some excellent computer scientists who are not
programmers. It is not what they do. Their papers read like
math papers. I could never do what they do, and I wouldn't try
to claim that I could.

For their part, I suspect that they wouldn't claim they are good
programmers either, at least not in languages like C. Perhaps
that's the real problem: people who claim to be what they are
not. But I wouldn't criticize computer scientists for not being
programmers, as long as they don't claim to be.

 

[Richard Heathfield]

Ben Pfaff said:

I know some excellent computer scientists who are not
programmers. It is not what they do. Their papers read like
math papers. I could never do what they do, and I wouldn't try
to claim that I could.

I take your point, but those people aren't applying for programming jobs,
so, for the purposes of the current discussion, they don't count.

 

[Keith Thompson]

I know some excellent computer scientists who are not
programmers. It is not what they do. Their papers read like
math papers. I could never do what they do, and I wouldn't try
to claim that I could.

For their part, I suspect that they wouldn't claim they are good
programmers either, at least not in languages like C. Perhaps
that's the real problem: people who claim to be what they are
not. But I wouldn't criticize computer scientists for not being
programmers, as long as they don't claim to be.

It reminds me of an Edsger Dijkstra quotation: "Computer science is no
more about computers than astronomy is about telescopes."

 

[birarai]

Take a look at www.monsterSDLC.com

 

[Richard Heathfield]

birarai said:

Take a look at www.monsterSDLC.com

....and you'll see a cartoon of an owl with a beach-ball stuck on his nose.
How is this relevant to our discussion of iteration vs recursion?

 

[David Lightstone]

But you would clutter their pristine young minds with all this
detail, when all they need to know is the abstract properties of an
operation! Something like teaching the basic definitions of a
limit (difference arbitrarily small as things approach arbitrarily
near, or we can find an epsilon such that, etc.) to budding
mathematicians. Or even that hot gases expand and urge pistons or
other things to move to budding automotive engineers.

In all seriousness though, the fundamental teaching problem is when
and where to draw the line between detail and abstraction, and
persuade the student to choose the appropriate view.

I thought Parnas resolved that circa the development innovation
modularization / incapsulation / data hiding.
Is a whole new bunch of programmers (and I know you are not one of them)
rediscovering the square wheel?

The lack
today of simple but complete systems, such as were built around the
8080, is a drawback. A stack is a detail, automatic storage is an
abstraction.

I do not consider that necessary to learn about systems. Laszlos's book
System View of the World will be adequate

 

[SM Ryan]

Apparently it is okay to go off topic if you are in the Elect.



#
# # > Richard Heathfield wrote:
# >> (e-mail address removed) said:
# >>
# >>> Possibly, though, I wasn't clear -- I wasn't so much claiming that
# >>> we *do* turn out a few who might be useful (though I hope that's
# >>> true) as saying that we *should* turn out a few such, and asking
# >>> for stories that would make it clearer what to avoid.
# >>
# >> Well, for starters, either teach them how to program or tell them
# >> not to apply for programming jobs.
# >>
# >> Seriously, it's not my place to teach you how to teach. But IF IT
# >> WERE, then I'd suggest the following:
# >>
# >> Make sure they have a thorough understanding of an abstract machine, to
# >> the
# >> extent that they can write non-trivial machine code programs in it. An
# >> 8-bit machine will be fine - 256 bytes of RAM ought to be enough for
# >> anybody. 16 bits if you're feeling astoundingly generous. Make sure it
# >> has
# >> a weird character collating sequence. I mean /really/ weird. (But keep
# >> '0'
# >> through '9' contiguous and ascending.) If you're feeling really pleasant,
# >> make it a two-byte machine with 11-bit bytes! Let them learn the meaning
# >> of
# >> the word "architecture" (or "agriculture", as we read in clc recently!).
# >>
# >> Set one of the really bright ones to write the machine code interpreter
# >> in
# >> something like C or C++; then make sure it works, fix it if need be, and
# >> use it forever afterwards for students to test their machine code
# >> programs
# >> on. Then get someone else bright to write an assembler and debugger for
# >> it.
# >>
# >> You're now in a position to teach programming at the dirty end - so make
# >> sure they all understand about stacks and heaps and how memory works and
# >> procedure calls, and so on ad nauseam. (Make sure they write enough
# >> machine
# >> code programs to get the idea, before you let them graduate to assembly
# >> language.)
# >>
# >> This doesn't have to be hugely in-depth, but I am sick and tired of
# >> teaching
# >> people what a pointer is, when they ought to KNOW what a pointer is.
# >> "Look,
# >> you want this function to update the pointer, right? So you ought to be
# >> passing a pointer-to-the-pointer into the function" + blank look = recipe
# >> for a police caution.
# >>
# >> Then, once they know all that, teach them programming from the clean end.
# >> High level, in other words. You should find that they pick it up
# >> rather
# >> easily, because they understand what's going on underneath.
# >
# > But you would clutter their pristine young minds with all this
# > detail, when all they need to know is the abstract properties of an
# > operation! Something like teaching the basic definitions of a
# > limit (difference arbitrarily small as things approach arbitrarily
# > near, or we can find an epsilon such that, etc.) to budding
# > mathematicians. Or even that hot gases expand and urge pistons or
# > other things to move to budding automotive engineers.
# >
# > In all seriousness though, the fundamental teaching problem is when
# > and where to draw the line between detail and abstraction, and
# > persuade the student to choose the appropriate view.
#
# I thought Parnas resolved that circa the development innovation
# modularization / incapsulation / data hiding.
# Is a whole new bunch of programmers (and I know you are not one of them)
# rediscovering the square wheel?
#
#
# >The lack
# > today of simple but complete systems, such as were built around the
# > 8080, is a drawback. A stack is a detail, automatic storage is an
# > abstraction.
#
# I do not consider that necessary to learn about systems. Laszlos's book
# System View of the World will be adequate
#
#
# >
# > --
# > "If you want to post a followup via groups.google.com, don't use
# > the broken "Reply" link at the bottom of the article. Click on
# > "show options" at the top of the article, then click on the
# > "Reply" at the bottom of the article headers." - Keith Thompson
# > More details at: <http://cfaj.freeshell.org/google/>
# > Also see <http://www.safalra.com/special/googlegroupsreply/>
# >
# >
#
#
#
#

 

[Richard Heathfield]

SM Ryan said:

Apparently it is okay to go off topic if you are in the Elect.

(a) The discussion is on-topic in, perhaps, three (maybe four) of the five
newsgroups that are carrying it, so I think your complaint is, to a certain
degree at least, rather misplaced.

(b) As somebody famous (Kaz?) once said, writing good, solid,
well-researched, interesting, helpful, *topical* articles for a newsgroup
is like putting florins (or dimes) in the bank - and indulging in off-topic
discussion is like taking out guineas (or dollars). Long-serving,
prolifically helpful, high-quality (and unpaid!) regulars earn a certain
(but by no means unlimited) amount of tolerance with regard to topicality.

(c) TINC.

 

[CBFalconer]

SM Ryan said:


(a) The discussion is on-topic in, perhaps, three (maybe four) of
the five newsgroups that are carrying it, so I think your complaint
is, to a certain degree at least, rather misplaced.

I was shocked, shocked I tell you, to see Ryan and his fouled up
quotation markers together with top-posting appear on
comp.programming. I thought I had him plonked everywhere.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>