Well, unfortunately many software engineers don't behave like real engineers, so is it any surprise?

I mean to say, most people here will be highly familiar with version control, but back in the days when I used to audit companies, version control was barely[1] used, and editing files on the live server was the norm. And even here we're still having discussions about how "hard" it is to manage dependencies, use strong typing, use safe languages, garbage collection, bounds checking, formal proofs, etc.

[1] I think I may be correct in saying never used. I can't recall a case where we saw a company using any kind of VCS, but perhaps I just forgot.

Your criticism is valid from our perspective, but the non-software engineers on the other side of the culture divide are even less aware of proper software practice, so I don't see how the failure of software people to follow those practices could be the source of the prejudice.

I think it's a different problem. Software engineering is fundamentally about the management of complexity. People who have only worked on small programs -- like most non-software engineers and scientists -- don't understand the need to manage complexity because they've never worked on any program large enough to require it. Programming in the small is easy, particularly when you're mostly doing numerics. Other engineers see that and think that all programming must be easy.

Whenever I describe software engineering I typically use some form of "a true software engineer doesn't just make something work, he avoids &#%$ing over the next person to pick up his or her code."

Funny that you include garbage collection as part of what we should be doing, in an article about software in cars. Garbage collection is almost never the right answer for software in embedded systems.

Unless the poster was including ARC-style systems in what they meant by "garbage collection".

Ideally you want something that is both deterministic (i.e., it's not running randomly in the background like a traditional GC) and that guarantees there are no leaks. In theory ARC gives you both of these.

ARC depends on malloc/free which isn't quite as deterministic as you make it out to be - precisely because malloc/free does not (typically) run in the background, it needs to update internal datastructures when it gets the chance, which can lead to considerable latency spikes.

In fact, I'd go so far as to say latency isn't the issue - the issue is that typically GC'd languages rely heavily on heap allocation because it's cheaper(!) not more expensive. Put another way: java creates lots of garbage, C/C++ does not.

If you wrote a C/C++ program that allocated as heavily as a typical java program... well, I'd expect performance issues that would probably be worse than java's.

True, any malloc (or new) and any free (or delete) is non-deterministic (unless you're using a placement allocator). But GC isn't better, because the new still has the same non-determinism, Also, the GC has to do more work than a programmer-controlled delete (walking data structures for liveness, or something approximately equally expensive), and tends to do both the walking and the deletes in bursts. But...

> java creates lots of garbage, C/C++ does not.

Properly written C/C++ does not. Badly written C/C++ creates garbage (leaks memory), and it can never be recovered, because there's no GC. The solution isn't GC, though - it's to pay more attention to who owns the memory.

The culture war is alive and well, many companies (mine included, unfortunately) treat software engineers as barely qualified typists of the "algorithms" designed by "real engineers". They'd get rid all of them in a second if they could, every so often a new manager tries.

The culture war has been going on forever.

When I was growing up in the 80's, my father was a software engineer at Honeywell and said they discriminated against the software guys, even when they knew software was the future of computing. He said it had been going on since the 60's and 70's as related to him by previous employees. He was told if he was a software engineer to just keep his head down and not talk to the "real engineers" working on "real problems".

Likewise when I was in college for computer science, he reminded me of the same struggles he had when I used to get fed shit from the other engineering students about how "If all else failed, they could become a CS major." and just be nice because one day they'll be coming to me for help.

And here we are today. Same thing, same arguments, same outdated viewpoints.