eiriklv's comments

On: Understanding React Compiler

[eiriklv]

I feel like redux-saga [0] also belongs on that list of algebraic effects - at least as an honorable mention.

[0]: https://redux-saga.js.org/

On: Understanding React Compiler

[eiriklv]

In Rick voice: Well, that just sounds like generators with extra steps..

[namaria → eiriklv]

This is a Morty line...

On: Effect – Build robust apps in TypeScript

[eiriklv]

A bit on the side:

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.

On: Deep Learning in JavaScript

[eiriklv]

Edit: Great work! I'd love to have a nice alternative to PyTorch in JavaScript :)

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);

[eduardoleao052 → eiriklv]

Thats true, it’s a limitation of working between these languages. I tried to mitigate it by using clear JSDoc, so that each variable pops up alongside an explanation when calling a function.

[eiriklv → eduardoleao052]

I feel you - Python has much better (more flexible) argument support than JavaScript in this case. Converting the entire set of arguments into a keyed object is usually what happens, but then it wouldn't look like PyTorch anymore.

On: Samsung bets on MicroLED and 8K for its premium 20...

[eiriklv]

I had the exact same issue and spent a lot of time figuring out why this was a problem for me, as I would alter between my old 15 inch and new 16 inch and feel the difference each time.

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...

[eiriklv → eiriklv]

It also helps to use the default resolution to avoid supersampling/anti-aliasing effects.

[yumraj → eiriklv]

Just saw this - I had played with numerous settings for a long time and some seemed to make it better, some not so. I did not try your solution.

BTW, I don't run into any issues with the 13" M1 AIR also. So, decided that it wasn't worth it for me to have to fiddle around with setting on a rather expensive piece of hardware and decided to return it and wait in case Apple launches a 15" MB Air with a regular (as in not mini LED) screen.

In they don't, I'll give the 16" MBP another shot and might try your solution.

On: Software Library: MS-DOS Games

[eiriklv]

CRT monitors made things look so much more vivid than on LCD. So when you look at old games today and think «Did it really look this bad and pixelated?», the answer is actually «no».

Ref: https://www.reddit.com/r/gaming/comments/anwgxf/here_is_an_e...

Edit: typo

On: The reMarkable as a notebook and eBook reader

[eiriklv]

Another lefty here - same issue. Did the pre-order long ago. I’m back to pen and paper as I could not tolerate it. It would be great if it was possible to calibrate it somehow, by hack or not. I’ve kept it in case such a solution surfaces.

[raffraffraff → eiriklv]

I definitely think they should be petitioned for a left-handed mode.

Edit: it has left handed mode?! Perhaps I've already set that, but it isn't thorough enough? Gonna go check now. Btw, it's under settings, accessibility.

On: Open Insulin Foundation

[eiriklv]

How much of the insulin is used for type 1 vs type 2?

On: Diablo II: Resurrected

[eiriklv]

That might not all be attributed to nostalgia. CRT displays actually make things look more hi-res and «depthy» [0]. We’ve barely caught up with 4/8K and OLED. This is why CRTs are so popular for retro gaming. Some effects aren’t even possible to display correctly on a non-CRT (without shaders at least) [1].

[0] - https://www.reddit.com/r/interestingasfuck/comments/9xg8w3/t...

[1] - https://mobile.twitter.com/gamesnosh/status/1232731118354550...

On: React is becoming a black box

[eiriklv]

Hooks are both a blessing and a curse.

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.

[ceedan → eiriklv]

Well said. I like the idea of generators if possible, but have no idea if it actually is possible.

> they are so tied to some «magical» implementation that requires a large set of rules to behave as expected 100% agree here & with your sentiment about the Class API

[mrloba → ceedan]

I tried this, and it's possible using a monadic interface. Just like replacing promise.then with async await you can replace monad.flatmap with generator yields. But I've already seen this concept discussed by the react team and it seemed they didn't like it.

What's cool with a monadic interface is that you can create lots of other interesting things, as long as you adhere to the interface. For instance, I think it's possible to achieve something similar to async render functions without specific support for it.

[zestyping → eiriklv]

> Maybe some form of implementation using generators would bring it closer to the language

That's what https://crank.js.org does. I haven't tried building a real app on it yet, but I have to say it does seem pretty elegant and promising at a first glance.

[rashkov → eiriklv]

Thanks for the idea. I've formulated a small version of this problem as follows, and provided a solution elsewhere in this thread:

  const React = /* Implement this */;

  function HelloComponent(){
    const [myNumber, setMyNumber] = React.useState(0);
    // Simulate rendering data to a screen
    console.log("My number:", myNumber);
    // Simulate rendering a clickable button
    const click = ()=> setMyNumber((num)=> num + 1);
    return click; 
  }

  React.mount(HelloComponent); // prints 0
  React.simulateClick(HelloComponent); // prints 1
  React.simulateClick(HelloComponent); // prints 2
  React.simulateClick(HelloComponent); // prints 3

[thursday0987 → rashkov]

this is a pointless example. it doesn't render anything, and therefore doesn't have to deal with React's render cycle.

also, you shouldn't use useState unless you want it to rerender, which you don't because you're printing to console. use a ref instead for myNumber.

the problem you are trying to solve, updating a number if someone clicks on something, is already solved in React:

    const HelloComponent => React.forwardRef((props, forwardRef) => {
     const myNumber = useRef(0)
     const printToConsole = () => {
        myNumber.current = myNumber.current + 1
        console.log("My Number:", myNumber.current)
      }
      render (
        <div ref={forwardRef} onClick={printToConsole}>click me</div>
      )
    }

then you can simply trigger a click by calling .click() on the forwarded ref wherever you happen to mount it.