I like this description of how the space shuttle got this way [1]. I don't think I'd hold NASA responsible for that.
Edit: I understand that The Space Shuttle Decision by T. A. Heppenheimer [2] contains a lot of the information that's in the Metafilter post, but in a more sober tone. The PDF is available direct from NASA [2]. It does at least mention that NASA itself wanted to cancel the shuttle program.
I'd put Liskov's Programming with abstract data types up against any of them. Fran Allen's work was so fundamental it's hard to find compiler stuff that doesn't build on her work.
You asked for "citations", the thread is literally filled with references to them. How is it not bad faith to have to prove to you things that you can easily check for yourself?
You misunderstood the request. Your original comment was claiming that there were many papers far more influential than any of the papers named that were by women. I was requesting evidence of this influence. In response you say that what, all of the references filling this thread are more influential than say Liskov or Allen? If not all, which ones?
The original comment you were responding to was pointing out that none of the papers listed were by women, and suggested several that were that are undeniably influential. Perhaps you think they aren't because you haven't read them, or presumably even heard of them?
I'm partial to this non-jokey take on two hard things:
Phil Karlton famously said there are only two hard things in Computer Science: cache invalidation and naming things. I gather many folks suppose "naming things" is about whether to use camel-case or not, or picking specific symbols we use to name things, which is obviously trivial and mundane. But I always assumed Karlton meant the problem of making references work: the task of relating intension (names and ideas) and extension (things designated) in a reliable way, which is also the same topic as cache invalidation when that's about when to stop the association once invalid.
While switching to terminology unfamiliar to me (intension vs extension of a word), I never heard anyone misinterpret "naming things being hard" as whether to use camelCase or symbols to use.
It was actually about coming up with short but sufficiently expressive names that greatly improve code legibility, so certainly names that would sufficiently well represent the intent and avoid confusion.
But I am not sure how it relates to "stopping association once invalid"? Is this about renaming things when the names are not suitable anymore? That's only a very special case of "naming is hard", but I do believe naming is hard even when starting from scratch (having seen many a junior engineer come up with what they thought were descriptive names, but which mostly explained how their understanding developed over time and not the synthesised understanding once they had it fully).
In the interest of DRY, naming things is hard because when you want to reuse code in a method or library, it should be easy and intuitive to find what you need.
Most, since, many devs name by what it does, rather than how it might be found.
For example naming a function calculateHaversine won't help someone looking for a function that calculates the distance between 2 latlongs unless they know the haversine does that.
Or they default to shortest name. Atan, asin, Pow for example.
At some point you just have to browse the library, and learn conventional names for algorithms.
If you want to synthesize this type of knowledge on the fly because you don't like learning other people's conventions, just feed the docs to chatgpt and ask if there's a function that solves your problem.
This is why a formal education is so important, and why books like "gang of Four" are some sort of standard. They've given a name to some common patterns, allowing a more efficient form of communication and higher level of thinking. Are the patterns actually good? Are the names actually good? That is besides the point.
I've come to understand 'naning things' to be glossing over many actual difficult things: knowing the concepts you're working with, explicitly, choosing where and when to use abstractions, knowing CS foundational terminology, and maybe the most common not following single responsibility principle. There's many others I'm sure. Failure to name a thing indicates you may not actually know what you're doing or why.
TL:DR "naming things" itself was the joke all along.
I always interpreted the hard part was not looking at something and naming it accurately, but the impossible ask of predicting future use & context (much of it not in your control) and somehow getting that right.
True. We make a best guess and if it turns out to be ineffective, refactor which means to choose a new factor. The other common cause of difficult naming is 'refactoring' without knowing what the new factor is, ie. blind deduplication or along arbitrary seams. My strategy is to delay abstraction if possible until we have an opinion one way or another. Some others like to have clean/abstracted code beyond current understanding.
Not being able to make a good guess is a lack of understanding of problem domain, nicely rolled up into this catch all term.
About naming things, in the computer science world, there is this often repeated saying, as well as countless books and articles about naming things, often contradicting each others. From coding style guides to URL schemes.
But on the other side, there is administration. I work on projects with names like FRPPX21, in category PX23, same idea for tax forms, and just about everything administrative. Should I write code with variable names like that, I would be yelled at by the unfortunate guy who gets to read it.
Neal Stephenson has a funny anecdote about explaining PowerPoint to a friend of his who had managed to be unaware of it until now, culminating in Stephenson's explanation "for people who can't communicate, it's what a dialysis machine is for people who don't have kidneys" [1].
This is the culmination of his response [2] to a question [3] in the Q&A period of a talk on his book tour for Seveneves [4]
> Then he says the sea hasn't risen and those people are actually right
You must be thinking of the bit where he says To be fair to those folks, it's true that – as they claim – the water level of various landmarks around the world, such as the Statue of Liberty, Plymouth Rock, and (in my own stomping ground of Sydney Harbour) Fort Denison, has not "visibly" risen since they were erected. but didn't notice the visibly.
> Then he says the sea is gonna rise a lot more than it hasn't.
I don't think he's trying to make people understand the proof, rather to show them that topology really has an application for problems that aren't themselves topological in nature, and it is comprehensible enough for that purpose.
[1] https://meaningness.com/geeks-mops-sociopaths