Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The C++ standard for the F-35 Fighter Jet [video]

youtube.com

Post reply on HN
Print view View original

381–390 of 451 posts

Re: The C++ standard for the F-35 Fighter Jet [video]

#381

Post by jll29 »

adolph wrote: post #371
p_l wrote: post #365

Earlier quoted context omitted.

TL;DR Ada programmers were more expensive

Since when was expense a problem for defense spending? In the video, the narrator also claims that Ada compilers were expensive and thus students were dissuaded from trying it out. However, in researching this comment I founds that the Gnat project has been around since the early 90s. Maybe it wasn't complete enough until much later and maybe potential students of the time weren't using GNU? The GNAT project started…

The DOD could easily have organized Ada hackathons with a lot of prize money to "make Ada cool" if they had chosen to in order to get the language out of the limelight. They could also have funded developing a free, open source toolchain.

Re: The C++ standard for the F-35 Fighter Jet [video]

#382

Post by jll29 »

IshKebab wrote: post #272
ecshafer wrote: post #231

Earlier quoted context omitted.

I've always strongly disliked this argument of not enough X programmers. If the DoD enforces the requirement for Ada, Universities, job training centers, and companies will follow. People can learn new languages. And the F35 and America's combat readiness would be in a better place today with Ada instead of C++.

I agree. First of all I don't think Ada is a difficult language to learn. Hire C++ programmers and let them learn Ada. Secondly, when companies say "we can't hire enough X" what they really mean is "X are too expensive". They probably have some strict salary bands and nobody had the power to change them. In other words there are plenty of expensive good Ada and C++ programmers, but there are only cheap crap C++ progr…

I agree - Ada is very similar to Pascal, and much faster to pick up than, say, C++.

Re: The C++ standard for the F-35 Fighter Jet [video]

#383

Post by zahlman »

SideburnsOfDoom wrote: post #260
bboygravity wrote: post #222

Earlier quoted context omitted.

Why is "no early returns" not a good rule? I do early returns in code I write, but ONLY because everybody seems to do it. I prefer stuff to be in predictable places: variables at the top, return at the end. Simpler? Delphi/Pascal style.

The "no early returns" rule came about because was a good rule in context, specifically C and FORTRAN code before roughly 1990. It was part of "structured programming", contemporary to "Go To Statement Considered Harmful", Dijkstra, 1968. And it became received wisdom - i.e. a rule that people follow without close examination. For example of the rule, a function might allocate, do something and then de-allocate again…

> And they're correct. In most modern languages it's fine. The "no early returns" rule does not apply to Java, TypeScript, C#, Rust, Python, etc. Because these languages specifically made early return habitable.

Early return is perfectly manageable in C as long as you aren't paranoid about function inlining. You just have a wrapper that does unconditional setup, passes the acquired resources to a worker, and unconditionally cleans up. Then the worker can return whenever it likes, and you don't need any gotos either.

Re: The C++ standard for the F-35 Fighter Jet [video]

#384

Post by SideburnsOfDoom »

zahlman wrote: post #383
SideburnsOfDoom wrote: post #260

Earlier quoted context omitted.

The "no early returns" rule came about because was a good rule in context, specifically C and FORTRAN code before roughly 1990. It was part of "structured programming", contemporary to "Go To Statement Considered Harmful", Dijkstra, 1968. And it became received wisdom - i.e. a rule that people follow without close examination. For example of the rule, a function might allocate, do something and then de-allocate again…

> And they're correct. In most modern languages it's fine. The "no early returns" rule does not apply to Java, TypeScript, C#, Rust, Python, etc. Because these languages specifically made early return habitable. Early return is perfectly manageable in C as long as you aren't paranoid about function inlining. You just have a wrapper that does unconditional setup, passes the acquired resources to a worker, and uncondit…

> In C, you just have a wrapper that does unconditional setup, passes the acquired resources to a worker, and unconditionally cleans up. Then the worker can return whenever it like

Right, so you allow early return only in functions that do not have any setup and clean-up - where it's safe. Something like "pure" functions. And you describe a way to extract such functions from others.

Re: The C++ standard for the F-35 Fighter Jet [video]

#385

Post by nmz »

lallysingh wrote: post #304
ecshafer wrote: post #231

Earlier quoted context omitted.

I've always strongly disliked this argument of not enough X programmers. If the DoD enforces the requirement for Ada, Universities, job training centers, and companies will follow. People can learn new languages. And the F35 and America's combat readiness would be in a better place today with Ada instead of C++.

No they won't. DoD is small compared to the rest of the software market. You get better quality and lower cost with COTS than with custom solutions, unless you spend a crap ton . The labor market for software's no different. Everyone likes to crap on C++ because it's (a) popular and (b) tries to make everyone happy with a ton of different paradigms built-in. But you can program nearly any system with it more scalably…

Go was built because C++ does not scale. Anybody that's ever used a source based distro knows that if you're installing/building a large C++ codebase, better forget your PC for the day because you will not be using it. Rust also applies here, but at least multiplatform support is easier, so I don't fault it for slow build times

