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. This is also btw. what I take from the recorded videos of SICP lectures (https://www.youtube.com/watch?v=2Op3QLzMgSY&list=PL8FE88AA54363BC46). Somewhere in the first lectures Abelson or Sussman state, that a "function" is a term used in mathematics and then he goes over to immediately talking about procedures instead. To me this makes perfect sense and makes a point of distinguishing between the two things, without introducing the word function into our programming or computing vocabulary. 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. 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 ;) On Tuesday, January 22, 2019 at 6:52:22 AM UTC, gneuner2 wrote: > > > 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.
