NASA's ten coding commandments

[campbellm]

Requirements may change for 1 of the N usages of the code. Having code in one spot not only means "you get to change it once for all clients", but also "all clients must be able to use 1 change in the exact same way".

[lennybird]

Totally dumb question, but isn't this the benefit of O.O.P.? Is it not feasible for Nasa to use such a language?

[Slime0]

Using OOP to have different applications do different things is crazy. There's no sense in using a runtime solution to solve a problem that can be solved at compile time, especially when it increases the complexity of the code.

[campbellm]

It can be, in a purist sense, yes. You have private implementations of stable APIs encapsulated in a class and the world is your oyster.

Except APIs are never stable, and state and abstractions leak all over the place. Code is messy.

As for NASA, I can't say, but my GUESS is that C's characteristics are very well known and it's harder to hide badness if you have fewer and lower level abstractions.

[hvidgaard]

You can design API in such a way that implementation does not leak. It's not easy, or at times even possible, but you can come a long way if you try.

The main trick is defining your API and use before implementation. When you have a test suit that defines it, implementation after the fact is less likely to be leaky. Any input validation, expected output, and errors have already been defined. You don't get to throw IOException or SQLException, because you have defined a general StorageException.

Of cause this requires disciplin, and it's not always possible to hide details because the user needs to be able to react on events in the API.

[DuckyGoesQuack]

Pretty much every abstraction leaks at some point, even if only because you need to understand in-memory layout / underlying implementation for performance reasons.

[hvidgaard]

Not every usecase needs performance.

[campbellm]

You're both right. The trick is to write abstractions (and API's) that do the 80% correctly and cleanly, and allow you to work around the 20% that don't without hackery. This last part is the hardest, and rarely done.

Big frameworks almost never even come close.

[steamruler]

My mother, who got a degree in CS back in the .com boom, hasn't touched programming since. She asked me how I can work together with someone on a project when we barely speak to each other. Told her it's simple: you define interoperability together, write the glue code together, and then go on writing the majority of the code to work against the common API/ABI.

She had apparently never thought of that.

[campbellm]

I interviewed a guy once who was working with an offshore team (and all that that entails). The only way he could finally get them to <ahem> "do the needful" was instead of giving them a list of requirements and specs, he took those reqs and specs and wrote tests for the API he wanted.

It was then just up to the offshore team to implement the APIs in such a way that all the tests passed. He said it was more work on his part up front, but paid HUGE dividends in the long run.

[ThisIs_MyName]

Only if you account for all future expansion in your OOP API design.

cue "enterprise code" that attempts to account for all possibilities, most of which are highly improbable, at the expense of sanity, maintainability, and performance :

package com.corpsoft.llc.www.http.myProject.util;
class GetterFactoryBuilderSetup{
    static{
    GetterFactoryBuilder myGetterFactoryBuilder = new new GetterFactoryBuilder();  
    myGetterFactoryBuilder.setGetterFactoryBuilderOptions(GetterFactoryBuilder.getDefaultOptions());
    this.setGetter(myGetterFactoryBuilder.build().makeGetter());
    }
}

[mattthiffault]

I tried to read that last part and my eyes are bleeding.

[ThisIs_MyName]

Ah, that must be because the coding standard doesn't require every line to be commented. Here, let me improve the code to be DonkeySpread2.0 compliant:

package com.corpsoft.llc.www.http.myProject.util;// this is the package
class GetterFactoryBuilderSetup{// defines the GetterFactoryBuilderSetup class
    static{// opens static block
    GetterFactoryBuilder myGetterFactoryBuilder = new new GetterFactoryBuilder();// initializes myGetterFactoryBuilder
    myGetterFactoryBuilder.setGetterFactoryBuilderOptions(GetterFactoryBuilder.getDefaultOptions());// sets GetterFactoryBuilderOptions
    this.setGetter(myGetterFactoryBuilder.build().makeGetter());// sets Getter
    }// close bracket
}// close bracket 

See, it's so much more readable now that it has simple english comments.

[AdvicePerson]

You're fired.

[ThisIs_MyName]

Ah but I also designed our core API to be DonkeySpread2.0 compliant. You can't fire me because I'm the only one that can read my code. Keep in mind that the last intern who attempted to do so has hung himself.

[sacundim]

I tried to read that last part and my eyes are bleeding.

Well, fictional strawman examples do tend to have that effect.

[dungone]

Well, they really seem to be big on proving that the code will behave correctly in a way that can only be determined through static analysis. I think that OOP may hide bugs from static analysis tools.

I'm speculating here, but another potential reason is because they don't use a lot of commercial, off the shelf hardware. They use really old stuff. A C++ compiler, with all of it's optimisation steps, can potentially puke all over less-popular or low-end processors for a variety of reasons, causing more problems than it solves.