Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programmers who want to change how we code before catastrophe strikes

theatlantic.com

Post reply on HN
Print view View original

191–200 of 274 posts

Re: Programmers who want to change how we code before catastrophe strikes

#191

Post by wolfgke »

nomel wrote: post #23
tmnvix wrote: post #3

> "Programmers were like chess players trying to play with a blindfold on—so much of their mental energy is spent just trying to picture where the pieces are that there’s hardly any left over to think about the game itself." This is an insightful description of the biggest mental challenge I face when programming.

My personal method is, every line of code that I write, I write for someone else. If it's internal, it's always for another developer (who may not exist) and, for the upper layers, a user (of the function/API/library) that may peek behind the scenes trying to debug some problem. If it's anything facing the "user", it's entirely written for that user, and I know they're not very good at reading or writing software. Th…

> My personal method is, every line of code that I write, I write for someone else. If it's internal, it's always for another developer (who may not exist) and, for the upper layers, a user (of the function/API/library) that may peek behind the scenes trying to debug some problem.

> If it's anything facing the "user", it's entirely written for that user, and I know they're not very good at reading or writing software.

In my opinion a very reliable way to get a deep hate on the respective person.

Re: Programmers who want to change how we code before catastrophe strikes

#192

Post by flukus »

brfox wrote: post #162
nitwit005 wrote: post #108

Earlier quoted context omitted.

My uncle worked at a very large corporation that couldn't update to a later version of Excel because they relied on some spreadsheet to do their taxes, and some minor difference between versions broke the spreadsheet. No one could reverse engineer what the spreadsheet did. With a complex enough sheet, every cell becomes a separate function with no documentation. That's unfortunately a pattern you see with these effor…

I totally agree. I just wonder if there is some way to take that open space, visual programming which so many people do with Excel and make it more robust. Well, actually, lots of people are working on making a better spreadsheet or putting the table data into a database and making interactive plots, so maybe that's not the angle here. Maybe we can figure out how to make our IDEs more Excel-like in some ways. Not for…

For things excel is used for I find a few unix tools and piping between them can achieve a similar affect yet still be maintainable, debuggable and repeatable. In lieu of convincing the masses to work this way, I wonder if visual tools could take the best parts? Instead of updating cells on sheets (global variables), have a UI that allows users to break down it down into a series of steps with an input and an output, much like a makefile. Then it would be possible to step through the script, inspect the input and output for each step and view the final result.

Re: Programmers who want to change how we code before catastrophe strikes

#193

Post by perl4ever »

catnaroek wrote: post #183
AnimalMuppet wrote: post #80

Earlier quoted context omitted.

