Hacker News Reader

Comment by raverbashing | Hacker News Reader

What I take from this: computer languages (C++ especially, but also systems built in C) are too complex for the average mind

No, I'm not significantly smarter than the average programmer

That's what needs to be addressed.

While C++ facilitates things, it is complex. While C is very simple it makes mistakes easier by requiring things to be done manually

IDEs don't help. Code completion is helpful but it is of limited help

And we keep repeating ourselves every time we write a for loop

View on HN

>computer languages (C++ especially, but also systems built in C) are too complex for the average mind

I'm not necessarily disagreeing, but have you looked at the source code [1] of the Apollo Guidance computer [2]? This software was shipped to production 50 years ago. It literally implements a "self-driving space rocket." It is staggering that this was completed in such a short time and actually worked.

The code is written entirely in the "Apollo Guidance Computer (AGC) Assembly" language. The hardware that it was written for had to be invented in at the same time, and was the world's first computer to use Integrated Circuits ("chips"). They also implemented a Real-Time Operating System with a multi-task priority scheduler, as well as a virtual machine and assembly interpreter within the software.

This was mission and life safety critical code, the risk involved boggles the mind. And yet the software was incredibly reliable. It was so reliable that it even saved the Apollo 11 crew and mission during the lunar descent by famously recovering from a peripheral hardware bug.

I honestly do not know how this feat was even humanly possible, but I do know that these programmers did not rely on "code completion."

[1] https://github.com/chrislgarry/Apollo-11 [2] https://en.wikipedia.org/wiki/Apollo_Guidance_Computer

Yeah, sure. But if they'd had code completion it would have been a help, not a hindrance.

>I honestly do not know how this feat was even humanly possible

The Apollo program, fixed for inflation, was something like $130 billion dollars. That's buys you a lot of talent, testing, etc. Its also worth noting that the program wasn't without its screw ups. The Apollo 1 deaths. The radar control on Apollo 11 eating up all the CPU during lunar landing. Apollo 13's famous O2 tank explosion.

I think you may be glamorizing something that was well done, but falls within the realm of 'you get what you pay for' and the occasional human error, which in the case of Apollo 1, turned out to be fatal. I wouldn't call a program with three deaths and an aborted lunar insert to be infallible.

That said, NASA/JPL publish code standards, although I imagine most tech companies would balk at giving up their toys and hot languages/frameworks to do fairly tedious work like this.

http://lars-lab.jpl.nasa.gov/

>That said, NASA/JPL publish code standards, although I imagine most tech companies would balk at giving up their toys and hot languages/frameworks to do fairly tedious work like this.

For most companies developing non-critical software, applying such harsh coding standards will not be cost effective after all. The cost of you browser crashing is not nearly as high as the cost of a crashing rocket...

Besides, even NASA sometimes makes mistakes: http://www.viva64.com/en/b/0416/

Agreed, there are reasons why we do certain things a certain way. But in the age of ransomware and endless cyberwars and nation state spoofing maybe the idea that browsers and other internet facing applications should be barely-shippable shit code is antiquated.

You can't protect everything, but I'm sure they have a secure browser at NSA )

NSA just uses isolation approach in air gaps or hypervisors like these:

The high-assurance community in academia and commercial sectors keep building secure browsers, though. One, OP browser, was inspiration for Chrome security model. They severely weakened it for performance. IBOS is probably most interesting. There's links at the comment below.

https://news.ycombinator.com/item?id=9969961

Quark kernel is one that's not in that comment for some reason:

http://goto.ucsd.edu/quark/

I just realized I forgot the link with their hypervisors. It doesn't matter because most of them suck. You're better off not seeing it. :)

I'm sure that there is a happy medium to be found; a modicum of organisation and discipline must surely save more money by avoiding confusion and wasted time than it costs. How much effort does it take to use a linter? To crank the compiler warnings up to maximum? -- versus the time wasted bug hunting and in heroic struggles with spaghetti-monster codebases...

> The Apollo program fixed for inflation is something like $130 billion. That's buys you a lot of talent, testing, etc.

