On Wednesday, May 6, 2015 at 11:19:07 AM UTC+5:30, Steven D'Aprano wrote:
> On Wednesday 06 May 2015 14:47, Rustom Mody wrote:
>
> > It strikes me that the FP crowd has stretched the notion of function
> > beyond recognition And the imperative/OO folks have distorted it beyond
> > redemption.
>
> In what way?
>
>
> > And the middle road shown by Pascal has been overgrown with weeds for some
> > 40 years...
>
> As much as I like Pascal, and am pleased to see someone defending it, I'm
> afraid I have no idea what you mean by this.
There are many hats...
As a programmer what you say is fine.
As a language-designer maybe even required -- one would expect a language
designer to invoke Occm's razor and throw away needless distinctions (read
syntax categories)
But there are other hats.
Even if you disregard the teacher-hat as irrelevant, the learner-hat is
universal
-- whatever you are master of now is because at some past point you walked its
learning curve.
>
>
> > If the classic Pascal (or Fortran or Basic) sibling balanced abstractions
> > of function-for-value procedure-for-effect were more in the collective
> > consciousness rather than C's travesty of function, things might not have
> > been so messy.
>
> I'm not really sure that having distinct procedures, as opposed to functions
> that you just ignore their return result, makes *such* a big difference. Can
> you explain what is the difference between these?
>
> sort(stuff) # A procedure.
> sort(stuff) # ignore the function return result
>
> And why the first is so much better than the second?
Here are 3 None-returning functions/methods in python.
ie semantically the returns are identical. Are they conceptually identical?
>>> x=print(1)
1
>>> x
>>> ["hello",None].__getitem__(1)
>>> {"a":1, "b":2}.get("c")
>>>
>
>
>
> > Well... Dont feel right bashing C without some history...
> >
> > C didn't start the mess of mixing procedure and function -- Lisp/Apl did.
> > Nor the confusion of = for assignment; Fortran did that.
>
> Pardon, but = has been used for "assignment" for centuries, long before
> George Boole and Ada Lovelace even started working on computer theory. Just
> ask mathematicians:
>
> "let y = 23"
>
> Is that not a form of assignment?
Truth?? Lets see...
Here is a set of assignments (as you call) that could occur in a school text
teaching business-math, viz how to calculate 'simple-interest'
amt = prin + si
si = prin * n * rate/100.0
# for instance
prin = 1000.0
n = 4.0
rate = 12.0
Put it into python and you get Name errors.
Put it into Haskell or some such; (after changing the comment char from '#' to
'--')
and you'll get amt and si
Now you can view this operationally (which in some cases even the Haskell docs
do)
and say a bunch of ='s in python is a sequence whereas in haskell its
'simultaneous' ie a set.
But this would miss the point viz that in Python
amt = prin + si
denotes an *action*
whereas in Haskell it denotes a *fact* and a bunch of facts that modified by
being
permuted would be a strange bunch!
Note I am not saying Haskell is right; particularly in its semantics of '='
there are serious issues:
http://blog.languager.org/2012/08/functional-programming-philosophical.html
Just that
x = y
in a functional/declarative/math framework means something quite different
than in an imperative one
--
https://mail.python.org/mailman/listinfo/python-list
