Why is asynchronous better?

[Paul Tarvydas]

I'm writing a report, which will include a discussion of why we used FBP
asynchronous techniques.

I know that the readers suffer from the Blub Paradox (google phrase:
'Paul Graham Blub Paradox').

I would welcome suggestions on how to explain this succinctly. I've
tried to explain this many, many times without much success.


[I'll probably re-read ch. 1 of
http://www.amazon.ca/Event-Based-Programming-Taking-Events-Limit/dp/1590596439
to plumb it for ideas...]

thanks
pt

[Raoul Duke]

¿Async is able to use resources more optimally than synchronous code.
However, most approaches to async either engender confusing code
(callback hell) or lead to outright bugs (races, deadlock, livelock,
you name it). Fortunately, some things purport to let us have your
async and eat it too?

[Ged Byrne]

Hi Paul,

Asynchronous is better because is models the real world.

Imagine a person walking. How do we model there footsteps.

Easily. Left Right Left Right Left Right.

Now add a second person. They start walking a split second later. We can model their footsteps easily only of they are synchronised exactly with the other.

Left Left Right Right Left Left Right Right.

Now imagine that the second person is walking at a slightly slower pace than the first. How will you model the foot steps?

it might be possible to put together an algorithm but it's going to get complicated. What if the walkers speed up and slow down?

When using a single thread of execution modelling the real world is difficult unless we synchronise all the activities.

The walkers must march in step with each, or they must wait their turn.

How much of what goes on in the real wold can we model with those restrictions?

Now give each walker a separate thread of execution and have each thread emit events.

Each thread has a simple model: left right left right. You can speed them up and slow term down. No problem.

A listener to the events will hear complicated patterns that interweave but the models that produce them are all simple.

Obviously we would use an actor based approach rather than FBP to model this particular.

Regards,



Ged

--
You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-progra...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alfredo Sistema]

In my opinion, trying to make a case for synchronicity is harder, so you could try that approach. Why do we need synchronicity and shared state so much?

Why do we try to flatten real world requirements , which motivate the creation of software in the first place, that are expressed as intertwined events and rules instead of dry sequences of steps ?

Why do we still want to solve problems as an old single core computer would ?

I think that you get my line of reasoning by now.

On the other hand, when people hear about async code, they think of node.js and callback hell, which is undesirable. Real examples speak by themselves.

[Paul Morrison]

All the responses are good! 

But, as you all said, I think the bottom line is that the world is asynchronous!  And most of us were brain-washed at an early age into believing that the von Neumann design was the only possible one for computers (supported by a lot of rationalization!) - hence the immense cognitive mismatch!

Regards,

Paul

[Raoul Duke]

> But, as you all said, I think the bottom line is that the world is
> asynchronous! And most of us were brain-washed at an early age into
> believing that the von Neumann design was the only possible one for
> computers (supported by a lot of rationalization!) - hence the immense
> cognitive mismatch!

er, if FRP has to run on von Neumann systems (since I guess most
computers anybody would use are such) then you have to explain to
anybody with a careful/experienced/persnickety/sophist/devil's-advocate
bone in their body why it is OK to shoe-horn/fake/paper-over that
synchronous thing; that there won't be any serious issues of leaky
abstraction going on.

[Humberto Madeira]

Hi Paul,

On Wednesday, 24 June 2015 14:25:50 UTC-4, Paul Tarvydas wrote:

I'm writing a report, which will include a discussion of why we used FBP
asynchronous techniques.

I think it might help if you considered FBP as contrasted with what?

If you are comparing against typical call/return approaches, it is much easier to build a case.

Otherwise it's more like trying to nail Jello to the wall. You present an idea, they counter with a what-if.

I know that the readers suffer from the Blub Paradox (google phrase:
'Paul Graham Blub Paradox').

 

Sadly, even after Blub programmers start working with the "better way", they will still be trying to use Blub techniques with it for quite some time.

I would welcome suggestions on how to explain this succinctly.  I've
tried to explain this many, many times without much success.


[I'll probably re-read ch. 1 of
http://www.amazon.ca/Event-Based-Programming-Taking-Events-Limit/dp/1590596439
to plumb it for ideas...]

The most compelling argument for me is that, since only data is passed between components (no shared context),

the components can all be built and tested by independent teams working at their own pace (no need to wait for a dependency from another team).

A component approach also encourages re-usability as the components can be organized into some sort of catalog, with individual descriptions.

It also increases malleability, since components can easily be swapped out with others.

By pushing the connections between components to a different layer, you can defer decisions about final assembly closer to release.

And, if you support configurable networks, even beyond release to actual deployment.

All good for adaptability to changing business requirements - you won't have to toss out the code after a few years (or worse, create a Frankenstein)  

just to cope with something unanticipated down the line.

Oh and as for the asynchrony - Moore's law stopped dead in it's tracks 15 years ago and all computers now have multiple cores (even a Raspberry Pi).

So you won't be able to improve performance past a certain point if you can't make your program work on multiple cores.

There are lots more more (finesse-y) arguments you could make, but I hope this gives you some ideas about how to select the more likely ones ...

Regards,

--Bert

 

[Sam Watkins]

I'm not sure about "asynchronous", but FBP / communicating sequential
processes versus sequential programming is like a factory production
line to build cars versus a solo mechanic building a car one step at a
time.

It's possible that a factory or FBP program follows a strict rhythm.
Most CPU cores follow the rhythm of the CPU clock, and they are similar
to FBP programs not sequential programs.

