Fork me on GitHub
#off-topic
<
2017-01-30
>
hardik_madhu04:01:05

Hey folks, this is Hardik. I am from India, a developer with experience in C and Python. I have worked in Product Conceptualisation and ( hell a lot of ) prototyping, Signal Processing, Image Processing, Machine Learning, Computer Vision, Data Interpretation and Analysis, Embedded F/W programming. Looking forward to find out about interesting projects and problems the community is trying to solve, and help out whenever possible. ๐Ÿ™‚

akiroz06:01:30

hello and welcome~ ๐Ÿ™‚

hardik_madhu06:01:22

thanks. ๐Ÿ™‚

hardik_madhu06:01:36

If you find some interesting projects, be sure to send them my way.. ๐Ÿ™‚

7h3kk1d19:01:59

Not sure if this is the right place to ask but Iโ€™m confused on what the differences of FRP and CSP are. Iโ€™ve googled it and read a few stack overflow posts but still donโ€™t seem to grok it.

7h3kk1d19:01:35

Is it that the data transformations in FRP are tied to the event?

qqq19:01:20

I don't know what CSP is.

qqq19:01:24

For FRP, look into the papers by Conal Elliot

7h3kk1d19:01:17

Communicating Sequential Processes, my understanding is thatโ€™s what core.async is

qqq19:01:05

They're two very different things. The way I think about "FRP" is -- imagine MS Excel -- and the ability to programmability create / delete cells on the fly.

7h3kk1d19:01:42

That makes sense. So FRP is not really about channels as much as just propagating change.

tbaldridge19:01:08

So...here's the problem. With FRP, the focus is much more on cells deriving their values from other cells. So the comparison to Excel is correct

tbaldridge19:01:55

CSP is much more about controlling communication between between processes via message passing and blocking.

tbaldridge19:01:18

So there's a whole ton of things in FRP that become hard...for example if you create a cycle in your cells, does the FRP engine hang?

tbaldridge19:01:04

Example: A = B + C, B = A, C = 1. What does that do in Excel?

7h3kk1d19:01:00

This makes a lot of sense

donaldball19:01:43

Entire off-topic, but since we are: google sheets prohibits circular references between cells on one spreadsheet

sveri19:01:47

I would expect it to detect a cycle and stop

tbaldridge19:01:00

yeah it does

donaldball19:01:04

But you can use IMPORTRANGE to establish a circular reference between cells on different spreadsheets

7h3kk1d19:01:25

So for a cljs example hoplon is closer to frp and the way om is developed is more like csp

tbaldridge19:01:59

yeah, so CSP is like a bunch of workers in a factory where workers = processes, and conveyor belts = channels

7h3kk1d19:01:13

Thanks so much everyone!

7h3kk1d19:01:31

cognitive hurdle of the day solved

tbaldridge19:01:34

Stuff can backup and stop, but when it does it makes sense, you look at the status of all the belts and see who 's belt is full, and who has nothing to work on.

qqq19:01:48

In FRP it isn't hard to detect cycles -- you just run topological sort ๐Ÿ™‚

qqq19:01:09

it's linear time, so you can declaratively know whether there's a cycle instead of having to run it, wait, and see which worker is bottlenecking everyone else ๐Ÿ™‚

qqq19:01:32

^^-- big fan of FRP; big fan of Erlang/Elixir actors; still not quite happy with core.async/go yet

fellshard19:01:06

