241 ms·
Then that's a breaking change of the someBigFunction()s interface and it should be treated with care, not just quickly patching on a promise and hope for the b
by Too 14y ago
Then that's a breaking change of the someBigFunction()s interface and it
should be treated with care, not just quickly patching on a promise and hope for the best. Javascript is single threaded so when you wrote someBigFunction() you didn't have to think of parallel side effects. If you suddenly pause the execution of someBigFunc() and allow the user to mess around with the interface, the global state that someBigFunc() is working on might become changed.
Simply slabbing on a promise inside such a function only works if the function is pure to start with. Usually that's not the case with slow functions in javascript since the slowest thing in javascript is messing with the DOM, i.e global state.
- daleharvey 14y agoThe fact that I changed a calculation from a constant to reading its value from indexeddb shouldnt need to be an intrusive change. It is makes things more likely to break, there isnt some 'oh you decided to do io so you deserve to do a big refactor' point
- infinite8s 14y agoAnd this is why handling state in imperative programs is such a mess. You are fundamentally changing the way state is treated in that application - why shouldn't it require a massive refactor?
- Evbn 14y agoFunctional programs don't make this easier. And don't say "monad transformer stacks" somehow solve this problem in an easier way.
- Peaker 14y agoHaskell definitely makes it easier. You can use preemptive green threads with almost all the ease of cooperatively multitasked code because of the prevalence of immutability. You get the performance benefits of non-blocking code. The simplicity benefits of blocking code. And (almost) none of the threading hell you get in imperative languages.
- fzzzy 14y agoAre they really preemptive? How does the scheduler decide when to switch?
- Peaker 14y agoYeah, they are preemptive (though there had been a long-standing bug where threads that have no allocations don't get preempted, I believe it is fixed now). This is some documentation of the scheduler: http://blog.ezyang.com/2013/01/the-ghc-scheduler/ http://blog.ezyang.com/2013/01/the-ghc-scheduler/
- daleharvey 14y agoNot necessarily because it is functional, but Erlang makes this vastly easier. I find the "oh you changed tiny piece of logic, you should totally have to refactor every line of code that follows it" very strange. It obviously sucks, there are far better ways to handle it and they are slowly making it into the language.
- fzzzy 14y agoErlang makes it easier because it enforces no shared state between actors, and each actor has it's own independent thread of control.
- ufo 14y agoFair enough. It might be a breaking change but wouldn't it be nice if instead of having to rewrite everything into continuation passing style (a boring and error prone process!) you could just do something simple like var a = await someBigFunc() or do a <- someBigFunc() Javascript in its current state is not built for supporting CPS programming very well. You often end up needing to reimplement control flow primitives like while loops, break statements and exception handling since those don't play nice with async stuff.
- GeZe 14y agoThis syntax already exists in LiveScript (http://livescript.net/#backcalls http://livescript.net/#backcalls) which compiles to straightforward JS. a <- doFirstThing() b, c <- doSecondThing(a) doFinalThing(b + c)