HN user

Widdershin

408 karma

https://github.com/Widdershin

Email me at ncwjohnstone@gmail.com

Posts6
Comments186
View on HN

This is the sort of thing people said about Blender for a long time, and my understanding is that it’s now often used in commercial contexts.

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

I missed this comment first time around, but I really appreciate this write-up.

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.

This has happened a few times to me.

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.

In the board I served on in the past we had an agreed quorum where we could make binding decisions if ~2/3rds of the members were present.

Probably a similar situation.

I started cycling again a few years ago.

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.

LLMs being used for math by programmers or engineers always makes me think of the rocket that blew up because they mixed metric and imperial units.

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

WebTorrent 4 years ago

STUN servers are only required for NAT punching, they don’t relay traffic. Only TURN servers are used as relays in the event that a direction connection can’t be established.

I recently ordered a magnetic usb-c adaptor and the box turned up empty.

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 the poster you’re responding to but I think they’re referring to the current need to allocate more memory when updating immutable data structures.

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

This is actually an area where there’s room to improve FP languages.

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.

https://gato-docs.its.txst.edu/jcr:4646e321-9a29-41e5-880d-4...

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.

I hope you’re not reading any paper books - the environmental impact of paperbacks is phenomenal when compared to eReaders.

And of course, you would never waste energy by purchasing a hardcover, that would be morally reprehensible.

Honestly wouldn’t surprise me if a kid playing minecraft on an old computer had drastically less impact on the environment than your average book snob - especially the “I buy paper for the experience” kind.