SCOUG-Programming Mailing List Archives

>> Next Message >>

Date:	Wed, 6 Aug 2003 08:16:21 PDT7
From:	Tom Novelli <tcn@mtdata.com >
Reply-To:	scoug-programming@scoug.com
To:	< "scoug-programming@scoug.com" > scoug-programming@scoug.com >
Subject:	SCOUG-Programming: Re: Warpstock 2003 Presentation

Content Type: text/plain

Lynn H. Maxson wrote:
> Frankly I enjoy the feedback. I would hope my somewhat
> emotional response with respect to C's mythical closeness to
> assembly language does not discourage Tom Novelli from
> participating actively. Unfortunately I used the word
> "condescending" inappropriately. My apologies to Steven.

> .... Sheer curiosity would question why if one is so close to
> the other, i.e. C to assembler, that such a difference in
> execution speed, some 4 to 1 and greater, should exist.

> In fact the only place that C approaches assembler lies in "int"
> and its variations. This forms the battle space between the
> advocates of "weak" (C) typing and "strong" (every other
> HLL). More to the point C does not offer bit strings, fixed or
> variable, as a native data type. Nor variable-precision,
> fixed-point, decimal arithmetic. Nor non-null-terminated,
> variable length character strings.

No, no, you didn't quite scare me away.. you only came about as close to
that as C comes to assembly :) I've been busy. Now I never said it was
the closest, only "close". I've tinkered with simple C compilers enough
to notice how every operation in C translates directly to a sequence of
machine instructions, about the same way I'd do it if I were programming
in assembler, except C requires less typing and I don't have to think
about registers. I don't know where you get this 4:1 speed difference; it
sounds contrived. I see 1:1 usually, maybe the occasional 4:1 where speed
really matters, in which case I use assembly.

Weak typing in C is analogous to assembly.. it seems like the few types it
does have are intended to reduce typing and allow some easy optimizations. I
don't use C++ (it's overkill) but I think C++ classes would cover all those
complex types you mentioned. It lends itself to abuse, though.. just look
at Qt+KDE or GTK+GNOME.

I'm using C because it's commonplace, I already know it (I've wasted enough
time screwing around with newer languages), I have a compiler and libraries
for my system (Linux based), and it's adequate for my needs (as an
individual, not an enterprise). It's a compromise. Maybe PL/I or APL or K
would be better, but they're more complicated and obscure, and I just want
to get things done. I've thought about writing a compiler with bitstrings
and variable length types but there's not much to gain from it.

> Does anyone here seriously believe that any performance
> difference for equivalent function should exist between
> symbolic assembly and an HLL? If you do not, why do you
> continue to accept implementations in which they do?
> Unfortunately most of open source is based on C or its
> derivatives. As it doesn't have the claimed "closeness" to
> processor architecture why not opt for something that does?
> Why should not an HLL, as a third and fourth generation
> language, not incorporate directly within its linguistic form
> second generation (symbolic assembly) capabilities? It's not
> that it's something new or unheard of.

The difference exists because programmers have intuition and compilers
don't. I take it as a given that intelligence is an emergent natural
phenomenon and therefore artificial "intelligence" is limited to brute-force
testing of every possibility according to strict pre-programmed rules. We
can learn, guess, take shortcuts... do we want to spend all our time
reprogramming everything we learn and guess into some gigantic compiler, or
do we just use our heads? And for speed-critical routines, why should I
settle for the best compiler-optimized code when I could do better with
assembly? Why should I have an optimizing compiler at all? If the purpose
of a compiler is not to produce optimal code, but only to automate the most
repetitive programming tasks, this speed difference isn't an issue.

As for all this debate about inline vs. called subroutines, I think you're
being idealistic... Idealism being what brought us the USSR and damn near
Armageddon, and there's still North Korea. Anyway, I've hardly ever had a
reason to inline a routine one place but not another.. it's either all
inline or all calls. For those rare exceptions, I just cut and paste.

> I can (and have) accounted for some of these things
> frequently over the years. However, it seems founded in
> historical convenience based on technology limits then, e.g.
> memory size or cost and processor speed, which have since
> disappeared. For example, if I have a hundred times faster
> processor now than then, I have no concerns that the
> software tools invest ten times (an order of magnitude) more
> effort toward producing an optimal result.

Wait a minute.. since processors are 100 times faster, why optimize the code
any more? You're making more work for yourself... unless that's the whole
idea, eh? $$$ :) Seriously though, that's what's wrong with our economy,
we're spending too much on bureaucratic overhead, especially IT.. it
wouldn't do you any good if your money is worthless, everyone's bankrupt,
and all you know how to do is sit at a desk... Not necessarily you
personally, but I've seen that attitude at every big company I've worked
for.

Please don't take this as an invitation to debate! I'm only suggesting the
simplistic approach as an easy way out -- a technically uninteresting
solution to the industry problems you mentioned. Anyway, it'll be
interesting to hear ya'll's thoughts :)

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 06 | August | 2003 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.