I know you like to write HTML. But stop doing it! So how do you define view state without HTML? You use functions! Then you can use any paradigm you like. And you get performance. Static sites and static site generators is still a thing, but it works very different from a client side app. Then we have the in-between with an app that renders a static view on the server. But you have to stop writing client side apps like if they where server rendered.
The Misunderstood Roots of FRP
41–50 of 66 posts
Re: The Misunderstood Roots of FRP
#42I spent a fair amount of time dabbling with FRP - for example, wrote a Pong for the web using SodiumFRP and Purescript[0]
imho FRP is absolutely elegant and wonderful when it all comes together. The difficulty, I found, is iterating and hacking away in order to discover what the end result was meant to be all along. In that respect FRP does slow down development time (at least in my hands. Maybe those with more expertise could iterate faster).
I'd imagine that even in that scenario it could be fruitful to use something less robust for prototyping, and then implement it with FRP for a maintainable release version that's easier to reason about.
Re: The Misunderstood Roots of FRP
#43Yeah okay. Then why does nobody use it? Even languages like Elm ditched it for easier to understand concepts. Let's face it. FRP kinda sucks. It's awkward as hell to use and takes way to many brain-cells to achieve simple results. Even the experts have trouble with it. I remember e-mailing the author of a popular FRP library once asking him how I could get multiple shapes moving on the screen at once (as opposed to j…
Step 1: when selling something, it helps to explain what it is and why it is good.
Re: The Misunderstood Roots of FRP
#44Even the article doesn't explain what FRP is . . .
Re: The Misunderstood Roots of FRP
#45Yeah okay. Then why does nobody use it? Even languages like Elm ditched it for easier to understand concepts. Let's face it. FRP kinda sucks. It's awkward as hell to use and takes way to many brain-cells to achieve simple results. Even the experts have trouble with it. I remember e-mailing the author of a popular FRP library once asking him how I could get multiple shapes moving on the screen at once (as opposed to j…
Agreed, partly. > The great irony is that nobody on the planet thinks of spreadsheets as time-varying continuous functions. Nope. People view spreadsheets as a big grid of numbers... i.e. state. People view some spreadsheet cells as state, and they view others as functions. There's a distinction between things that are naturally represented as one, vs the other. This is why I preach to people about MobX whenever I ge…
>> People view some spreadsheet cells as state...
But a cell with a function is not a function, it’s a result of calling a function at a certain set of values. That is even true if you only use ArrayFormula.
E.g. you can’t define a formula inside a cell and the call that cell with certain arguments.
Re: The Misunderstood Roots of FRP
#46Nobody quickly understands: A(B(C(D(E(x))))) That is why they use the assignments. e= E(x) d= D(e) c= C(d) b= B(c) a= A(b) But many people can understand: x-> E -> F-> C-> B-> A // where -> is a pipe operator. Now you see that you first execute E with x as input. This shows that Functional program has some kind of problem, if it is not presented in a good way. There are also other problems. The overuse of Currying is…
The first line seems the most easily parsed to me. The second one is the worst, and the third one only works for a tidy pipeline; if you have to combine multiple pipelines you'd need to bracket them, as in the first.
The first line makes it hard to parse actual diffs in git.
Re: The Misunderstood Roots of FRP
#47What’s FRP?
yep. i knew in our field the F & P could only mean functional programming. but the R eluded my acronym decrypting skills. glad to find someone found what it meant. i almost thought it was "recursive"... can we agree to stop using these meaningless acronyms?!
You just have to spell it out once at the beginning of the article, then it's fine. The author never did it once.
Re: The Misunderstood Roots of FRP
#48Imagine you were trying to explain the temperature-conversion program's behavior in the simplest, clearest way possible. (That is, after all, what programmers fundamentally do: try to explain things to computers as simply and clearly as possible.) You'd probably say something like: "When the user changes the Celsius textbox, the computer changes the Fahrenheit textbox to the converted value." And indeed, that's the p…
Thinking about things like this is really tiring, but I suspect I get less bugs when I do.
Re: The Misunderstood Roots of FRP
#49Earlier quoted context omitted.
You can think of a timeline as immutable, but you don't know values from the past unless you arranged for them to be recorded, you don't know values from the future until they happen, and you don't know what's going on at any other node unless they send you a message about it and it eventually makes it across an unreliable network. (So, sometime after it actually happened.) If you model this in a declarative way then…
> be careful to avoid implying that all events should be remembered Is that true in a post-AWS world with storage getting cheaper faster than you can consume it? Maybe don't put 4k video in the log. But, you're right, we can stream, shard and forget as necessary. > also avoid depending on anything in the future unless you want to wait for it Can you elaborate on this, my gut reaction is to ask why I need to avoid dep…
i think it falls into the slightly-too-clever category, but
http://www.neilconway.org/docs/vldb2014_edelweiss.pdf treats safe log truncation as a conservative optimization.
its similar to tail-call in that the efficacy of your program depends on the compiler figuring out what you're trying to do - which is unsatisfying
but its a great idea and a ray of hope here
edit: this also implies that the set of reads against the history is fully known at compile time - which may make it irrelevant depending on the usage
Re: The Misunderstood Roots of FRP
#50Earlier quoted context omitted.
Agreed, partly. > The great irony is that nobody on the planet thinks of spreadsheets as time-varying continuous functions. Nope. People view spreadsheets as a big grid of numbers... i.e. state. People view some spreadsheet cells as state, and they view others as functions. There's a distinction between things that are naturally represented as one, vs the other. This is why I preach to people about MobX whenever I ge…
>> People view some spreadsheet cells as state... But a cell with a function is not a function, it’s a result of calling a function at a certain set of values. That is even true if you only use ArrayFormula. E.g. you can’t define a formula inside a cell and the call that cell with certain arguments.
The arguments are the other cells it references, which are themselves either state or other functions