I guess with FBP we have the flexibility to activate components in any
order, or simultaneously, and still get the same results. Still, it
might be more efficient to follow a certain pattern of activation.

Anyway, I'm not sure that "asynchronous" is the right word for the
essential difference between FBP systems and single-tasking sequential
or shared memory multi-processing systems. It seems to me that the
asynchronous stuff is more because we are running FBP programs on
top of single-processor systems. Ideally all the components would be
running at the same time, and it would appear to be more syncronous.
Or maybe I didn't understand the meaning of this term!

[Ged Byrne]

Hi Paul,

Can I ask why you are focusing on the asynchronous aspect of FBP?

If I was going to argue the case of FBP I would focus on Dataflow rather than asynchronous.  For asynchronous the NodeJS/Twisted/Tornado crowd are making a lot of noise right now and that's likely to cause you trouble.

Its a perfect fit for the blub paradox because while the benefits of dataflow have been known for decades developers haven't bothered making the change because of Moores Law. 

https://deepfriedcode.com/posts/2013/12/28/index.html

Why pay for the improvement lunch when Moore's law is giving it away for free?

The free lunch ended a decade ago, and finally the industry is realising that it must change its ways:

http://www.gotw.ca/publications/concurrency-ddj.htm

The path to dataflow is a twisted one and entrenched thinking does not yield easily.

Consider Google's path to Dataflow: https://cloud.google.com/dataflow/

• We have translated our experience from MapReduce, FlumeJava, and MillWheel into a single product, Google Cloud Dataflow. It's designed to reduce operational overhead and make programming and data analysis your only job.

Regards, 

Ged

[Paul Morrison]

Very good points, Humberto!  I totally agree!

BTW There is a good wiki entry on the Blub paradox - http://c2.com/cgi/wiki?BlubParadox .  One important point in it is the advice to consider the problem domain - you can't just place all languages on a continuum, especially when there is a paradigm shift involved!

Regards,

Paul M.

--

[Sam Watkins]

On Thu, Jun 25, 2015 at 09:15:07AM +0000, Ged Byrne wrote:
> Its a perfect fit for the blub paradox because while the benefits of
> dataflow have been known for decades developers haven't bothered making the
> change because of Moores Law.

By far the biggest advantage of FBP in my opinion is that it is much
simpler to build and maintain modular FBP systems, compared to other
types of software systems.

Moore's law does not make programmers twice as productive each year!

I don't know why we "haven't bothered making the change", although it
would simplify our lives and programs considerably, and enable us to be
much more productive. It's mostly dumb inertia, I guess.

I also don't know why we spend so little effort on simplifying and
refactoring programs. (By "we" I mean "most software companies and
developers".) Maybe it's difficult, but the alternative is chaos.

Perhaps we're afraid that if our systems are too simple, we might lose
our jobs, so we complexify things on purpose. But there's no need to
attribute to malice that which is adequately explained by stupidity!

[Ged Byrne]

Sam, 

The problem is that we celebrate complexity and the increasing power of Moore's Law has allowed developers to indulge themselves.

I love this story from Jackson’s Software Requirements and Specifications: a lexicon of practice, principles and prejudices:

• “What do you think of Fred?” he asked. “We all think Fred’s brilliant.” “He’s certainly very clever,” I said. “He’s not very enthusiastic about methods, but he knows a lot about programming.” “Yes,’ said the DP Manager. He swivelled round in his chair to face a huge flowchart stuck to the wall: about five large sheets of line printer paper, maybe two hundred symbols, hundreds of connecting lines. “Fred did that. It’s the build-up of gross pay for our weekly payroll. No-one else except Fred understands it.” His voice dropped to a reverent hush. “Fred tells me he’s not sure he understands it himself.”
  
  “Terrific,” I mumbled respectfully. I got the picture clearly. Fred as Frankenstein, Fred the brilliant creator of the uncontrollable monster flow chart. That matched my impression of Fred very well. “But what about Jane?” I said. “I thought Jane was very good. She picked up the program design ideas very fast.”
  
  “Yes,” said the DP Manager. “Jane came to us with a great reputation. We thought she was going to be as brilliant as Fred. But she hasn’t really proved herself yet. We’ve given her a few problems that we thought were going to be really tough, but when she finished it turned out they weren’t really difficult at all. Most of them turned out to be pretty simple. She hasn’t really proved herself yet — if you see what I mean?”

Regards, 

Ged

[Paul Morrison]

Or this story, from Chap. 9 of my book:

Suppose we have a batch application where a stream of banking transactions must be run against a stream of account records.  This is often the most efficient way of updating the account records when you have to process millions of them every day.  One might think that it would be simpler to just access each account record directly, but this will be extremely I/O-intensive, so the batch approach is still extremely heavily used, and it is one of the hardest types of application to code using traditional programming techniques, and is usually referred to as an “Update” program. I once figured that something like a quarter of all business programs running today are Updates! Whether or not that is the right figure, Update programs are hard to code and harder to modify, and yet the only assistance programmers ever received in pre-FBP days is a piece of paper, handed down from father to son, showing the basic logic for Updates, which is a pattern of moves and compares usually called the “Balance Line” technique. This logic then has to be modified by hand to suit the particular situation you are faced with. However, it is still only a description of an approach – to adapt it to a particular application you have to massively modify it. I once had the dubious pleasure of having to modify an update program (not FBP, obviously!) whose author had written the client an explanation of why his enhancement request could not be satisfied, which started, “Owing to the limitations of data processing,...”!  My clear recollection is that modifying that program (and, for a conventional program, it was really quite well-written) was only almost impossible!

Regards,

Paul M.