171 karma · joined April 29, 2014
Stream processing of data is nicer using a declarative approach. Though I've found that describing control flow is often more intuitive using an imperative approach. It's a shame that redux-saga got tied to react/redux, because the idea of generators and declarative effects are universal - useful on both backend and frontend.
Edit: formatting
Making JavaScript look like Python in this case could potentially bite you in the ass.
From the example:
const torch = require("js-pytorch");
// Instantiate Tensors:
x = torch.randn([8,4,5]);
w = torch.randn([8,5,4], requires_grad = true);
b = torch.tensor([0.2, 0.5, 0.1, 0.0], requires_grad = true);
And: class Transformer extends nn.Module {
constructor(vocab_size, hidden_size, n_timesteps, n_heads, p) {
//.....
this.b1 = new nn.Block(hidden_size, hidden_size, n_heads, n_timesteps, dropout_p=p);
For both `requires_grad` and `dropout_p` you wouldn't be able to change the ordering + you're creating global variables. /**
* All of the arguments for this function are positional
* and cannot be provided in a different order than defined
*/
function performOperation(values, arg1 = false, arg2 = -1) {
//....
}
/**
* This works, but only because of the order
*/
const result = performOperation([1, 2, 3], arg1 = true, arg2 = 10);
/**
* This does not work
*/
const result = performOperation([1, 2, 3], arg2 = 10, arg1 = true);
/**
\* What is actually happening
\*/
arg1 = true; // global variable
arg2 = 10; // global variable
const result = performOperation([1, 2, 3], 10, true);Long story short, I found a solution that removed all my issues;
- Use the accessibility «contrast» feature set to level 2
- Use an app[0] that applies a gamme filter to adjust the white level down to account for the contrast increase
- (optional) use an srgb color profile that disables temporal dithering of colors
This reduces you max brightness level to the same amount as the old 15 inch (I don’t need the extra brightness) but allowes you to keep the backlight at max output, minimizing the pvm strobing effect[0] that some people seem to be sensitive to.
[0] https://michelf.ca/projects/gamma-control/
[1] https://osxdaily.com/2021/05/14/workaround-pwm-oled-iphone-i...
Ref: https://www.reddit.com/r/gaming/comments/anwgxf/here_is_an_e...
Edit: typo
[0] - https://www.reddit.com/r/interestingasfuck/comments/9xg8w3/t...
[1] - https://mobile.twitter.com/gamesnosh/status/1232731118354550...
The most telling difference after starting to use hooks when working with both junior developers and more seasoned ones is that code that seemingly (and intuitively) behaves in one way actually does something slightly different, or worst case - something entirely different. Most often the culprit is a combination of the hooks themselves, the rules and the more general issue of the dependency array and lack of built-in immutability in the language.
This happened before hooks as well, but the class syntax and lifecycle methods felt like a thinner layer on top of JavaScript. Hooks is a much more proprietary concept that tries to solve a much wider problem - having stateful functions, except they make no sense outside the realm of react as they exist right now. Maybe some form of implementation using generators would bring it closer to the language, but that would most likely introduce it’s own set of challenges.
Don’t get me wrong - I enjoy working with hooks, but it just doesn’t feel quite right that they are so tied to some «magical» implementation that requires a large set of rules to behave as expected. It helps to look into the implementation, and especially to reimplement a simple version of react with hooks yourself - but that’s just not a realistic option for many.
Kudos to all the innovation coming from the React team and community though - I’m sure they think about this stuff all the time.
[1] - https://jamanetwork.com/journals/jamapsychiatry/article-abst...
[1] - https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2989833/
[2] - https://www.health.harvard.edu/depression/is-your-antidepres...
Looking at a possible implementation of setTimeout makes it clearer:
function setTimeout(func, delay) {
// wait for the delay to complete..
func();
}
Here you can see that when the function is called there's nothing to the left of it.If you're doing a direct function call like myFunc() there is nothing "left" of the function call. But you might think of it as actually doing window.myFunc(), which again explains why this === window. In strict mode this behavior has been "fixed" so that this === undefined.
It's all about how a function is called.
Booked until July though..