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

231–240 of 274 posts

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

#231

Post by imtringued »

sidlls wrote: post #169
emodendroket wrote: post #132

Earlier quoted context omitted.

So basically all our problems will go away if we return to UML and requirements documentation that's hundreds of pages long and edited for ages before anyone writes any code.

That sort of development practice has a much closer relation to engineering than current practice does: it's just that it's extremes are on the other end of that one.

The difference is that engineering has to get it right the first time. There is no second try. Most software isn't like that. It gets continually updated and maintained over several years after the initial release.

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

#232

Post by imtringued »

vssr wrote: post #227

Even though this article resonates with me, I think it portrays everything much too glamorous. I wish the subjects described were the only source of problems. I suspect that in reality, most mistakes have quite 'simple' causes. Some observations: - By putting an abstraction layer in between, people visually creating applications, the problem is pushed to the layer below and new problems will be introduced. - Supporti…

>- Those millions of lines of codes usually include a number of Linux kernels.

Yes. They didn't write the majority of the code themselves.

Here is a repository that shows how much opensource software is inside a BMW i3 https://github.com/edent/BMW-OpenSource

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

#233

Post by AndrewDucker »

dasil003 wrote: post #178
SiVal wrote: post #153

Earlier quoted context omitted.

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…

Apparently a "subtle conceptual error" can have massive consequences in architecture.

http://people.duke.edu/~hpgavin/cee421/citicorp1.htm

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

#234

Post by lmm »

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…

It's analogous to a translation note: any time you need to add a comment is a time where you've failed as a programmer. Sometimes it's necessary, but it should be a last resort.

I can well believe that writing Perl would require comments, but to my mind that's a case of "don't do that then".

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

#235

Post by Bartweiss »

woah wrote: post #94
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…

Do you also consider static types, for loops and exceptions to be "snake oil"?

No, and I don't think they have anything to do with Bret Victor's vision outlined in the article.

If by "change how we code" you mean use Rust for safety guarantees? Then yeah, sure. But that's not how you get to "not putting code into a text editor".

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

#236

Post by talmand »

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…

One problem I see with that quote is that it is presuming that all programmers choose to just dive in at their discretion. It ignores the fact that often programmers are simply told to just dive in and deliver quickly. It's simply a game of mixed attitudes on project management delivers mixed results.

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

#237

Post by tangue »

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 tend to write code four times following the same principles, the first two are similar, then the client explains his real needs and I have to start again.

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

#238

Post by daemin »

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…

Actually I would consider that a decent comment, since get_name() doesn't actually say what name it is getting. It could have been some other name in the system.

This would depend on the context and the surrounding code though.

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

#239

Post by igravious »

shalabhc wrote: post #147
igravious wrote: post #97

So. Minus all the doom and gloom. Better safety harnesses, better developer abstractions, more interactive/responsive programming environments. Whatever Bret Victor's selling, I'm not buying. He's the type of self-promoter who doesn't acknowledge all the actual hard work that has been going on for decades in all of these areas.

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? Why not glass half full? Why not say, "wow – given how many lines of code are out there isn't it amazing how much has not gone tits-up? (pardon the expression!) That wouldn't fit the Bret Victor narrative though.

One last thing – the claim that we are oh so crap at manipulating symbolic machinery. That too is suspect, one could argue we actually seem hard-wired through evolution for linguistic, logical, and symbolic thought.

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

#240

Post by wolfgke »

mac01021 wrote: post #224
amag wrote: post #152

Earlier quoted context omitted.

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…

Sounds like you should have gone to the CEO and got there before the sales guy did....

> Sounds like you should have gone to the CEO and got there before the sales guy did....

He did the right thing: He did quit the job.

No, seriously: If you work at a company where the CEO gives the salesperson that kind of permission (with the described consequences), you really better quit, since it is by definition a dysfunctional company.

Post reply on HN