My Delorean runs Perl | Hacker News Reader

My Delorean runs Perl

opensource.com

190 pointsrcarmo54 comments

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

With C++ you can even do it over template parameters.

Yep, in C++ you can pass in a lambda to create the comparator inline:

  std::sort(
    myvec.begin(), 
    myvec.end(), 
    [](obj& A, obj& b) {
      return A.attr < B.attr;
    }
  );

That is disgusting as a non-C++ programmer

eh, it's not Haskell (or even D for that matter) but C++ has come a long way in the last few years.

If you use std::begin and std::end instead of the member functions this will even work with old-school C-style arrays.

Yes, and you can even use the range syntax instead of begin/end.

Here's a file with a few different ways

https://gist.github.com/anonymous/78b4f257e60d55537b36e2e4f3...

.. and Herb Sutter recommends those free functions over the member functions for this reason -- genericity.

What I'm talking about is arbitrary attributes that might not exist on the base class, resulting in something like:

  std::sort(
    myvec.begin(), 
    myvec.end(), 
    [](obj& A, obj& b) {
      int A_attr1= dynamic_cast<Thing1*>(&A)? dynamic_cast<Thing1*>(&A)->attr1
                 : dynamic_cast<Thing2*>(&A)? dynamic_cast<Thing2*>(&A)->attr1
                 : -1;
      int B_attr1= dynamic_cast<Thing1*>(&B)? dynamic_cast<Thing1*>(&B)->attr1
                 : dynamic_cast<Thing2*>(&B)? dynamic_cast<Thing2*>(&B)->attr1
                 : -1;
      return A_attr1 < B_attr1;
    }
  );

and then compare that to

  @list= sort { ($a->{attr1} // -1) <=> ($b->{attr1} // -1) } @list;

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.

perl can be hard to read. but then again it can be easy e.g. https://gist.github.com/anonymous/a229b77c8ab25026633f1ab819...

I can write readable page of code. I want to write readable line of code.

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

Seems directly related to Larry Wall's (Perl founder) "Laziness, Impatience, Hubris " idea: http://wiki.c2.com/?LazinessImpatienceHubris

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.

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.

> 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 me, I start relying on the readouts for speed and rpm around the four hour mark. Tired brains don't work well."

Wow. I never rely on readouts. Always use the window :)

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.

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.

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

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.

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.

It is not a plane flying IFR. You don't really need an instrument panel to drive.

Losing the speedometer means you need to drive a bit more defensively. And you have higher risks of getting a ticket.

Losing the fuel gauge means you need to be more careful with your fuel management and refill more often. You can also use a dip stick.

Losing the light indicators is no big deal. They are mostly redundant information.

Losing temp and warning lights may be a problem but only if something else goes wrong.

Nothing really critical. It must be fixed but it won't prevent you from getting where you want to go.

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.

Interesting project. The real issue with the Dolorean however is the engine and drivetrain not the dash.

That can be fixed. Here's Stanford's all-electric, self-driving, self-drifting DeLorean.[1] With a computer display as the dashboard.

[1] https://www.youtube.com/watch?v=WNIDcT0Zdj4

That video is awesome, but self-driving is only true if you want to drive in tight little circles.

Who else was hoping to see some Perl scripts running in a shell on the dash of the Delorean..

That's a lot of lines for "it's my $##& project and I wanted to use perl."

More power to 'im! I use lua for such things myself. Because I like it.

That's the beauty (and even a big part of the reason) for solo projects. You get to do it your way.

Perl 5 or 6?

It's clear that he's using Perl 5. XS and CPAN are concepts exclusive to Perl 5.

I don't think that is entirely true.

> Uploading a module to CPAN is the preferred way of distributing Perl 6 modules. [0]

Though XS was replaced with NativeCall in Perl6, so he is still using Perl, not it's new brother.

[0] https://docs.perl6.org/language/modules#Upload_your_Module_t...

I haven't read the parent to this comment. But:

> XS [is] exclusive to Perl 5.

Perl 5 modules, including XS ones, are `use`able with P6 (`use Module::Using::XS:from<Perl5>; # P6 code...`).

> CPAN [is] exclusive to Perl 5.

CPAN has been an optional store for Perl 6 modules since 2016 iirc. In the last couple months it's become more or less the preferred store.

I wonder how long it takes to boot up the system before you can drive with this approach.

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.

Now what I would like to know is ... is this perl code on github?

> embedding C++ code into Perl

What could posibly go wrong.

No seriously, the project looks amazing.

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?

You ruined it!

Perl was first released in '87, so it kinda fits.

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)

Where's the flux capacitor?

People who like Perl are weird.

:-)

But productive.

https://en.wikipedia.org/wiki/History_of_programming_languag...

Objective-C? Or maybe Ada is more contemporaneous…

Reply on news.ycombinator.com