Tools like that also show where you may have logical faults in your flow (unless, of course, you're working with e.g. something with differential equations, and then you just need a different toolset.)

tbaldridge20:01:28

So there's nothing wrong with FRP, but a lot of people reach for it in a UI context where it has a lot of problems. More generally FRP isn't as good of a fit where you have asynchronous data continually being pushed into your dataflow.

tbaldridge20:01:40

For example, REST responses, user interactions, that's all async input that has to be handled, and FRP tends to react in bizarre ways when handling lots of async inputs, or you have to deal with value bouncing.

tbaldridge20:01:55

That's the reason I prefer other models in the UI over FRP.

tbaldridge20:01:02

@qqq and don't get me started on actors ๐Ÿ˜‰

tbaldridge20:01:34

CSP isn't the perfect answer either, they are all tools that can be used for different situations.

tbaldridge20:01:12

I will say that almost every distributed system I've worked on has ended up being Queues + Servers (CSP), and I don't think I've ever looked at a system and said: "You know what would be awesome here? Actors!".

qqq21:01:15

@tbaldridge : I've studied many of your screen casts, and know beyond a doubt that you're a better programmer / architect, but this I don't understand: I just treat rest / async data the same way I treat "user input" -- some state variable got changed -- and the FRP system updates the rest. What precise problems are you running into? I haven't run into any yet.

tbaldridge21:01:11

Everyone is not flawless...me doubly so, never be afraid to ask questions. ๐Ÿ™‚

tbaldridge21:01:09

A common problem in FRP is jitter and over-calculation:

tbaldridge21:01:35

Assume C = A + B, and that A = [1 2 3] and B = [4 5 6], you would assume that C = [5 7 9]. But in reality, in an async context, C might be [5 6 8 9]

tbaldridge21:01:25

This is known as Jitter, there may be times when the output of a cell needs to "settle" a bit before all the inputs of the cell have been propagated. Depending on the engine, a valid result may also be C = [5 9].

tbaldridge21:01:05

In short, may systems don't properly take time into account, or have a way to lock A and B to have the same time value.

qqq21:01:03

does this "jitter" happen in single threaded systems? (I am not recommending FRP in distributed systems) -- just for JS GUI

tbaldridge21:01:19

The systems that do take time into account often suffer from over calculation. If each cell calculation always takes the most recent value from it's dependencies, you will loose out on transition states but the engine will be faster. If you execute the graph in lock-step it will take longer to resolve the graph.

qqq21:01:19

a proper impl of frp would be (1) topological sort everything (2) update everything exactly once

tbaldridge21:01:01

Right but the problem is that you often can't wait for everything to process. For example, making a REST call may take a unknown amount of time. So it's possible that the modification of some cells may trigger a few HTTP calls, but the response order of those calls is undefined, so that can result in jitter in the UI.

qqq21:01:29

"multiple REST calls in flight => different response order => possible jitter" by this definition of "jitter", wouldn't a callback / core.async approach also "suffer from jitter" ?

tbaldridge21:01:50

oh yes, that's why I also don't recommend core.async for UI work, for the same reasons

tbaldridge21:01:28

I think core.async is perfectly suited for building data processing pipelines. But stuff like Om.Next have much better designs for doing UI, as opposed to FRP.

qqq21:01:35

I guess the problem is I misunderstood the entire conversation, I thought we were debating "frp vs core.async for gui" (this is not ridicilous given https://swtch.com/~rsc/thread/cws.pdf ) -- I don't know enough about Om.next to comment on that.

greenhorse22:01:22

@tbaldridge I think in hoplon the situation you described can't happen. > Assume C = A + B, and that A = [1 2 3] and B = [4 5 6], you would assume that C = [5 7 9]. But in reality, in an async context, C might be [5 6 8 9]

tbaldridge22:01:37

it's a problem quite intrinsic to FRP, it probably can if all these values are from async streams @greenhorse

gcommer22:01:12

It depends what combinator you choose, surely

greenhorse22:01:53

If I remember correctly there is a guarantee that cell C will be always consistent in regards to A and B and that it will be updated only once.

tbaldridge22:01:21

sure, that's fine, but that doesn't apply in an async context.

tbaldridge22:01:12

what we're discussing is values over time. When I gave those vectors I was trying to show values that changed over time

qqq22:01:25

oh!, I misiunderstood that exampl

qqq22:01:31

I thought A and B were both vectors of length 3

qqq22:01:00

why is it reasonable for you to expect that async REST requests somehow happen in a "order / synchronized" manner ?

qqq22:01:46

in this case, the "jitter" is becuase we do not receive 3 synchornized packets of a1b1, a2b2, a3b3

qqq22:01:02

... but what I don't get is -- why is this a reasonable assumption when making REST requests ?

tbaldridge22:01:35

it's not, but the problem is, most FRP code I see assumes that to be the case.

qqq22:01:58

ah, and your argument in favor of Om.next -- is it partially due to its ability to say : "I want, in a single 'transaction', all the followin values -- and you better make damn sure for me that all these values are 'consistent' in that they all map to a single unified time stamp" ?

tbaldridge22:01:01

people will see A = [-1 -2 -3] and B = [1 2 3] and assume that C is always zero, but that's really not true

tbaldridge22:01:46

No it just doesn't even program that way. In Om.Next all your data is in one place, (or at least the business level data). So you are free to update/change it however you want and run constraints at that level

qqq22:01:18

hmm, I should go study Om.next as I don't understand how it works; the "cursor" model in Om turned me away from it

tbaldridge22:01:24

it's a completely different model that really doesn't look like FRP at all

gcommer22:01:15

> people will see A = [-1 -2 -3] and B = [1 2 3] and assume that C is always zero, but that's really not true unless you choose the right combinator... eg the choice between zip vs combine from https://github.com/cujojs/most/blob/master/docs/api.md#zip

qqq22:01:27

@gcommer : I think @tbaldridge 's point is as follows: T0: a = -1, b = 1, c = 0 T1: a = -1, b = 2, c = 1 // oh shit "jitter" T2: a = -2, b = 2, c = 0 // good again

qqq22:01:46

because at time T1, when we receive b = 2, we have no idea about "hey, we should wait for a to update too"

gcommer22:01:21

if you use eg 'zip' (or equivalent combinator in your library of choice) then you never get the a=-1 b=2 case, it'll wait for an event to get emitted from both sources

qqq22:01:44

can 'zip' be implemented as pure-frp? it seems like a hack that depends more on just current value

gcommer22:01:52

for what level of "pure"? I've heard people use that to many different degrees of strictness

tbaldridge22:01:56

@gcommer that's not really true FRP though

tbaldridge23:01:53

So "true" FRP is almost like a constraint language where you can say (def c (+ a b)) and c will always be the sum of a and b

tbaldridge23:01:49

@gcommer notice how in this case there is no specification of "time" or "events" you are just declaratively saying that C is the sum of A and B.