The trouble is, his knowledge covers just a slice of it. He won't talk about stuff like functional programming for instance

▲

josephg 17 hours ago | parent | next [-]

Yeah. Casey is just some guy who’s good at software and YouTube. I’ve worked with dozens of people at his level technically. But very few with his interest and skill at making videos.

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.

▲

nextaccountic 7 hours ago | parent | next [-]

Safe Haskell is just a worst version of Rust's unsafe. What it actually does is equivalent to Rust's #![forbid(unsafe_code)] which immediately lead to a question: so Haskell has unsafe, just like Rust? And of course it does. Any practical systems language has unsafe in one form or another, not only for FFI but also for performance, Rust is just honest about it.

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...

	▲	josephg 3 hours ago \| parent [-]
		The thing I really want is a language or environment with no implicit access rights. So, if I call add(a, b) then the add function doesn’t have implicit access to the filesystem, network or global variables in other parts of the program. If you want to give a function access to a subdirectory, you should pass a handle to that subdirectory as an argument and use openat() or equivalent. 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.

▲

15 hours ago | parent | prev [-]

[deleted]

▲

Jach 17 hours ago | parent | prev [-]

This is my objection as well. His talk last year on OOP was heavily focused purely on the style of OOP that led to C++'s version. It completely ignored everything else going on outside that historical thread. As history it was interesting but doesn't inform much outside of a C++ view of the world and it missed so much relevant history about OOP more generally.

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.

▲

josephg 17 hours ago | parent [-]

If you know this stuff, please make videos / talks yourself going through it. Casey doesn’t have the background for a lot of this. He’s doing great as a C++ dev but as you say, he’s just one guy with one perspective.

	▲	Jach 15 hours ago \| parent [-]
		I really think videos and talks are the least effective ways to get these things out there. I'd rather just point people to references I've read myself about specific topics rather than try to create a structured synthesis or presentation. I tend to think that's sort of best anyway for a curious individual: go read primary sources about some topic, and if interested further, citations or other related works. Every Turing Award Lecture transcription I've read has been insightful. I just recalled that Uncle Bob was writing a book about influential programmers, he was calling for suggestions on names a few years ago: https://x.com/unclebobmartin/status/1714972421269119190 One could just read through those names and the names of those the comments added (I had several more) and the work they are most known for, and by the time one is done with that, one will have a very nice historical picture of computer science up to the 70s. Nowhere near complete, of course. It seems he did publish his book at the end of 2024 (https://www.amazon.com/We-Programmers-Chronicle-Coders-Rober...), I'll have to check it out at some point. (Edit: and I'm reminded of another funny thing. Early in the book Clean Code, he asked some other programmers what they thought was meant by the idea. I remember penciling in some objections in the margins that he should have asked x,y,z other people who I would rather have read from than some of his sample.) 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.