91–100 of 338 posts
Earlier quoted context omitted.
This is a whole class of problem - I wonder if there's a name for it. More examples include: talking about welfare being unnecessary because no one is starving. Or people on medications stopping because they feel better (while still on them).
Like when people say to IT: "Everything's working, what am I playing you for?!"
I recently experienced a nasty bug with BLOB in MySQL. The software vendor was storing a giant json which contained the entire config in a single cell. It ran fine for months, and then when it was restarted it totally broke. Reason was: the json had been truncated the entire time in the database, so it was gone forever. It was only working because it used the config stored in memory on the local system. Nasty!
Earlier quoted context omitted.
Nope. Definitely not goofy. My dad was a programmer in the early days. The machines he started on in the 1960s had 8 KB of RAM. Saving a byte then is the equivalent today of saving 1 MB on an 8 GB machine. Multiply that times, say, the thousands of customer orders you're trying to process and the goofy thing would be burning a lot of additional RAM because it might help somebody 35 years later. Who among us is writin…
>Who among us is writing code today worried about how it will be used in 2052? This decade I knowingly wrote code that will break in 2036 [1]. My supervisor was against investing the time to do it future-proof (he will be retired by 2036), and I have good reason to believe the code will still be around by that time. I don't think I'm the only programmer in that position. [1] Library specific variant of the y2038 prob…
Sure, but how bad was it really? Something you could fix relatively quickly with a little time and money, or an instance of Lovecraftian horror unleashed upon the world like so much COBOL code?
It's fascinating... the Y2K problem never came to fruition because - arguably - of the immense effort put in behind the scenes by people who understood what might have happened if they hadn't. The end result has been that the entire class of problems is overlooked, because people see it as having been a fuss over nothing. I sometimes think it would've been better if a few things had visibly failed in January 2000.
My long-term active retirement plan involves building a year-2038 consultancy.
Earlier quoted context omitted.
Similar to how much effort goes into dealing with things like dangerous strains of bird flu, only to have people complain about how much money was spent on "nothing" when an outbreak doesn't occur.
This is a whole class of problem - I wonder if there's a name for it. More examples include: talking about welfare being unnecessary because no one is starving. Or people on medications stopping because they feel better (while still on them).
https://en.wikipedia.org/wiki/Availability_heuristic
The availability heuristic is a mental shortcut that relies on immediate examples that come to a given person's mind when evaluating a specific topic, concept, method or decision. The availability heuristic operates on the notion that if something can be recalled, it must be important, or at least more important than alternative solutions which are not as readily recalled. Subsequently, under the availability heuristic, people tend to heavily weigh their judgments toward more recent information, making new opinions biased toward that latest news.
Earlier quoted context omitted.
> Self-confidence as a programmer is when starting a new project, storing the transaction ID as a long rather than an int... uint64_t even Or a UUID as others have suggested. Technically C spec doesn't really say exactly how many bits int, long and long long should be. If you want specific sizes and your code to be somewhat portable use the specific bit sizes to make that clear. There are also types for size-like thi…
> If you want specific sizes I would go further and say you should _always_ use specific sizes, unless forced otherwise. There's no reason not to.
Self-confidence as a programmer is when starting a new project, storing the transaction ID as a long rather than an int...
Earlier quoted context omitted.
> I sometimes think it would've been better if a few things had visibly failed in January 2000. Having to spend billions of dollars on programmers' goofy means of saving a few bytes of memory is a pretty visible failure.
Nope. Definitely not goofy. My dad was a programmer in the early days. The machines he started on in the 1960s had 8 KB of RAM. Saving a byte then is the equivalent today of saving 1 MB on an 8 GB machine. Multiply that times, say, the thousands of customer orders you're trying to process and the goofy thing would be burning a lot of additional RAM because it might help somebody 35 years later. Who among us is writin…
Spending that much money on storing "19" just so your code keeps working in the unlikely event that it's still in use 3+ decades into the future isn't a good tradeoff. Obviously things are different now.