Most of this kind of content comes off as relevant/topical but mindless entertainment. This is not a "deep dive" of anything that I could practically apply in my daily work. It feels good to think this content might add value and then to subsequently consume it, but it's effectively junk food.
I used to spend a lot of time watching crap like lex and primagen before it became obvious that these kinds of information channels are not meaningfully enriching despite sounding like they should be to a casual observer.
> Open source is the very worst thing currently going on because it is so incredibly exploitative, it's far more exploitative than any actual company is of the workers who work at the company.
> Even the people who are getting paid in open source are getting massively underpaid to do it compared to how much the people who are using their code are making, it's nothing compared to the power that is accreted by the people who have co-opted that work thanks to the open source model. And then mark zuckerberg gets to define how the internet works despite having paid for almost none of the software that his company actually needed to make that work.
> It's like feudalism or serfdom, these people did the work and got nothing for it. It's like you took the worst aspects of capitalism for workers and the worst aspects of socialism for workers and put them together, that's open source. You get no power and you get no money.
> It's exploitative whether the people chose to be exploited, just because someone chooses to let you exploit them does not mean that you didn't exploit them. And for the record that's how most exploitation works; convincing people to do something that turns out to be very bad for them and very good for you, and that's exactly what the open source movement has turned out to be.
> I really don't see the "we post stuff on github under a gpl2 or lgpl or apache or mit license", all that is to me now is just exploitation. You can say that there's solutions but until someone demonstrates that those solutions work, it's the standard "real communism has never been tried" argument. AGPL is the only thing that I've seen so far that's an attempt to fix these fundamentally unfair compensation practices.
1. Not paying for the labor corporations exploit. GPL is better here, but still imperfect. MIT/BSD is awful here. It wouldn't matter in an ideal post-scarcity society, but we don't live in that yet, so it does matter. Until post-scarcity, a better model would route revenue from exploitative capitalist uses back to the creators and/or their desired sinks.
2. The open source bait-and-switch - startups using open source to get users and then pulling up the ladder and going closed source and monopolistic once they have achieved scale to enforce/ achieve lock in.
In fact they don't seem to care about money at all, often believing all corporations/capitalism are bad, and that they and everyone else should just be poor and live in the woods or something.
I feel like if you plotted open-source vs proprietary code percentages against the rate of innovation, it would be a bell curve: once you start giving away too much, the incentive to innovate diminishes.
When has History of any kind ever held practical value?
Casey is far more measured, careful and accurate. Casey feels like an engineering educator first, who happens to make YouTube videos. I don’t always agree with Casey’s technical opinions, but he seems like a thoughtful guy who thinks things through.
I skimmed through the video because I don't have two hours but there's no lost knowledge in it, he's going over well known papers from Dijkstra, Hoare or Knuth. The paper he bases most of the talk around Knuth's Structured Programming with go to Statements is his most often cited work, there's a very high chance you'll encounter that early in any undergrad course. So the answer to your question is, pretty much at any local uni with a CS course.
But I'm curious who you think #3 is.
I should also add that even interviews are valuable. Coders at Work is fantastic at that and drawing out technical opinions and reasoning; notably the subjects interviewed don't all agree and have sometimes drastically different work styles and preferences. (And also adding from another comment, Turing Award Lectures are great history, and Uncle Bob even has a history book out now on influential programmers.)
While I suspect he could do research, he also just isn't personally experienced in large tracts of SWE culture as others. Others have worked a far larger variety of jobs in the software industry and thus tend to have a broader idea of the cultures and how they've evolved. In a recent clip I saw of him and others discussing how BS are various phrases engineers say (the root of all evil phrase being one of them), he hadn't heard of the YAGNI acronym/idea before. That's no fault on him, programmers live in different worlds. But regardless of one's feelings about such ideas, or whether they've heard of them or not, a history of SWE would have to cover them and the schools of thought that originated them. And this is just one minor thing in living memory and recent careers, there is so much from before he was born that has to be researched and if possible also talked about with the older practitioners who are still around and remember things. If you don't already have some awareness of things that should be covered in a history, whether from personal experience or just general curiosity about history that has led you to see such things before somewhere, the only hope is further research uncovering them, and I don't trust his researching that much.
Reading The Psychology of Computer Programming from the 70s was such an interesting read for me from a historical perspective as well as being able to see how some ideas they were thinking about back then came to fruition in some way or another. (e.g. Stack Overflow.) It's just one small part of history. A "complete" history as the top comment suggests would be better as a multi-author endeavor, would probably need many books, and that's if it could be done at all. In the meantime at least one can always go read primary sources and develop an idea of the history on one's own.
It's just absurd to me to point at Casey, of all people, as the most informed person who would be best positioned to publish something containing all of the history of anything broad.
It’s a pity there’s not more people like him. I’ve met some incredibly smart people in the FP world. I wish more of them made approachable YouTube videos explaining what they know. I recently learned about “Safe Haskell” which, if adapted to rust and other languages, could solve a lot of the security problems with npm and cargo. But nobody knows about it! We need FP Casey.
There's two reasons Safe Haskell is substantially worse than what Rust does. Safe Haskell works by annotating code that is safe, but that's entirely backwards. We need to annotate unsafe code, and explain in plain English exactly why it is okay in that particular instance (of course it would be better to explain in code, like, give a formal proof that is checked by the compiler, but then it isn't unsafe anymore!). Safe Haskell answer for that is to annotate good unsafe code as trustworthy, but that doesn't work because it doesn't goes in detail on why the code is trustworthy (to do so you really need to go into the details, you can't handwave it). It's the // SAFETY comments that are at the heart of Rust's unsafe, carefully explaining safety invariants that must be kept (specially important if we are modifying code), not unsafe { } blocks.
The second reason is much simpler. It's optional, and approximately nobody uses Safe Haskell or cares about it. If people used it we would have something to improve upon. So Rust achievement here is mostly sociological, it's a community of programmers that care about safety. Which is good given that a Rust program typically have much more unsafe code than a Haskell program.
Here's a thread about Safe Haskell issues https://www.reddit.com/r/haskell/comments/zwkqke/deprecating... that links to https://discourse.haskell.org/t/deprecating-safe-haskell-or-...
And an older thread https://www.reddit.com/r/haskell/comments/msa3oq/safe_haskel...
This would guarantee - at a language level - that leftpad or log4j can’t root my computer.
Safe rust doesn’t give this guarantee. Safe code can still make arbitrary syscalls. Safe rust can convert a path string to a File. Or open arbitrary network sockets. Rust also doesn't have a way to import a crate but forbid the use of any unsafe blocks.
I want to be able to use 3rd party code from cargo without getting hacked. Right now rust does not keep me safe from these supply chain attacks.
I don’t know enough about safe Haskell to know how close it tacks to this. But that’s what I want.
But if you don't want an ironclad guarantee and instead you're content with making wrong code obviously wrong even if it's not formally verified, then I recommend Haskell with a capability system (what the Haskell world calls an "effect system"). As far is I'm concerned there are two practical choices in 2026, Bluefin (mine) and effectful (one of Bluefin's inspirations)
On infection, I think it's a bit like being infected by mitochondria :)
I don't think you'll find anything like that from a General Purpose Language, so you probably want something like WUFFS [Wrangling Untrusted File Formats Safely].
Casey points out that many of the lessons they came to were so obvious that it just became how it is done that no one even remembers it was done in any other way. In the talk the laments it makes it really hard to track down who originally came up with these ideas.
Like I agree with most everything he says and I like to optimise my own software, but for my day to day jobs and contracts it's simply not feasible.
That level of performance and rigor is not what is demanded nor paid or appreciated.
E.g. in Enterprise circles it's still OOP from top to bottom.
Mixed with a tad more functional style due to varying adoption of that paradigm in the languages used by enterprise.
But low level optimizations are not interesting to these customers at all, even though they could help them with some problems.
I suppose it is a matter of what one works on, but that has been consistent in my career.
I have seen many be rewarded for choosing what I would deem intentional, gross negligence. But hey, those devs get work finished faster, and that's all that matters to the non-technical folks.