Comments (6)
Cloud (or multi-node) FRP (originally here)
While my intention was to continue my research in the direction of prototype 4, I have been tantilized by the problem of how to extend the FRP abstraction to "the backend". In other words, apps with data stored somewhere "in the cloud".
To extend the simple counter application, simply make it a multi-computer counter, that aggregates all the counts to a button across all computers. As is often the case, once put in those words, the problem doesn't seem so hard. One approach is to have a "lift" operator that would allow us to transform a button's Event ()
into a MultiWindow [Event ()]
, upon which we could do various operations, such as merging all the event streams and counting the occurrences.
Or consider the much more complicated problem of a realtime multiplayer game like agar.io or slither.io. As I've learned the hard way, you cannot simply send the x- and y- positions of each player to each other player and update position accordingly. You must instead anticipate where each player is going to be based on their current position and velocity and project them there until you receive the next word on their position and velocity and then you can subtly nudge that player to where they actually are, and are headed.
How could I model such an arrangement without mentioning low level details such as sockets? I think the concept of perspective is relevant here. From a single player's perspective the x- and y- position, and velocity are all FRP Behaviors, defined at all points in time because their computation happens to quickly. However, those values for other players must be modeled as FRP Events, because we only get glimpses of them at discrete points in time. However we must on the screen display other player's positions as continuous behaviors so we must use the complicated logic to predict and update our perception of the other players to construct a Behavior for them out of our Event of them.
My thinking above is lead by my intuition of FRP, types, and what the abstractions allow. However I feel a desperate need to have a proper medium to help shape my thoughts to only go in proper ways. Potentially Haskell or PureScript could be such a medium. I am considering watching/reading Conal's advice on denotative design again. Maybe I need to come up with mathematical objects to model what I mean by a "multi-widow" or "multi-user" application or event stream. These are the question on my mind when I pick up this stream of thoughts...
from futureofcoding.org.
Shower denotational design (originally here)
Conal Elliot is the man. My god, I'm so excited to be able to grok a part of what he has to say! Yesterday I re-watched Denotational Design: from meanings to programs and was re-blown away. It's funny: whenever I recommend Conal to friends I have to caveat it with, "I need to watch his stuff multiple times before I get it." This was true of this talk as well.
So here's the denotational methodology as far as I can tell:
- Come up with abstract "uses" you want the library to be able to accomplish
- Come up with a sketch of an API
- Write down the relevant types
- Write down the μ (mu, meaning) of those types as mathematical objects (likely, functions)
- Write down the μ of each API function
- See if any of your types fit existing type classes (monoid, functor, applicative, monad, comonad, etc)
So I tried to follow it in the shower yesterday and I think it went pretty well!
I had a few key insights:
- There should be a way to turn
Events a
on one computer to something likeEvent (Event User a)
, where the outer event represents this computer's perception of the event happening and the inner event represents when the event actually happened. - Another key insight: the default behavior of FRP applications should be to persist data for forever unless programmed otherwise. The resetting of app's data on page reload is a wacky accident!
- I was having trouble coming up with the semantics for a User... We want a way to authenticate someone and then we need a unique key to identify them. In terms of access for reading and writing, I imagine that logic should live (like everything else) with the relevant pieces of state.
from futureofcoding.org.
Denotation of users (shower 8/25/18)
- creating a user is a very imperative notion.
- much better if we say that a user merely is a pair of keys:
user :: (public key, private key)
- when we want to construct an stream that's tied with a user, we must merely
sign :: User -> Stream a -> UserStream a
the stream. - setting any user details (name, email address, photo) are merely signing data that claims those things for yourself
- Reading seems less natural, but the idea is that when we want data from another computer, we need to
lift
aStream
to aStream (Stream)
of some sort (to account for when we get the stream as well as when it happens), and in this lifting we can optionally supply aUser
parameter. Pieces of state themselves will decide if and how they will allow themselves to be lifted, and to which users.
from futureofcoding.org.
- At SPLASH, I was really excited to find ScalaLoci which was about placement types of reactive programming in Scala. Very related to this work. I need to peruse their Related Work section for more details.
- I found a way to make sense of reading (which I was having trouble with above). All data is "public" but by default anything you do is encrypted so only you can read it. You can also encrypt it with others' private keys if you want them to have access. We'd probably want to make who can have access be a
Behavior
so that we can change this if we want to revoke access. - Eventually, the next step here will be implementing this, probably in Haskell
from futureofcoding.org.
Apache Beam shares some ideas with FRP, mainly that you build a graph based on data dependencies (denotational-style).
from futureofcoding.org.
Thanks @tswast!
from futureofcoding.org.
Related Issues (20)
- futureofcoding.org/links should be linked on the landing page HOT 5
- Image hosting 3
- Slack link does not work HOT 1
- image hosting 2 HOT 27
- fix all deleted links
- get email when github is down
- Multi-node / Cloud FRP
- p4 HOT 7
- Liberal Software (r0ml)
- Google Search Console Mobile Usability Issues Detected
- Intellectual family tree
- DCTP
- SciHub HOT 3
- Code Equality / Normal Form HOT 3
- Website re-org
- Transfer all things to Github Issues and Projects HOT 1
- Prototypes History
- Turbine 7GUIs HOT 1
- Name ideas
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from futureofcoding.org.