Type theory is much less than "correct by construction" formal methods. Type theory is great at preventing a whole class of bugs (an operation on a value for which that operation doesn't make sense). But it's inadequate for the larger problem, of whether the operation is the correct one. Formal methods can ensure that the code matches a formally written spec, for all the aspects of the code that are covered by the fo…

> And you have the little problem of (correctly) creating the formal spec. How on Earth did we end up putting people who can't write down precisely what they want in charge of programming machines that do exactly what you tell them to?

I was just told today that gathering requirements is not my job, it's the PM's. But they are swamped in administrative minutiae, and all too often the only person who knows how something worked has quit anyway. So in sum "no spec, no spec, you're the spec!"

Re: Programmers who want to change how we code before catastrophe strikes

#194

Post by gregmac »

milkytron wrote: post #160
gregmac wrote: post #33

Earlier quoted context omitted.

> for another developer (who may not exist) You, 6 months from now (or whenever you stop touching this code base), are effectively "another developer". New developers don't seem to really grasp this until the first time they have to maintain their own old code. I don't think it really hits home until the first time you experience: "What is this? Who wrote this garbage??" runs git blame "..oh, crap."

This is why I usually throw in comments with myself as the recipient for understanding where complexity exists. I've heard people debate over whether comments should be in well written code, including some that argued comments should never be used at all. Party A: Code should be easily understandable so that comments aren't necessary. Party B: Comments should exist where complexity exists to save a developer's time w…

Obviously the worst comments are utterly obvious:

    // Get the users name
    name = get name();
There are lots of cases where inline comments are very useful though.

As an example, most of my team isn't strong on regular expressions, so when I use one, I'll usually put a comment explaining what it does in slightly more detail than I normally might (to the point it would be a bit too rudimentary to anyone well versed in regex).

I've also been writing lots of automation scripts for stuff running at AWS lately, which often involves using strange AWS CLI filter syntax, jq expressions (for JSON parsing) and some other random utilities like sed, cut, sort, etc. Even for myself, I put fairly detailed comments, but I don't use those on a regular basis and usage isn't always obvious anyway.

Re: Programmers who want to change how we code before catastrophe strikes

#195

Post by toss1 »

arvinsim wrote: post #180
toss1 wrote: post #124

Earlier quoted context omitted.

>> how many engineering projects face regular enemy action? The last time somebody actively tried to compromise a system I was building was two weeks ago. How many engineers live like that? Every bit of military hardware, or child's toy, for starters. More generally, you cite anticipated harm from vandalism or car crashes as being part of the general environment. It is far past time to recognize that the hacking envi…

> It is far past time to recognize that the hacking environment in which we live IS THE NORMAL ENVIRONMENT, and these hacks ARE everyday anticipated harm. > The only basis for this is impatient project management where the key priority is to to ship yesterday because the management are idiots and think software is trivial. I agree with the former but it is negated by the latter. The economic incentives certainly do.…

I agree that the First-To-Ship mentality you mention and other shortsightedness negate the reality of the current environment.

But if the industry doesn't start changing itself, it'll have change imposed upon it.

The Equifax breach alone, especially if it is weaponized by a state actor has the potential to completely undermine our banking system. All because of weak software and inadequate maintenance.

This is not like we have sophisticated attackers going after solidly designed & engineered structures. It's like we have teenagers and squirrels wandering around the back and freely climbing in windows where the specification didn't even include installing glass. And then commenters like GP saying that it is too great a threat to design around teenagers and squirrels.

Re: Programmers who want to change how we code before catastrophe strikes

#196

Post by Roboprog »

haskellandchill wrote: post #133
AnimalMuppet wrote: post #127

Earlier quoted context omitted.

It is my impression (as an outsider) that web programming might be the hardest environment for formal methods. Yes, I could see formal methods proving that only valid HTML was ever emitted. But how do you prove that your layout aligns on Firefox 55.0.3? So it seems to me that, if you can make progress on formal methods in your environment, you're not picking low-hanging fruit...

If FireFox provided a formal model of how it lays things out I can prove I use it correctly in my code. It's about trust and providing models for other programmers to use in their proofs along with our code. Or code and proofs can be even more intertwined, since they are very related.

Interesting point.

It's hard to prove theorems without the [correct] axioms.

I suppose what our field needs to do is some "triage" categorizing aspects of systems that MUST be "defined and proven" vs those that can be "intuited" - e.g. - back-end database updates need to be correct, but it's acceptable to have the user reload a web page if something crashes occasionally???

But The Man wants lots of 'wares made by cheap full stack developers, er, dev-ops :-(

Re: Programmers who want to change how we code before catastrophe strikes

#197

Post by catnaroek »

wolfgke wrote: post #190
catnaroek wrote: post #171

Earlier quoted context omitted.

Humans can read and write proofs just fine, if they are taught how to.

The problem is that the proofs that one finds in typical math papers are very different from the proofs for computer programs. Proofs in math papers are "mostly right" about rather complicated facts. This means that what is shown is highly non-trivial, but when an error is found, it rather does not matter since it is rather easy to fix the hole in the proof. The reason seems to be (but this is my personal opinion) th…

> The reason seems to be (but this is my personal opinion) that the typical things mathematicians love to write proofs about have a high level of redundancy for this kind of error.

Rather than “redundancy”, it's a matter of having nice (algebraic, geometric, whatever) structure. Of course, a pure mathematician has more freedom than a programmer to decide what kinds of structures he wants to work with.

> statements that are rather trivial and obvious, but very subtle in the edge cases.

This is a contradiction in terms. If it seems “trivial and obvious”, but is actually “subtle in the edge cases”, then you are underestimating its complexity.

> Often the a non-formalized proof is "trivially correct" when a human skims it, but often is wrong for very, very subtle reasons.

Then you need to roll up your sleeves and actually prove things, not just skim through purported proofs.

Re: Programmers who want to change how we code before catastrophe strikes

#198

Post by flukus »

gregmac wrote: post #194
milkytron wrote: post #160

Earlier quoted context omitted.

This is why I usually throw in comments with myself as the recipient for understanding where complexity exists. I've heard people debate over whether comments should be in well written code, including some that argued comments should never be used at all. Party A: Code should be easily understandable so that comments aren't necessary. Party B: Comments should exist where complexity exists to save a developer's time w…

Obviously the worst comments are utterly obvious: // Get the users name name = get name(); There are lots of cases where inline comments are very useful though. As an example, most of my team isn't strong on regular expressions, so when I use one, I'll usually put a comment explaining what it does in slightly more detail than I normally might (to the point it would be a bit too rudimentary to anyone well versed in re…

Regular expressions are the perfect use case for unit tests, they are simple input/output pure functions. Not only do you ensure that they work, you provide several examples to future devs of what should and should not be considered a match.

On the automation scripts I really need to take a leaf out of your book though, I'm awfully undisciplined at commenting them and it always comes back to bite me.

Re: Programmers who want to change how we code before catastrophe strikes

#199

Post by gregmac »

flukus wrote: post #198
gregmac wrote: post #194

Earlier quoted context omitted.

Obviously the worst comments are utterly obvious: // Get the users name name = get name(); There are lots of cases where inline comments are very useful though. As an example, most of my team isn't strong on regular expressions, so when I use one, I'll usually put a comment explaining what it does in slightly more detail than I normally might (to the point it would be a bit too rudimentary to anyone well versed in re…

Regular expressions are the perfect use case for unit tests, they are simple input/output pure functions. Not only do you ensure that they work, you provide several examples to future devs of what should and should not be considered a match. On the automation scripts I really need to take a leaf out of your book though, I'm awfully undisciplined at commenting them and it always comes back to bite me.

100% agree on unit testing regex, but spending a minute to type a detailed comment that saves sometime the extra time of navigating to and reading several unit test cases is worth it. If someone is modifying the regex the tests are essential, but for someone just reading the code why not save them the time?

Re: Programmers who want to change how we code before catastrophe strikes

#200

Post by hasenj »

chroem- wrote: post #24

The dangerous unreliability of software is an accountability problem, not a technology problem. Engineering disciplines are regulated so that engineers are held personally and even criminally responsible if they endanger property or lives. Software, being the newcomer, has no such regulation. Instead we have people trying to claim that software deserves a free pass from due diligence because "software is hard," when…

You can definitely do that. You just have to pay them 20x more money and give them 50x more time and give them absolutely all the tools they need. Best possible hardware. Best possible software. Fastest possible internet connections. etc.

Show me an employer willing to do that and I will immediately sign up.

Most companies want to do the exact opposite. Spend the least amount possible, because, you know, the budget is tight and the business side wants all these features ready yesterday, nay, last week.

Post reply on HN