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

171–180 of 274 posts

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

#171

Post by catnaroek »

haskellandchill wrote: post #105
Bartweiss wrote: post #84

Earlier quoted context omitted.

There are definitely people making a real effort here, and I appreciate you. But I can't shake the feeling that the reason your task is so hard is that everyone before you has been selling snake oil. "Visual programming", "human-readable software languages" and so on are all just ways of saying "crippled tools". It's not an accident that the examples in the article were WYSIWYG editors, Photoshop, Squarespace, and Ma…

Yeah I'm not a fan of visual programming, but visualizing effects of programs to help with reasoning, I'm a fan of that. Proofs is my approach, but as humans we don't deal with proofs as text well and have things like sequent calculus and semantic tableau that are amazing aids to reasoning.

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

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

#173

Post by kurtisc »

nitwit005 wrote: post #108
brfox wrote: post #13

The article didn't mention it, but I think that Excel is a great example of where "the masses" have learned to do programming. It is visual and the effects of changes are immediate.

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…

http://www.ni.com/cms/images/devzone/pub/nrjsxmfm91216399872...

I don't see the problem!

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

#174

Post by Karrot_Kream »

Our company uses memcached to store short-lived pieces of user-specific data for one of our (web) products. The way this was architected, any time a user visited a page, a request would be made to memcached with the user, check to see if memcached had data, fetch the data, and then clear the cache.

This feature had always been a bit buggy, but then we decided to start adding more things to this user-specific data store. And it blew up. Data we wanted to store for the user wasn't being stored at all, data was being fetched many requests after they should have been fetched. Sometimes stale user data was being fetched days after the data should have been cleared, and the data was not being cleared.

After being pulled into the war room for this, I started looking into the code and architecture of the issue and was appalled. Code for the feature was designed piecemeal, tests were nonexistent, and of course only certain cases of the code were tested. The whole thing was a concurrent nightmare and would not hold up to concurrent reads/writes.

Rather than sit there and make sense of it all (I started sketching it out on paper because it was so convoluted), I ended up writing the spec out in TLA+. Just forcing myself to write the spec out made me consult the implementation dozens of times, to verify the exact behavior in a way that TLA+ could model it. And then after I did that, it was obvious that the code was broken.

So in my TLA+ model I shored up what I thought were the problems, ran the model checker, and was expecting a fix. Nope. The model checker found another bug. I tried a different strategy, and it found another bug. I iterated with the model checker dozens of times, and slowly changed the model entirely, making it simpler and clearer to understand. Finally the model checker couldn't find any bugs. I converted the model to real code and, after some code review, I shipped the fix. It worked.

I wish more people would spec their code with something like TLA+, but as I've seen in my own teams, the mantra is ship first think later.

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

#175

Post by catnaroek »

AnimalMuppet wrote: post #125
ScottBurson wrote: post #92

Earlier quoted context omitted.

I don't know what kind of code you've been writing, but I've been working in compilers and static analysis for decades, and set theory is exactly the right tool for the job. I don't imagine it's the only thing you would ever need for any kind of programming, but I bet there aren't many kinds of programming to which it is entirely irrelevant.

For static analysis, OK. For a compiler, OK. But I want the static analyzer and the compiler to do that so that I don't have to - I don't want to have to think in set theory to program. And in saying that, I see that I was probably unfair to haskellandchill's point. The claim wasn't that I needed set theory; the claim was that the tools needed it (at least, so it appears to me on re-reading).

Not every program property of interest can be (conveniently) verified using automated tools - especially if your verification tool is a type checker! Sometimes you need to roll up your sleeves and prove things yourself. (Which, by the way, isn't always a bad thing.)

That being said, hopefully you won't have to use set theory, where any structure that actually matters to you has to be encoded in terms of sets containing sets containing sets, until you reach turtles.

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

#176

Post by dasil003 »

amag wrote: post #152
valuearb wrote: post #104

"For Lamport, a major reason today’s software is so full of bugs is that programmers jump straight into writing code. “Architects draw detailed plans before a brick is laid or a nail is hammered,” he wrote in an article. “But few programmers write even a rough sketch of what their programs will do before they start coding.” I almost always dive in, but I almost always write my code twice. Essentially the first round…

Me too. The very few design specs I've seen during my 15+ yrs as a programmer are typically high-level enough to be the mechanical equivalent of "cogs needed here, and springs!". What kind of cogs, e.g. diameter, teeth count, diameter of the center hole (should the hole even be in the center?) and what kind of springs are never mentioned. If you ask the customer about functionality their response is "we want it to wo…

This is brilliantly funny, you made my day. In all seriousness though, go find a new job.

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

#177

Post by shusson »

One of the biggest benefits of model driven development is having a common language to talk about design with other people. State becomes clear and any complexity is inherently linked to how you designed your model. I really hope it becomes more popular and more companies start supporting it.

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

#178

Post by dasil003 »

SiVal wrote: post #153
Latty wrote: post #107

Earlier quoted context omitted.

Exactly. This is ignoring the fact that code is a more useful blueprint than anything else for programs. I'm sure if architects had the ability to magically conjure building materials out of thin air and try things in real life for free, architecture would involve a lot more trying and a lot less planning. Of course, I'm sure the article is talking about people just rushing into production code without thought, and I…

I think there's a bit of a problem with the architecture metaphor in general. It implies a limited range of things planned and built. As software eats the world and does more and more things, a metaphor that more closely reflects the variety of software is people telling other people to do stuff. If you tell someone to bring you your socks, you don't need to plan for it. If they bring the wrong socks, you just fix it…

One way the architecture metaphor breaks down is that very tiny details can have incredibly large knock-on effects in software. This is different from normal architecture and building engineering where it's certainly true that there are many details that need to be carefully considered, but those things are well understood and managed from project to project. Software on the other hand could be doing anything, in a world of pure logic traversing scales analogous to the smallest quark ranging to the entire universe. Building physical things just doesn't deal with those scales, you only have to worry about material properties and structures within a range of few orders of magnitude.

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

#179

Post by thethirdone »

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.

I feel that it is dramatically less like playing blindfold chess and more like playing normal chess.

You can always refer to the code or state in the debugger at a given time, but being able to think through steps ahead in your head is very helpful. Likewise in normal chess you can always refer back to the board to reset your mental state, but it helps to be able to think 5 moves into advance.

Playing blindfold chess isn't much harder at the beginning of the game; you can always reset to the initial state and replay moves if you want to. But as the game goes on it becomes hard to remember "Did I move the A rook or the H rook?", basic playing of the game isn't too hard. If you could refer to the board every 10 moves, blindfold would not be very hard at all.

When programming, all the information is there, being able to run it in your head is just faster than asking the computer to do it.

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

#180

Post by arvinsim »

toss1 wrote: post #124
Bartweiss wrote: post #43

Earlier quoted context omitted.

> The only difference is that these other engineers are motivated to be significantly more thorough about their jobs. Hang on. Sure, all engineering has hurdles. But 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? We hold civil engineers responsible when bridges collapse unprompte…

>> 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.

> These approaches to start slinging code, write it fast and change it often are useful only for prototyping. In writing real software, my first two steps are 1) understand your problem in depth, and 2) work very hard for a long time to avoid writing code (i.e., better architecture to simplify, separate dependencies, etc.++)

Ideally this would be the case but this approach is a luxury many could not afford. This is especially true in an "Agile", first-to-ship mentality seen in most startups.

Post reply on HN