Re: The C++ standard for the F-35 Fighter Jet [video]

#386

Post by repelsteeltje »

tatjam wrote: post #351
repelsteeltje wrote: post #293

Earlier quoted context omitted.

Can you elaborate? For instance, how would better tooling help with storing a TCP buffer in global memory?

As a quick example, compare doing embedded work with a C static uint8_t[MAX_BUFFER_SIZE] alongside a FreeRTOS semaphore and counter for the number of bytes written, vs using Rust's heapless::Vec , behind a embassy Mutex. The first will be a real pain, as you now have 3 global variables, and the second will look pretty much like multi-threaded Rust running on a normal OS, but with some extra logic to handle the buffer…

Okay, fair enough.

So it's mostly about the absence of abstraction, in the C example? C++ would offer the same convenience (with std::mutex and std::array globals), but in C it's more of a hassle. Gotcha.

One more question because I'm curious - where would you anticipate C would be able to squeeze out more performance in above example?

Re: The C++ standard for the F-35 Fighter Jet [video]

#387

Post by jandrewrogers »

mainecoder wrote: post #362

Did they really have to tell their programmers this ? (see Page 52) AV Rule 174 (MISRA Rule 107) The null pointer shall not be de-referenced.

There are old idioms in C where null pointers are intentionally dereferenced to induce the expected outcome. Not the best way to write that code because beyond being less explicit about intent it also isn't guaranteed to work.

The rule is likely speaking to this code.

Re: The C++ standard for the F-35 Fighter Jet [video]

#388

Post by coppsilgold »

j16sdiz wrote: post #243
coppsilgold wrote: post #187

Earlier quoted context omitted.

> This can be bad if a particular memory cell has failed. If every variable has a fixed address, and one of those addresses goes bad, a patch can be loaded to move that address and the mission can continue. This seems like a rather manual way to go about things for which an automated solution can be devised. Such as create special ECC memory where you also account for entire cell failure with Reed-Solomon coding or s…

It is more than that. This is what make remote debugging possible. It is impossible to do interactive remote debugging over a ultra low bandwidth link. If everything have static address and deterministic static, you can have a exact copy on ground and debug there.

> If everything have static address and deterministic static, you can have a exact copy on ground and debug there.

You can also have deterministic dynamic - the satellite could transmit its dynamic state (a few bits signifying which memory cells failed) and then you proceed deterministically on the ground.

Re: The C++ standard for the F-35 Fighter Jet [video]

#389

Post by fauigerzigerk »

skepti2 wrote: post #319
fauigerzigerk wrote: post #314

Earlier quoted context omitted.

> Why require that companies use a specific programming language instead of requiring that the end product is good? I can think of two reasons. First, achieving the same level of correctness could be cheaper using a better language. And second, you have to assume that your testing is not 100% correct and complete either. I think starting from a better baseline can only be helpful. That said, I have never used formal…

How do you define a better programming language, how do you judge whether one programming language is better than another, and how do you prevent corruption and cartels from taking over? If Ada was "better" than C++, why did Ada not perform much better than C++, both in regards to safety and correctness (Ariane 5), and commercially regarding its niche and also generally? Lots of companies out there could have gotten…

>How do you define a better programming language

A language that makes avoiding certain important classes of defects easier and more productive.

>how do you judge whether one programming language is better than another

Analytically, i.e. by explaining and proving how these classes of bugs can be avoided.

I don't find empirical studies on this subject particularly useful. There are too many moving parts in software projects. The quality of the team and its working environment probably dominates everything else. And these studies rarely take productivity and cost into consideration.

Re: The C++ standard for the F-35 Fighter Jet [video]

#390

Post by jandrewrogers »

bluGill wrote: post #303
jandrewrogers wrote: post #89

Earlier quoted context omitted.

There isn't much of a conversation to be had here. For low-level systems code, exceptions introduce a bunch of issues and ugly edge cases. Error codes are cleaner, faster, and easier to reason about in this context. Pretty much all systems languages use error codes. In C++, which supports both, exceptions are commonly disabled at compile-time for systems code. This is pretty idiomatic, I've never worked on a C++ code…

What you wrote is historically correct, but new analisys shows exceptions are faster that error codes if you actually check the error codes. Of course checking error codes is tedious and so often you don't. Also is micro benchmarks error codes are faster and only when you do more complex benchmarks do exceptions show up as faster.

The performance benefits of exceptions are not borne out in practice in my experience relative to other error handling mechanisms. It doesn't replicate. But that is not the main reason to avoid them.

Exceptions have very brittle interaction with some types of low-level systems code because unwinding the stack can't be guaranteed to be safe. Trying to make this code robustly exception-safe requires a lot of extra code and has runtime overhead.

Using exceptions in these kinds of software contexts is strictly worse from a safety and maintainability standpoint.

Post reply on HN