4 ms·

The Python 2 dependency would be on par for industrial/automotive stacks, unfortunately. This area of the industry is not really up to date regarding modern sof

by q3k 6y ago

The Python 2 dependency would be on par for industrial/automotive stacks, unfortunately. This area of the industry is not really up to date regarding modern software development practices (sometimes for good reasons, but more often not).

throWaythxMod 6y ago
I am surprised to see this posted here. Among the general population, people think adding features is easy, but I'd expect people on HN would understand tech debt. Maybe they don't understand automotive is old. There is more tech debt than you can imagine.
- q3k 6y ago
  I understand tech debt. But you can't just handwave all tech debt as 'it just happens, get used to it'. It's debt. You're supposed to pay it back at some point, and automotive/industrial/embedded is really, really bad at it, forever stuck in a 'it works, ship it' mentality. If you're never paying back your tech debt, it's not tech debt. It's just poor software engineering practices.
  - throWaythxMod 6y ago
    You can't shut the line down. At best you have a week off for Christmas.
ravingraven 6y ago
I work with embedded systems and I can tell you for a fact that there are exactly two reasons for not including Python or newer versions of it: 1) Hardware constraints. 2) Software must be real-time. Non-embedded developers are usually unable to understand the constrains of embedded and chalk it up to "you are dinosaurs". Not true.
- q3k 6y ago
  Sure, and I wouldn't run Python on embedded devices either [1] - and that's not what I was suggesting in the first place. The lack of Py3 support is not about Python vs $language on $environment, it's about using EOL software in general. [1] - my last public embedded software contribution was in fact an ELF loader for a smartwatch so that I wouldn't have to use micropython: https://git.card10.badge.events.ccc.de/card10/firmware/-/tree/master/epicardium/l0der https://git.card10.badge.events.ccc.de/card10/firmware/-/tre...
  - ravingraven 6y ago
    Looks awesome!
morganvachon 6y ago
I get that, and I wouldn't want a higher level (interpreted) language like Python anywhere near safety-critical systems that require a real time OS and software. Given this project targets infotainment only, well let's just say I've seen terrible systems from the major automotive manufacturers (Ford, Chrysler, etc) in that space, not to mention the hilariously bad aftermarket infotainment products flooding the market right now, and I'd like to see an open source project come out swinging and not be encumbered by last decade's language choice. But again, I'm not a developer and I'm just getting my feet wet so my opinion is likely wrong.

by q3k 6y ago

throWaythxMod 6y ago

I am surprised to see this posted here. Among the general population, people think adding features is easy, but I'd expect people on HN would understand tech debt. Maybe they don't understand automotive is old. There is more tech debt than you can imagine.

q3k 6y ago
I understand tech debt. But you can't just handwave all tech debt as 'it just happens, get used to it'. It's debt. You're supposed to pay it back at some point, and automotive/industrial/embedded is really, really bad at it, forever stuck in a 'it works, ship it' mentality. If you're never paying back your tech debt, it's not tech debt. It's just poor software engineering practices.
- throWaythxMod 6y ago
  You can't shut the line down. At best you have a week off for Christmas.

ravingraven 6y ago

I work with embedded systems and I can tell you for a fact that there are exactly two reasons for not including Python or newer versions of it: 1) Hardware constraints. 2) Software must be real-time. Non-embedded developers are usually unable to understand the constrains of embedded and chalk it up to "you are dinosaurs". Not true.

q3k 6y ago
Sure, and I wouldn't run Python on embedded devices either [1] - and that's not what I was suggesting in the first place. The lack of Py3 support is not about Python vs $language on $environment, it's about using EOL software in general. [1] - my last public embedded software contribution was in fact an ELF loader for a smartwatch so that I wouldn't have to use micropython: https://git.card10.badge.events.ccc.de/card10/firmware/-/tree/master/epicardium/l0der https://git.card10.badge.events.ccc.de/card10/firmware/-/tre...
- ravingraven 6y ago
  Looks awesome!

morganvachon 6y ago

I get that, and I wouldn't want a higher level (interpreted) language like Python anywhere near safety-critical systems that require a real time OS and software. Given this project targets infotainment only, well let's just say I've seen terrible systems from the major automotive manufacturers (Ford, Chrysler, etc) in that space, not to mention the hilariously bad aftermarket infotainment products flooding the market right now, and I'd like to see an open source project come out swinging and not be encumbered by last decade's language choice. But again, I'm not a developer and I'm just getting my feet wet so my opinion is likely wrong.