And it's a fantastic principle in general, since it's like the technical equivalent of the Principle of Charity.
And it's a fantastic principle in general, since it's like the technical equivalent of the Principle of Charity.
Obvious "errors" like if(false) is a stupid example of this, why would someone commit if(false)? Is it supposed to be if(true)? Is it for debugging only or is it code that should actually be removed? Maybe it's used for other reasons by a preprocessing-tool that you are not aware of?
I've had the joy of seeing code which broke completely if you removed the line while(false){}. Some hideous synchronization bug was solved by this line, and while it obviously wasn't the right solution, simply deleting it produced bad outputs. Profilers and processing tools are, as you say, other likely causes of dumb-looking code choices.
The stupider the "error", the more suspicion you should assign to its presence in any half-decent code.
Assume that those who came before you had good reasons for their actions, and assume that those after you will be unable to identify any motivation you don't state explicitly.
I'd be curious to see a strong legislative version of this - enshrining the spirit of the law in the text, and giving courts explicit rights to strike down laws which no longer fulfill their original intent. Done well, it's the sort of change which could have worked wonders on our legal system's constant failure to adapt to technological change. The Aereo suit, for instance, shouldn't have happened under any kind of intent-based legal system.
There's a limit to that assumption, though. I'm always inclined to assume that people had reasons, and that they looked good at the time, but without knowing what those reasons are, there's no way to know if the reasons are as good now as they were then, even if you make the charitable assumption that they were good reasons at the time.
I would be a big fan of the idea that legislation had built-in turnover clauses, for instance, that required renewal every N years (for a value of N not much larger than the turnover rate of legislators). Which then means if you want something to persist, you would have to document your rationale for posterity, and convincingly argue that that rationale still applies.
> I'd be curious to see a strong legislative version of this - enshrining the spirit of the law in the text, and giving courts explicit rights to strike down laws which no longer fulfill their original intent.
I agree completely. Laws should state up front that "the purpose of this law is to ...", and for that matter explicitly state any other relevant considerations or side effects and whether they're considered beneficial, undesired, or simply neutral. That would mean there would have to be at least a pretense of a sensible motive, and that interpretations that don't serve that motive could be thrown out.
> The Aereo suit, for instance, shouldn't have happened under any kind of intent-based legal system.
It still could have, depending on the intent. The intent of copyright law, for instance, is supposed to be "we want more works produced, but we also want more works to enrich the public domain, so there's a tradeoff". The intent was never about authors and what they want; that's a means to an end. However, that rarely seems to be reflected in deliberations.
Let's be honest. These things would mostly be just bundled up and passed all at once. Or, alternatively, they would be used as leverage like the budget currently is. Actually, it would pretty much be exactly like the budget at this point. It either sails through with no issues, or it begins months of partisan bickering.
EDIT: Also, could you imagine the kind of flex we might see on major laws? I can only imagine large sets of laws sunsetting every time the Congress majority changes... Hey, at least it will create a whole industry centered around these adjustments! That's job creation right there! And, as always, the lawyers will be making their money.
It might be simpler to just sunset every law by default after some period and require lawmakers to periodically renew them - if a majority can't form to support renewal, then it's reasonable to assume the original motivation lacks support. It's also a handy way of nudging updates to the laws to keep up with current times.
While that doesn't seem like the main intent of such an approach, it certainly sounds like a beneficial side effect. New legislation is not a thing that should occur particularly often, or lightly.
> It's also a handy way of nudging updates to the laws to keep up with current times.
Agreed. (You'd also need to have some requirement to prevent any omnibus renewal legislation.)
If you're refactoring, you can use unit tests and proofs of equivalence to demonstrate that your changes don't pose a threat. If you're rewriting a whole codebase, you're likely to wander down the same paths of "wait, the simple way doesn't work" that the person before you took.
Even bafflingly small changes like removing always-false tests have been known to break code, which ought to inspire real hesitation any time you see "stupid" code written by a smart person.
Okay, how is this even possible? Reflection/pre-processing magic?
Other issues I run into a fair amount is dealing with hardware/naked interrupts often involves a lot of subtle timing and read/write access issues. Sometimes this happens in code you don't own.
>I've had the joy of seeing code which broke completely if you removed the line while(false){}. Some hideous synchronization bug was solved by this line, and while it obviously wasn't the right solution, simply deleting it produced bad outputs. Profilers and processing tools are, as you say, other likely causes of dumb-looking code choices.
https://news.ycombinator.com/item?id=10036050
I can also imagine methods with side-effects. The test is always false but a side-effect is necessary.
def stub():
while(False):
print("smart stuff")
print("hello, world")
stub()
If you remove the `while(False)` loop, the working code will stop working. def stub():
return
print("hello, world")
stub()
There, it works.That said, boo Python for not admitting empty bodies. It needlessly adds a special case to its syntax. I suspect this comes from the implementation of its lexer.
It was implied that we were talking about a C based language. You proved nothing. Others did.
Yes, but really, if you write stupid-looking code because of arcane reasons you really owe the rest of humanity at least
//THIS SHOULD BE LIKE THAT BECAUSE ARCANE REASON
comment.This is the main purpose of comments.
It's important to try to understand why something exists, but it is also important to understand that the reason often is that it was either unintentional or silly, but you won't be able to prove it because it isn't documented and the person responsible is gone/unknown.
Usually this meant digging in deep, questioning really basic stuff like "Are we sure this model is normally open or closed? Did the manufacturer forget to tell us?", and normally there would be clues or evidence to hint at the next round of questions. Eventually you'll have enough information that the evidence fits the questions, and there's no clear line of inquiry left. Life experience and just volume of work teaches one the limits of inquiry (old engineers can be shockingly good at this, to the point of appearing sloppy :)
I once spent 6 hours overnight troubleshooting a confusing gas non-leak that ended up being the result of a default setting changing on a valve being replaced off-the-record by not-the-usual-guy. It gave me the confidence that this process does eventually get to the bottom of it, but it was a long, meandering path from miswired panels to out of date schematics in the wrong language to noting how clean the part was to know someone replaced it. All to dig out the missing tribal and undocumented information, proving the PLC was actually correct to interlock the whole machine out. (It's like knowing your program will halt - you can't prove it, but you can still be damn sure it will. At least until it doesn't ;)
For example, I could prove that I don't have a dragon in my pocket without breaking a sweat.
... which I'll happily sell you for just $2000. Remember, phase-shifted dragons are dangerous!
But I do have two formative things: Feynman's lecture on Cargo Cult Science is excellent, with this gem:
"The first principle is that you must not fool yourself--and you are the easiest person to fool. So you have to be very careful about that. After you've not fooled yourself, it's easy not to fool other scientists. You just have to be honest in a conventional way after that... I'm talking about a specific, extra type of integrity that is not lying, but bending over backwards to show how you're maybe wrong, that you ought to have when acting as a scientist. And this is our responsibility as scientists, certainly to other scientists, and I think to laymen." - Feynman [0]
I can't tell you how many times this has saved me in the field. Replace the word 'scientist' with '<YOUR DISCIPLINE HERE>' as needed. (And I think moreso for engineers than scientists, since safety absolutely requires this mentality.)
And I really like the ideas in The Pragmatic Programmer [1]. More than anything specific, the idea of not being married to any particular concept or solution, but rather to pragmatically chose what is correct then for that circumstance helps a lot. The book is opinionated, but reasonable, and copying that pleasant tone is a fast way to make allies when solving problems in a group. And it's a pretty good book to boot.
[0] http://neurotheory.columbia.edu/~ken/cargo_cult.html (and is an HN favorite, to be sure)
[1] https://pragprog.com/the-pragmatic-programmer (another HN favorite, though not always brought up in terms of engineering)
The 'assumption of truth' step doesn't require us to believe anyone who walks up and says "A ^ ~A". Rather, it says that you shouldn't immediately reject a philosophy because it disagrees with your prior notions.
The 'resolve contradictions' similarly doesn't mean that we have to overlook flawed claims. It's a tool to help learn an idea even if you don't get a perfect presentation of it. There may be a valuable concept available even if the person explaining it to you can't properly work through every detail.
As an example, most people who could talk to you about evolution can't explain the development of eyes, but that doesn't mean you should assume evolution is bunk when you hear about it. The principle of charity says "there might be a good reason here, whether or not they can provide it".
In short, the principle is an attempt to get value out of ideas you're presented with. That might mean you're engaging with a different idea than what you were actually presented with, but it gets you more insight. It's not something you want to use when faced with a concrete form of the document - it's not a reason to pass a bad-but-well-intentioned law.
He had a great story to go with this, but the TLDR is that the PoC is the safe choice when applied to engineering: give a true, best-faith effort to prove the opposing view correct. (And best-faith is important: you can not approach it with bias, lest you waste everyone's time.) If you're right, then you'll find an irrefutable flaw in the engineering, and if you're wrong you've learned something new.
If it sounds like a lot of effort, it is.
But this is also utterly win-win. It's a way of assuring that you've been careful. Avoiding the humiliation of hubris is great if a detail of the implementation was missed at first glance. But you also will inevitably more fully understand the problem when you've failed to implement the opposing view; it also puts you in the excellent position to graciously be on the same side as your opponent and now you can sway your now-ally-in-war in their reasoning. In either way, your goal must be to solve the problem, and not merely "win" political points.
Of course, there's crackpot theories and stupid ideas and foolish plans which should be dismissed with prejudice. But hopefully you're working in a professional environment where your coworkers really are trying their best to succeed. And even then, a serious engineer will still give the stupid ideas at least some (small) time of day, as you must have a reason for all decisions, even dismissals; as you become experienced, you'll be able to properly dismiss these faster and more precisely, but you'll still need to go through the process. That process is what separates the people who loudly proclaim they are smart and right from those who would testify in court they are right.
(Incidentally, this is part of the reason why I get immensely frustrated with "idea people", as it takes much more work to flesh out their half-assed ideas into full-assed ideas. Non-engineers don't get that there's a huge amount of effort to constantly take everything and everyone seriously.)