tikhonj

The "data inputs" were also, very much, somebody's "value added" IP.

We're talking about things like text people wrote, not some kind of raw data floating out in the ether.

There are still a lot of smaller totally independent projects like this. I suspect that there are more—far more—just-for-fun projects today than in past decades in absolute terms.

I love Haskell, I've spent a lot of time in the general area around functional programming, types, proofs and PL, and there is still a vibrant community with lots of amazing non-commercial projects there. I'm sure the same is true in other areas of the programming world.

Ditto for the Emacs world. Emacs and its package ecosystem are amazing, better than they've ever been, and ≈entirely driven by non-commercial work.

Same for a big chunk of NixOS, although there's also been some real commercial investment there now.

I never really thought about it before writing this comment, but, except for games, most of the software I use and care about is primarily community-driven rather than commercial. And it's absolutely great.

Despite smaller communities and low monetary investment, a remarkable number of things about Haskell and Emacs and Nix are simply better than any commercial alternative, full stop.

The problem isn't that this kind of software has died—it's thriving more than ever—but just that the rest of the field has grown around it even faster. Programming is so commercially valuable that there has been a ton of investment in it and now we have millions of people for whom it's just a career, and trillions of dollars pouring into companies powered, primarily, by programming. It's a wild time. The overall feel of the field is definitely different now, but you can still find classic hacker enclaves. You just have to cut through the noise first.

The biggest obstacle to that is the electorate. People (voters!) would go wild. Anything the NGOs do, however shady, won't compare to that.

We had a successful campaign to recall a progressive prosecutor over less.

None of those things make homelessness appealing in any absolute sense. Like, if people had a (reasonable-to-them) path to getting a home, the vast majority would go for it even if there were a bunch of services available.

The real answer is that the electorate is vehemently opposed to providing paths like that if those paths feel even remotely like "unfair handouts". Votes hate that idea even if it would be empirically cheaper. We collectively preserve the problem of homelessness because we feel like people who can't/won't work deserve to be unhappy, because we believe that we need the threat of homelessness to coerce people into working, because we believe people on drugs/etc are undisciplined and immoral, because... well, you get the idea.

I've had the opposite experience, where Spotify (and, to a lesser extent, YouTube) has been a great way to find different music that I enjoy. The Discover Weekly playlist in particular has been surprisingly good at surfacing music that I enjoy but would have never encountered on my own.

This is handy for me because my taste in music runs pretty different from most of my friends.

I don't know how much of this comes from using Spotify in a different way, and how much is Spotify's algorithm adapting to my weird preferences.

It's a bit harder to find, but I've had a good experience with liquid melatonin. Each drop contains like 0.1mg, so it's easy to dial in the small dose that you need.

I did this the last time I tried reading Gravity's Rainbow and it definitely helped. Still required more prolonged focus that I have readily available though :P

Emacs is, in fact, an IDE and some general purpose automation harness. And some other stuff.

That's the point.

When I've been in that position, I've just trusted junior folks to figure out the tooling-specific way to do things like that, and it's worked out perfectly well. If anything, it leaves people happier and learning more.

And, instead, I can focus on the fuzzier, higher-level things that involve non-trivial tacit knowledge rather than things somebody can resolve with a Google search (or just ask Claude).

That doesn't follow.

For one, there might be trade-offs against dimensions other than safety and expressiveness. Performance, corporate support, libraries, popularity, learning curves, similarity to other languages...

For two, popularity is simply not strong correlated to quality. Popularity is a social function driven by, well, social factors. It's heavily path-dependent and noisy. There is absolutely no guarantee, not even close, that the "best" thing in any sense will be the most popular, or popular at all.

It isn't nearly as much of a trade-off as people say. Languages like Haskell are both remarkably expressive and provide a lot of safety. (And, of course, languages like Python, Java and Go are the opposite.)

Is that actually a word, or were you thinking of "wrought"?

If you have even the remotest mental slop filter, I assume you are not really part of their target market.

It's interesting how people view software as a distraction and an annoying side quest/cost center, but never apply that to, say, 90% of what management does. None of that "directly" makes money either!

That tells us a lot more about the leadership and management philosophies at modern companies than anything fundamental about what kind of work actually matters.

Kicking out 2% of your existing customers in a physical venue violates people's expectations, so it's going to get you disproportionate bad reviews and word-of-mouth.

Good thing that we've managed to keep everybody's expectations a hell of a lot lower for software quality then :)

I mean, it has definite Borg Bill Gates vibes, doesn't it?

It's totally reasonable for tech folks to be leery of a company using a strong market position from one system (Windows/Claude) to push mediocre complementary software (IE/CC).

Which online stores? I don't see that in Steam.

