Looks like she's ready for Twitter code review.
HistoryPorn
If you would like to become a mod in this community, kindly PM the mod.
HistoryPorn is for photographs (or, if it can be found, film) of the past, recent or distant! Give us a little snapshot of history!
Rules
- Be respectful and inclusive.
- No harassment, hate speech, or trolling.
- Foster a continuous learning environment.
- No genocide or atrocity denialism.
Pictures of old artifacts and museum pieces should go to History Artifacts
Illustrations and paintings should go to History Illustrations
Related Communities:
Vibe coders out there thinking they could accomplish the same thing by getting a robot to make it
I can make twice that amount of code in 24hours! And I am willing to bet it would be just as good as SpaceX!
Dark hair and glasses. Nerdy women's style hasn't changed much in 80 years, and I'm here for it.
No, not THAT Margaret Hamilton.
In the vein of awesome women at NASA, there’s also Judith Love Cohen who worked on the abort guidance system for Apollo and was Jack Black’s mom.
I mean she still is his mom.
Well she was.
Are you sure? Do you have a source for that claim?
"Jack, I really like your friend Kyle. I really hope you never turn your back on him to score points with conservatives."
One of my favorite Lego adaptations.
From the official Women of NASA set.
I'm old. I know this kind of binders, and have used them a lot back then.
Daniel Radcliffe has so much range
I've always loved that picture for the sheer look of pride on her face. This is someone who knows she did something great and is happy to show it off
Damn, girl.
That's one of the most appealing women I've seen all week
No kidding, geeky hotness is the best and most hot kind.
If you want to see what the code looks like, it's on Github: https://github.com/chrislgarry/Apollo-11
It's funny to look at this code because a large fraction of current programmers (perhaps a majority?) think that comments are a "code smell", an indication that the code is fundamentally flawed. Granted, in that language code really couldn't be self-documenting with descriptive variable and method names, but it was still sufficiently reliable and maintainable to get men to the moon and back.
No unit tests either lol.
This is my first time hearing that anyone thinks comments are code smells. What's the logic behind that supposed to be?
Fla already explained the rough logic behind it, but I also think a big part of it is that people have a habit of approaching advice like this too dogmatically. For example, guidance that says "commenting your code is not a substitute for sensible structure and variable names", and someone may read that and go "I shouldn't use comments, got it". Certainly I have seen (and written) code that overuses comments in a manner that the average comment has pretty low information value — for me, this was because I was inexperienced at writing code other people would use, and comments were things that I felt I should do, without properly understanding how to do it. Like if there's a line that says a += b
, I don't need a comment that says "# adds b to a". That misses the point of comments entirely, and would make important comments harder to see, and the code harder to understand.
Another area where I often see this overly rigid mindset is the acronym "DRY", which means "don't repeat yourself." It's a decent principle, and it's helped me to identify larger structural problems in my code before. However, some people take it to an extreme and treat it as an absolute, inviolable law, rather than a principle. In some circumstances, repeating oneself would improve the overall code.
If I had to choose between code that had sensible variables and structure, but no comments, and code that was opaque but heavily commented, I'd probably choose the former. However, in practice, it's a "why not both" situation. It's less about the comments than how well they're used, and identifying comments as a code smell may be an attempt to get people to approach code readability slightly differently and using comments more wisely.
That makes sense. I've certainly been guilty of excessively DRYing my code. On one hand, it's a fun little puzzle to work on. On the other hand, it's been making it very hard to quickly iterate, and that's especially bad for research code.
It only nakes sense to apply DRY principles when you find you keep having to copy paste the same code to muliple locations on your codebase, and its reasonably clear it will never diverge from eachother. In other words, apply as needed to maintain development velocity (and in turn stability).
Not an opinion i hold. But i've heard others say that code should be written in a way thats simple and easy to understand, e.g. variables/methods with meaningful names. Logic kept simple within aptly named methods that define what it does.
The stance seems to be that if you should keep code simple enough, or named well enough that comments aren't necessary in the first place (excluding niche situations).
I can even begin to imagine how I'd explain with only code how various hacks are necessary because of a bug in something it's interfacing with, or how various mathematical expressions were derived.
I ran into this when I was doing the Accessibility/VoiceOver stuff for an iOS app. VoiceOver is (or was at the time - maybe they've fixed most of the problems) buggy as shit in lots of weird ways, and I sometimes had to do strange things in the code to get things to work properly in VoiceOver mode. I would always add comments explaining why I had to do these weird hacks before I would submit the code. The guy approving our pull requests was a young developer solidly in the "all comments are bad" camp and he would always just delete my comments. Sometimes, because he wasn't even remotely aware of what VoiceOver was for or how it worked, he would also delete the changes I had made to get VO to work in the first place. For good measure, he also badmouthed me to our bosses whenever possible, calling me technically incompetent (because of the comments).
The fun part was when our app failed its annual accessibility review (badly) and he had to scramble to restore all my changes that he had deleted. He didn't restore my comments, though, which apparently led to us failing the following year's review as well because other developers deleted my shit, having no idea why it was in the app. He and I had both been laid off at that point so there wasn't any institutional memory of it at that point - another reason why comments are important, as they're essentially the only form of documentation that there's even a chance future developers will read.
Yeah. Code explains how, comments explain why. I can see what happens, but I surely cannot see why someone thought this was a good idea. Please don't write int addSomeSpecificFillerBytesBecauseTheLegacyAPICountsTheHeaderAsPartOfTheDataStructureAndTheCurrentAPIDoesNot()
She was around 33 when this photo was taken. I don't want to talk about what I had achieved at 33.
Yeah, it's probably too late for you...
RIP Fauja Singh 😢
Robert Downey Jr. was nominated to Oscar in 1992, at the age of 27, he didn't win though. There was a joke about him in Simpsons in 1999, so he was already a well known name far before Iron Man. https://www.youtube.com/watch?v=UhjHVQsJOlo
His life is more like an example of how people can get back to the top after years of heavy drug abuse.
Martha Stewart wrote her first book at the age of 42, I would count that as the start of her career.
This chart is a bit confusing, sometimes it lists when people started a later flourishing business, sometime when they were at the top.
I wrote a calculator in 6502 assembly one time. So I'm okay life achievement wise.
Margaret Hamilton is a total boss. Check out her wikipedia entry
https://en.m.wikipedia.org/wiki/Margaret_Hamilton_(software_engineer)