My Hyundai likes to auto slam on the brakes when cars in front of me turn off the road, even when I definitely won't hit them. It's almost caused collisions with cars behind me.
> ruining HN with 10 articles on the front page per day about how software engineering is dead.
Even this article, which is theoretically about playing games on a MacBook and not about AI, has devolved into AI discussions. It's honestly kind of tiring.
I suppose the article invites it by putting an AI blurb up top, and I suppose I'm also not helping by adding my own comment, but _still_.
It's honestly kind of chilling just how effective smear campaigns can be.
I don't think there's any reasonable person who could read the full medical description of the injuries sustained and think "yeah 2.7 mill was too much".
Yeah, I also don't understand their take. HN also dictates what their users can and can't read. There's tons of stuff that can't be posted here without being removed. That's a good thing.
There's technically a proposal to add immutable lists and records floating around somewhere. I think it's kind of old at this point. I'm still hoping it makes it through, though.
Oh for sure. This is definitely one of those "inherited some weird & inconsistent legacy system" situations.
Honestly, it didn't even register as a potential issue in my mind until I had a chance to use LINQ query syntax in C#, and thought it was kind of nice to have the `from` up front. It's a minor annoyance at most, at any rate.
I'm not sure. I think it's fairly common for something like "Now was the column name on this table description_primary or primary_description? I can't remember... Oh well, I'll just SELECT * and figure it out later" to happen. Starting with FROM would at least eliminate that backtracking.
Interestingly, the mathematical definition (and functional programming definition) of idempotency is slightly different. Or I've seen it used slightly differently, anyways - specifically, a function is idempotent if the result of f(x) is the same result as f(f(x)).
I've seen this lead to some confusing back and forth between software engineers, where one engineer means one definition, and the other engineer meant the other definition.
An interesting choice of words. "I don't have the data to back it up" seems to want to imply "we don't have the data at all". But I don't buy that Amazon, of all companies, doesn't have the data. I assume they have it, and it doesn't back what they're trying to push.
Can't speak for every case, but local concerts usually only made a bit of money when we were the ones hosting the show somewhere, inviting other bands, and selling tickets. Even then it was a bit of a gamble. More than a few lost us money.
Otherwise, if we weren't hosting, the money we were paid for playing wasn't even enough to cover band expenses (instrument maintenance, travel costs, etc). Selling merch helped. Selling LPs / EPs was usually just an attempt to make back the cost of recording them in the first place.
If the band was signed, things were different depending on their specific deal. But those bands probably don't count as just "local" anymore, at that point.
Technically you can have noticeable differences before you even make it to 1 cent. For example, if you're trying to determine if a result of a calculation is negative, 0, or positive for whatever reason. With floats/doubles, you would probably need to consider "0" to actually be "a number sufficiently close to 0, if not 0 exactly" and then remember to handle that everywhere.
It can also be noticeable if you're just trying to calculate something like "is the invoice paid off". Maybe your view layer is showing $0.00 balance to the end user, but the backend hasn't correctly rounded off those extra bits from a floating point calculation, so your backend logic is now saying the invoice is not actually fully paid off, even if the end user has no idea what they could possibly still owe.