> "Because I don't have a lot of time to plan out the full requirements of my objects, it has been a great boost to productivity to just toss in an additional few attributes on unsuspecting objects, or quickly sort through a list of objects based on criteria that would require awkward reflection code in Java or C++."
In Java, sorting objects based on arbitrary criteria doesn't require reflection. Just pass in a Comparator to one of the JDK-supplied sort methods. It's not awkward. I'm not a C++ programmer but I suspect it's similar.
You need reflection if the type of object you're comparing doesn't have that attribute, and only half the subclasses do. You then have to inspect the actual class to see if the attribute exists before you can access it, and the code to do that is so ugly it would take less time to go edit the base class and constructors to give them all the attribute. This is the hassle that perl is avoiding, in the same way that JavaScript would avoid it. Every object is just a collection of attributes and you can access them by name. It's not as efficient as structs or interfaces, but it's very convenient for prototyping.
I still fall back to perl for experimental/recreational programming. Possibly because it is the first scripting language I really felt fluent in, but I think just because it is so quick and flexible to write.
These days, anything I inflict on others in this category tends to be redone in Python, but for hacking? Perl just hits a sweet spot like no other language for me.
Perl is joy to write (especially with Modern::Perl qw(2016) and feature qw(signatures)) but is hard to read. I can write lot of code in single line with map/reduce/split/join/regexps, but without chaining of operators it is mess, because order of operators is opposite to order of execution. It because of traditional function or operator invocation syntax: "x(a1, y(a2, z(a3, a4), a5), a6)", instead of modern chain of calls: "z(a3,a4).y(a2, a5).x(a1, a6)" . The more operators I pack into single line of code with traditional syntax, the harder it to read.
Perl6 has "feed operator", but it is not ported to perl5 to date. Perl6 syntax is clean:
my @array = <7 8 9 0 1 2 4 3 5 6 7 8 9>;
@array ==> unique()
==> sort()
==> reverse()
==> my @final-array;
say @final-array;
but perl6 is slow, so it is not gaining any popularity.
Not sure when you last tried to run your Perl 6 program, but things have improved over the years. Today Rakudo Perl 6 celebrated having one of the most tested canary programs break the 100x faster barrier: https://twitter.com/zoffix/status/957322578460315649
I'm a fan of car modding myself, but I don't think replacing the entire instrument cluster with a single centralised system --- where one fault can leave you with no instruments instead of just one inop --- is such a good idea. Adding a secondary display for less critical indicators would be useful, however.
Interestingly enough, the Qt framework (very common in cars) uses a rather clever trick to avoid that. The QtWayland module allows to create your cluster on the compositor level instead of application level. That way, each widget can be its own process and crash at will. QtRemoteObjects even sync C++ object across either the network or QNX IPC so the logic can also be in its own process and crash at will.
In a way, it's like microservices, but completely implicit to the developers, without explicit serialization and all the way to the "individual pixels" on the screens.
Why is a failure of the cluster readout display, during driving, a big deal?
If it fails, it would be fixed soon. The driver still has the window. I'm struggling to see how an immediate failure of speed readout etc would immediately endanger the car? Assuming it performs no control function.
If you lose the odometer and the gasoline tank level meter you no longer have a way to plan refueling on longer trips. Run out of gas in a bad place and you can end up freezing to death (happens every year to people during blizzards) or dying from heat stroke (happens every year to people around Death Valley/Mojave, usually from getting their vehicle stuck). "Door is open" warning indicator is also part of the dash. Driving with a door that flies open unexpectedly could easily lead to a crash. Seatbelt warning lights not operating is a safety issue. Losing the battery warning indicator can leave you stranded, losing the ABS warning indicator can lead to a crash, losing the engine warning indicator can lead to very expensive repairs.
In response to your first sentence, if it were me, surely I would not plan a big trip if I just lost my instrument console. If it were my car and I was in the middle of the big trip, I would hopefully have packed my laptop so I can try to fix the problem.
Door ajar? Seatbelt loose? Now we're just getting into paranoia scenarios. What if a nuclear bomb landed and there won't be enough gas to drive me away from the blast zone!
Do you do a lot of road trips? The only scenario from the above list I have not personally been involved in, as a driver or passenger, is ABS problems leading to an unexpected change in handling, mostly because I have older vehicles. Yes, I have been in a car where a door opened while underway.
The one vehicle I have right now with ABS has intermittent ABS issues but a soft failure mode. Newer cars rely a lot more on ABS (especially in off-road modes), same goes double for motorcycles. Losing ABS/TC on a motorcycle drastically changes the envelope of safe brake application. If your muscle memory for safe brake application is (mis)trained to rely on ABS/TC at the limits of available traction, losing ABS/TC will very easily lead to a front wheel lockup or unexpectedly losing the front/rear in a lean.
> Why is a failure of the cluster readout display, during driving, a big deal?
It's true that you probably won't die immediately. But for most people, driving a long distance without a cluster display would be extremely dangerous. Especially at night on an empty road. For me, I start relying on the readouts for speed and rpm around the four hour mark. Tired brains don't work well.
Which means you probably have to get it fixed ASAP. If that happened more than a couple of times with a car, I'd sell the car / not buy it in the fist place.
You aren't wrong, but if you really are concerned about those sorts of things, you should probably drive a late-model Toyota, not a Delorian.
They stopped making this car in 1983; it is far beyond it's design lifetime already, and was never a particularly reliable car to begin with, from my understanding. Like most classic cars, you probably shouldn't drive it unless you enjoy maintaining it, and are okay with (and carry substantial liability insurance for) a car that is dramatically less reliable and less safe than a modern car. Like most classic cars, you probably shouldn't drive it places where you are likely to die or otherwise suffer dramatically bad consequences if it breaks down. This isn't a criticism of the Delorian specifically as much as it is a truth about early '80s automotive engineering and running vehicles beyond their service life.
Of course, as a society, we've decided that this (tradeof off cool car vs danger) is a reasonable choice to make; we don't force people to buy newer cars because they are safer. Within this context, the addition of a special instrument panel seems to me like it's not adding substantial additional danger to the system.
The DeLorean is actually more reliable now than it was back then because we have 37 years of test data available on what goes bad and how to prevent it. There's also a number of improved components available made from newer materials.
Also it did really well in the crash tests of the 80's and current owners baby them, so the insurance is pretty cheap.
For the DeLorean, there's pretty much just 4 that matter: oil pressure, voltage, temperature, and brake fluid light. I wouldn't drive any long distance without being able to see these.
If it is just you driving the car that is fine, it is not as if he has modded an Airbus A380 and put his own telemetry in the dash for some other pilot to be using it.
Plus he can probably ssh into the dash from his phone and get the 'oil level' that way, at 88 mph, driving through the fog.
I think that since this isn't German engineering to go in millions of cars a CSS/JS/HTML solution in an actual browser launched full screen would have been the way to go.
Heh, I used to drive around in a '67 Galaxy whose light switch would overheat and the headlights would turn off. Almost always on hilly winding rural roads.
Dash cluster going dark is pretty safe in comparison methinks.
Won't even mention the surplus postal jeep's antics...
It is a great idea to program a dashboard to one’s taste. Most dashboards these days are terrible and illustrative of somebody else’s UI dreams. Imagine something more useful than what Audi or Tesla provides and not the crap Apple/Google gives us on our phones
Tesla owners have been writing javascript websites to run in the web browser on the 17" touchscreen ever since the Model S was released. You can't do much of a car dashboard, alas, but you can do weather forecasts, TODO lists, geofenced content like work server status while I'm driving to work, and so on.
It is easy to tune Debian Wheezy such that it boots into your X application from rotating HDD in less than 15 seconds from powerup on typical Atom ITX board. For newer distributions with systemd you don't even need any special tuning for the boot time to be dominated by BIOS POST.
Let me get this straight. You have a DeLorean DMC-12, a touchstone of '80s aesthetics and American pop culture icon, and you tear out the instrument panel and replace it with contemporary over-engineered Linux-powered glitz?
The DeLorean was famous exactly because it wasn't 80's aesthetics; it STILL looks like the car of the future. But the instrument cluster? it's made of cheesy analog gauges that bounce with the fluctuations of the system voltage. It desperately needed an upgrade. (but I have all the original pieces and no parts were cut in the process of the mod ;-)
But that's part of the experience, is it not? Analogue gauges!
Also, assuming you're the one that did this modification; How long does it take for your instrument panel to boot? Fast enough to see the tach needle (or replacement thereof) jump up as the engine starts and then bounce back down to normal? Being in a car where I wouldn't be able to see that happen would be… surreal.
My kernel takes 2 seconds, and the userspace takes about 4, mostly waiting for Xorg to initialize the display (which I could probably improve using a hardcoded xorg config, rather than autodetect). The real killer is BIOS though- my FitPC 3 takes about 7 seconds to POST. However, I power it on when the door opens, rather than when the key turns, and one of these days I'll get it connected to my remote unlock button. The microcontroller is always on and consumes almost no power. I would buy a new PC if I knew for sure that the post time was less, but nobody ever advertises that statistic, and anything based on BIOS/UEFI tends to be abysmally slow.
Meanwhile the display rendering should be within ~50ms of the measurements from the microcontroller, so the tach and other measurements feel really "tight". (the tach is that curved column of horizontal bars on the left)
In Java, sorting objects based on arbitrary criteria doesn't require reflection. Just pass in a Comparator to one of the JDK-supplied sort methods. It's not awkward. I'm not a C++ programmer but I suspect it's similar.