$130 billion was the total Apollo program budget. For the Apollo Guidance Computer (AGC) software in question, "In total, software development on the project comprised 1400 person-years of effort, with a peak workforce of 350 people." [1]

I would value 1400 programmer person-years at about $200 million. So ... a lot of money, but still less than GitHub's $250 million Series B raise.

Edit: Also, refer to the Mythical Man-Month for explanation of why throwing people and money at a software project doesn't guarantee success.

> Apollo 1 deaths

This was not due to any AGC software bugs. It was a cabin fire during a launch rehearsal test at Cape Canevaral and was essentially a plumbing design issue. [2]

> Apollo 11 eating up all the CPU during lunar landing

That was not catastrophic and was NOT due to an AGC software bug. It was caused by a peripheral hardware error. In fact AGC software's priority scheduler design actually saved the Apollo 11 mission and crew by recovering the CPU. [3]

> Apollo 13's famous O2 tank explosion

Again, nothing to do with the AGC software. Apollo 13 was a mechanical failure related to the famous O-ring issue. [4]

[1] https://en.wikipedia.org/wiki/Apollo_Guidance_Computer#Softw... [2] https://en.wikipedia.org/wiki/Apollo_1#Major_causes_of_accid... [3] https://en.wikipedia.org/wiki/Apollo_Guidance_Computer#PGNCS... [4] https://en.wikipedia.org/wiki/Space_Shuttle_Challenger_disas...

The cost vs results obtained where astronomical and ridiculous. Ok for such pioneering work hitting many grand challenges at once. Not in any way applicable to normal software development given its constraints. However, I think a few numbers from high and medium assurance are interesting to show how things improved.

1. The high-assurance LOCK program to build secure HW/SW system w/ UNIX compatibility layer cost only 58% more than a normal, solid development. That's with ancient formal methods.

2. Altran/Praxis uses strong requirements gathering, formal specs in Z, language-level safety with Ada, design-by-contract for interfaces, SPARK where possible to prove absence of specific errors, and plenty of testing. Error rate is around 0.04 per Kloc. Cost about 50% extra the one time I heard a price reference.

3. seL4 spent about $350/loc on a 10,000 loc system for formal verification down to C itself.

4. COGENT is one of approaches moving safety into type system of safe, system language with certified translators. This allowed non-experts to safe-code the ext2 file system with effort going down from 1.65 person-months per 100 loc in seL4 to 0.69 in COGENT.

So, we're steadily seeing the level and pervasiveness of assurance go up in these projects while cost goes down. Also, as in 80's and 90's recommendations, the best results come from applying high-assurance engineering to stuff that is small, changes little, aids correctness of other stuff, and is reusable. Fortunately, some of our most important stuff has those properties. Including compilers, type systems, parser generators, TLS-style protocols, standard libraries, and so on.

So, we certainly can't spend Apollo money on a pile of assembly code using rope memory getting Apollo results. We can spend 30-50 percent on improvements to software development using existing tools to get nearly 0.04 defects per kloc. We can also do better than Apollo using state-of-the-art tooling like Isabelle/HOL, COGENT, QuickCheck, Design-by-Contract, SPARK, and CakeML. Each thing we build, if focusing on right places, can bootstrap more trust or quality into the other stuff. So, given existing and open-sourced work, it's just as exiting time to be in high-assurance engineering as it was back when Hamilton et al had free reign to invent it.

[1] https://cryptosmith.files.wordpress.com/2014/10/lock-eff-acm...

[2] http://www.anthonyhall.org/c_by_c_secure_system.pdf

[3] https://www.semanticscholar.org/paper/From-a-Verified-Kernel...

[4] https://ts.data61.csiro.au/projects/TS/cogent.pml

Margaret Hamilton, whose team built it & co-invented software engineering, described the process they used to build that in "Apollo Beginnings:"

http://htius.com/Articles/r12ham.pdf

It had little to do with assembly language. They did what most don't by trying to understand root cause of every issue they encountered in software development. Then, they modified their tooling and methodology to systematically eliminate it. They also designed a multi-process, fail-safe OS whose properties are similar to Erlang. They also invented a form of Design-by-Contract to catch errors at interfaces, which are majority.

