On 1/21/2019 11:52 PM, Anthony Carrico wrote:
On 1/18/19 6:36 PM, George Neuner wrote:
> Historically, many computer language designers were mathematicians, and
> they deliberately sought to distinguish "computer" functions from
> "mathematical" functions.
>
> It has yet to work completely - witness the legions of newbies every
> year who don't understand that computer arithmetic differs from the math
> they were taught in school.
George: Aren't you making my case here? The mathematicians actually have
the same trouble with their components as we engineers! Stoy says, "a
careful distinction is vital in the case of functions", admonishing us
not to "confuse functions with the algorithms representing them."
Weren't Schemers making this distinction with the word "procedure"?
You and I may, in fact, agree on the basis - but I don't believe we are
arguing the same things.
If I understand correctly, you are arguing that computing should
distinguish functions from procedures because functions have a
connection [however tenuous] to mathematics that procedures do not.
I am arguing that, in computing, functions and procedures have no
significant difference, and that distinguishing them erroneously
conflates computing with mathematics and thus confuses people.
You began by saying:
However, for practical reasons, the programming community is now
placing more emphasis on the distinction between functional and
procedural abstraction, so I'm very surprised to see the Racket
community rally to eliminate it. Even within the same abstraction
mechanism, the two ideas are very useful.
The problem I see is that the ideas AREN'T separate.
Somewhere upward in this thread I wrote [not necessarily to you,
Anthony] that mathematical functions simply are, whereas their
corresponding computer "functions" are a series of steps that, at best,
can only approximate the result of the mathematical version.
There is no "series of steps" distinction between a computer function
and procedure - they both are a series of steps.
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.
For computing, "function" vs "procedure" is a distinction without a
difference [at least a significant difference]. The mathematical sense
of "function" doesn't exist, and teaching people that computers /
languages can provide mathematical guarantees is - I think - both
misleading and a disservice to the learner.
Should an engineering education sweep the distinction between the
abstract and the concrete under the rug?
In engineering the distinction actually exists - and it is not ignored.
Engineering takes great pains to call attention to the difference
because there is NO mathematical certainty in engineering - however
close, everything is just an approximation.
Computing IS engineering - which I think is at least part of your point.
My [not quite the same] point is that computing IS NOT math and should
not be conflated with it.
> The problem is that quite a lot of the talk about functional programming
> is just marketing.
So, are people gravitating away from the word "procedure" because
"functional" is now being marketed? But seriously...
What people choose to call something is related to their understanding
[or lack thereof] of the subject.
In any case, it's a different question than why people are gravitating
toward languages that *claim* to provide more mathematical guarantees.
The average programmer today has only high school math, no computer
science education, and has programming skills that are only slightly
better than "script kiddie".
I would argue that they don't understand that the so-called
"mathematical guarantees" being offered are a sham, and so most of the
increased use of such "mathematical" languages is merely the result of a
marketing effect.
There is also the "shiny new object" effect. I don't put any stock in
growth numbers ... the real measure of a language is its steady state -
how many adopters are still using it 10 years later.
I've had a similar argument many times about sales of books. I keep
pointing out that sales of intro books are not a real measure of
language use - lots of people will buy an intro book and then abandon
the subject shortly thereafter. Sales of intermediate/advanced books
are a much better measure, but they too can be misleading because at
that level buyers may be interested in something *related* to the
language but not the language itself.
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.
