171–180 of 327 posts
// CSINameTranslator can get the CSI Driver name based on the in-tree plugin name type CSINameTranslator interface { GetCSINameFromInTreeName(pluginName string) (string, error) } Do people actually find comments like the above useful?
// KEEP THE SPACE SHUTTLE FLYING. I understand the intent, but it is a bit funny that the comment references a system that is no longer operational due to its poor safety record. In ten years or so, will people even remember the Space Shuttle in a good light?
Per passenger mile traveled, the most common measure, it's one of the safest vehicles ever created and flown.
> will people even remember the Space Shuttle in a good light?
This is an honest question, since my childhood was squarely in the 1980s, but how can you possibly not? Are you so young that your only perspective of this program and all it's missions and accomplishments are purely in retrospect and colored by the zeitgeist of our current civilian space contractors?
Earlier quoted context omitted.
I wish code like this still felt normal to me, but over the past ~10 years it seems that many people have come to value brevity over explicitness. I strongly prefer the explicitness, at least for important code like this. More than once in my career I've encountered situations where I couldn't figure out if the current behavior of a piece of code was intentional or accidental because it involved logic that did things…
> I strongly prefer the explicitness I have a rule for my teams: "Don't write clever code". I try to constantly reinforce that we don't write code for ourselves, we write it for the next person. We should be doing everything in our power to decrease their cognitive load. I try to envision the person that comes after me (who may be me in months or years!) and imagine that they are having a Bad Day and they have to mak…
This sort of code strikes me as an ideal candidate for translation into a declarative, rule-based, table-driven system. Such a thing is more comprehensible and more verifiable than ad-hoc imperative if-clause-rich code. Messy code of this sort is usually a sign of a missing abstraction.
The Go ideology is basically to just write down all the code, in a more or less straightforward translation of what you would have written in C, and not to try to abstract anything.
I once had to go through some code that was objectively terrible. The guy who wrote was is a mechanical engineer, close to retirement at the time, and self-learned in programming. He had absolutely none of the background you can expect a professional programmer to have, and in particular abstraction seemed like a foreign concept to him. Have 50 buttons, each doing essentially the same thing, and you will see 50 copy-pasted blocks of code. Particularly ironic that he was using Java, a language known for its culture of abuse of design patterns and abstraction.
But despite that huge mess that code was, it was surprisingly readable. You could look anywhere in the code and understand what it is doing. No calling though interfaces, when you see foo.bar(), you can just follow the symbol in your IDE and that's the instruction that will be run, and many times, there is not even a function, just code, thousands of lines of it, different cases are just dealt with ifs.
Maybe it was the most pleasant "bad code" I had to work with. Code using the wrong or too much abstraction is much worse, because it is just as buggy and ugly, but you don't even know what to expect when all you see is an interface call where the actual code is in a completely different part of the software, and what connect the two is in yet another place. With more "factories", "managers", "dispatchers", etc... than actual logic.
Earlier quoted context omitted.
Well over 100 successful missions carrying a bunch of people and gear up into outer space and then bringing them back home. I hold it in a good light now, and will likely continue to feel that way. As far as human progress and net good, it was a success.
100 success and 2 failures. About a 1.6% failure rate from memory. That’s not a great record. Sure it’s a complex field, and it’s not as dangerous as say being US President, but a failure rate of >1% is not something to write home about.
https://www3.nasa.gov/centers/kennedy/pdf/566250main_SHUTTLE...
// KEEP THE SPACE SHUTTLE FLYING. I understand the intent, but it is a bit funny that the comment references a system that is no longer operational due to its poor safety record. In ten years or so, will people even remember the Space Shuttle in a good light?
The situation with the Space Shuttle is more complex than simply poor safety. In terms of missions, it has a better record than many other launch vehicles - 2 fatal missions out of 135 for the shuttle, 2 out of 66 for the Soviet-era Soyuz, and a frighteningly poor 1 fatal mission out of only 12 spaceflights for SpaceShipTwo. However, the Space Shuttle had a much larger crew capacity than most missions probably needed…
We rarely flew the maximum number of passengers. On non-EVA missions we typically only sent up 5 astronauts. For EVA missions we usually sent up 7 with the two extra crew typically being dedicated to the EVA.
EVAs are a real chore. The shuttle is at 14.7 psi with regular atmosphere, but the EVA suits are 4 psi with pure oxygen atmosphere, so you have to spend a lot of time pre-breathing just to put on the suit. It also drains the hell out of you because it's microgravity, not zero gravity, and moving around and positioning in the suit using just your hands all day wears you out fast.
The extra capacity was also useful for bringing other nations personnel onto a mission with us. They didn't strictly have a large mission role, but it is good diplomacy, and helps other nations build up their own space program. Plus.. a few times.. we sent up 6 but brought back 7, which is a nice feature.
Anyways, when not sending up extra crew, we used the additional space for equipment and large experiment packages, some of them as large as a single person.
> and probably used a little more than it should be.
NASA did a great job of making space flight look normal and routine. Which is a bummer, because if you dig into any of their voluminous documentation on the shuttle program as a whole, or into individual missions, they are all anything but.
Space is just an absolutely insane environment to work in, let alone to discover and study from, and the shuttle was an excellent platform for that work. Somewhere along the way space commercialization became about building stations and just trucking people back and forth to them. And for that inglorious mission the shuttle is definitely not appropriate.
Anyways.. one of my favorite things about the orbiter.. the front thermal windows need to be tinted; obviously, but what I found out recently is they used the same green dye they use in US banknotes to do that.
Earlier quoted context omitted.
Regressions are not implied by that statement. A bug doesn’t exist in the human realm until a human observes it.
Oh, the Schrodinger's Bug.
The claim that a codebase of 420k lines contains "only one error" is of course absurd, and the members of this forum would laugh anyone out of the room who made such a claim about any other project, pointing out how they cannot possibly know, actual logical contradictions in the claims as described by GP, or just plain ridiculing it without further elaboration.
But since the code in question cannot meaningfully be tested by the public, and people have been indoctrinated to believe the myth that aerospace engineers are an entirely different species that doesn't make mistakes in the sense that the rest of the workforce does, the hubris is accepted until disproven, which it probably won't be for various practical reasons.
Nevermind that the Space Shuttle was a death trap that killed two crews, and that the associated investigations (especially for Challenger) revealed numerous serious issues in quality and safety management. People will continue to just nod their head when they hear nonsense like this, because that's what they have seen others do, and so Schrödinger's Hubris can live on.
BTW, when linking to a file in GitHub like this, you can link to a range of lines of the file, by using the URL fragment identifier, like: #L60-L92 https://github.com/kubernetes/kubernetes/blob/60c4c2b2521fb4...
I (well really, a coworker of mine) just today discovered a JetBrains action “Copy GitHub URL” [sic] that, if you have lines of code selected in the IDE, includes those lines in the copied URL fragment. So so so much better than my old workflow of stopping what I’m doing, going to the file in GitHub, and selecting the lines there to share links to bits of code.