And the usual corollary: Not just thanks to his training data, but because training data of that kind and for this kind of topic - still - exists.

>verifiable "never looked at the original source"

...erm.

To adress the elephant in the room: Who exactly is supposed to be verifiable to never have looked at the original source? You or the LLM?

Both. Good question.

Although it would be much harder to prove, of course, that I never saw the original code/implementation.

The new Windows 11 22H2 task manager?

Works just fine here (1920x1200 125%, 4K 150%, 1080p 100%).

Nah, that's not a "sacrifice", but the only sane way. In the ideal case, clearly document the constructor with a warning that it's not ISO conformant and offer a ISO conformant alternative.

In my (unfortunate) experience, DateTime/Timezone handling is one of the things most prone to introduce sneaky, but far-reaching bugs as it is. Introducing such a behaviour change that (usually) won't fail-fast, will often seemingly continue working as before until it doesn't and is deceptively tricky to debug/pinpoint/fix ist just asking for a fast lane into chaos.

And even with JS going the extra mile on backwards compatibility, I don't think most other languages would introduce that kind of breaking change in that way either.

>Ok, you can click on the sun icon to fix it by switching to night mode, but then... aaaaargh!

TBF, I felt so perfectly trolled with this one I couldn't help but chuckle... :)

Huh, fascinating. The Patagonia structure is actually strikingly similar to the Bosch model - non-profit owning the shares, but no voting rights, trust having voting rights but no shares - just taking it to the logical 100% conclusion without the residual influence of the Bosch family (having retained a few percent in both).

The model has worked well for many decades for a 100 billion$ revenue company like Bosch, good to see others taking a cue from them.

(Also goes to show that even constructs like these are not safe from corporate fuckups - see the emissions scandal...)

>and has the best parts of Typescript

I really like C#, but I wouldn't go that far - unions are at least on the horizon, but I've sometimes come to miss the power and flexibility of TS's structural typing...(And so has Hejlsberg, apparently, seeing his reasoning for choosing go over C# for tsc :) )

>And so has Hejlsberg, apparently, seeing his reasoning for choosing go over C# for tsc

It was more related to the fact that the existing TS code was more easily ported to Go, and also .NET AOT wasn't mature enough at that time. Structural typing has its own problems. I'm personally not a big fan of it.

Might be my own taste, but except a few of the common and easy to understand structural typing code, I find it sometimes actually make things needlessly complex.

I also write lots of Typescript, and the furthest I go is to use 'Omit' and other utility types, but already feel like it's too much.

I've come to really appreciate Typescripts structural typing, because it reduces some of the overhead & prevents the unnecessarily tight coupling that has often annoyed me in other languages.

The overhead argument seems fairly objective to me - clean code with low coupling in C# et al. requires separate definitions of interfaces and implementations, explicit conversion methods between compatible interfaces etc. This adds up over time and makes refactoring pretty annoying.

The tight coupling happens when people don't bother to define interfaces. Suddenly I have to couple class hierarchy to classes from unrelated modules, all so the compiler is happy when I pass structurally equivalent data. To keep my own modules clean I have to add yet more interfaces, conversion methods etc!

It prefer static functions and stuff we can quickly understand, avoiding big objects or a great deal of indirection. Don't tell Uncle Bob!

Of course, you'd still need interfaces for DI, mocking etc, but that's pretty most of my interface usage.

I hope once they introduce unions, they also introduce some sort of error union.

>- Less bugs (Visual Studio has been progressively getting worse).

Eeeeeeh...it's not quite roses and rainbows on the Rider side either, and that's coming from a Jetbrains fanboy. (Although admittedly, I'm not really up-to-date on the current state of VS in day-to-day work)

But yeah, the coding/refactoring support (Resharper et al) and general quality and integration of tooling (database tools, package managers, version control, debugging (esp. multi-process) etc.) is the big one for me.

> Eeeeeeh...it's not quite roses and rainbows on the Rider side either, and that's coming from a Jetbrains fanboy

Obviously. IME it is better than Visual Studio.

> But yeah, the coding/refactoring support (Resharper et al) and general quality and integration of tooling (database tools, package managers, version control, debugging (esp. multi-process) etc.) is the big one for me.

I rarely use any of these tools tbh. I just want Resharper and something that works reliably on Linux. I would transition to using vim entirely but half the vim stuff I like using I can't use with Windows (work is never not going to use Windows).

In the context of this thread that's a non-issue. Good TVs have been in the ~5ms@120Hz/<10ms@60Hz world for some time now. If you're in the market for a 4K-or-higher display, you won't find much better, even among specialized monitors (as those usually won't be able to drive higher Hz with lower lag with full 4k+ resolution anyway).

I think the best description of this kind of "obfuscation" that especially afflicted Java still is Steve Yegge's "Kingdom of Nouns" rant:

https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...