Regulations aren't fungible, so this is not a particularly meaningful perspective.

It's an illustration for a blog post on a largely different subject, it really doesn't matter.

Who would be looking up the integral of one of the most common functions in applied math in a random philosophical article aimed mostly at SREs?

The US has a notion of "disparate impact"[1] that means you can be liable for discriminating based on a protected characteristic on the basis of correlation. This is why HR departments are very hesitant to use things like IQ tests for screening candidates, for example.

[1] https://www.congress.gov/crs-product/IF13057

Property based testing is useful for finding bugs even in these kinds of CRUD heavy apps. There can be a surprising number of bugs and unexpected behaviors in the interaction of multiple sub-systems or APIs, and one way to find those bugs is to come up with properties on traces of calls.

For example, I saw a paper on using metamorphic testing (a particular technique for defining properties to test) to find bugs in the web APIs of Spotify and YouTube[1]. I don't have time to reread the paper just now, but I remember that they found weird behavior in pagination of search results. Not a big deal in that particular case, but I've definitely seen internal APIs with behavior that could be similarly wrong but with a much larger real-world impact.

[1] https://ieeexplore.ieee.org/document/8074764

Personally, I see property-based testing and formal specification more as tools for design and debugging more than full-on correctness. Even with AI models it's still really hard to fully prove something correct, but having even a partial logical specification can let you trade design time for debugging time and lets you find inconsistencies or potential edge-cases when you're initially figuring out a system, rather than waiting until you have a massive codebase to debug and redesign in production.

It's not a panacea and you still have to be careful at the boundary between your nicely modeled system and the real world, but, once I got the hang of working in that style, having some formal properties or partial logical specifications of the behavior I needed has been really nice to have, as much for saving effort as for ensuring correctness.

I've mostly worked in slightly different domains, but I've found property-based testing useful both as a tool to catch bugs but also as a tool for communication. I spent a couple of years building and supporting a supply chain simulation at Target, where I frequently got requests for new metrics from the supply chain planning team. By teaching them how to specify either the whole metric or, at least, some of the expected behaviors of the metric as mathematical properties, it took far fewer back-and-forth conversations to correctly implement the metric in the simulation. We could then test these things by checking these properties over a bunch of random simulation traces. Day-to-day this saved a bunch of time in debugging small simulation mistakes. In the longer-term, having this test suite also let us rewrite the simulation code in a new style in Rust to drastically increase performance. All of this would have been possible without the set of properties, it would have just involved a whole lot more slow, tedious work.

Ironic that this of all books got garbage collected prematurely.

The neat thing with Emacs is that the core concepts of the system are all first-class programming entities with their own documentation. So if you want to know what your current mode does, you can use C-h m to get a bunch of information including commands, key-bindings and links to code. If you have a key command, you can use C-h k, enter the keys, and you'll see exactly what function that command runs. You can get info about functions with C-h f and variables with C-h v; coupled with some kind of fuzzy-find-autocomplete (which, unfortunately, isn't set up by default), it's usually pretty quick to find the functions and config options that are relevant to whatever you're trying to do.

I still use web searches to look up Emacs things occasionally, but the built-in help commands are still useful because they're naturally tied to (and organized by) the core code entities that power Emacs.

So, if FTX had managed to stay afloat a bit longer, they could have gotten away with it.

Which is a much more interesting statement in the context of certain other crypto organizations than it is about FTX...

"Let's have more world wars" isn't a great thing to aim for.

Counterpoint: I absolutely give credit to Sonic for being a great ISP and recommend them to everyone. I got my parents to switch when Sonic finally rolled out to their neighborhood.

If online comments are anything to go by, I'm not alone.

If you're in the Bay Area and you can get a Sonic fiber connection, I would highly recommend them over AT&T/Comcast/etc.

You always have a choice. Sometimes the best move is not to play.

The point is that it's the same process with—much—better priors.

This seems like a reasonable view to me. It's surprising just how much better priors matter and how we can develop those priors by training on a bunch of text. But it also explains, or at least hints at an explanation, for why LLM capabilities are so jagged, and in such inhuman ways.

This project isn't for running Haskell on the JVM, it's for writing a compiler that produces JVM bytecode. You'd use it if you wanted to implement your own JVM language in Haskell or maybe if you wanted to have some kind of JVM-backed domain-specific language embedded in Haskell.

Just because you can't get everyone to agree does not mean that the concept is not well-defined or clear. People can and do disagree over almost anything. That could just mean that one side is wrong and the other side is right, even if it is difficult to determine which is which... or simply difficult to navigate the underlying politics regardless.

Besides, in your example, either kind of gap could be a bug or a missing feature. It's a totally orthogonal question.