138
points
jy14898
Joined 280 karma
- you might like https://omrelli.ug/g9/ which is a similar concept but for graphics
- The post stated that it was believed duplication improved loading times on computers with HDDs rather than SSDs
- Stopped at 74 but managed to par all before that somehow. Didn't really do any problem solving/deep thinking about it, just clicking what felt right
- I don't think you can apply Unix philosophy to a (GUI) web browser, you don't use it compositionally.
- Open the page in two windows, with one that has note mode enabled
- ramburgers are quite healthy, they've been shown to improve memory
- I'm interpretting your message as you asking me to share my API keys
- Fair enough, but this isn't that case. They have Y (it's in the first photo) and tested a previous version of the model. The changes are predictable (rotating letters and slight scaling) so I don't think it's unreasonable to be confident and not waste plastic.
- What do you mean by "CSS is basically pre-tokenized input"? Can you give an example of what you have trouble with?
- It tickled me seeing the streaming example, thinking about how much better HTML deals with streaming
- The font is around 6 years old and free, so I wouldn't be suprised
- > The other option is to misuse refs to also maintain a current state there in addition to the useState. So always use the ref, but set the state in the end to trigger a re render.
Arugably this isn't a misuse, but just accepting that Reacts state management isn't powerful enough for what you need. Something akin to useRef + useSyncExternalStore is often what developers want.
For example, there's no guarantee that your useEffect will be invoked with the intermediate state you wanted to observe.
- example:
you wouldn't want to call perhapsFireNuke with DontFireNuke, even though the types are compatibletype FireNuke = boolean; type DontFireNuke = boolean; function perhapsFireNuke(action: FireNuke); - 1 point
- Now make it an HTTP API where content negotiation always succeeds
- I think I take the attitude that you parse/validate data as soon as possible (ie when reading a file/coming from an API), so that the rest of the code can rely on typechecks alone.
That said, I come from a background where the language doesn't let you consider that the type of a value might be wrong (Haskell, for example), so perhaps I have more trust than typescript deserves.
- > An API call, reading a file, calling less well-behaved libraries or making some system calls can all result in objects that pass compile-time checks but will cause a runtime exception or unexpected behavior.
Seems crazy to me to have this attitude, the whole point of typescript (and indeed many other languages with type checkers) is that we can leave out unecessary checks if proven by the compiler. The burden of compatibility is on the caller to ensure they supply correct values
However, I'm happy it's happening because you don't need an LLM to use the protocol.