Re: 6502 Programming Is Not Interested?

["Bill Garber" <willy46pa@comcast.net>]

Would anyone like to post the list of 12 words found in the
dictionary which were NOT used in Michael's previous post?

Thank you,

Just kidding Mike. I enjoy all of your posts. ;-)

Bill @ GarberStreet Enterprises };-)
Web Site - http://garberstreet.netfirms.com
Email - willy46pa@comcast.net

"Michael J. Mahon" <mjmahon@aol.com> wrote in message
20030810144705.24166.00001109@mb-m16.aol.com">news:20030810144705.24166.00001109@mb-m16.aol.com...
> Chris Morse wrote:
>
> >On Sun, 10 Aug 2003 04:32:42 GMT, "desiv" <desiv@attbi.com> wrote:
> >
> >>Now, there can be art in programming today.  There are some programmers
who
> >>are that good, and I'm sure you are one of those..  But any one who
programs
> >>or works with programmers knows that there are a LOT (as in huge
percentage)
> >>of bad point-and-click programmers out there.  People who learn 1 tool
(VB
> >>for instance) and drag and drop code.
> >
> >I have to admit this too Dave.  I do fully agree that the "art" of
> >programming is not dead.  The way I see it, back in the days of the
> >Apple II, a "real" program had to be developed by pretty much "real"
> >programmers.  Almost all commercial software was written in assembly,
> >which pretty much forced the programmer to have a decent idea of what
> >he was doing.
>
> (Actually, it is "desiv", not Dave, who is quoted above.)
>
> In my original post, I did not say that the art of programming was dead,
> I said that "the age of art and craft in programming is over".
>
> By that I meant that the standards by which programmers are judged
> and the goals that they are charged with by their employers have
> shifted from "take your time and get it right" to "get it working by
> the end of the week".  And this is economically (if not esthetically)
> justified by the rising cost of labor and the falling cost of hardware.
>
> A real craftsman today will usually be at odds with his programming
> team.  He will generally not be satisfied with the first way he tries
> to do something, but will want to measure the code's behavior and
> alter its design to improve it--often in radical ways.  (One of my
> favorite saying is: "The most underutilized design tool is the
> wastebasket."  ;-)
>
> The time pressure under which most commercial code is developed
> militates against the less predictable "learning process" whereby
> a problem is eventually solved with elegance, not brute force.
>
> Of course real software craftsmen still exist--thank goodness--but
> they are now considerably outside the mainstream of programming.
> Many are working on embedded systems and in other resource-
> constrained, high-value environments.
>
> >>Of course, there were bad programmers "back-in-the-day", but there's a
much
> >>higher percentage now.  Why?  It's easier to be a bad programmer now.
> >>Better tools, excess RAM and drive space.  It's very easy in todays
world to
> >>write bad sloppy bloated code and get away with it...
> >
> >Yes, it was harder to be a "bad" programmer before, if you were doing
> >it for a living and writing commercial software.  Commercial
> >applications were almost NEVER written in BASIC.
> >
> >I think, also, back in those days 20 years ago there were A LOT fewer
> >professional programmers than there are today.  Those few that did
> >program professionally 20 years ago most likely were keen and in tune
> >with their machines.
> >
> >Today, I am surprised when I discover how many placed employ
> >programmers who couldn't program out of a wet paper bag.  Visual Basic
> >is all they know and even then it's sloppy and inefficient.
> >
> >But there are a lot of programmers out there that are the complete
> >opposite, too.  It's more of a mix than it was before; today it's
> >easier to be sloppy and get away with it.
>
> I have been in system programming for many years, and I don't see
> "a lot" of code craftsmen.  I see a few--perhaps five out of a hundred--
> and that's among _system_ programmers!  If we extend the sample
> to _all_ programmers, I would be surprised if it's more than five in a
> thousand.
>
> The point is that programming has become an industry, driven by
> market pressures and the need for lots of "bodies".  This inevitably
> causes a shift in the distribution of skills.  Today, the few people
> who actually understand the meaning of code optimization on a
> multi-level cached, multi-execution-unit, pipelined machine are
> not writing application code.  They are (hopefully) writing the
> optimizers that will enable mainstream coders to get reasonably
> good code out of their compilers.  Sadly, much of the code fed
> _into_ those compilers is so naive as to make mere code
> optimization relatively worthless in the face of algorithmic
> inefficiency.
>
> Admittedly, it was a simpler world many years ago, when just
> a table of cycle counts would allow a programmer to know how
> his or her code executed.  Most optimization was done at one's
> desk with pencil and paper.  But some of the results were
> stunning in their elegance and efficiency.
>
> In the 60's, I could generally pick up any listing and, by reading,
> find clever things to appreciate in it, and perhaps add to my own
> bag of tricks.  Today, looking at random samples of code seldom
> produces admiration or learning--except perhaps by "bad example".
>
> Of course, there is still literate code around--there must be!  But
> it has become harder to find.  I hoped that the Open Source
> movement would bring more "great code" into the light, and
> perhaps it has, but the programmer's objectives have changed.
>
> The art of "doing more with less" has largely given way to
> the art of "doing more with lots more".  This is, I suppose,
> a natural consequence of Moore's Law--making human effort
> the constrained resource, and hardware resource relatively
> unconstrained.
>
> In the 70's we dreamed of constructing modular operating
> systems, with layered abstractions.  But while these were
> excellent design ideas, any _actually_ layered implementation
> gave up a big factor in efficiency for its structure.  Most systems
> were forced to adopt a quasi-monolithic implementation of the
> abstract, layered design, to obtain clean abstractions combined
> with run-time efficiency.
>
> Now, virtually all system implementations are based upon much
> deeper layered abstractions, and the consequent context-switching
> and calling overhead is simply taken for granted.  If the past is any
> guide, and if the code internal to each layer were efficient, this
> layering is costing almost a factor of ten in pathlength compared
> to a more monolithic implementation.
>
> But it is unlikely that the code in each layer is really efficient, and
> it would be a maintenance impossibility to have a "merged"
> implementation of a modern system.  We have concluded that
> the cost of modularity, however high, is a "sunk cost", and now
> cannot build systems without paying it.
>
> Ack!  All of this sounds like fogey-mode!  ;-)
>
> I enjoy the functionality (however fragile ;-) of modern systems,
> but still, from time to time, I wonder what these supercomputers
> we call PCs could do if programmed "on the metal".  Of course,
> the answer is "not much", since no "one" could produce enough
> code to make a difference (Linux supporters may object.  ;-)
> But it would be fun to send one back in time to see what
> wonders might ensue...
>
> -michael
>
> Check out amazing quality 8-bit Apple sound on my
> Home page:  http://members.aol.com/MJMahon/


---
This email ain't infected, dude!

Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.507 / Virus Database: 304 - Release Date: 8/4/03