This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # bangalore-clj (1)
- # beginners (104)
- # boot (207)
- # cider (173)
- # cljs-dev (157)
- # cljsjs (1)
- # cljsrn (51)
- # clojure (196)
- # clojure-berlin (1)
- # clojure-chicago (1)
- # clojure-italy (4)
- # clojure-new-zealand (1)
- # clojure-nl (1)
- # clojure-russia (28)
- # clojure-spec (17)
- # clojure-uk (73)
- # clojured (13)
- # clojurescript (110)
- # core-async (4)
- # datascript (25)
- # datomic (92)
- # editors (1)
- # emacs (157)
- # events (4)
- # hoplon (16)
- # klipse (74)
- # lein-figwheel (10)
- # leiningen (2)
- # lumo (13)
- # off-topic (78)
- # om (3)
- # om-next (3)
- # onyx (14)
- # protorepl (1)
- # re-frame (17)
- # reagent (23)
- # remote-jobs (1)
- # ring-swagger (33)
- # schema (2)
- # slack-help (3)
- # spacemacs (7)
- # testing (1)
- # yada (7)
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. 🙂
If you find some interesting projects, be sure to send them my way.. 🙂
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.
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.
That makes sense. So FRP is not really about channels as much as just propagating change.
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
CSP is much more about controlling communication between between processes via message passing and blocking.
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?
Example: A = B + C, B = A, C = 1. What does that do in Excel?
Entire off-topic, but since we are: google sheets prohibits circular references between cells on one spreadsheet
yeah it does
But you can use IMPORTRANGE to establish a circular reference between cells on different spreadsheets
So for a cljs example hoplon is closer to frp and the way om is developed is more like csp
yeah, so CSP is like a bunch of workers in a factory where workers = processes, and conveyor belts = channels
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.
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 🙂
^^-- big fan of FRP; big fan of Erlang/Elixir actors; still not quite happy with core.async/go yet
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.)
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.
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.
That's the reason I prefer other models in the UI over FRP.
@qqq and don't get me started on actors 😉
CSP isn't the perfect answer either, they are all tools that can be used for different situations.
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!".
@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.
Everyone is not flawless...me doubly so, never be afraid to ask questions. 🙂
A common problem in FRP is jitter and over-calculation:
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]
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].
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.
does this "jitter" happen in single threaded systems? (I am not recommending FRP in distributed systems) -- just for JS GUI
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.
a proper impl of frp would be (1) topological sort everything (2) update everything exactly once
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.
"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" ?
oh yes, that's why I also don't recommend core.async for UI work, for the same reasons
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.
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.
@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]
it's a problem quite intrinsic to FRP, it probably can if all these values are from async streams @greenhorse
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.
sure, that's fine, but that doesn't apply in an async context.
what we're discussing is values over time. When I gave those vectors I was trying to show values that changed over time
Yeah my bad
why is it reasonable for you to expect that async REST requests somehow happen in a "order / synchronized" manner ?
in this case, the "jitter" is becuase we do not receive 3 synchornized packets of a1b1, a2b2, a3b3
... but what I don't get is -- why is this a reasonable assumption when making REST requests ?
it's not, but the problem is, most FRP code I see assumes that to be the case.
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" ?
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
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
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
it's a completely different model that really doesn't look like FRP at all
> 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
@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
because at time T1, when we receive b = 2, we have no idea about "hey, we should wait for a to update too"
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
can 'zip' be implemented as pure-frp? it seems like a hack that depends more on just current value
for what level of "pure"? I've heard people use that to many different degrees of strictness
@gcommer that's not really true FRP though
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
@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.