On 1/22/2019 2:31 PM, Zelphir Kaltstahl wrote:
If the terms procedures and functions in computing have no significant
difference, then why use two terms for the same thing, of which one is
already used in mathematics, enabling confusion to appear?
This would make a fine argument for not using the word "function" for
computing at all and keep to using the term "procedure" all the way.
That's what many older languages did - Fortran and Lisp being notable
exceptions, but they can be forgiven because they were the first
(abstraction able) programming languages, and their early users were
people who knew and understood the difference between computing and
mathematics.
In the world of syntax design, wholesale use of the term "function" -
*relatively* - is a new thing.
I disagree on one more point. It is not necessary to always remember
the low level character of code running on a machine, if the language
we are using abstracts it well and guarantees us, that there will not
be strange effects in all the relevant cases for our programs.
But a language CAN'T guarantee that there will not be effects -
"strange" or otherwise. Spectre attacks work even against code that is
correct WRT its programming language because languages either are
ignorant of - or are intentionally ignoring - side effects of those
fiddly little machine operations.
What I am relating to is:
> The computer abstraction of "applying a function" can only be stretched
> so far. Those fiddly little "steps" that approximate the function
can't
> legitimately be ignored: they consumed time and energy, and [barring
> bugs] in the end they gave you only an approximation - not an answer
Yes it can only be stretched that far (not infinite resources,
precision etc.), however, there are many situations, where I think the
stepwise nature can be legitimately ignored. I would say, if a
language is well designed and the interpreter / compiler and things in
between that run it are proven to be correct, I do not see, why we
should not ignore the stepwise nature of code execution. Why would it
be useful to look at that, provided our program is sufficiently
performant and does what we want? Furthermore they often do give me an
answer. It may not always be the case for numbers, because of
precision and such things, but think of things like joining together
some strings, some constructs well defined in the language we use and
the result of such procedure call would be an answer and not only an
approximation.
I don't think it's a good idea to conflate the meaning of "function",
from my current level of experience at least ;)
The problem is that there are far more situations where the abstraction
leaks (or fails utterly) than there are situations where the abstraction
holds. That's why programming should be considered engineering rather
than science. [In truth, I think programming is more an art than an
engineering discipline, but that's a different discussion.]
As you noted, a major problem area is numerics. But it's more of a
problem than you realize. The average programmer today has had no math
beyond high school, and consequently most uses of floating point are
unstable and buggy. There is far too much code that works by
happenstance rather than by careful design.
In the past, it was true that more programs worked with strings (or
symbols) than with numbers, but that no longer is the case. Today,
numerically dominated programs vastly outnumber symbolically dominated ones.
There are quite a few CS scholars who think the default for safe
programming languages should be arbitrary precision, decimal
arithmetic. Rational arithmetic in Racket (and Scheme and Lisp)
similarly is safe, but the fractional representation is off-putting to
many people. Something more like BigFloat would be a more palatable
choice for the masses.
[1] You may (or not) remember that stock prices used to be quoted using
fractions: e.g., $42 ^3 /_8 . When online brokerages allowed the masses
to begin trading, stock pricing was changed to be in decimal units
because it was found that ordinary people found it too difficult to
compare prices expressed as fractions: e.g., is ^3 /_8 greater or less
than ^11 /_32 ?
[2] The tee shirt saying "5 out of 4 people have a problem with
fractions" is, unfortunately, not a joke.
YMMV,
George
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
