stinos

Wel yes, that's exactly my point: when done like that there's a watchdog in place. My issue (or rather reluctantce to use it) is that HA and the likes provide as far as I'm aware no watchdog features for systems which don't yet have it. Think some hardware AND-style gate which is only going to apply HA's last state if, say, HA can prove it is up and running properly.

- having HA control your heating's on/off hours, where the watchdog is the heating's thermostat making it stop heating when it's warm enough or forces heating if it gets too cold. So HA crashing and leaving the heating in heat mode might be just a waste but not a serious issue.

- having HA control the wanted temperature on the other hand is more problematic, because for all I know it could misbehave and make the heating want to go to 30 degrees Celcius or to a value so low that there's no frost protection anymore, then crash and never get it out of that state anymore. And there's no watchdog anymore correcting for it. Potentially this can cause issues. Chances are small, but I don't like the idea that AFAIK these chances are much larger than standalone heating acting up like this.

Likewise we can now opt for a dynamic electricy tarrif, basic idea being that for instance when you now the prices are going to drop below a certain threshold during the night you're going to tell your home battery to charge at that time. Of course the thing acts like a watchdog for itself in that it stops charging when full, but there is no watchdog keeping it from charging continuously. In other words: if it's put into charging mode and HA crashes and leaves it in charging mode then it will happily continue charging during peak hours. Not 'serious' per se but pretty stupid.

For starters for normal desktop usage like >95% of the time the thing I want to click on isn't under the mouse yet so it doesn't obscure anything. Instead I move the mouse to it and by the time the mouse is there I don't care what is under it anymore because the decision to click it was made already.

Second when the mouse is over something I need to be able to read it seems I tend to move the mouse away (even when it's over text and turns into a straight cursor). The reason being that no matter what cursor is used its lines are typically wider and higher than the lines in rendered characters underneath so always obscures something. In other words: even if the cursor weren't tilted it would still obscure the same amount of surface, but just in a slightly different location. And that's really only slightly so for practical use won't matter.

Wrt where something is approached from: that depends on where the cursr is and where the target is. It would be really interesting to put this in a heatmap from daily usage, but I quickly checked some of the things I access often, like in my bottom taskbar and browser tab bar at the top, and since the things clicked often are both left and right of the screen and my cursor can be seeminlgy anywhere there might still be one approach direction used more but only by some marging.

Lastly most software I checked where obsucring could actually matter (e.g. CAD) uses custom cursors like 1 pixel wide crosses etc, not something tilted.

Well, ok, then I simply misunderstood the intent of your comment.

Normal people hate

I have no idea where those claims come from, or what you mean with normal people. Source?

E.g. wouldn't normal people rather just ignore articles about stuff they do not care about instead of hating it?

Isn't the takeaway from this study that they aren't really, but rather that once they happen to come close to it they cannot get away from it anymore?

The huge amount of times I saw

    //This makes everything work somehow
    sleep(1)

That's sort of the point though: we do that, but whereas around y2k forums were the online communities, I don't exactly have the impression that is still the case. And it's not like you're going to see much NSFL content on, say, TikTok.

But in any case: yes, I know it's a different context, but that's not the question. Rather: is it realy that easy to just separate context 100%, and at will?

On the other hand many people, if I had to guess I'd say the vast majority, have not seen any of that stuff on the internet. I have, but because I actively went looking for it. Likewise if I ask around amongst friends the only ones who saw the real gore all admitted having actively searched for it. In other words: even before we saw it there might have been something different in our world view already.

Yes, because for every unit of energy you directly put into it (in the form of electricity) it outputs more energy (in the form of heat). Which is unlike any other typical heating system, which usually puts out less or at max the same amount.

In my opinion they still are pretty unique because their efficiency is higher than 100%. Which was what I thought the sentence would continue with when I started reading it. Cannot be stressed enough. It's like magic :] Sure your LED is more efficient than your incandescent light bulb, but it still produces heat which is not intended nor really wanted. In my book there's no comparing that to a heat pump. That being said, not really a fan of such sentences either.

Who are these people, really? I mean, I was that for a rather brief period of like a year, somewhere 3-4 years into programming IIRC. I met others like it. But in the end people seem to learn and grow out of it, and rather quickly so, because it becomes clear what the issues are quickly. Really good learning by mistake though, wouldn't have wanted to miss out on it.

mantra

That's imo just another mistake to make: wrapping a rather strict and narrowly scoped principle in a paradigm-like-must-be-followed mantra hurts the right-tool-for-the-job idea, which feels vastly superior.

Firstly the idea that unmaintainable code is necessarily an issue is already wrong to start with, in my book. Obviously it's not ideal and where appropriate - meaning nearly always - should be avoided at pretty much all cost, but I have enough examples where it does not matter at all. As in: code which hasn't been touched in 20 years and probably won't ever be touched. Does it look like a nightmare? Yes. Does it work correctly? Yes. Does it need changing? No. So, is it an issue where spending time (or having spent time) on it would make anything other than the programmer's peace of mind (well, or ego perhaps) better? Clear no.

Secondly: of course I get where you're going with such definitions but it again lacks the very much needed nuancing. I can write unmaintainable code in one file but where you need to change 20 different locations. You could than claim that your mantra still applies because the code should have been split over 20 files, but yeah, that's what you get with mantras :) Likewise depending on the feature it's perfectly possible many files have to be changed but that doesn't necessariy mean the code is hard to maintain. Could try to claim that it wasn't very well architected to start with, maybe, but welcome in the real world where not everything can be thought of from the very start except in small toy applications.

