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