Please. Yes the pricing sucks, but that means more capacity to build more computers will develop. It will equalize at some point.
Crashing the data center boom in a vain attempt to get a cheaper pc is a) short-sighted and selfish and b) counterproductive, bans on data centers would almost guarantee permanent high prices, or lower performing parts.
Pretty much this. The less software on the car, the fewer problems.
It's practically impossible to test every permutation of code against every system. Maybe AI can help, but practically it'll just mean the software gets more complicated, with more features. And to top it all off, more and more features get regulated, so they have to be there. The rear-view camera requirement in particular, since you need a screen to see the output. And if you have a screen... well it's an already paid cost, so, might as well display other things too.
It all comes down to cost. At scale, testing hardware is appreciably more expensive than testing software. The former requires specialized machinery that costs the soul of your firstborn, and the logistics overhead for each do-over means long iteration times. The latter can be done with a CI pipeline for pennies worth of compute in a fraction of a working day.
At scale, testing software is appreciably more expensive than using hardware. That's why at most people test a tiny slice of it, and ships out broken software in the hopes of fixing it later. Testing hardware is expensive because nobody thinks it can be fixed cheaply afterwards.
Stuff like climate control and radio/Bluetooth were included in many/most cars in the last decade. Expensive as they were, the cars were a lot cheaper than today's cars. And they just worked, which means they were either so simple that sophisticated testing wasn't necessary, or they tested it thoroughly.
I don't think they're saving that much by ditching them and going to SW.
They also didn't need updates (well, the Bluetooth module may have, but nothing else).
It definitely was nice not to have to worry whether the climate control may stop working because the radio was modified. Or because of any update.
As a driver, dumping everything into one SW system has significantly degraded my experience. What I gain ("Ooh, I can now use Waze on a bigger screen!") is minimal.
> The latter can be done with a CI pipeline for pennies worth of compute in a fraction of a working day.
I'd appreciate the point if they were successful at it. As it is, they're not. It's rare to find a non-buggy car.
bluetooth audio is probably all one needs for phone <-> car integration. but carplay/android auto are sadly really popular.
So already, your phone can connect in two different ways, just over bluetooth, with cars today. And car companies have to support both.
Plus the car must show something on the screen when a phone isn't there, and the rear-view camera isn't on, at the very least on test drives/ showroom displays.
I don't know. On balance, the reality is cars are better overall nowadays, but every aspect of our life has gotten more complicated, including cars.
If you had the option of no screen at all, no rear-view camera, and with physical switches, would you? If this Slate truck gets released, that's the closest, but it's still required to have a rear-view camera/screen sadly.
I'd be OK with the screen doing other things, as long as it's not inferior to my just using the phone. Currently, AA is inferior.
You don't need a huge screen for the rear view camera. There's plenty of space to have that screen and have all the usual buttons for climate control and radio/audio. Cars had been doing that for over a decade.
It's one of the reasons the US military is so good. As a soldier, you know they will come for you, behind enemy lines, so you can fight like hell, knowing that your fellows have your back.
I actually wonder about his conclusion that 50 years hence English will be unrecognizable.
There will be changes of course. Yet we are also more connected than ever, whereas the next town over would be a whole day trip in the past. The separation allows for more divergence.
Well, maybe if we get to Mars, differences might crop up again.
This isn't how I read his conclusion. He's saying English will be different in fifty years, but he's not saying it'll be unrecognizable. Look how little difference there is between the 1900 passage and the 2000 passage.
In fairness , Dickens is quite dry. My mind would wonder off.
In some sense, it's better these days, competition has led to care for the reader that probably didn't exist as much then, since so few people can read.
Yeah, there's something of a tension between the Perlis quote "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures" and Parse, don't validate.
The way I've thought about it, though, is that it's possible to design a program well either by encoding your important invariants in your types or in your functions (especially simple functions). In dynamically typed languages like Clojure, my experience is that there's a set of design practices that have a lot of the same effects as "Parse, Don't Validate" without statically enforced types. And, ultimately, it's a question of mindset which style you prefer.
I don't really get why this is getting flagged, I've found this to be true but more of a trade off than a pure benefit. It also is sort of besides the point: you always need to parse inputs from external, usually untrusted, sources.
Agree with this. Mismatching types are generally an indicator of an underlying issue with the code, not the language itself. These are areas AI can be helpful flagging potential problems.
Start with a more dynamic type, do stuff that doesn't care about the shape, parse into a more precise type, do stuff that relies on the additional invariants, drop back into the more dynamic type again.
I find a balance is important. You can do nominal typing in a structural type system with branding, and you can kinda do structural typing in a nominal type system, but it's not as ergonomic. But you should probably end up doing a mix of both.