Now: the way I approach an example like this is similar to what you do, but the difference is that I'm merely aware there's a bunch of different containers out there which behave in different ways wrt lookup/add/remove/... and for the vast majority of them I have no clue about the implementation. I don't need such implementation knowledge to realize that another container might be the trick here. I also don't really need that knowledge to decide which container that eventually might be, nor to come to conlusions fast (since you're stressing that): that's a couple of minutes to lookup moreover the final decision stage will be through performance testing anyway, because measuring under actual usage is the only way I'll ever be convinced one is effectively better than the other. That's usually what is going to take time, not picking one out of x. In the extreme it might even be so that I'd first need to write a wrapper to then have a configurable container type just to be able to have people test it under different workload types, etc.

Obviously I've been through this a couple of times and by doing so did become aware of main traits of various containers/algorithms/... and yes that will be somewhat faster in the decision process. Likewise there have been certain domains in which I did dig down all the way to the very bottom and obviously having to sort out problems in that domain will be faster for me. But in the end: for me personally 'x algorithms programmers should know' is useless. Job-dependent perhaps, on the other hand I've seen enough people struggle to come up with actual and practically useful software aspects exactly because they kept on getting lost in implementation details.

- some sensor triggers lights on via impuls relay (that's what I have to happen in my home), HA stops functioning, lights remain on. How to make sure instead they're turned off? I get that not using impuls relays but relays which need to be driven high constantly might be one step in the right direction, but that would still assume whatever line the relay is driven with is pulled low when HA stops functioning.

- you setup HA to instruct your home battery to charge during off-peak hours, HA stops functioning during off-peak, battery is left in 'charge as much as you want' state. Unless battery has functionality to tell it 'charge max x hours' it will try to keep charging, whereas it would be nicer if it wouldn't

- same for heating: leave for vacation, tell HA to put heating in low power mode but to start heating the house again in normal mode 3 days before I'm back (because that's roughly the amount of time needed with low temp heating to get everything warm again). HA stops, I come home to a cold house.

   git ls-files -m -o --exclude-standard | fzf -m --print0 --preview "git diff {1}" | ....

Yeah, I have a bit of a love-hate relationship with it. But I actually have that with all shells out there. I don't know if it's just me or the shells, or (the most likely I think): a bit of both. But PS is available out of the box and using objects vs plain text is a major win in my book, and even though I still don't know half of the syntax by heart it feels less of an endless fight than other shells. And since I use the shell itself for rather basic things and for the rest only for tools (like shown here), we get along just fine.