[Scott Dorsey]

Les Cargill wrote:
Scott Dorsey wrote:

I see folks graduating from CS programs without any real programming skills
and without good algorithm analysis skills... and I thought that was much of
the point of the CS program in the first place?

It went the way of EE grads being able to solder.

I don't think that EVER existed.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

[Carey Carlan]

Les Cargill wrote in
:

and programmers have
been running out of CPU since Moore himself was involved.

I'm a bit tounge in cheek, but this is like saying an Arctic
expedition failed because they ran out of food. That's certainly
what happens, but there's more to it than just that.

You are jumping to the conclusion that if a programmer runs out of
memory he just gives up.

All the effort devoted in previous generations (and I was in some of
that) to speed and efficiency were done to make up for the lack of
cycles and space. When the programmer ran out of CPU or memory, THEN is
when he started devoting time and effort to making it smaller and
faster. Everything started with a reasonable efficiency level, but the
real crunch only came when we ran out of CPU or RAM.

Modern demands have changed. In the majority of my Windows
applications, my code is running for maybe 20% of the time. The rest of
the time Windows is in control. Update the screen? Call Windows. Write
to disk? Windows won't let me do that directly.

In my office, the efficiency required now is not efficiency of code--
it's efficiency of delivery. If I don't get task X done by date Y, I
may not eat on day Z (not quite that severe, but you get the idea).

I design my code. I run my code. I get my code operational, THEN can I
find the bottlenecks and fix them. Sometimes I have to wait for the
user to get the code to see what parts are used and what parts are
ignored. It is simply not cost effective to optimize everything all of
the time. Shaving 20% off code that only runs 10 milliseconds per
session is futile. OTOH, leaving code unoptimized that runs for seconds
or minutes can lose a contract or a client.

As a side note, most of the explosive growth in application size is part
of two separate evolutions. User interface design is growing
increasingly complicated as each generation of Windows offers more
screen widgets. Applications that use massive processing and memory
(such as DAWs and video) that were impossible a generation or two ago
are now growing down into smaller and smaller desktop computers.
Designing code for interface requires a thousand little routines that
fit into Windows here and there answering event calls and queuing
messages. The math portions of super-streaming jobs like audio and
video are coded in optimized compilers. Sure, I must design well at the
component level, but for bits and bytes, the compiler will override me.

In neither of those two worlds, the interface or big math, can I do much
to optimize my world beyond making simple, straightforward design
without excess baggage.

Time for me to get off my soapbox.

[Carey Carlan]

Les Cargill wrote in
:

I usually wait the roughly ten years for those to be packaged in
something like Tcl/Tk before I bother with them. I messed around
with MASM32 for a while; great fun for Letwin style 'Doze stuff, but
that's about it. But 'Doze as a lifestyle choice ( and it is that)
was never an option.

I think I've found our point of division. I create Windows applications
exclusively and create a retail product that sells on the basis of looks
and first impression (who reads feature lists anymore?). I get few design
specs, no interface specs, don't know exactly who my user will be, and have
to design to a ridiculously bullet-proof (interface) level.

The part that keeps my design efficient is that I also have to support the
product. Does wonders for my structured design and clear documentation.

Applications that use massive processing and memory
(such as DAWs and video) that were impossible a generation or two ago
are now growing down into smaller and smaller desktop computers.

About '05, that simply was a solved problem. If a P4 wouldn't do it,
you were doing it wrong.

But the scale is changing. My friend with the SOTA 8 CPU Apple still
renders his video files overnight. Desktops continue their inevitable
growth line toward supercomputers.

I have read you for years, and never known any of this about you.
Thanks.

How do you think I can pay for all this cool audio gear?