What really disturbs me is this comment:
,,But no one said fs.promises.readFile should perform similarly to fs.readFile ''
I'm happy that it was downvoted at least, but there should be a better way to set expectations for excellence in development.
,,But no one said fs.promises.readFile should perform similarly to fs.readFile ''
I'm happy that it was downvoted at least, but there should be a better way to set expectations for excellence in development.
The programmers didn't bother to free() any of their memory - instead they just calculated the maximum amount of RAM their program could consume while the rocket was in the air, doubled it, then installed that much ram in the rockets.
The author owes me a new keyboard.
Am I the only one who is terrified by reading an "amusing story" about "on-board software for a missile"? The amusement sort of requires us to completely ignore the individuals being blown to pieces.
Presumably, the RAM was a rounding error in the total budget.
And this move eliminated an entire class of bugs (use after free).
edit: And, you don't have to worry about memory fragmentation, or how long free() might take in the worst case.
I think a better approach (and one which NASA uses from what I've read) is to only use static memory.
In 1996, Ariane 4's successor, Ariane 5, took its maiden voyage to carry the Cluster constellation into orbit, when this happened https://www.youtube.com/watch?v=gp_D8r-2hwk&t=54s
Ariane 5 used a different launch profile. The impossible was now possible and the 16 bit value overflowed. The inertial reference system failed, along with its backup (which was running the same code), causing the rocket to receive wrong data.
At the same time, having added big uppercase warnings in the Ariane 4 source code and architecture docs, might have prevented this.
So, important, in safety critical code, to assume that others might blindly copy paste in bad ways -- and then try to warn them, although you might not be there any longer
The new one did not have these interlocks, instead doing everything in software. The result of this was a few people being fatally irradiated when a certain race condition was triggered.
It's not going to malloc randomly...
In fact, it's common in real time applications to pre-allocate everything you need at the start of the program or use static memory, and never allocate afterwards.
Don't take this for defending him, but it's in the realm of possibilities ¯\_(ツ)_/¯
I think his point is valid even if slightly tongue in cheek. Bugs are defined by the contract / specification not wishful thinking.
Do you categorize thinking that JSON parsing takes at most O(n log n) time as wishful thinking as well?
It's humanly impossible to code for contract, that's why generally it's important to strive for no surprises in an API. This is the only way to build more and more complex software over time.
If this is how you do your work, you are asking for a computer to replace you! We should aspire to be better than this. It’s crazy to me that people take massive salaries and expect other people to spoon feed their tasks to them.
I remember being one of two software engineers working on a project in a small company. We were cooperating with two bigger companies delivering other parts of the system.
I kept asking myself: "These guys have hundreds of well paid engineers working on this, and they never deliver! Are they sabotaging the project?".
In the end we delivered the finished prototype and the customer ran a 48h acceptance test, their parts fizzled out almost immediately, while ours just kept running.
It took me a few years and joining a bigger company to notice that thinking about what you're doing is not expected in bigger corporations, where everything is bureaucratized. Also if the company is big enough it can shift the deadlines set by its customers. It drove me near madness whenever a colleague said something "wasn't their job". I never heard such an attitude before, and these people were paid twice as much as in my previous company.
I still, to this day, hope that a lot of these people get replaced by computers. Defective programs can at least be improved.
“Not my job” people tend to be the most frustrating folks to work with. While I understand wanting to mainly do the work you were hired for, there are always going to be times where you have to roll up your sleeves and do something different.
I wish I was the kind of person who would thrive in that environment because it sounds nice, but I’m not wired that way.
"When I pass X in, I'm not getting anything back - no error, I can't see the logs. Can you assist?"
"Not my job - you figure it out. We can't be expected to know how everything works."
"Yes but... this is literally something your team wrote in the last 3 weeks to support the larger project we're all on, and I was told to make my code work with yours. Have you ever tested taking input? If so, what am I supposed to pass in to your system?"
"Not my job - we're not here to babysit you - go read the code."
Later... someone else...
"Why are you spending all the time trying to trace through this code? You just have to ask. You have to learn to talk to people."
I sent over screenshots of the previous 'conversation' and got nothing back.
Thankfully this doesn't happen very often, but I'd realized that this org had segmented some teams so poorly, and put such deadlines on, that the culture of half the teams was "do minimal work and throw it over to someone else". It was more confusing because I interacted between a few internal teams, and some teams literally did not believe other people behaved this way. Even with written evidence, the problem was always assumed to be "oh, you're just not asking the correct way".
I’m not sure where in my comment you got the idea that I was advocating for engineers to have their tasks spoon fed to them by other people. My comment is simply about reading comprehension and not arguing against strawmen.
I think as a general rule it is good to assume the best, even though I myself might not always be able to do so because of various limitations of understanding.
Then again, 206 downvoters didn't seem to think so (unless their reason for downvoting was objection to such a low form of wit).
Now when I think about it
> such a low form of wit
I think it's fun :-)