C vs. FORTRAN
00704a-Liber
nevin1 at ihlpf.ATT.COM
Fri Jul 1 09:55:04 AEST 1988
In article <20506 at beta.lanl.gov> jlg at beta.lanl.gov (Jim Giles) writes:
|LISP isn't terribly hard to read either, but it's not what I want to
|code numerical expressions in. The syntax that mathematics uses is
|really well suited to the task. The programming language syntax for
|the same purposes should look as similar as possible to the original
|math. There is no reason that I can see to adopt any other rule of
|choice in language design.
Since when does 'x = x + 1' resemble anything besides an obviously false
statement in mathematics?? Also, since many of us use C for tasks other
than number crunching, does this mean that we should have NO desire for a
programming language to resemble mathematics? Your reasoning is a little
faulty here.
|The choice I'm talking about is whether to cause a function call (the
|most expensive of all the 'simple' operations). Doesn't matter what the
|subroutine library does, you've already made the expensive call.
A function call may not necessarily be made (can you say 'inlining').
|Fine, C is fixing something that shouldn't have been broken to begin with.
It was never broken (a little inefficient, but not broken).
|Finally! Something we agree upon. But what does this have to do with
|the value of placing the operator into the syntax? Just because it's
|seldom used for large or non-constant arguments, doesn't mean it needs
|to be arcane or cryptic when it IS used.
If all the arguments are constant, what do you need a run-time operator
for?
--
_ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194
' ) ) You are in a little twisting maze of
/ / _ , __o ____ email paths, all different.
/ (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blah
More information about the Comp.lang.c
mailing list