From: Robert Harley
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <5c7os1$plk@news-rocq.inria.fr>
Erik Naggum <····@naggum.no> writes:
>[...]
>you flunk, D. J. Bernstein.
>[...]
>you aren't bright enough to understand the issues I raised and you
>instead think this is about machine operations [...]
1. This is uncalled for.
2. Dan knows a thing or two about arithmetic and most certainly does
understand the issues.
3. We'll continue merrily using C and putting in checks for overflow
when they are needed. If you're lazy, use some other language that
always checks even when you know for a fact that overflow cannot
occur, thereby increasing your code size drastically and
needlessly slowing down most arithmetic operations.
There are times when ultra-safe, high-level prototyping is productive
and there are times when non-portable hackery in machine code is
essential. But most of the time, most programmers strike a balance
between these two extremes and find that C is a happy medium.
Horses for courses and all that.
Bye,
Rob.
From: Erik Naggum
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <3063019639826071@naggum.no>
* Robert Harley
| If you're lazy, use some other language that always checks even when you
| know for a fact that overflow cannot occur, thereby increasing your code
| size drastically and needlessly slowing down most arithmetic operations.
this is interesting. do you have a suggestion for how I can have the
software that fails for me (or that I can't trust) automatically rewritten
into a language that does check for overflow, to take but one example?
it is also interesting that you think it's either all or nothing and that
overflow is extremely expensive. no wonder programmers like you don't want
overflow detection! but I can only guess that your job security is better
than your users' safety.
as for speed, I'm using Allegro Common Lisp in two projects right now. the
compiler has a switch `declared-fixnums-remains-fixnum' that gets true if
speed > 2 and safety < 1 in the optimization settings. (those are the
defaults; I can change the conditions under which it is true.) I can wrap
a piece of code in (locally (declare (optimize (speed 3) (safety 0))) ...)
and then I won't have overflow detection. I love _having_ that option, but
it has yet to be used in real code. in any case, the code produced at
these settings is as fast as C, or even faster, considering that a lot of
other optimizations kick in that C can't do. (e.g., tail call merging.)
#\Erik
--
1,3,7-trimethylxanthine -- a basic ingredient in quality software.
In article <··········@news-rocq.inria.fr>
······@pauillac.inria.fr "Robert Harley" writes:
> There are times when ultra-safe, high-level prototyping is productive
> and there are times when non-portable hackery in machine code is
> essential. But most of the time, most programmers strike a balance
> between these two extremes and find that C is a happy medium.
Actually, there are ways of turning off checking in Lisp.
Common Lisp allows the programmer to write a declaration
telling the compiler to maximise speed, and minimize safety,
amoung other things. The scope can be global or local,
depending on how the declaration is made.
Safty and speed are _not_ mutually exclusive. The choice
doesn't have to made globally. Some languages give you
a choice, but your first choice is the language to use.
After that...
> Horses for courses and all that.
I have to agree with Erik on this. C doesn't give you the
choice that CL does. What actually CL compilers do with the
optimise declaration is another matter, of course.
See <http://www.cs.cmu.edu/Groups/AI/html/cltl/cltl2.html>
and look up section 9.2, if you have any doubts.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers � Developer and Information Broker � London, UK
Please remove the "nospam" if you want to email me.
"Blow out the candles, HAL."
Hi!
RH> use some other language that
RH> always checks even when you know for a fact that overflow cannot
RH> occur, thereby increasing your code size drastically and
RH> needlessly slowing down most arithmetic operations.
Actually every compiler that's worth it's name will do exactly that -
analyze if checks are necessary and only put in those checks that are
needed. Ok, every compiler that compiles a language that's worth
mentioning, so you can drop C here.
bye, Georg
From: David Hanley
Subject: Re: Theory #51 (superior(?) programming languages)
Date:
Message-ID: <32F24FBB.19CF@netright.com>
Georg Bauer wrote:
>
> Hi!
>
> RH> use some other language that
> RH> always checks even when you know for a fact that overflow cannot
> RH> occur, thereby increasing your code size drastically and
> RH> needlessly slowing down most arithmetic operations.
>
> Actually every compiler that's worth it's name will do exactly that -
> analyze if checks are necessary and only put in those checks that are
> needed. Ok, every compiler that compiles a language that's worth
> mentioning, so you can drop C here.
This is just plain silly.
int foo( int a )
{
return a * 10;
}
I know, as a programmer that a will never exceed, say, 1000. The
compiler cannot.
Please note I'm not arguing for using C over lisp! I'm simply stating
that there may be times when you want to use C, and that people who code
in C are not neccecarily ignorantm, nor stupid.
--
------------------------------------------------------------------------------
David Hanley, Software Developer, NetRight technologies.
My employer pays me for my opinions; nonetheless he does not share all
of them
E-mail address munged to defeat automailers, Delete _nospam
Hallo David,
> I know, as a programmer that a will never exceed, say, 1000. The
>compiler cannot.
You simply can't know, except it is stated in the code. And if it is stated
in the code, the compiler can use this information for subsequent
optimizations. Have a look at Eiffels pre/post-conditions. A good compiler
can make much out of this. I always hear this words "I know what will
happen here" far too often. In every not trivial situation this statement
is simply wrong. There are other routines that call this routine that won't
work correctly, there may be another programmer in the team that doesn't
know about the stated fact, there may even be a bug in a library routine in
the compiler.
My job isn't building new applications in great new (or old) languages -
highlevel languages like Lisp or functional languages are mostly my private
hobby and a relax from my day-to-day job. May job is to work on a 13 year
old legacy system written in Cobol and C (and the Cobol-parts are the good
ones ;-)). Believe me, there are times where I really would like to shoot
all C-programmers that are known to me ;-)
bye, Georg