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

211–220 of 274 posts

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

#211

Post by combatentropy »

hwayne wrote: post #93
katelynsills wrote: post #21

Earlier quoted context omitted.

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

Sure! I've written a quick demo here[1] and a longer-form piece here[2]: [1] https://www.hillelwayne.com/post/modeling-deployments/ [2] https://medium.com/espark-engineering-blog/formal-methods-in...

Is TLA+ pseudocode? It doesn't actually do anything, right? Your example with updating servers, it will never actually update the servers, right? After you try it out in TLA+, you still have to write the real code in some other language, like Bash.

If so, then isn't there still a risk of bugs in your Bash program, from typos, leaving out something from the TLA+ plan, or otherwise miscopying it?

If so, TLA+ does less than I thought. But I can see how it might be useful to work out a complex algorithm and scan it for holes.

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

#212

Post by btschaegg »

michaelchisari wrote: post #164
fusiongyro wrote: post #119

Earlier quoted context omitted.

I feel like this is part of why Brooks says build the first one to throw away, because you're going to. People seem quite unable to imagine life with a program that doesn't exist. Building a more precise specification would be valuable if people were really able to evaluate the specification as if it were a program, but they don't seem to be able to do that. So we wind up building the whole thing to see if it's right…

> Brooks says build the first one to throw away A great theory, but all too often, companies have a hard time scheduling time for a rewrite, and the hacked-together rough-prototype code gets pushed into production in perpetuity.

I'm more and more wondering if the real reason isn't that business people have issues with technical terminology. In this case: A prototype is something you throw away before you build the real thing. Yet somehow many non-technical people think its meaning lies more along the lines of "beta".

I've seen other misunderstandings like people describing security-focused static analysis as "pentest". Each time I'm just left scratching my head...

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

#213

Post by btschaegg »

ako wrote: post #210
michaelchisari wrote: post #164

Earlier quoted context omitted.

> Brooks says build the first one to throw away A great theory, but all too often, companies have a hard time scheduling time for a rewrite, and the hacked-together rough-prototype code gets pushed into production in perpetuity.

And that's because companies have learned that customers usually aren't patient enough to wait for something rewritten. Most customers want something now, even if it's not perfect, rather than wait for something better. So, to survive in a markplace with these types of customers, companies have to shorten time to market...

Well, even that explanation would imply that the company should give you time to at least fix the worst hacks after they've released the first version (which will probably have problems anyway), but that also doesn't seem to happen...

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

#214

Post by chis »

Does anyone work in the field of formal verification? I’m a senior in school and always enjoyed the actual “computer science” more than coding itself. I’m gonna end up at a google/Microsoft type place programming webapps unless I find something else to do in the next couple months.

I guess my question is just: is it a worthwhile career, and is the field growing?

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

#215

Post by jahewson »

chis wrote: post #214

Does anyone work in the field of formal verification? I’m a senior in school and always enjoyed the actual “computer science” more than coding itself. I’m gonna end up at a google/Microsoft type place programming webapps unless I find something else to do in the next couple months. I guess my question is just: is it a worthwhile career, and is the field growing?

Microsoft Research has a group which explores tooling for software engineering:

https://www.microsoft.com/en-us/research/group/research-in-s...

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

#216

Post by skgoa »

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…

I almost always write the major steps as comments (beginning with 'TODO:') first and then do the implementation once I'm satisfied that I know what a good solution looks like. Over the years I have had the misfortune to discover way too many functions that just were 50% implemented or simply did something that was not at all what they were supposed to do.

I don't doubt that conscientious developers can arrive at good code however they prefer. But there are a lot of people out there who will start with a quick and dirty implementation that they then debug into a more or less functional state. I see a push towards making people stop and take a moment to think about what they are going to do. Test-driven development is another tool to achieve that end.

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

#217

Post by Aeolun »

HumanDrivenDev wrote: post #203

A lot of it comes down to the fact that this isn't engineering, and we aren't engineers.[0] The field has a very low barrier to entry (much lower than a bachelors degree). The standards are low, the expectations are low, and there's a strong anti-intellectualism streak. Don't believe me? try talking about "esoteric" stuff like category theory, logic programming, LISP or writing functional specs. At the workplace most…

> category theory, logic programming, LISP or writing functional specs

But does it fix my problem? I'm sure category theory is interesting for it's own sake, but it won't help my boss add this extra attribute to our product, so it won't help me get paid.

Given that I've already added fifteen form fields this week, my mind is too overburdened to care much about category theory, which will have exactly zero relevance to my next week of adding form fields.

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

#219

Post by shubb »

skgoa wrote: post #216
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…

I almost always write the major steps as comments (beginning with 'TODO:') first and then do the implementation once I'm satisfied that I know what a good solution looks like. Over the years I have had the misfortune to discover way too many functions that just were 50% implemented or simply did something that was not at all what they were supposed to do. I don't doubt that conscientious developers can arrive at good…

That's more like the carpenter drawing marks in the wood to tell him where to cut.

I feel like, complexity is a problem when there is more software than one person could write. At this point, you probably need to do some Business Analyst type stuff.

For instance, we are aware of race conditions in code, and maybe we can avoid them by writing purely functional programmes in rust or whatever people do these days.

But what about the race condition of several servers restarting repeatedly and coming back up in a different order? Or a customer registering online when he already sent a form in by post?

The oldschool way of doing this was big UML drawings. This was a compromise because both programmers and business subject matter experts hate drawing them equally.

People don't tend to do this anymore because it is 90s and smells of XML and Java. But what replaced it?

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

#220

Post by zubairq »

For me, it was nice to see Chris Granger (now working on Eve at witheve.com) and the Light Table guys get recognition for Light Table influencing Apple. To quote: "The default language for making new iPhone and Mac apps, called Swift, was developed by Apple from the ground up to support an environment, called Playgrounds, that was directly inspired by Light Table."
Post reply on HN