Re: Intro to Programming w/ Machine Language

From: Randy Howard (randyhoward_at_FOOverizonBAR.net)
Date: 02/27/05 

Date: Sun, 27 Feb 2005 19:55:28 GMT

In article <2UeUd.6667$MY6.5797@newsread1.news.pas.earthlink.net>,
randyhyde@earthlink.net says...
> We are talking about software that is being used by a *large* number
> of users. As the numbers increase, development cost asymptotically
> approaches zero. That's the whole point of the discussion -- a small
> amount of extra development time (up front) saves a tremendous
> amount of user time. Obviously, for low-volume software applications,
> this discussion does not apply.

If you want to save the world some time, outlaw Television. This
utopian dream of harnessing all this supposed horsepower sitting
in front of PC's playing solitaire and reading blogs is
underwhelming.
 
> And we *do* see a lot of people switching (for example) from
> IE to Firefox for a variety of reasons. Performance is one
> of them (security is another).

Security is the reason, performance is the pleasant surprise.
Subtle rendering bugs on some websites are the cost of admission.

> > Perhaps you'd like the whole world to think that if every line
> > of code isn't hand-tuned assembly then it's not good enough
> > to buy. I don't really care if vi is optimized for my AMD
> > 64-bit processor, because I can't type fast enough for it
> > to matter.
>
> Who said anything about assembly?

If you talk about not wasting time long enough, it is bound
to come up. Surely you of all people know this.

> the lack of performance in modern apps has *little* to do
> with the implementation language and just about *everything*
> to do with the attitude of the programmer writing the code.

WIth certain obvious exceptions for Java, giant applications
all written in scripting languages, etc., ok.

> If the programmer, from the offset, takes the attitude that
> performance is irrelevant, how can anyone be surprised when
> the software runs slow?

If I ever encountered a programmer that said "performance is
irrelevant" I would try to get them sent to Antarctica on
the next ship. I have yet to meet one of these in person,
yet some purportedly exist on Usenet.

> Conversely, if someone *is* concerned about performance,
> they could write their app in Java and still produce a
> useable piece of software.

It depends upon the app, but in general I agree. Since
"any time wasted" is evil and a moral imperative for the
programmer to expunge from the universe, then Java must
be killed. :-)

> When Java was first becoming popular, I remember reading
> a quote that said something to the affect of "Java is making
> my life miserable. When I write in C, I can get away with
> linear searches; when I write in Java, I have to use binary
> searches to get reasonable performance."

Bleh. I am sure you can find something stupid on almost
any topic. I am sure there are programmers somewhere that
really think this way, but I wrote exactly one linear
search routine, for some CS101 homework assignment decades
ago. Most C programmers I know use it for "close to bare
metal, almost an assembler but with architecture portability"
aspect, so performance is quite important to them. C++
programmers on the other hand, think that invoking 1600
constructors per second is a wet dream.

> This quote pretty much tells you what's wrong with software
> development.

No, it tells me that one person is a lazy good for nothing
that shouldn't be in the industry. It also makes a point
about being wary of those that jump to generalizations from
a single data point.

> Unless they're forced to do so, programmers typically take
> the easy way out and do whatever is expediant rather than
> spending the time to do it right in the first place.

*Sigh* Give me a break. This is extreme stereotyping. Are
there wannabe programmers? Absolutely. Are all programmers
like this? No. In another few decades the good ones
may be all dead, but I still have hope that people will start
taking an active interest in serious software engineering
once again and it might even be taught in colleges once more
after the .COM boomers have all left to work at McDonald's.

> > I've certainly written my share of assembler, WHEN PROFILING
> > SHOWED THAT IT WAS IMPORTANT, but I don't do it just for
> > the fun of it in a bunch of functions that get called once
> > a week, so I can tell everybody how many imaginary clock
> > ticks I could save if they got called 3000 times a second
> > instead.
>
> That's the big mistake. Thinking that you can add performance
> to a system after you've already written it. You put too much
> faith in the 80/20 rule.

