4 ms·
I am truly astounded by the hatred exhibited in some of the comments in this thread. Wow. A few points: If your software development experience is limited to
by robomartin 4y ago
I am truly astounded by the hatred exhibited in some of the comments in this thread. Wow.
A few points:
If your software development experience is limited to web or mobile development, please understand you lack a massive amount of context when it comes to software in the context of complex hardware manufacturing. To put it in simple terms, you really don't know what you are talking about. It's like someone who writes code for embedded systems in clothes washing machines having a strong opinion about how to engineer, deploy and maintain a tech stack for a SaaS.
Next, the cults formed around programming languages are some of the funniest things I read on HN. Except, they are not funny at all. There is nothing wrong with C or C++. Nothing. The problem is people who don't know how to program. At the core, to perform a certain function the microprocessor will, for the most part, do pretty much the same things, regardless of what language might be used to describe that. Blink a light in response to a button being pressed? At some point you are sensing and de-bouncing the input and then setting an output pin. Maybe there's I2C, SPI or CANbus in between, but what you have todo is the same.
Languages like C and C++ have been around for longer than most people reading this have been alive. They have been used --successfully and without issues-- for more projects, products and systems than anyone can imagine and at scales from a watch to spacecraft and everything in between. This cult of languages as solutions to problems caused by bad programming is nonsensical. One can write bad code in any language.
Professional certifications. This isn't going to stop people from writing bad code. At all. Designing and implementing complex code for real time systems is far more complex than designing a bridge or a building. Certifications are not magical inoculants against bugs and system design problems. Trying to view and fit software engineering from the context of other engineering disciplines is a mistake. They are not the same thing.
When you are dealing with fault-tolerant hardware + firmware systems things can get exponentially harder. Folks who work on web products have the luxury of being able to make lots of mistakes and fix them as fast as their deployment system allows. Imagine if you got ONE CHANCE to ship a non-trivial codebase and it has to be guaranteed to work to a high degree of certainty for ten or twenty years. Once you ship it, there will be millions of users and you cannot touch it at all. In fact, you have to telemetry data of any kind. You don't know if there are issues, if it has random failures, race conditions or odd failure modes you cannot possibly simulate at scale in the lab.
Imagine this next time you deploy an update. Imagine you are not allowed to touch it at all after that and it has to work. Imagine that, and maybe you can get a sense of what some of this work can be like.
This isn't limited to automotive. This goes for commercial, industrial, aerospace and other domains. Hardware is a million times more difficult that pure software products, particularly web type software. We just shipped a thousand units of one of our new products for installation in a large industrial facility. The firmware had to go through a year of testing before we dared ship even a single unit. That's another thing to imagine; the idea of having to test and qualify your web SaaS --not with clients as test subjects, on your own-- for a year or more before you can launch your business (and you are not allowed to touch it after that).
Anyhow. Don't be language cultists. That isn't the problem. Bad programmers and bad process is far more of an issue. Changing languages isn't going to magically fix that. It isn't a solution. You can build anything with C or C++. If written correctly, it will perform better than just-about anything and be reliable within the bounds of system specifications.
- kanbara 4y ago
- robomartin 4y ago> sounds like you are language culting c/c++ :) Not sure I know what that means. To clarify, the cultist behavior comes in when there are tools that are perfectly fine and people insist on using something else. > i want modern, secure languages with good paradigms and good package managers which have nice syntactic sugars and actual string types, memory checking and garbage collection. Sorry, you lost me at garbage collection. Nobody I know who does serious real time embedded wants to touch garbage collection with a ten foot pole. Everything you mentioned above is for the benefit of the developer. None of these things are necessary to build good software, at all. The proof is in history. Not to go too far, Linux: C.
- robomartin 4y agoBTW, that's not to say we don't use other languages here. I have personally worked with everything from multiple assembly languages through Forth, C, C++, Visual Basic, LISP, APL, JS, Objective-C, PHP, Python, MicroPython and who knows what else. We just haven't turned any of the above into a religious belief. In that context, with that level of experience, from consumer to aerospace, time and time again I find myself making the same observation about C and C++ being more than adequate for just-about everything. We are reinventing the wheel to allow for less capable, less knowledgeable software developers (or both).
- Gwypaas 4y agoRust is coming to Linux. https://lwn.net/SubscriberLink/908347/da67a5162d1bc4a3/ https://lwn.net/SubscriberLink/908347/da67a5162d1bc4a3/
- javcasas 4y ago> If written correctly Therefore, there are ways to write bad code. Do you think it's reasonable there may be better tools that prevent writing some cases of bad code? I mean, I think we all can agree that, in general, a codebase with significant test coverage hass less bugs than a similar codebase without test coverage. So, I don't think it's crazy to require, potentially via a tool, some degree of test coverage. Yes, some people will cheat by constructing some bad tests, but, in general, I think we should expect some level of quality improvement. Rust adds another tool that, on average, should improve quality. Again, this is not a solution. This is not a silver bullet. Neither is depending on the programmer to write correct code.