Widdershin

Not a given by any means, but it’s happened before and it will happen again.

All it would really take is a company of decent scale deciding they want to base their engine around Godot and having an appetite to upstream some meaningful work.

I apologize for being a bit snide in my original challenge, I'm fairly sensitive to the "why don't you just" attitude, but I agree with pretty much everything you have to say here.

I have a very similar approach around enumerating and testing assumptions when the going gets tough, and similarly have found that has enabled me to solve a handful of problems previously claimed impossible.

I think the tautological issue with our initial framing is that if you're able to easily identify these problems you probably are a subject matter expert. In many ways it's the outsider art of analytical problem solving - established wisdom should not be sacred.

First was some downhill skateboarding projects - a bushing recommendation system and a site that allowed me to search all NZ skate shops from one place.

A popular US skate shop posted on Reddit looking for interns, but they weren’t interested in hiring so remotely.

Fast forward a week and the CTO got in touch to say that he’d interviewed a bunch of dud candidates, and meanwhile had been watching me commit exactly the code they were looking for.

Ended up contracting with them for a bit building an internal equivalent of the search tool, as well as bushing recommendations integrated with their listings.

The next is my work in the Cycle.js community (niche FRP JS framework). Mostly worked on trendy dev tools, but also did some valuable work on improving the speed, reliability and clarity of async UI tests that is still arguably close to best-in-class for JS.

That resulted in multiple job offers and an approach from Manning for a possible book deal, but none of it was that good of a fit.

Probably a similar situation.

I avoided taking the lane while I started, but after being forced into the gutter and nearly side-swiped multiple times, I started regularly taking the lane for my own safety.

That’s what really disappointed me about motorists as a cyclist - you give them an inch and they try to kill you.

They’ve definitely made some significant missteps over the last few years, mostly around breaking storage APIs and being slow to fix it due to being part of the macOS release cadence.

It definitely happens in the wild as well, I’ve seen devs using copilot for napkin math far more than I’m comfortable with.

I left a review warning others this was a possibility, but Amazon removed it since it was critique of a seller rather than the product.

It’s impossible to tell if you’ll get a genuine product if Amazon censors reviews critiquing sellers sending the wrong product or no product at all.

Not that there aren’t ways to represent mutability in Haskell, just that the de facto use of immutability causes excess allocation.

If you track ownership in functional languages, you can statically determine if a value is used more than once.

If it’s only used once, you can apply any updates to that value in place without allocating more memory.

This gives the performance benefits of mutability with the safety benefits of immutability, in some common cases.

The main trick is adjusting memory layouts accordingly. You can keep it simple by only applying this optimisation for functions of A -> A, or if you’re replacing it with a different type you can analyze the transformations applied to a value and pre-emptively expand the memory layout.

If a value is likely to be used only once, but might be used multiple times, you can also apply the same approach at runtime by reference counting and updating inplace when there’s only a single reference (for functions of A -> A at least).

I believe the Roc folks are aiming to have aspects of this functionality, and I also believe there’s similar stuff becoming available in Haskell under the guise of linear types.

Finally, if you really need a shared mutable value, that can be achieved with mechanisms like the State type in Haskell.

In short, the pieces are there to create a functional programming language that doesn’t introduce needless memory usage overhead, but I don’t think anyone has put all the pieces together in a convenient and accessible way yet.

Here’s one analysis that takes those factors into account, and eReaders still come out massively on top on average.

Paper isn’t the problem, it’s the fact that’s books are heavy and bulky, so the transportation and storage have massive carbon implications.

On top of that, most books end up in landfill as a result of not selling in stores. If you care about the environment and read books an eReader is a worthy investment.