That's not what I said, and I don't have any faith at all in
the 80/20 rule. I did not say I want to "add performance"
afterward. The point was that *IF* unexpected performance
issues show up, then you deal with with them. That is not
the same as "don't worry about performance unless it bites
you in the ***". You really need to stop overgeneralizing
about everything you encounter, it makes you sound foolish.

> > I'm not trying to be facetious, I've seen people spend
> > days or weeks optimizing code that would never show up
> > in any production performance test, no matter how
> > accurate your clock is. Even worse, more often than not
> > the optimized code would contain bugs not present in
> > the original. Programmers have a bigger social responsibility
> > to preventing bugs making it out the door than wringing
> > every last clock tick out of the code.
>
> I'm sure I would absolutely agree with you that programmers
> have a bigger social obligation to provide as few defects as
> possible in their code, even if that means writing less efficient
> code.

They pretty much have to do so, as error handling code isn't
free. So, there is some amount of "time wasting" that must
be acceptable in order to not have swiss cheese software.

> However, it's pretty lame to use "robustness" as an excuse
> for not supplying performance. After all, most software is not
> only slow, but buggy as well.

That would be pretty lame, but *again* I was not making
excuses. I was pointing out that there are actually larger
issues involved, and some of them act counter to your goal
of removing all excess runtime cost.

If your points were as solid as you'd like to believe they
are, you wouldn't have to keep putting words in others'
mouths to make them.

> > that the market doesn't care. If there was even one drop of
> > marketing data showing people would pay extra for spare
> > clock ticks, we'd have benchmarks on everything. As is,
> > gamer boys seems to be the only market segment that really
> > is willing to spend extra for such minor improvements.
>
> That, perhaps more than any other reason, is why programmers
> have a social obligation to provide high-performance designs
> and implementations.

If the customer doesn't care, then the programmers are not
the social nanny for the world user population in lieu of
them doing it for themselves. That's just silly.

If I felt I was wasting too much time waiting on process foo
to do something, I would solve that problem. Obviously, if
some people do not think they are wasting too much time,
even if *you* think that *they* are, that's not your problem.
It's also none of your business. Maybe they are bored and
like to waste time to make the day go faster. I don't
know, and I don't care, it's their life.

If someone came to me and said a piece of software I was
responsible for was taking too long to do something, first
of all I would be surprised, because my standards for these
things are usually much higher than those using it, and
then I would immediately track it down and figure out why
there was a problem. Hopefully any rational programmer
would do the same. If not, that programmer is the issue,
not the industry as a whole.

I am quite sure that if 25 million people voted with
their wallets and said they would NOT be buying Windows
for their next PC purchase unless Microsoft could make
Outlook start 4X faster than it currently does, then
the lights would be burning late to get it fixed. The
fact is, the market doesn't care enough collectively
to do anything about it.

> When an individual end-user wastes five minutes a day
> using a piece of software, they probably think "what's
> the big deal?"

If they think that, then that is their right. You don't
get to decide whether they are being utilized effectively
or not.

> They don't see that five minutes (or whatever) being wasted
> by *all* the users of the software. Five minutes (or
> whatever number you want to pick) isn't much to an
> individual.

EXACTLY. And this is about individuals. We don't have some
giant socialist master scheduling dictator fighting to keep
every waking hour of every individual's life fully utilized,
thank goodness. Nobody would want to live like that, so
the suicide rate would skyrocket, and you'd lose millions
of minutes per day of potential productivity.

> Indeed, most individuals waste *far* more time than this,
> per day, on their own.

... sitting in traffic. Sitting on hold. Waiting in line
for a table. Filling out forms. Ad nauseam. The PC
component of that is in the roundoff error.

> However, when you consider the accumulated effect of all
> this wasted time, time that could be reclaimed if the
> software performed a little better, it tends to have a huge
> impact on society.

Horse pucky. If they got done 5 minutes earlier, they'd be
talking at the water cooler 5 minutes longer, or go home
five minutes earlier, and watch 5 more minutes of TV.

