I'm perfectly aware of the fact that IEE 754 ROUNDS floats as you can't, for obvious reasons, represent them exactly. However, if we really want to hammer details here, how would you represent Pi in binary EXACTLY? The most obvious approach would be a classical LongInt: that is a number array with each number representing a digit. But the Pi digits we're talking about are decimal so now we don't get every possible piece of binary data! Well, sure, you could calculate & represent Pi as hexadecimal digits but what's with the underlying computing system? RAM is, generally, organized in pages (on a system you would calculate Pi anyway and I sure as hell wouldn't do this on an MCU with a raw memory model) and you don't know how those pages are laid out, you don't even know if you can fill those pages! My point is, if you really don't want to take this with a wink, if you really want to go into the details in a pedantic manner, the statement in the OP isn't nearly as clear as if you take the basic idea and run with it. I'm somewhere between a physicist and a software engineer, not only do I need pedantry in my job, I love it! Well, I don't technically need it, I got co-workers proving day after day that you don't need discipline, that clearing up the mess arising from handwaving important details but I'd rather pour effort into fun parts of the job and clearing up a mess I've let lying around isn't fun. However, this is the lounge here, not a specification meeting, and the OP got a fantastic idea in theory. So I'm treating this one with a wink. Without winks, arbitrary precision doesn't make sense. Without winks, you need a precision up to a fixed point. This point depends on the use case, of course, but there's still a finite point to which we need numbers to be precise. Including measurement results, including Pi. So if you really want to get into the practical implications of all this, then Pi is effectively finite.

I've studied physics and there, we got methods to get right answers from values with finite precision B)

Not according to IEEE 754 :p

This makes me thing of a soldering project from a while ago. It came with a couple pushbuttons and an instruction sheet on how to get stuff done with those pushbuttons. Not exactly impossible, far from that, but I found that digging through the code & uploading a custom binary to the MCU is sooooo less hassle than controlling this thing with the buttons.

I consider a lock failed if it doesn't let me bloody in (and apparently, safety overrides weren't in place) and yup, that's what happened.

That's not new. Smart doorlocks failing because of an internet outage ain't even news anymore. The HP one is harmless by comparison.

Maybe there's method in this madness after all. A while ago, I've read an article speculating about Musk being overworked. If that's true, then fucking up as much as possible to show everyone that you are in fact overloaded isn't the best coping mechanism, but it is a coping mechanism.

Living in a country with strong customer protection agencies (backed by strong customer protection law) got its perks: I don't have to sip through this legalese which, I swear, is written in a manner as obtuse as possible on purpose. Should they write something there which puts the user at an unfair disadvantage, it won't hold in court anyway so I don't have to care. I'm not bothered about missed appointment fees. In fact, they could be higher. It's not like they're doing it to earn an extra buck, appointments are a rare commodity and if you don't use your slot and don't tell them so they can fill in another patient, that's actually kinda evil.

Now they just need to make the taskbar side-dockable again.

Nit UX design but processes. I had a boss who had literally 0 idea that you FIRST define the requirements for a process and AFTERWARDS define the process. He dictated me a process that's somewhere between a fever dream and a friggin' joke and went very personal very quickly when I started explaining, based on the known facts about the product strategy, how exactly this process is a bad idea. This asshole doesn't work here anymore.

I'm rather happy with my Razer Chroma. This thing could use some less key travel but on the flipside, it's got rather defined pressure points. Really hard-defined pressure points. Got my GF such a thing for gaming, tried it and bought myself 2. One for home working/gaming, one for the office.

The problem with doing stuff you like is that you naturally gravitate towards eating while doing said stuff you like. It is a problem because that's kinda shitty from the health perspective, both metabolic & mental so I force myself to get away from the home office desk for lunch.

I'm pretty sure ~90% of that stuff gets created as a learning experience for the author. Hell, even the stuff that makes it into mainstream may lack a product vision, growing instead of being designed. I personally would not consider myself a luddite but I think "do we really need that" more often than "hey, that's some cool new stuff". Actually, I'm a huge tech/software enthusiast. It's just that I'm also a huge fan of use cases, tech solving use cases, not tech for the sake of tech.

This bloody #include hell is huge reason why I'm looking forward to widespread standard module support. Until then, I combine all the external includes into one header & include that.

Sim City is/was massively popular. Rule of thumb: if the user changed something and things break, the user blames that something. That is, if the user upgrades to Win95 and things break, user will blame Win95, instead of the sloppy QA that went into Sim City.

Speak for yourself. I, for example, love ?? and switch expressions for making the syntax more readable, actually. They are concise, that is, there's less syntax to achieve the same thing, meaning less overhead to parse when reading.

At the basic level, they're close. Very close. When it comes to finer nuances, C# got ways to write concise code that Java doesn't (top-level statements, switch expressions to name two examples). There's also some nice syntax sugar in C# that Java doesn't have when it comes to OOP. But overall, they're REALLY similar. After all, they all inherit the basic C syntax. I switch between C# (my main development language) and C++ (a project of mine is a user-mode driver the binary requirements for which .NET won't fulfil without bending backwards) and the transition isn't too bad. Syntax-wise, Java fits nicely into the same family.

It's certainly not bad. You can do low-overhead programs in C# just like you can do in Python (which, I presume, is what they're doing for teaching purposes), you can go fully-blown structure like you'd do in Java. Speaking of structure, C# is well-structured and allows learning concepts without delving too much into the implementation. Which is, as far as I'm concerned, a good way to learn such things. Too many co-workers of mine tend to get lost in the details, missing the big picture, as if they never learned to think outside of low-level details...

I'm annoyed by Linux for similar reasons. It's a lot of hacks on hacks, a lot of accepting the status quo as how things must be instead of taking a huge step back & re-evaluating whether the present behavior really is the best platform to build the future upon. However, do you really have to deal with it every 90 days yourself? Meaning, can't you schedule that stuff (assuming there's no more troubleshooting involved)?

Depends on the language the original was written in as well as how well-structured it is. I would go about this by first and foremost separating business logic from plumbing. Then, by mapping the APIs used in the business logic part to .NET parts. While P/Invoking them is certainly feasible, that's only advised if the goal is defined as sticking as close as possible to the original and/or there's no corresponding .NET APIs.