benhoyt

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.

The guy certainly had ba... uh, courage. Jesus is known for saying striking things, like "If your hand or your foot causes you to stumble, cut it off and throw it away. It is better for you to enter life maimed or crippled than to have two hands or two feet and be thrown into eternal fire." (Matthew 18:8) He was the master of attention-grabbing metaphor. Of course here he means "deal seriously with your sin", not "get out the butcher's knife".

I do it by working for Canonical. The vast majority of our projects are open source. Yes, Canonical's application process is very long and thorough, but it's a good company to work for. Those aren't "my" projects, of course; I'm still very much working for an employer, but it's nice that our development effort is in the open and freely available. I also maintain a few of my own open source projects, for which (via GitHub Sponsors) I get about enough for one coffee date with my wife.

Sure, it's UptimeRobot: https://uptimerobot.com/

My fly.io-hosted website went down for 5 minutes (6 hours ago), but then came right back up, and has been up ever since. I use a free monitoring service that checks it every 5 minutes, so it's possible it missed another short bit of downtime. But fly.io has been pretty reliable overall for me!

> It's all the design principles of Java that I don't like, but more of it.

I'm curious what you're referring to there. I think of Go as the "anti-Java". Where Java has "org.apache.commons.httpclient", Go has "net/http". Where Java has stuttering like "final Logger logger = LogManager.getLogger();", Go has "logger := log.New()" (and no log4j vulnerablity). A typical "simple" app in Java puts files in "src/com/username/simplewebapp/subdir", typical Go project structure is to put files in just "subdir", or even just in the root dir. And so on.

I missed this too. However, I've found you can work around it pretty easily with clauses like CASE WHEN @field != "" THEN column = @field ELSE true END.

Example from the sqlc creator (https://github.com/sqlc-dev/sqlc/discussions/364#discussionc...):

  -- name: FilterFoo :many
  SELECT * FROM foo
  WHERE fk = @fk
    AND (CASE WHEN @is_bar::bool THEN bar = @bar ELSE TRUE END)
    AND (CASE WHEN @lk_bar::bool THEN bar LIKE @bar ELSE TRUE END)
    AND (CASE WHEN @is_baz::bool THEN baz = @baz ELSE TRUE END)
    AND (CASE WHEN @lk_baz::bool THEN baz LIKE @baz ELSE TRUE END)
  ORDER BY
    CASE WHEN @bar_asc::bool THEN bar END asc,
    CASE WHEN @bar_desc::bool THEN bar END desc,
    CASE WHEN @baz_asc::bool THEN baz END asc,
    CASE WHEN @baz_desc::bool THEN baz END desc;

Brian Kernighan sent Gawk maintainer Arnold Robbins an email linking to this blog post with the comment "Hindsight has a lot of benefits, it would appear."

Peter Weinberger (quoted with permission) responded:

> That's interesting, Here's some thoughts/recollections. (remember that human memory is fallible.)

> 1. Using whitespace for string concatenation, in retrospect, was probably not the ideal choice (but '+' would not have worked).

> 2. Syntax choices were in part driven by the desire for our local C programmers to find it familiar.

> 3. As creatures of a specific time and place awk shared with C the (then endearing, now irritating) property of being underspecified.

> I think that collectively we understood YACC reasonably well. We tortured the grammar until the parser came close to doing what we wanted, and then we stopped. The tools then were more primitive, but they did fit in 64K of memory.

Al Aho also replied (quoted with permission):

> Peter's observation about torturing the grammar is apt! As awk grew in its early years, the grammar evolved with it and I remember agonizing to make changes to the grammar to keep it under control (understanding and minimizing the number of yacc-generated parsing-action conflicts) as awk evolved. I found yacc's ability to point out parsing-action conflicts very helpful during awk's development. Good grammar design was very much an art in those days (maybe even today).

It's fun to hear the perspectives of the original AWK creators. I've had some correspondence with Kernighan and Weinberger before, but I think that's the first time I've been on an email thread with all three of A, W, and K.