By the time assembly was ready, they had done an amazing amount of specification, analysis, and testing on both individual functions and groups of them. They also had fail-safe and recovery built-in to everything to anticipate inevitable failures, which did show up. There were also 400, highly-motivated individuals working at it for a good chunk of time. The result was this pile of software [1] got people to the moon safely despite multiple failures outside of it. Quite amazing but says almost nothing about safety assembly in regular development.

[1] https://www.wired.com/wp-content/uploads/2015/09/Margaret_Ha...

I wouldn't say that the number of errors in code directly depends on complexity of the language. From my practice I learned that the code quality depends on a software development process implemented in your team. Now we have whole bunch of practices and tools that allow us to minimize risks of appearing stupid mistakes in code: covering the code with unit and integration tests, static and dynamic code analysis, continuous integration, code reviews, refactoring and so on, and, I should say, these things work. So, I think, this article demonstrates that still there are a lot of teams whose development process can be improved.

> While C is very simple it makes mistakes easier by requiring things to be done manually

I wouldn't describe C as simple but basic. Of course, it's start being less basic with all the macros and all the tools needed to compile and distribute a C program , like autoconf ... with all these layers , C becomes as complicated as any other language because it relies on so many 3rd party tools (which are often dynamic languages) to fix its shortcomings. But as long as linux kernel is written in C the language isn't going anywhere.

That's actually the problem Ada's designers set out to solve. They add to what they solve every iteration with safe defaults and contraints on use. Whether you do Ada or not, you will likely find skimming this book to be helpful to see how one can systematically analyze all forms of programmer error and attempt to eliminate them:

http://www.adacore.com/uploads/technical-papers/SafeSecureAd...

That's at language level. At process level, Harlan Mills developed Cleanroom back in 80's to try to get software defects as low as cleanrooms CPU's were built in. It combines a formal approach of describing/connecting things, constrained implementation for easy verification, iterative development, and usage-based testing. Defect rate was extremely low even for first use by teams with cost ranging from slightly more to cheaper due to less debugging.

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.88....

On productivity side, the DSL-based approach on top of safe, functional languages seems to be winning out. Safe, functional combo already knocks out a lot of problems. DSL's for common categories of programming let you read and write less code to get same work done possibly safer with sane auto-generation (eg parsers, protocols, GUI's). iMatix even did it for C-based, enterprise software.

So, there's certainly work on methods for mainstream software development of average coders with still high quality. Cleanroom was most successful in terms of defect rate. Eiffel pretty much made a market out of it by combining safer language, safe concurrency, OOP, and Design-by-Contract. They're still going strong. Haskell community probably most advanced given last item on my list with some financial companies using it. Jane Street's and Esterel's Ocaml work shows it has similar benefits. These have steeper learning curve but benefits add up quickly afterward.

Cleanroom w/ Design-by-Contract and safe, high-level language seems to be best combo to deal with your list.

Switch to Common Lisp.

And with lisp, you don't have to repeat yourself: any pattern, or any boilerplate can be abstracted away with a macro.

> can be abstracted away

Except for too many levels of abstraction.

Is that the fault of the programmer or the language, though?

It's a reference to https://en.wikipedia.org/wiki/Fundamental_theorem_of_softwar... (and the "humorous clause" mentioned there as well)

Yes, I believe one of the problems is the way things are abstracted, and I don't see a language solving this

Adding more levels can only go so far

But I don't know how to do it better. Module/Class/Method won't cut it anymore

That's kind of what some compiler optimizations do isn't it? Look through the abstraction and discard it?

The fact that something can be done doesn't mean that it should be done.

How can CL prevent something like "i1 == i1" instead of "i1 == i2" error?

First, since the AST is so simple to walk programmatically, one could write a simple check for that kind of bug in, I'm guessing, a few lines of Lisp.

Second, just because you can come up with a bug that can be written in a language doesn't mean the language doesn't prevent all sorts of other bugs.

All languages can have bugs written in them. That's not the point.

This also includes analysis of C#, which is quite different from C.

Yes, while C#/Java will prevent some kind of errors from happening, others are very common

(Example: copy/paste errors, parameter order problems, etc)

Reply on news.ycombinator.com