German talk about FRP with Sodium

[tnfink]

In my experience a good approach to build up some comprehension of a topic is to give a talk about it. I did this and gave a talk at the BED-Con, a conference in Berlin, about functional reactive programming with Sodium. An, at least for me, interesting part of the talk was the introduction and motivation of the transactions in the GUI layer.

The german slides can be found here:

Funktionale reaktive Programmierung mit Sodium

Any feedback is of course appreciated.

[the-real-blackh]

Thank you for doing this! I enjoyed reading the slides. Here's some feedback I can think of:

• displayC.listen(displayListener) is preferable to Operational.updates(displayC).listen(displayListener).
• calculatorController.displayCell would be preferable to calculatorController.getDisplayCell(). If you declare the field as final, then the Java 'getter' idiom isn't needed.

I loved the calculator example!

[dakom]

Wish I could read German... if you ever put together an English translation, please share!

[tnfink]

Thank you for the feedback!
I will adapt the code as soon as I get some spare time.

[tnfink]

I confess that I did not update the code yet. But, I quickly wrote a short blog article in English about my current understanding of the transactions in Sodium:

GUI Transactions with the FRP Framework Sodium

Feedback is appreciated!

[the-real-blackh]

Great! Thank you for doing this!

The updates to the state can depend on the existing state of the model cell (using snapshot) and in most practical cases you would want to do this.

Simultaneous update events could occur. You can either prioritize these using .or_else() to merge the streams, which would throw out some of the changes if others took precedence. Or, to keep all changes, you would express the changes as functions of the old state, and merge them by chaining the functions in the simultaneous case.

Most Sodium implementations should have a shortcut for this - c.accum(i) - that accumulates a cell c of state changes of type S(S) where S is the state type. i of type S is the initial state.

[dakom]

Oh this is interesting, thanks for writing the article. We need more of these

I'm wondering if my mental model of Transactions as they relate to time is correct? Here's what I'm thinking so far:

Sodium operates over continuous time... but what is "time"? In the sense of a wall or computer clock - it's a series of seconds, or milliseconds, or however we break it down discretely... but Sodium doesn't have a notion of a clock like this. Rather, it only cares about the order of changes. Each change happens in a "moment" a.k.a. "Transaction" - and so Transactions are basically Sodium's internal unit of time?

With that in mind - changes can happen in the same moment/transaction - even in javascript (where there's no true concurrency), by explicitly creating a transaction and causing multiple changes within that wrapper.

[tnfink]

I updated the listener on Github.
I could not change the displayCell because I used an interface to abstract the different solutions. But I totally agree with your point.

[tnfink]

hm, from what I remember from my distributed systems lecture, there is nothing like a global time/clock. There are only local clocks counting up. Each count produces an event that can be observed. Concurrency just means that two events are not causally ordered.

In this sense a clock can be naturally modeled in Sodium as a stream.

With my current understanding, a Sodium transaction gives structure to the update of states. It does not define a single unit of time because in a Sodium transaction concurrent events can happen.

But, I am no expert.

[the-real-blackh]

@tnfink, that's right. Sodium's timer system gives a transaction a single time stamp so all updates within it see the same clock time. Sodium doesn't work like a distributed system, so there is a global clock.

Within a transaction all updates are logically simultaneous. Where simultaneous events are merged, an order must be chosen explicitly.