HN user
`useReducer` is the most powerful core building block for state management in React 16.8, but its API is more complicated than it needs to be. `use-state-methods` offers a simpler alternative with no loss of expressiveness. Think in terms of "methods" which either mutate state or return a new state. No dispatching actions, no giant switch statements to handle them, and with free callback memoization.
The idea of Dan Abramov having trouble finding employment is beyond comical.
Cute alternate version of Hilbert's grand hotel.
I'm very interested in trying the beta!
ID: pelotom
They may be a tolerable layout for your set of apps, which tends to be pretty small, but for organizing all your files it quickly becomes a giant mess.
I tell you you have 12/0 apples. Write the number of apples you have on a piece of paper. Some "functions" are not defined for all inputs. Better to give a "that doesn't make sense" answer than a bogus answer.
Don't get me wrong, PHP is a joke of a language, but I don't see Rasmus as the one behaving childishly here, and I also don't think he's in the wrong. APIs are allowed to change in major releases, and the behavior the plaintiff was relying on was so clearly broken it boggles the mind that he would riddle his code with dependencies on it.
Not to mention being able to rule out large classes of errors at compile time, and ease of refactoring large code bases. You mean I get all that for free? Where do I sign up?
Kind of ironic that the website is glitchy on iOS Safari.
It sounds pretty, but I'm not convinced this is a sound analogy. I think the walls are elastic to some extent. The real limitation on how much you can learn is not storage space, but time spent "moving furniture". You only have so much time to spend learning things, and you have to choose where to allocate it.
Some related material (in the order it should be read) for those interested:
On understanding types, data abstraction, and polymorphism: http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf
On Understanding Data Abstraction, Revisited: http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf
LtU discussion: http://lambda-the-ultimate.org/node/3668
LtU discussion of Steele's post: http://lambda-the-ultimate.org/node/3702
This argument is valid... the flaw in the author's logic is rather the assumption that encryption is a function, i.e. that it is deterministic. In fact decryption is deterministic, but encryption is not, and that's what prevents this kind of attack. Yes, you can obtain an encryption of any given ASCII character using a constant-valued function "inside the encryption", but the important point is that it's just an encryption, not the encryption, of that character. The decryption function, which you do not have access to, will send all possible encrypted representations back to the same plaintext.
7. Don't write code in C
Better yet, teach them a language which doesn't even have the "extra layer of [OO] nonsense". Teach them something simple, clean, and logical. Teach them Haskell.