21 Jun
2004
21 Jun
'04
3:46 p.m.
On Mon, 21 Jun 2004, William Donzelli wrote:
Well, the administrators are certainly not big fans of it.
"Why teach programming - you can BUY any program that you need."
It is not just Microsoft. Most software these days is
bloated. Yes, I
think it is extreme, and I really have to wonder just what these
programmers are doing with all of that code. The truth of the matter is
that they are not being paid to write compact, efficient code. They are
being paid to write nice looking programs in a short amount of time, with
the knowledge that the hardware resources will just get bigger and better,
week after week. Nice looking programs make money, not code efficient
ones. Programs that ship on time (or nearly) make money, not ones still
"in the lab" being optimized like crazy.
That's right
But a GOOD programmer writes code that needs less optimization
than a poor programmer who writes code that needs significant
later optimization.
This is what the industry wants, so this is what the
schools teach.
We do, indeed, get higher enrollment in C++ than in Assembly
Language.
When my C
students take an Assembly Language course,
there is often a visible improvement in their C code.
Probably - in fact I would
hope so. I am not against learning assembly. It
would be great if all CS and CE kids did, however I can see it falling
from grace simply due to "almost-obsolecence". On a side note, about your students - it could be
simply because they are
just more experienced. My C improved greatly after taking a Graphics
class.
No question that simple experience is a major factor.
A couple of times, I've had a C class one semester, and
then they took various other courses the next semester,
and then came back to me for the Data Structures And Algorithms
course. Those who had taken Assembly Language seemed to
have the most improvement, followed by other programming
languages, including C++ and Java, with the least improvement
from those who did not have a programming class, such
as
either no CS classes, or applications or networking classes.
But I never had a sufficient sample size, nor adequate
objective measures to be able to draw significant conclusions.
... and the choices of topics to specialize in in each
course could easily have as much influence as what the course was.
This fall, I get to teach Assembly Language again! (after 2 years)
They've scheduled it for Saturday morning, which sucks,
but it's still worth it.
I need to make some decisions about some of the content.
Should I include discussion of the .Net IL assembler?
How much on other kinds of processors? (RISC)
How much time should I spend on interrupt handlers, v
file handling?
How much time should I spend on coupling assembly language
subroutines with high level languages?
How much on using assembly language knowledge to debug
high level language problems?
Should I get into writing assembly language stuff that
runs as real Windoze applications, or stick to DOS based stuff?
--
Grumpy Ol' Fred cisin(a)xenosoft.com