asyncio: What is the difference between tasks, futures, and coroutines?

[Rustom Mody]

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