Comment by 🚀 stack

Yes!

We used to write software that worked _before_ shipping it. We would test it, and maybe a few bugs would turn up and we would have to issue a new version a year or two later.

Now, we often release software before it's even written -- there are tons of repos with wishlists on github, with promises to start soon. And daily updates to my system inevitably break things, especially those written in Python.

The constant updatability is the worst thing that happened to software.

May 19 · 7 months ago

8 Later Comments ↓

@stack I avoid anything with python for this very reason.

javascript too.

Yeah, Jonathan Blow knows what he's talking about, only as long as he sticks to programming. An expert in one field does not make an expert in other fields.

Anyways, what I will add to this is that while it is true the people who "glue" code don't care as much about this "mathematics lives forever" perspective, what they *DO* care about oftentimes is the Art they are making. Mathematics and glue code are not ends in themselves, they are a means to an end.

And thus, many people use glue code and libraries because they don't know any better, or because they don't want to become high-level mathematics students to get certain things done. Specialization is a good thing. Not everybody can be experts in everything.

While he left this ambiguous, there is a separation between glue code and libraries. Some libraries can last for a long time if you hold the source code to it, because that let's you recompile the library. Something that's completely antithetical to closed-source software, ironically.

Which gets back to the specialization - libraries allow people to specialize in one thing, and allow everyone else to specialize in other things.

The problem with software is not libraries, but not caring about compatibility and stacking too many libraries/components on top of each other.

Jonathan Blow does often correctly identify some problems in the industry, but he doesn't try to fix them, and doesn't try to teach people a better way. But maybe that's a good thing, because he's also an asshole, and teaching requires caring about your students enough to want them to do better. Which he doesn't.

And when he does try to fix things, it is always when he can benefit from it most. I mean, he's a closed source girlie, what can people expect.

Is Joe Blow his real name?

@stack Yes, afaik; well... I don't think he's ever gone by "Joe", just Jonathan. I used to watch him *a ton* back in like 2017-2020, along with Casey Muratori.

He's been working on a new game, based on Sokoban, for some years now, in his own programming language too (called Jai). Anyways, I don't watch him anymore, for reasons outside of the programming stuff.

We were told to use libraries for code re-use, but sometimes this causes more harm than good.

I have heard horror stories about corporations having their infrastructure collapsing because they relied on an open source library for a trivial task that could be achieved with a handful lines of code, and then that library became unexpectedly inaccessible.

IMHO the choice of programming language helps, too. I like to stick with C because, despite its historical baggage, it has had stable interfaces for a very long time. Also, programs written in C tend to have fewer moving parts and reduced scope, compared to JS or Python behemoths, so less surface for errors.

@xavi Eh. Imo, you can't really overgeneralize all libraries as if they were leftpad, lol. Mathematics libraries are pretty solid. A library to prepend a bunch of spaces to a string is just stupid. But leftpad's problem was not that it was open source, it was that it used npm crap.

Open Source has almost nothing to do with code distribution because you can distribute your open source code anywhere, and people can keep local copies of open source code anywhere they want. So the fact that leftpad was "an open source library" is kinda irrelevant.

The code distribution was the problem, and so was the fact that people felt the need to use leftpad in the first place (especially when it should have been in the JavaScript API early on).

I don't really get how anybody goes from "Python and JS are crap" directly to "C is the only language worth using ever". Like, there's a whole spectrum of programming languages now that aren't Python and JS (and aren't Rust either!). And just because a decent middle language might not exist right now (it does though!) doesn't mean it can't exist in the future.

This is basically my problem with the JS fanatics and the C fanatics. JS people see C and think "I'm never touching anything with manually memory management or typing again" and C people see JS and think "I'm never touching anything outside of C and very low-level languages again."

It seems like everybody in programming is trying to gravitate to one extreme or the other, and I find it to be nonsensical, and kinda religious-political too. It's part of why I'm just so over it. I do my own little thing and pay no mind to other programmers, because I'm just done with the stupid politics and religious fanaticism.

And it's actually mostly the opposite of how Jonathan Blow programs in reality. He's made JAI that's definitely "higher level" than C and lower level than JS and Python, with an excellent standard library and fancy meta programming stuff.

There's a whole middle point between the extremes. But people are too busy picking examples to justify extremes that they can't see this.

Anyways, seriously, the problem with leftpad was more that someone was able to delete it and break a bunch of people's software, because of npm's terrible code distribution system.

That's why Jonathan Blow argues for comitting your libraries directly to your source control in the very article above!

Leftpad is only used as an example of overuse of libraries in that there's no reason to rely on the library in the first place, but the debacle is a completely separate thing; one could rely on leftpad by comitting it directly to your repo and not had your entire website collapse because of npm's crap.

And this is my biggest criticism of Casey and Jon, they come up with the stupidest reasons to go after open source *in general* rather than going after the open source ecosystem. They use the ecosystem to justify closed-source, and I find that entire argument to be a complete jump in logic that makes absolutely no sense.

Seen this one too, hard agree. As far as open source stuff goes, I don't agree either, but I think I could steelman the arguments against it, to some extent at least.

Neither of these apply to open-source __in principle__ but they do apply to how a lot of it happens in reality. Which ofc you could say makes them not legitimate, but there's a definite connection there.

In no particular order,

1. The need for mainaining code due to external reasons

A statically linked executable (at least in theory) only relies on the kernel functionality, which is relatively stable, so no maintainance needs to be performed for it to work. But when you distribute source code, you take up responsibility to keep it compilable, which can fail without any involvment from you, since the build process involves so many steps (see Casey's thread).

You might say, just package the executable and source code together, so the user can choose whichever he wants to use. But again, when you distribute source code, there's an expectation that it is maintained. So distro maintainers could just choose to compile your source themselves instead of using the existing one, change static dependencies into dynamic ones and so on.

2. The lack of responsibility

Again, not every open source project, just vast majority of them. When you work on something for free, you don't have the insentive to make it as good as when you're financially dependent on it being good. Same happens for big companies actually: when you receive your paycheck divorced from the quality of the product, that quality becomes less relevant to you. Very different from Jon's situation for example.

Attached to that, the open source culture of just submitting one patch and disappearing forever. If it's a bugfix, no guarantee that the bug is actually fixed. If it's a feature, no guarantee that no bugs have been introduced, or that it fits in any way with the existing code.

3. The finance problem

Best exemplifed by Mozilla. When you devote most of your time to an open source project, you still need to put food on the table. The problem is, pretty much every one of these alternative methods is worse for the user than just paying for the product directly. Which you can't really do if you're open source, since anybody can just fork your project, take your customer base and leave you with nothing.

Original Post

The right way to write software — Adapted (mostly pasted without modifications) from Jonathan Blow. Originally found here: [https link] I read this article about software development, which I knew about because I saw Prime reacting to it: [https link] For the most part I think it is fine: a relatively young programmer is doing the healthy work of introspecting on what he should really be doing. But there's one part of the article that I think is a deep mistake, and the author doesn't know it'...