Re: Low-level vs. High-level programming (was My First Computer)

["Joel Kolstad" <jkolstad71hatespam@yahoo.com>]

I agree with many of the comments here and wanted to add a few of my own:

-- As someone suggested, the problem seems to be that a lot of people who
ended up as programmers weren't really cut out for it in the first place,
but instead merely saw it as a 'not _too_ annoying' _JOB_ that paid
particularly well.  You can't really blame people for choosing programming
for that reason; the sad truth is that relatively few people (<5%?) have a
clear-cut idea of exactly what they'd like to do for a job and are
reasonably skilled in that area.
-- Consumer demand for 'high tech' goods far exceeds that which can be
produced only by the 'elite' designers out there, so -- while any company
would prefer to just have those elite employees -- reality steps in and
companies are forced to hire lesser-skilled workers and do the best they can
with them.  At that point it becomes very much a management issue.  I'm
firmly convinced that many average programmers can product high-quality code
with really good management, it's just that -- in some companies -- 
management isn't particularly good and sub-par results are considered
acceptable.
-- Having low-level assembly skills certainly is useful.  But you could take
it even further than that -- how many of the 'old school' 8 bit assembly
programmers are familiar with modern superscalar processor design these
days?  Where overall CPU performance is all about keeping the various
parallel execution modules within the CPU busy by avoiding data dependencies
and other forms of 'difficult to predict' execution?  With a supserscalar
CPU, often the optimal assembly code looks like a God-awful mess.  For,
e.g., digital signal processing routine, a good C compiler would probably
produce better code than someone coding with the 'linear' assembly language
mindset that the older RISC and single/multi-cycle CPUs used.  Someone
intimately familiar with the CPU in question still might very well be able
to do better than the C compiler, but at some point it comes down to a
question of: How much extra time does it require of the programmer to
produce an incremental gain in performance?  Most employeers probably figure
that by the time you need to spend more than a few hours to get another 1%
performance from your design, it's time to move on to the next project.
Additionally, keep in mind that in many pieces of software these days, the
CPUs are fast enough that the bottleneck is going to be, e.g., the hard
drive speed or the network link speed and the total CPU time consumed by the
program is almost negligible.  In any case, the point is that high-level
languages ostensibly allow programmers to not have to constantly keep
learning the ever more complex details of new processor architecture while
incurring only a 'small' (<20%?) reduction in performance relative to native
assembly coding.
-- The quote from Microsoft about .Net is disheartening but it does make
sense keeping the foregoing paragraphs in mind.  History has shown time and
time again that the 'average' programmer needs a fair amount of help in
producing solid code, and if this isn't coming someone from management, then
it might as well come from the tools.  I doubt Microsoft would ever attempt
to argue that the .Net languages are the most efficient (fastest) or produce
the smallest 'executable' (MIDL), but they would argue that given very
pragmatic 'weightings' from industrial concerns (the guys with $$$ who pay
MS), .Net looks pretty good.

---Joel Kolstad


"Kevin Lawton" <kepla@btinternet.com> wrote in message
news:bcja6o$nhs$4@hercules.btinternet.com...
> vector <root@localhost> wrote:
> | "White Flame (aka David Holz)" <whiteflame52@y.a.h.o.o.com> wrote in
> | message news:b3qo6h$5ar$1@barad-dur.nas.com...
> || "Really" <barryem@yahoo.com> wrote in message
> || 1c7cf088462765c2a0e63c17ceaa1ece@news.teranews.com">news:1c7cf088462765c2a0e63c17ceaa1ece@news.teranews.com...
> ||| Through a 35 year programming career (I'm retired now) there was
> ||| never a month where something didn't make me very glad to have that
> ||| assembly experience, even though I never actually used assembly
> ||| during some years.
> ||
> || Though I've only had a 10 year programming career (20 years of
> || programming experience) doing very high-level code, I can fully
> || agree.  You don't technically *need* to know low-level concepts in
> || order to create working code, but it certainly helps you do it
> || *well*, as well as helps in debugging and optimization.  When doing
> || wavelet graphics on a 68k Palm for a web browser, I did it all in
> || C++, but continually looked at the generated assembly code and
> || massaged the code to produce the optimum asm code from the compiler,
> || knowing how it works.
> |
> | Here's a fun quote from a Microsoft employee speaking of Visual
> | Studio .NET at a seminar I attended: "The more we can lower the bar,
> | the better we can enforce good coding practices."
>
> Sounds like typical M$ plonker-speak to me.   :-)
> Quite how was this guy thinking ?
>
> | I was both sickened and awed by the very idea that MS, by way of this
> | guy's statement, had essentially told me I am too stupid to be
> | trusted to be a programmer.
>
> I, too, am a reluctant user of recent high-level languages - having worked
> at first on assembler and then C. Fast, efficient, compact programs just
> don't seem to be the aim of programmers anymore. How else could you
explain
> Java ?
>
> | Worse, were I to replace "I am" with "the IT industry is" in the above
> | sentence, I'd actually agree with that statement right now.  I think
> | that's directly from where IT's current slump comes: normal people
> | (i.e., non-nerds) who were attracted to programming as a career
> | because they didn't want to be doctors or lawyers anymore, but just
> | didn't have the mindset for it.  At the core of all the layoffs,
> | downsizing, shakedowns, whatever, I think we're witnessing the
> | computer industry shake off the burden of having hired these people
> | that thought computer programming meant f��ball-tables, Sprite, and
> | snowboarding all day.
>
> Unfortunately, the industry also managed to shake off several of us who
can
> work in assembler and dump-crack when required.
> Unfortunately, 'progress' doesn't always seem to be accompanied by
> 'improvement'.
>
>
>