If you have an imperative program and can’t identify “the thing”, then the thing is the entire state of your program. To translate that to a functional program, you’d need to plumb the thing into and out of every function in your program.
-
-
Show this thread
-
This transformation is doable, but the problem is that references inside the original imperative program have to be turned into some sort of representation of the entire path from the top level state object to the thing the reference can be modified.
Show this thread -
Hence I think the sweet spot for large-scale programming is an imperative language with a pure functional subset, not a functional language with imperative plumbing like Haskell monads. Then the beast that needs to be tamed is data races in the shared state concurrency model.
Show this thread -
In an engine, “the thing” is the scene graph. The simulation updates it once per frame based on object interactions. Then perhaps there are several much smaller independent things, like the state of the input system, the network replication system, and so on.
Show this thread
End of conversation
New conversation -
-
-
Isn't calculating stuff about an unchanging thing the same as calculating a new version? I.e. the output of the calculation is the new version, you go from A->B instead of A->A', but you still take bits and produce bits. Or are you saying that computation is either map or reduce?
-
To add some rigor, we can define a new version T1 of a thing T0 if we bundle up the program’s logic and unchanging state into a constant F, and identify a subpart of the program which is a sequence of updates T1=F(T0), T2=F(T1), etc. A game Koop is an example.
- 2 more replies
New conversation -
-
-
I see this as reactive vs non-reactive rather than imperative vs functional. Imperative programming makes it easy to write reactive code, but in an implicit way—you're using mutable state to implicitly model time. In FP, we need an *explicit* model of time.
-
Functional reactive programming (FRP) is a great example of what I mean—it lets you write code about things that change over time *by making time an explicit part of the abstraction*.
- 1 more reply
New conversation -
-
-
I'm starting to believe that what we need is some elegant synergy of the 3 computational models: logic, imperative and functional. Where you're not forced to emulate (hack) features of one paradigm with features of another.
-
There's also the distinction between static and runtime computation. Spiral is a language that makes this distinction explicit:https://github.com/mrakgr/The-Spiral-Language/ …
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.