How far can stack [LIFO] solve do automatic garbage collection and prevent memory leak ?

[David Kastrup]

John Bokma <john at castleamber.com> writes:

> David Kastrup <dak at gnu.org> writes:
>
>> John Passaniti <john.passaniti at gmail.com> writes:
>>
>>> Amen!  All this academic talk is useless.  Who cares about things like
>>> the big-O notation for program complexity.  Can't people just *look*
>>> at code and see how complex it is?!  And take things like the years of
>>> wasted effort computer scientists have put into taking data structures
>>> (like hashes and various kinds of trees) and extending them along
>>> various problem domains and requirements.  Real programmers don't
>>> waste their time with learning that junk.  What good did any of that
>>> ever do anyone?!
>>
>> It is my experience that in particular graduated (and in particular Phd)
>> computer scientists don't waste their time _applying_ that junk.
>
> Question: do you have a degree in computer science?
>
> Since in my experience: people who talk about their experience with
> graduated people often missed the boat themselves and think that reading
> a book or two equals years of study.

I have a degree in electrical engineering.  But that's similarly
irrelevant.  I have a rather thorough background with computers (started
with punched cards), get along with about a dozen assembly languages and
quite a few other higher level languages.  I've had to write the BIOS
for my first computer and a number of other stuff and did digital
picture enhancement on DOS computers with EMM (programming 80387
assembly language and using a variant of Hartley transforms).

I have rewritten digital map processing code from scratch that has been
designed and optimized by graduated computer scientists (including one
PhD) to a degree where it ran twice as fast as originally, at the cost
of occasional crashes and utter unmaintainability.  Twice as fast
meaning somewhat less than a day of calculation time for medium size
data sets (a few 100000 of data points, on something like a 25MHz 68020
or something).  So I knew the problem was not likely to be easy.  Took
me more than a week.  After getting the thing to compile and fixing the
first few crashing conditions, I got stuck in debugging.  The thing just
terminated after about 2 minutes of runtime without an apparent reason.
I spent almost two more days trying to find the problem before bothering
to even check the output.  The program just finished regularly.

That has not particularly helped my respect towards CS majors and PhDs
in the function of programmers (and to be honest: their education is not
intended to make them good programmers, but to enable them to _lead_
good programmers).

That does not mean that I am incapable of analyzing, say quicksort and
mergesort, and come up with something reasonably close to a closed form
for average, min, and max comparisons (well, unless a close
approximation is good enough, you have to sum about lg n terms which is
near instantaneous, with a real closed form mostly available when n is
special, like a power of 2).  And I know how to work with more modern
computer plagues, like the need for cache coherency.

So in short, I have a somewhat related scientific education, but I can
work the required math.  And I can work the computers.

> Oh, and rest assured, it works both ways: people who did graduate are
> now and then thinking it's the holy grail and no body can beat it with
> home study.
>
> Both are wrong, by the way.

Depends.  In my personal opinion, living close to the iron and being
sharp enough can make a lot of a difference.

Donald Knuth never studied computer science.  He more or less founded
it.  As a programmer, he is too much artist and too little engineer for
my taste: you can't take his proverbial masterpiece "TeX" apart without
the pieces crumbling.  He won't write inefficient programs: he has the
respective gene and the knowledge to apply it.  But the stuff he wrote
is not well maintainable and reusable.  Of course, he has no need for
reuse if he can rewrite as fast as applying an interface.

-- 
David Kastrup