You've been drinking some very interesting kool-aid, but
I hope it's not in wide distribution.

> > > DS3 still doesn't match local file speed.
> >
> > It's actually pretty close to the expected random I/O throughput
> > from a conventional IDE hard drive. But, that's not really
> > the point. I was just saying that no matter what the bandwidth,
> > web designers will try to take more than their fair share of it
> > anyway.
>
> And we could argue that web page designers whose sites are
> very busy have a social obligation to provide a faster experience
> for their visitors (and thank God Webster isn't in that realm :-) ).

So just outlaw anything but text on web sites. You just saved
the average internet user about 2 hours a day. So much for
your five minutes. Pfft.

> IE is a perfect example of software that wastes a lot of user's
> time.

So if any programmer stands up and says "Hey, I want to learn
how to write software just like IE", then feel free to slap the
piss out of them on general principles. The rest of us use it
as an example of what not to do.

> Programmers have a social responsibility to *not* write
> crappy code.

I don't think they have a "social responsibility" to write,
or "not write" anything. If end users buy their slop, then
then so be it. If in a free market, the worst software wins,
(I.e. Microsoft), we get what we deserve. But, if something
better comes along and exposes flaws that were heretofore
accepted (I.e. Linux), then everybody benefits in the long
run as both fight to better the other. This is why monopolies
are so bad. Not because somebody makes too much money,
(I.e. Gates), but because everybody else gets cheated out of
knowing the benefits provided by competition.

> If they write *decent* code to begin with, the software
> *will* perform just fine.

For a suitably narrow definition of *decent*.

> I dunno. I've seen a lot of people who claim to be "serious
> professionals" still taking the easy way out on many of
> their projects.

I wouldn't be surprised. When a 13-yr old in Outer Mongolia
bids $4.25 an hour to implement an e-commerce engine, it
would be hard to get motivated to work hard to compete
against that. After that project, and all those like it
fail, which they will, the whipsaw will be an exciting
ride for any left standing though. Hopefully there will
be enough of them qualified to prove once and for all that
"professional" is a word that applies to proper software
development, instead of "rent-a-tech", "code monkey", "wage
slave", etc.

> I'm certainly not claiming that *all* programmers have
> gotten lazy or never learned to write decent code in the
> first place.

That's the first time you gave off the impression that you
did not think just that. Thanks for clarifying.

> I have seen *far* too many programs that deserved a better
> implementation, however.

Semantics again, alas, but "deserved" a better implementation?
Sorry, that doesn't pass the sniff test. I am fairly sure
that I have never seen a piece of real world software (as
opposed to some toy demo or hello world app) that couldn't
be improved on. That's the devilish thing about software,
if you really care about it, you can never call it done.
There is always something that could be done better. I
also think it makes it interesting. You can always crack
open an old program and tinker with it some more.

> And regardless of the skill level, programmers still have
> a social responsibility to write decent, high-performance,
> code (or, if you prefer, to avoid writing crappy, inefficient
> code).

"social responsibility" is some vaporous non-entity, so it's
hard to agree with that. I certainly think that if they
are going to write software, they should do it as well as
they possibly can. And in doing so, performance will likely
be higher than if they didn't care or try hard. Whether or
not they owe that to anyone but themselves and perhaps their
employer is the question.

I think society has a responsibility to forcibly refuse to
support irresponsible software. If there is a huge heaping
pile of blame here, it is on the consumers for not demanding
that all the crap on the shelf be recycled into something
better. Programmers wouldn't have an option of putting out
such garbage if consumers didn't allow them to shove ludicrous
"license agreements" down their throat, to the effect that
"any bug is your problem once you click yes below".

If you could be sued for malpractice, the problem would
be as rare as heart surgeons that don't care if your
brain fits back in your school when they're done mucking
around with it. 

-- 
Randy Howard (2reply remove FOOBAR)
"Making it hard to do stupid things often makes it hard
 to do smart ones too." -- Andrew Koenig
Loading