I'm not very familiar with functional programming and Haskell in particular. I think I understand the gist of this article, and "use data structures that make illegal states unrepresentable". However, is there a similar article but written with more common languages (C#, C++, Java, Go) in mind? Or is a big part of this concept only relevant for strong functional languages with sum types and pattern matching?
Not me personally, but a GitHub user wrote a replacement for Go's regexp library that was "up to 3-3000x+ faster than stdlib": https://github.com/coregx/coregex ... at first I was impressed, so started testing it and reporting bugs, but as soon as I ran my own benchmarks, it all fell apart (https://github.com/coregx/coregex/issues/29). After some mostly-bot updates, that issue was closed. But someone else opened a very similar one recently (https://github.com/coregx/coregex/issues/79) -- same deal, "actually, it's slower than the stdlib in my tests". Basically AI slop with poor tests, poor benchmarks, and way oversold. How he's positioning these projects is the problematic bit, I reckon, not the use of AI.
Same user did a similar thing by creating an AWK interpreter written in Go using LLMs: https://github.com/kolkov/uawk -- as the creator of (I think?) the only AWK interpreter written in Go (https://github.com/benhoyt/goawk), I was curious. It turns out that if there's only one item in the training data (GoAWK), AI likes to copy and paste freely from the original. But again, it's poorly tested and poorly benchmarked.
I just don't see how one can get quality like this, without being realistic about code review, testing, and benchmarking.
That's a good caution. However, traversing a flat AST (iterating a "struct of arrays" rather than a pointer-based tree) is also going to be faster. So the next steps of the compiler, say type checking and code emitting, will also be faster. But how much, or whether it's worth it even then, I'm not sure.
I use the "baby bear" strategy mentioned in the article. My criteria are something like: archive emails from humans as well as important emails like receipts and invoices; delete advertising emails, newsletters, notification emails, and things that I can just as easily find online.
Yes, definitely still got/getting something out of it, thanks. And I'll probably get more out of it when I read up on "how to write a real chess program" for v2, and learn about all the things I didn't think about.
Yeah, I use this sometimes too (even though Python makes "monkey patching" easy). However, note that it's simpler and clearer to use a default value for the argument:
def do_foo(sleep=time.sleep):
for _ in range(10):
sleep(1)
A program that will play chess (written in Go). My 18yo daughter can now beat me at chess (not that I'm any good). I figured if I can't beat her, I'll see if I can write a program to beat her instead. My idea for v1 is that I'd write the algorithm myself, without looking up anything about how to write a chess program (I'm sure such literature abounds). I've just about finished v1; still a few bugs to iron out. To be honest, I didn't find it all that fun, mainly because of all the special cases (all the castling rules and the like).
> “The ships hung in the sky in much the same way that bricks don’t.”
That is probably my favourite phrase from the whole book. For some reason I find it hilarious. It has stuck in my brain in much the same way that names don't.
Forth is (I think?) the oldest and most well-known. Postscript, the printer control language, is possibly more widely-deployed. And Factor is a modern take on Forth.
The format feels ad-hoc to me. These are intended almost exclusively for machine-reading, so why not JSON? One of the proxy endpoints (version metadata) returns JSON, so why not this one? If I were writing the client, I'd much prefer to parse a structured JSON object than that text file. So I'm curious why this choice -- I'm probably missing something.