Yeah, I think the article assumes the employees doing the work have the leverage to implement the changes themselves. How often is that the case?

>> "The requirements changed three days before launch."

> Of course they did! What happens when requirements change inside the launch window?

What answer is wanted here? "Moving forward, we'll ignore the VP of Marketing's last minute 'must haves'"?

> What answer is wanted here?

"We will be more proactive and agile, and volunteer to work during the entire weekend to keep our customers happy, sir!"

"Good, good, but don't bother me with the details."

Your callout just gave me a great idea: the iPhone Duo has three screens. Depending on orientation, the front screen could be used to show ads to others!

Don't give 'em more ideas! :)

>in places where it's pointless to check, like IOException

Can you explain why this is pointless? In my mind, this being a checked exception would hopefully be a hint that I should think about this failure-case and make an explicit decision whether to handle it or not. Network connection failed? Maybe I retry. Maybe I store that data somewhere else as a fall back. Isn't this similar to Go programmers needing to check if err is not nil?

I don't think I can recall a time where I routed-around-the-damage on the basis of a particular typed exception.

As soon as you consider retrying a network failure, you immediately need to start thinking about distributed systems failures, idempotency, and all that good stuff.

As soon as you start thinking about the above, it becomes immediately obvious that low-level calls should not be able to decide to re-run themselves.

>I don't think I can recall a time...

I appreciate that there is a _ton_ of different experiences out there when it comes to solving problems, but I _have_ encountered exactly the case I was describing, which is what led me to my original question. Isn't the fact that it was a checked exception that led you to "consider retrying a network failure, you immediately need to start thinking about distributed systems failures, idempotency, and all that good stuff" worth it as opposed to an unchecked exception you may not realize is being thrown?

Exactly. I've been hosting a site from a spare M1 Macbook Pro with Ngrok. An equivalent bare metal server would be much more expensive.

Tcl brings with it some other ambiguity when serializing though.

    {a 1 b 2}

Should the above be serialized as a dict, a list, or a string (ignoring the various possibilities of treating ints as strings themselves):

    {"a": 1, "b": 2}
    ["a", 1, "b", 2]
    "a 1 b 2"

But _worse is better_.

Tcl has a library called "comm" [0] that lets you expose an interpreter over a socket and since everything in Tcl has a string representation, there's no need for a serialization/deserialization step.

[0] https://core.tcl-lang.org/tcllib/doc/trunk/embedded/md/tclli...

I know Racket was reworked to build upon Chez Scheme several years ago. If the HN migration to CL was due to performance reasons, I wonder if sticking it out and waiting for the Chez version of Racket would have paid off.

here:

    I’m curious: was Arc running Racket BC or CS? I understand it got a big performance boost after switching to Chez Scheme.

    dang: It was running BC. I had high hopes for switching to CS because I'd heard the same thing you had, but when I tried it, HN slowed to a crawl. This stuff is so unpredictable.

https://news.ycombinator.com/item?id=47140657

It was running an old version of BC.

I can't remember the details, but I recall that Arc was pinned to an older version of Racket and didn't benefit from improvements to BC and then later to CS.

But ... be aware that the Arc interpreter is much more dynamic than Racket, so in general normal Racket programs are more efficient than Arc programs.

I think what the other comment is getting at is that you're essentially leaving footprints behind on various servers and that information could be used to narrow down who you are, where you work, etc. For example, if you used the same key pair for a work machine at the big social media site example.com as you did late.sh, they could probe example.com's machine and see that you'd been there.

That sounds like the kind of edge-case thing that wouldn't be even slightly a problem for like 99.9% of people.

I'm surprised there's no call out highlighting Common Lisp and Clojure's "liveness" compared to Racket (and Scheme). Racket is "batch compiled" wherein CL and Clojure you're editing a live image.