ORMs would be my next battle, but SQL injection could become an issue if not treated carefully, so I would still consider libraries like SQLDelight or other SQL first libraries

I want that experience to be good, and not using a subpar tool like (Teams, IRC etc)

As a rule of thumb, I want to use the best tool available for the job, IntelliJ for the IDE, the best coding model (whatever that is at the time), the best Video call tool, the best monitor, the best keyboard etc

Although best is usually subjective, in some of this cases what is "best" is objectively clear, in some cases the gap between the best and the next one is small in others is huge. In the case of communication tools I think the difference is huge.

Is this needed to do my work? nope It makes working more pleasant? definitely yes

Avoid July and August, horrible heat and most people have left the city

You mean it's bad that you don't have to wait in lines or get into crowded spaces?

27” 5k (5120 x 2880) -> 218 PPI

32” 4k (3840 x 2160) -> 137.68 PPI

34” 5k (5120 x 2160) -> 163.44 PPI

39,7 5K (5120 x 2160) -> 139.97 PPI

Apple Pro Display XDR 32" 6k (6016 x 3384) -> 218 PPI

PPIs will display sharper pictures, provided that they have enough quality.

You don't get more real estate, indeed, since that depends on zoom level. However, depending on your setup and habits, you may actually gain some. In my case, I use 4k at 100% zoom. I don't care for window decorations, interface icons and so on, so it's not an issue if they're small.

Have a 27" 4k monitor and a 42" 4k monitor? Move the 27" close enough that it takes up the same FOV as the 4k and you get the same experience.

This isn't like home theatre where you're constrained to the dimensions of a room (ie. wall or console location a TV sits on top of and seat viewing distance).

If that is true, I'd consider move the screen closer to not be an option.

Otherwise this is a commonly propagated myth related to radiation from early TV sets.

https://theopticalshoppetn.com/is-sitting-too-close-to-the-t...

I do dislike the fact that Apple removed decent support for lower resolution monitors, but I also don’t see why anyone would prefer them to higher res unless it’s a budget issue.

This forces you into 5k screens, or tricks to make the OS do actually useful scaling.

I'm also unable to believe someone would consider 27" 4K text illegible on a mac since that's what I use that every day and can read text comfortably. Edit: Unless you're using it unscaled, then yeah, text isn't that legible.

These are strange statements to make without any detail.

https://github.com/waydabber/BetterDisplay

I'm saying macOS is unusable on native resolutions - everything is either too small or too blurry, so a 4k display won't do me any good. 25x14 is the sweet spot for me, but I guess Apple decided I'm holding it wrong, because they want me to get a 5k display to get usable 25x14.

ABNB creates externalities to the countries where it operates (increase rent prices), so it would make sense to tax them because of it.

And if they don't like the tax, they are free to stop operating in that country ;)

I guess ultimately it depends on which language you are more familiar with...

    type Message 
        = IncrementBy Int
        | DecrementBy Int
        | Set Int

In Dart, if you do:

    sealed class Message {}

    class IncrementBy extends Message {
      final int amount;
      IncrementBy(this.amount);
    }

    class DecrementBy extends Message {
      final int amount;
      DecrementBy(this.amount);
    }

    class Set extends Message {
      final int amount;
      Set(this.amount);
    }

    onlyOnIncrement(IncrementBy increment) {
      ...
    }

    sealed class Message {
      final int amount;
      Message(this.amount);    
    }

    class IncrementBy extends Message {
      IncrementBy(super.amount);
    }

    class DecrementBy extends Message {
      DecrementBy(super.amount);
    }

    class Set extends Message {
      Set(super.amount);
    }

    showAmount(Message message) {
      print(message.amount);
    }

It's only more verbose for the code that is defining new types. Code that is simply defining behavior (either in functions or methods) is unaffected and my experience is that that's the majority of code.

In practice, most real-world Dart code that uses sealed types also defines methods in those types, getters, and all sorts of useful stuff. Once you factor that in, the data definitions themselves are a relatively small part.

(Of course, you could argue that defining class hierarchies is already intrinscally bad. But Dart is an object-oriented language targeting people that like organizing their code using classes.)

    type Message 
        = IncrementBy Amount
        | DecrementBy Amount
        | Set Amount

    type Amount = Amount Int

Given the above ADT, how would you write a function that prints the amount of a Message, regardless of which case it is?

Of course, you can also reorganize you datatype so that the shared state is hoisted out into a record that also contains a sum typed field for the non-shared stuff. But that reorganization is a breaking change to any consumers of the type.

Modeling this on top of classes and subtyping lets you make those changes without touching the user-visible API.