Earlier quoted context omitted.
I fantasize about a future where we have enough CPU and memory that we can waste them on nice stuff like immutable data structures and software rendering.
I fantasize about a future in which buying a faster computer means my software runs faster. I don’t spend thousands on computer hardware so that lazy devs can get lazier.
4x Smaller, 50x Faster
21–30 of 205 posts
Re: 4x Smaller, 50x Faster
#22Earlier quoted context omitted.
I've always thought of immutability as great for situations where you want to "explore" (clone complex current state and go do some "what if"), need internal transactions, or allow time travel (snapshot/undo/redo) - situations where the state sharing is both efficient and feels "natural". Also if the data/history are relatively small compared to the available memory it's a fine default that generally leads to "nicer"…
Video can be played backwards and forwards, can be sought, or jumped to a particular point in time. It fits well with the "time travel" benefit of immutable data structure. The author mentioned it was extremely easy to implement some kind of a checkpoint or key framing with immutability. That's exactly using immutability to its strength.
Re: 4x Smaller, 50x Faster
#23The immutable hype is finally fading. People starting to realize the drawbacks of treating hardware as an infinite resource.
Re: 4x Smaller, 50x Faster
#24The immutable hype is finally fading. People starting to realize the drawbacks of treating hardware as an infinite resource.
mutability is a data structuring virtualization but i'd just as much suspect the runtime virtualization. that the bundle used to be 570kB isnt an immutability issue. itcs that clojurescript drags in a whole clojure runtime, a new virtualization layer atop the js runtime. that, to me, is the most likely suspect. that said, for sure, short tbeow away high gc allocation patterns are generally not good. at work there's a…
And you can of course just use java objects whenever you want.
Re: 4x Smaller, 50x Faster
#25Earlier quoted context omitted.
Historically, you could embed an animated .gif into a web page going back before Y2K, and there are tools to make such a thing from recording terminal sessions. No Javascript, no third party websites.
You can’t pause and rewind or skip ahead in a gif in any of the major browsers.
Re: 4x Smaller, 50x Faster
#26Earlier quoted context omitted.
I fantasize about a future where we have enough CPU and memory that we can waste them on nice stuff like immutable data structures and software rendering.
I fantasize about a future in which buying a faster computer means my software runs faster. I don’t spend thousands on computer hardware so that lazy devs can get lazier.
Re: 4x Smaller, 50x Faster
#27It's awesome to see performance-oriented projects to find their way to SolidJS( https://www.solidjs.com ). So satisfying to see success stories like this one. Great work.
And it might be worth putting in your HN profile that you are the creator of SolidJS. :)
Re: 4x Smaller, 50x Faster
#28Earlier quoted context omitted.
This article doesn't really support that. ClosureScript targets JavaScript, which is a platform that doesn't have special support for optimizing immutability.
How would one optimize for immutability in this case, other than turning it back into mutability behind the scenes? I've certainly seem some code written in an "immutable" style where it was pretty clear that the intent was for one data structure to be a mutation of another, just called something else because the language required it. That case might be easy to optimize ... but the general case?
Re: 4x Smaller, 50x Faster
#29The immutable hype is finally fading. People starting to realize the drawbacks of treating hardware as an infinite resource.
Re: 4x Smaller, 50x Faster
#30I’d probably paint it on canvas and then overlay an invisible plaintext node to allow selection.