saiojd

Out of curiosity did you push for a raise? Not criticizing btw, just wondering how things played out

Agreed, upvotes are a failed experiment, especially for comments.

Lots of us here have wasted our youth playing games and are uncomfortable with the fact that it was, indeed, a waste.

Thanks, that makes sense!

Ok, that makes more sense. The part I still don't get is how we can pick a number x such that s2 < x < s3 without directly assuming that [0, 1] is uncountable.

I don't follow why Bob can play any legal move when s_n is not possible. The proposition is that, if S is countable, Bob has a winning strategy. Suppose S = (s1, s2, s3), which is finite and therefore countable. On turn 1 Alice picks s1. Since s1 is already taken, Bob picks any legal move, which means any number in [0, 1]. Suppose he picks s3. Then, Alice picks s2 and wins?

I wish all languages just adopted ML syntax for function application.

For starters people are intrinsically motivated to accomplish video-game tasks while most people are only extrinsically motivated to accomplish work tasks. I'm having trouble believing you aren't being disingenuous.

Yes it does seem to be a very difficult problem. That being said, some hard problems deserve hard solutions!

I agree. Something must absolutely be done about the orphan rules, IMO they are Rust's biggest wart. They damage composition in a fundamental way, and gimp the otherwise extremely expressive trait system.

I find it hard to believe that there exists no set of import declarations which remove all ambiguity, i.e., allowing orphan traits but requiring that they get imported explicitly.

I'll concede that it's not charitable but if anything I think UI needs to change more, and in ways which aren't superficial like switching icons. Compare this to Mac OS 9, is it really that different? Have we really not figured out anything better? For instance, we should not have to search through menus to find what we want. Every app should support something like Blender's operator search (like the Help > Search feature but generalized to every command, not just the menu bar). Instead of discussing stuff that matter people complain about the appearance of things.

People on this site always comment negatively on literally anything related to UI except if it looks like it was made in the 90s. Absolutely zero sense of perspective or open-mindedness.

Thanks. Batching was more efficient with diffing because you can avoid keeping track of which array indices changed within the same batch?

That makes sense. It is mostly the O(n) rerendering which is expensive, not the array copy. With regards to superficial/syntactic issues now, I just don't see the advantage of:

`setState('list', state.list.length, newItem);`

over

`list.push(newItem);`

Considering that the two operations can be otherwise equivalent when using proxies (from what I understand).

Thanks, that makes a lot of sense (basically Mobx but fine-grained). When I mentioned diffing, I meant for updating state objects like lists. Your `<For/>` element only updates if a new list is created, but only re-renders the changed elements. I assume this is accomplished by diffing the old and the new list?

I'm not sure I understand your argument in favor of setState correctly. By splitting the state into two parts (a read-only view, and a setState function to update it), isn't the opposite being accomplished? It is now possible to pass the data without passing the ability to update it, or vice-versa. Which could very well be desirable but could be accomplished by other means (i.e. leaving to the parent the choice of passing a read-only or a mutable proxy). Settings aside the superficial issue of syntax, the main thing I dislike about the setState interface is for updating things like lists, where you need to perform a full copy just to insert one element. That being said I haven't yet looked into how exactly you handle lists.

I've been playing around with your library for the last hour and so far it's excellent, pretty what I had hoped for after working with React for a while. The performance of individual renders is one area of improvement but I think the main contribution is the clarity the update model provides.

React works well until you try to avoid re-rendering and then it really falls appart. For example, updating a context re-renders the whole component chain from producer to consumer, and trying to block useless re-renders with shouldComponentUpdate easily leads to mistakes where children don't update when they should. Since React rendering use lazy evaluation of JSX expressions, tracking who exactly updates and when is much harder than what it might seem initially (akin to tracking mutations in a language with lazy evaluation). As this library actually tracks dependencies and only re-renders what you want, all of this bloat is avoided. One aspect that impresses me in particular is that JSX expressions actually return real DOM nodes, making it easy to keep references to them for imperative operations (not a big deal but so much nicer than React refs).

I'm wondering why you opted for the setState API rather than a nicer imperative API like Mobx. From what I can gather, state changes are tracked by diffing? Why not just return a proxy?