Hacker Newsnew | past | comments | ask | show | jobs | submit | romonopoly's commentslogin

"When you really boil it down to its implementation, FizzBuzz is something of an irritating program. I’m not sure how much the author of the problem really thought about FizzBuzz, but it turns out it’s difficult to express well with the tools available to most imperative programming languages..."

Nonsense.. you call a simple loop with a couple conditions difficult?


Haven't thought about safety to be honest. Reason being cars already come with proprietary operating systems in the center console, so this wouldn't be any different safety-wise.


Sure, but most proprietary systems have only basic interactivity, which you might consider to be a feature rather than a flaw. Some even disable interaction while driving. An average driver already can't control much more than the steering wheel and pedals at once.

That said, I'd be totally down with some passive applications for a console. Maybe a navigation plugin that helps find the cheapest gas without wasting extra miles to get there, or a roadtrip meal planner that helps direct you to restaurants you like at proper eating hours.

Hopefully no Facebook though, and definitely no GTA.


Right, so maybe a moderated app market would be a good solution, with apps being placed in two categories, one category that works whether driving or parked, and the other would only work when the car is parked.


How about not trying to solve this problem by artificially crippling the software up-front and instead just leave it up to national governments to regulate this sort of thing? We don't have special software in mobile phones to make them turn off when they're in a car, we've just made it illegal to fiddle with them while driving.

The same should work just fine for certain dashboard interaction.


Yeah I've seen one, pretty nifty (but messy with all the wiring). The idea would be that the manufacturers don't lock it down to allow outside developers to bring value to the platform and utilize additional APIs. I made a mockup of how it would look like: http://s13.postimage.org/8bt3a7kdj/Car_Droid.jpg


It would be built into the car, instead of the navigation/entertainment system and feed off the alternator, so no battery drain :)


Here is the idea, please vote if you like it: Most cars already have a big LCD in the center console for navigation or entertainment, but each manufacturer writes their own software for it. My idea is to have it run Android, which would allow anyone to make apps specifically for cars, entertainment or information-based, taking advantage of special API like vehicle speed, fuel, error codes, etc (from OBD2 or ECU). This would bring huge value for car manufacturers(offsetting the development cost) and customers would love the limitless customization possibilities. Here is how it would look like: http://s13.postimage.org/8bt3a7kdj/Car_Droid.jpg


For what it's worth, a lot of manufacturers use .NET actually. Microsoft started pushing for integration into those systems back in the WINCE days, and has made significant headway. The "SYNC" based players are just the latest iteration.

Figure the car development cycle is about 3 years, and realize Andriod was just starting to exist in the minds of car designers when this year's models were being designed. It'll be a while, but I wish you the best.

Bet you dollars to jelly beans that the Google driverless cars have Android though =)


This is definitely already happening - I tangentially work on a number of projects embedding Android into transport, and it's really just a matter of time before manufacturers adopt Android as a matter of course.

For example, the top two manufacturers of in-flight entertainment systems are already transitioning to Android (Thales and Panasonic). There are a number of benefits using Android like this, least of all you can take advantage of the hardware expertise that already exists for building Android backed devices, and leverage the larger amount of software talent available.

Of course, there are problems. All these embedded systems have very long shelf lives, much longer than a typical handset. A IFE unit in a plane might be expected to last 15 years at least, a car is hopefully going to spend a decade or more on the road. The hardware is not going to be upgraded - don't expect updates to later Android versions.

This presents problems for third-party development, assuming manufacturers offer it. Ideally, you'd hope for a manufacturer supplied SDK that offered you easily consumable information and telemetrics (vehicle speed, fuel level, etc) and an open app store. Car companies may not see an advantage to offering it at this time.

So really, the challenge isn't to convince car manufacturers to use Android: most are almost certainly already considering it for their high-end models. Instead, it's to get a tech eco-system that's open.


> For example, the top two manufacturers of in-flight entertainment systems are already transitioning to Android (Thales and Panasonic).

Hmmm, on a flight a couple of years ago my IFE screen (Panasonic I believe) crashed, and I was treated to linux kernel boot messages and then a bunch of SDL (the hoary old linux graphics/game library) error messages as it messily failed to restart properly...

It definitely had a bandaid-and-chewing-gum feel, so using something like Android would probably be a good thing.


I know from a friend that a big German manufacturer uses .NET in their cars.


Any more details?


It got rejected by Nissan, not sure why...


That's strange since it's in the top 10 with votes.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: