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

21–30 of 274 posts

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

#21

Post by katelynsills »

hwayne wrote: post #15
combatentropy wrote: post #6

If TLA+ really does let you prove your program is bugless, then maybe it is something to look into for cars, airplanes, medicine, etc. For the rest of us, who still wrestle with complexity but probably would't accidentally kill someone, here are some simpler aids: 1. Don't put a computer there. My microwave doesn't need to be digital. It needs two dials, time and power. My mother's washing machine can be controlled b…

> maybe it is something to look into for cars, airplanes, medicine, etc. For the rest of us, who still wrestle with complexity but probably would't accidentally kill someone, here are some simpler aids: TLA+ isn't perfect, but it's actually not that hard to use! I'm a webdev and it comes in handy all the time. > Data-driven programming. I'll just quote some really smart people: You might want to check out Alloy. It's…

Can you expand on your process for using TLA+ in web development?

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

#22

Post by busterarm »

vorotato wrote: post #20
Jtsummers wrote: post #12

Earlier quoted context omitted.

The analogy would be more appropriate if you said programmer and not software engineer. Anyone calling themselves a software engineer should be providing input into the design of the thing they're producing. Their role is very explicitly managing requirements and codifying them in, well, code. Either directly doing the programming or managing those who do.

Except software engineers are often placed in subordinate roles because "WE WANT ONLY THE BEST". If you aren't given the authority to change the design, caring about it is an unnecessary source of anxiety and stress.

Many times, I feel this.

Really though, caring about what the problem is and trying to solve it means: 1) you work slower, 2) you ask a lot of questions, 3) you push back on things. Basically you're spending more mental effort trying to encapsulate what the problem is than the stakeholder.

Those things will often make people either hate you or think you're bad at your job.

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

#23

Post by nomel »

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.

Thinking about the developer helps prevent me from being lost in complexity, abstraction, or the general specific of the problem. Thinking of the user keeps the game in sight.

In all cases, I've had very "clever" solutions that are fun and challenging, that I completely scrap for something the other developer, and myself, can understand in 3 months.

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

#24

Post by chroem- »

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 in reality other engineering disciplines deal with unexpected failure modes all the time. The only difference is that these other engineers are motivated to be significantly more thorough about their jobs.

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

#25

Post by Animats »

bsaul wrote: post #9

Great article, but it leaves me with one question : what's the difference between good code generating systems (the ones mentionned, that you'd use to build critical system), and the horrors that we saw back in the time with wysiwig HTML editors such as dreamweaver ( to the point where nobody today would dare to write an html website with something other than a text editor) ? The second problem seems a lot easier to…

What went wrong with Visual Basic?

(HTML/CSS/Javascript was botched so badly that Dreamweaver-type editors no longer work. This is embarrassing.)

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

#26

Post by FrancoisBosun »

combatentropy wrote: post #6

If TLA+ really does let you prove your program is bugless, then maybe it is something to look into for cars, airplanes, medicine, etc. For the rest of us, who still wrestle with complexity but probably would't accidentally kill someone, here are some simpler aids: 1. Don't put a computer there. My microwave doesn't need to be digital. It needs two dials, time and power. My mother's washing machine can be controlled b…

Smartphone controllable light switches and blinds are useful for disabled people.

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

#28

Post by Animats »

walshemj wrote: post #27

The example however (911 outage) is a poor one a traditional telco could not make that mistake with POTS they talk in major failures (ie losing a switch) as a once in a generation or two.

In the history of the Bell System, no electromechanical exchange was ever totally down for more than half an hour for any reason other than an natural disaster.

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

#29

Post by walshemj »

FrancoisBosun wrote: post #26
combatentropy wrote: post #6

If TLA+ really does let you prove your program is bugless, then maybe it is something to look into for cars, airplanes, medicine, etc. For the rest of us, who still wrestle with complexity but probably would't accidentally kill someone, here are some simpler aids: 1. Don't put a computer there. My microwave doesn't need to be digital. It needs two dials, time and power. My mother's washing machine can be controlled b…

Smartphone controllable light switches and blinds are useful for disabled people.

Voice control would be easier (assuming they are not deef bind )

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

#30

Post by david927 »

Animats wrote: post #25
bsaul wrote: post #9

Great article, but it leaves me with one question : what's the difference between good code generating systems (the ones mentionned, that you'd use to build critical system), and the horrors that we saw back in the time with wysiwig HTML editors such as dreamweaver ( to the point where nobody today would dare to write an html website with something other than a text editor) ? The second problem seems a lot easier to…

What went wrong with Visual Basic? (HTML/CSS/Javascript was botched so badly that Dreamweaver-type editors no longer work. This is embarrassing.)

What went wrong with Visual Basic?

The language was simple enough for beginners but not sophisticated enough to scale for large projects. All too often you would have a project that started in VB as a proof of concept which then extended to become the actual system, and then as that system grew it started to collapse under its own weight. The conversion to the CLR fixed a lot of that, but now it isn't really for beginners anymore.

HTML/CSS/Javascript was botched so badly

That combination is atrocious out-of-the-box. There was no "botching" it, but rather (again) scaling to larger problems showed that the foundation was always made of sand.

Post reply on HN