Programmers who want to change how we code before catastrophe strikes • Hacker News Board

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

#201

Post by arvinsim » Thu, Sep 28, 2017, 3:00 AM UTC

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.

I agree with this.

Imagine studying about web design, accessibility and usability for many years. You feel that you have something to contribute to the design of any app.

Then the higher ups just hands you a spec and assigns you to a task to fix this bug/implement this feature without your input.

That's pretty damn demoralizing. It will just push you towards caring more about streamlining your own workflow to rather than care about the actual usability of the app.

Maybe that's the reason why there is so much interest in the in what workflow to use, what IDE/text editor to use, which languages to program in, etc.

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

#202

Post by maerF0x0 » Thu, Sep 28, 2017, 3:29 AM UTC

drawkbox wrote: post #184

Programmers write code badly due to time constraints in many cases or really disconnected teams being led by business not engineering. Rarely is budget allotted for quality code, you have to fight for it as a coder to your own detriment internally on timelines/shipping. Engineer led companies, or companies that value engineering as a main decision maker in the company usually fare better with issues like this and are…

Even given good amounts of time engineers often skip tools that could catch some bugs. Examples, TLA+, fuzzers, full code coverage etc.

Sadly all things are economic, so we apply the tools where the cost of a bug is high. In the case of 911, its very high but underfunded. In the case of some consumer app, its (presumably) very low...

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

#203

Post by HumanDrivenDev » Thu, Sep 28, 2017, 3:52 AM UTC

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 of your fellow professionals will stare at you blankly, and even on self-selected places like here or proggit, half the people will rush to dismiss it.

There aren't - as an example - mechanical engineering "bootcamps" because mechanical engineering is an actual engineering field, with high standards, real accreditation, and professionalism. We don't have that, we have middle aged men giving talks in t-shirts and saying stuff like "ninja" and "awesome".

I think we need to face up and rectify the fact that we aren't engineering before we can advance. And yes this requires excluding people who aren't up to standards. We're not the equivalent of chemical engineers - we're the equivalent of alchemists.

[0] with the Caveat that stuff done in Avionics, or Medical Imaging, or anything else with very high standards and rigorous processes could probably be called that.

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

#204

Post by bitwize » Thu, Sep 28, 2017, 3:55 AM UTC

Model-based design has been the wet dream of software managers looking to eliminate costly, finicky programmers for what? Decades now? I remember when I was a college student being told that eventually, the work products of software architects would be UML diagrams that could be turned into code by a simple turn of the crank on an automated generating tool. I didn't buy it then and I sure don't buy it now. The reason why is because once you specify models with sufficient granularity to be automatically turned into code, the graphical symbols in your modelling language become isomorphic to keywords in some programming language, and your programmer-replacing code generator becomes a compiler.

As for Bret Victor... Programming is hard because you are trying to reason about not just the future of a dynamic process, but all possible futures of that dynamic process. That's way too much information to be represented in a visual manner for all but the simplest of systems, and it's why visual programming tools have been met with spectacular failure outside of constrained niches (e.g., LabVIEW, Max and its relatives).

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

#205

Post by dsego » Thu, Sep 28, 2017, 3:58 AM UTC

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…

More and more I'm writing high level pseudo-code, and planning ahead, before diving in. When I'm done, I basically have a to-do list and a good chance of not painting myself into a corner, which would otherwise happen way too often.

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

#206

Post by bitwize » Thu, Sep 28, 2017, 3:59 AM UTC

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.

Bret Victor is like an "all-mouth-and-no-trousers" version of Alan Kay. And many of his talks recapitulate work that Kay and Ingalls did in Smalltalk and Squeak in their various forms. His sexy presentations very closely resemble the "Active Essays" that got promulgated in the Squeak project in the 90s.

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

#207

Post by HumanDrivenDev » Thu, Sep 28, 2017, 4:00 AM UTC

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…

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

I don't think that's a good analogy. Engineers might claim we have it easy because we don't have to face earthquakes or electrical surges or birds flying into our turbines.

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

#208

Post by Animats » Thu, Sep 28, 2017, 4:12 AM UTC

Animats wrote: post #28

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.

Someday I should write up how that was done in modern terminology. You can read the "Number 5 Crossbar" documents, but the terminology is archaic.[1]

Crossbar offices consisted of a dumb switching fabric and lots of microservices. The switching fabric did the actual connecting, but it was told what to connect by other hardware. Each microservice was implemented on special-purpose hardware, and there were always at least two units of each type. Any unit of a type could do the job, and units of a type were used in rotation.

Microservice units included "originating registers", which parsed dial digits, "markers", which took parsed dial digits and routed calls through the switch fabric, "senders", which transmitted dial digits to other exchanges for inter-exchange calls, "incoming registers", which received dial digits from other exchanges, and "translators", which looked up routing info from read-only memory devices. There were also trouble recorders, billing recorders, trouble alarms, and other auxiliary services.

Every service unit had a hardware time limit. If a unit took longer than the allowed worst case time, the unit got a hard reset, and a trouble event was logged. This prevented system hangs.

Failures of part of the switching fabric could only take down a few lines. Failures of one microservice unit of a group just slowed the system down. Retry policy was "try one microservice unit, if it fails, try a second one, then give up and log an error". If a retry with a different unit didn't work, further retries were unlikely to help.

All microservice units were stateless. At the end of each transaction, they went back to their ground state. So they couldn't get into a bad state. All state was in the switching fabric.

All microservice units were replaceable and hot-pluggable, so maintenance didn't require downtime.

This architecture was very robust in practice. It's worth knowing about today.

[1] http://etler.com/docs/Crossbar/

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

#209

Post by jeffdavis » Thu, Sep 28, 2017, 5:22 AM UTC

haskellandchill wrote: post #59

vtange wrote: post #49

So we need to write more code to make fancy Photoshop-like editors for the average-Joe programmer who can't see the big picture? That just adds more to the code issue - even Photoshop has bugs you know. The fact that "Few programmers write even a rough sketch of what their programs will do before they start coding" is a soft-skills/experience issue that isn't specific to software. I too can use Photoshop to draw logo…

No, we need to use logic and set theory and provide tools for visualizing the implications of our rules and checking correctness of desired properties. There's a strong history and lots of good people working on these things but it's tough to get our message out to working programmers. This article helps but based on the comments we've got a lot of perception work to do :)

It goes beyond perception; I think there's something missing, and I think someone is close to finding it.

Databases are already employing logic and set theory to great effect (whether practitioners realize it or not). The fact that you can write a few dozen lines of SQL in a few minutes, and run it over millions of records, and feel confident in the results is astounding.

But there are other types of programming where it has not been so successful. I'm trying to learn some TLA+, and I'd like to see if it can help model resource management/lifetimes.

I think rust is very promising because it brings a lot of PL ideas into a practical setting. One of the best ideas they had was to make it not depend on a runtime, so you could use it without reinventing the world.

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

#210

Post by ako » Thu, Sep 28, 2017, 5:34 AM UTC

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.

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