Hacker News Reader

Comment by morganvachon | Hacker News Reader

I was interested in dabbling with this project until I came across this regarding Python support:

Note: Python 2.7.3 or greater excluding Python 3.x, which is not supported.

I'm not a developer by trade or talent, but I'm learning and I'm starting with Python. Everything I've read and been told about Python development says to start with 3.x because the 2.x branch is officially deprecated and should only be targeted if one is intending to learn specifically for maintaining a legacy project that still uses it. I'm learning to learn, not to work, so I think I'll wait until AGL is brought up to a current version of the language before I dive in and get myself confused.

Beyond that though, I do like the premise of having the infotainment stack open source from the ground up. It would be nice if manufacturers would pay attention to this project and write open source drivers for their hardware.

View on HN

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).

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.

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/-/tre...

Looks awesome!

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.

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.

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.

You can't shut the line down. At best you have a week off for Christmas.

Reply on news.ycombinator.com