[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Low-level vs. High-level programming (was My First Computer)
"Kevin Lawton" <kepla@btinternet.com> wrote in message
news:bcja6o$nhs$4@hercules.btinternet.com...
> 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 ?
Let me first state that most of my programming anymore is for tiny embedded
machines that has extremely limited resources. Some of my projects don't
have RAM outside of the CPU registers. So I'm no stranger to assembly, C,
and going through all manner of flips and twists to shave off bytes from my
code.
That said...
For an awful lot of computing these days, the scarce resource that drives
development is time to market, and the related variable, development time.
When you're optimizing a variable like development time, a rational engineer
will make choices that fly in the face of the years of hard-learned lessons
from old timers. An example of this are digital cameras, most of which have
several megs of ram, as much flash as will fit in the case, an RTOS, and a
32-bit RISC CPU. Do you need this to move CCD data to flash? Heck no - but
if you have to support the USB and/or firewire interfaces and keep the
pixels on some sort of commonly used file system, and do it all in 6 months
with a team of 10 engineers, it makes sense to not scrimp on the hardware
and software baseline.
Java and .NET are great examples of providing the programmers slick ways to
leverage lots of existing libraries and tool chains to let them get
something out the door in a hurry. I doubt anyone would argue that XML is
the best way to store data, but it sure makes it convenient for the
programmer. CORBA and RMI are slick ways to invoke remote operations on
data, but are a lot more overhead than raw sockets and a well-defined packet
format.
Sure, this sort of development model is rather wasteful of resources. But
the resources it wastes are, in fact, the cheap resources - the transistors
and magnetic oxide particles that just keep getting cheaper and cheaper all
the time. The resources that it seeks to conserve are the expensive
resource - human labor.
Another advantage of the modern development tools ("lowering the bar for
developers", as the Microsoft guy phrased it) is that making the tools
easier to use means that expensive, highly-talented, programmers can be
supplemented (replaced?) with cheaper programmers. While this sounds
nefarious, it's not any different than the way the building trades have
moved in the last hundred years - there was a time when your carpenter was
also your architect and you paid highly for his skills. Now the architect
is highly specialized, expensive, and not as common in single-family
dwelling construction; the guy who hammers nails is barely trained, cheap,
and ubiquitous.
> 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'.
"Progress" really depends on where you're standing. If you're a highly
trained, talented developer then you might feel threatened by this trend to
"lower the bar". If you're the VP of Engineering at some start-up, you
might think it's a great step forward.
My advice: don't forget how to code in assembly and how to read core dumps,
but spend a few hours a month learning the new tools, too.
Kelly