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

241–250 of 274 posts

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

#241

Post by wolfgke »

btschaegg wrote: post #212
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.

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 lef…

Solution: Be pedantic in your usage of words and correct people around and before you all the time if they use a word wrongly.

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

#242

Post by zimpenfish »

cup-of-tea wrote: post #228
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…

Oh dear. Thank goodness civil engineers do not build by trial and error. Many programmers do use the trial and error approach but their programs are riddled with bugs. There is no way that code is the best or most useful "blueprint" for software. Your analogy is quite good, though, just not in the way you intended. If civil engineers did what you suggest then they would build magnificent structures which work in thei…

> Thank goodness civil engineers do not build by trial and error.

Oh but they do. Hundreds - if not thousands - of years of trial and error and catastrophes and deaths.

But the failures get written up, taught, remembered, and applied to future projects.

(And even then not perfectly - witness Mexico City and buildings on a drained lake in an earthquake zone; or Houston's wild building expansion in a hurricane-prone floodplain.)

Software, in contrast, has barely 60 years under its belt and a culture of hiding failures. Give it another 500 years and it'll start to look more like the architecting and building industries we have today.

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

#243

Post by TheCapn »

Bartweiss wrote: post #43
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…

> 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 engineers live like that?

Well for one thing the engineer planning the electrical isn't the engineer planning the structure. The engineer who scoped the HVAC isn't the guy who wrote the company's website either.

This is a long term problem that we need to begin recognizing and addressing today. I wouldn't expect the programmer who is building the frontend to understand the network security. I wouldn't expect the database guy to know the server administrative role.

Sure there's overlap but to have a team of people whose focus is that specific role is partially what engineers do. As a software engineer myself it's illegal for me to go onto my client's sites and start engineering their electrical system. I pass that effort to my coworkers who are electrical engineers in just the same way they ask me to design them their databases and their network.

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

#244

Post by kwhitefoot »

WYSIWYG has been mostly a disaster. We now have several generations of people who 'paint' documents instead of writing them and styling them. Every paragraph has its own explicit style. It's next to impossible to render such documents to a different published format because nothing is tagged to explain why it looks the way it looks. I was at least as productive writing in Wordstar 35 years ago as I am now in Word 365 or whatever the current name is.

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

#245

Post by kmicklas »

AnimalMuppet wrote: post #80
kmicklas wrote: post #56

Disappointing to see such a long article and no mention of type theory, or any other work from the "correct by construction" school of formal methods. It's all normie model checking, TLA+ etc.

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…

> But it's inadequate for the larger problem, of whether the operation is the correct one.

Huh? Types (of the sufficiently advanced kind) are one way of specifying behavior in the same sense as TLA+ and other models. The difference is that type theory provides a coherent story for how to form entire systems like this in a composable manner. Traditional modeling/spec languages, not so much.

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

#246

Post by kazinator »

A programmer should be able to dive straight into code and get it right the first time, up to a certain level of complexity of problems.

I'm not going to say that the bigger the problem you can solve just by throwing code at it the better the programmer you are. But it speaks well for you; you have an advantage in an certain dimension.

If I can visualize the solution, see all the cases and debug it in my head, why not go to code? We should encourage that; the more you practice taking a problem straight to code, the better you get at it. Just people have to be reasonable about it; don't try to just code something whose complexity is two orders of magnitude out of the ballpark for that.

Currently I'm grappling with the design of compiling functions with nested lexical scopes. I haven't written any code on this for a couple of weeks, but I have some box and arrow diagrams representing memory and pointers. I've mulled it over in my head and have hit all the requirements. I have a way to stack-allocate all of the local variables by default, and hoist them into the heap when closures are made. I have kept in mind exception handling, special variables and such. Amid all this thinking, I barked up a few wrong trees and backed down, thereby avoiding making such mistakes more expensively in coding.

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

#247

Post by noir_lord »

mac01021 wrote: post #226
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…

I remain open-minded to the idea that category theory could help me make better computer programs, but I have yet to see anything that suggests to me that it really would. FWIW, I understand how monads work in Haskell & co, and I definitely see their value. But I don't consider myself to know any category theory at all.

SQL and category theory have a fair degree of overlap so there is that.

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

#248

Post by btschaegg »

wolfgke wrote: post #241
btschaegg wrote: post #212

Earlier quoted context omitted.

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 lef…

Solution: Be pedantic in your usage of words and correct people around and before you all the time if they use a word wrongly.

Let's say it that way: If that's an effective way for you to deal with this, I envy you for your work environment.

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

#249

Post by shalabhc »

igravious wrote: post #239
shalabhc wrote: post #147

Earlier quoted context omitted.

Can you point to what work specifically has improved the situation in terms of `developer abstractions` and `interactive/responsive programming` in the last few decades?

Yup, I can. Safety harnesses -> work in type theory and proof theory, witness the success of Rust and Haskell and Coq and so on. Developer abstractions -> work on design patterns and anti-patterns among other things. interactive/responsive programming -> IDEs, refactoring, time-travel debugging, visual programming spring to mind. To write off all these advances is suspect in my opinion. Also, why so glass half empty?…

> interactive/responsive programming -> IDEs, refactoring, time-travel debugging, visual programming spring to mind.

> one could argue we actually seem hard-wired through evolution for linguistic, logical, and symbolic thought.

I think you're still talking about programming environments layered on top of the text centric representation, while Victor seems to be talking about something a little different. Sure we can do some symbolic and linguistic manipulation, but consider that rigorous blueprints for physical products such as cars and buildings are 'diagrams', not text. So purely language based description and manipulation doesn't apply everywhere. Now, what if many programs, or parts of programs may be better represented not as text with symbols, but in some other form that we haven't discovered yet?

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

#250

Post by shalabhc »

igravious wrote: post #239
shalabhc wrote: post #147

Earlier quoted context omitted.

Can you point to what work specifically has improved the situation in terms of `developer abstractions` and `interactive/responsive programming` in the last few decades?

Yup, I can. Safety harnesses -> work in type theory and proof theory, witness the success of Rust and Haskell and Coq and so on. Developer abstractions -> work on design patterns and anti-patterns among other things. interactive/responsive programming -> IDEs, refactoring, time-travel debugging, visual programming spring to mind. To write off all these advances is suspect in my opinion. Also, why so glass half empty?…

> To write off all these advances is suspect in my opinion.

> That wouldn't fit the Bret Victor narrative though.

Consider the possibility that there are real gaps people see and are trying to fill, rather than just trying to 'fit' a particular narrative.

Post reply on HN