* Steven D'Aprano:
On Sat, 05 Dec 2009 11:26:34 +0100, Alf P. Steinbach wrote:
Regarding my terminology, "routine" instead "function" that everybody
except you remarked on, it is of course intentional. [...]
I think you failed to realise that your use of the term was ambiguous. It
wasn't clear that you were using "routine" as a noun, it seemed like you
were using it as an adjective, that is, "routine objects" meaning
"ordinary, common objects one would use routinely".
Your second example was:
(42).blah = 666
(which of course fails, because ints are immutable and you cannot add
attributes to them). It isn't surprising that we failed to realise you
were talking about callable objects when exactly 50% of your examples
were not callable objects.
One example and one counter example. I can't think of why anyone should lump
these together as examples of the same thing.
Given the context, I think we were completely
justified in thinking that you meant routine in the sense of commonly
used.
Bah.
I use the term "routine" because I think the terminology influences what
we can easily think of and what we therefore tend to use and/or discuss.
In that respect I think people need to be educated to use more language
independent, or Eiffel-like, or just historically original, terminology,
because
* "function" is misleading in itself (due to the hijacking of this
term in mathematics), and
"Function" in the mathematical sense dates back to Leibniz and Johann
Bernoulli in the late seventeenth century. I'm not sure, but I think that
may have pre-dated computers by a couple of years *wink*
Yes, that was my point. Wink.
http://www.gap-system.org/~history/HistTopics/Functions.html
* it gets worse when you can't reasonably talk about "co-functions"
or "function-like functions". :-)
"Co-function" is specifically a mathematical term, from trigonometry.
Sine and cosine are co-functions, because they are related via
complementary angles: the sine of an angle is equal to the cosine of the
complementary angle.
That's the only definition Google has found:
http://www.google.co.uk/search?q=define%3Aco-function&ie=UTF-8&oe=UTF-8
Webster's dictionary agrees this is the only definition:
http://www.merriam-webster.com/dictionary/Cofunction
So I have no idea what you think a co-function (or cofunction) is, or why
you can't talk about it.
Right. That was my point. Wink. Heh heh. :-) Try substituting "routine". That
is, s/function/routine/g.
As for "function-like functions", I can't think why you would want to use
that term!
See above. ;-)
If something is a function, it's obviously function-like, in
the same way that cats are cat-like and chairs are chair-like.
Right, that was my point.
Including that with the C/Python terminology it isn't.
If you want to talk about "function-like objects", or "function-like
data", or "things that behave like functions but aren't actually
functions", that is reasonable. We have names for such things: functor
(from C++, different from functors in Haskell), or callable, or
(verbosely, in Python) "any object with a __call__ method". But function-
like functions? That would just be a function.
Right.
The devolution of terminology has been so severe that now even the
Wikipedia article on this subject confounds the general concept of
"routine" with the far more specialized term "sub-routine", which is
just one kind of routine.
I'm not sure how to reply to that, since I'm not sure what you think a
"routine" is in computing.
See the Wikipedia article and allow for some confusion on the part of the
authors. Or, if you have TAOCP handy, look it up there. However, you may
disregard Donald Knuth's definition of "reel time" :-), I'm not invoking him as
an authority on terminology, just a handy accessible source for the general
meaning of "routine" (disclaimer: haven't looked it up for this posting, so I
can't guarantee that you'll find it, although as I recall in volume I).
In my experience (which dates back to the early 80s), "routine" has never
been anything but a generic term without any specific technical meaning.
That is, one might talk about the "print routines" without caring whether
they are external programs (say, printer drivers) or internal sub-
routines (functions, procedures, co-routines, methods, or even just a
chunk of code you GOTO).
Well, my experience is perhaps a bit longer, but not much. And you're on the
right track. It's a more general term, *and* it has context dependent meanings.
It is of course OK with me that there is a
default meaning, and that there are several different context
dependendent meanings. I'm just mentioning this as an example that the
terminology effectively constrains one's thinking, to the degree that
even a moderately long encyclopedia article on the subject fails to
mention or focus on the important aspects.
What do you consider the important aspects of routines?
One of the most important aspects is the invocation model. There are many such.
Sub-routines and co-routines are the two most common special cases, but for a
little more general way of thinking about how routines are invoked and
communicate, if you can find a copy of Patrick Henry Winston's "Artificial
Intelligence" nearby, as I recall he discussed some other options in a very
clear way (illustrated with Lisp examples).
Perhaps modern programmers
should be forced to study Donald Knuth's TAOCP. Or something.
Perhaps. But not every car mechanic needs to be able to re-build an
engine from scratch.
Besides, if every programmer had read Knuth, what reason would we have to
feel superior to the code-monkeys? *wink*
I've-skimmed-parts-of-Knuth-and-am-therefore-superior-to-99%-of-coders-ly
y'rs,
He he. :-)
Cheers,
- Alf
--
http://mail.python.org/mailman/listinfo/python-list
