dmux

This comment is just repeating a point made in Casual Finance's youtube video here: https://www.youtube.com/watch?v=roe3SgezmmU (timestamp 1:06)

I say this half tongue in cheek, but maybe we need a new law like "Greenspun's Converse": Any sufficiently large dynamically typed codebase contains an ad hoc, informally-specified, gradually-adopted, optional implementation of half of Haskell’s type system.

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'"?

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!

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

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

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.

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.

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.

Yeah, I was originally thinking of the latter and generally interested as to what they were providing.

Curious to see where you'd place Knockout (still my favorite framework to date)

I also see this mentioned often and have wondered the same. I can sort of envision this working in a single threaded application, but how would this work in a web application for example? If a problematic function needs to be debugged, can you pick what thread you're debugging? If not, do all incoming requests get blocked while you debug and step through stack frames?

I'm not a fan of dynamic typing at all (currently maintaining a decade's old e-comm monolith written in Ruby on Rails), but instead of arguing about what bugs are caught where, I've instead switched to arguing from a position of developer experience. The _tooling_ that statically typed languages have is levels above those found in dynamic languages. Runtime errors are runtime errors, but knowing at typing-time that the shape of thing A is what thing B needs is a huge benefit.

This is PG's response about Sam leaving YC. It says nothing about the original motivation of offering him the position at YC.

And here I thought it was an initiative to get Detroiters to be more active!

>If you mess up, redo the part you messed up correctly 5 times in a row.

I think it may be important to note _when_ to redo this. I started off this way, but after working with a guitar teacher (a Berklee graduate), he recommended that I continue on with the song and return to the problematic parts afterwards. If you constantly stop at the problematic parts to replay them and get it right, you'll have no idea what other parts you'll have trouble with further into the song until much later. In addition to that, being able to move on and continue playing the song after making a mistake is an important skill itself. If you build that skill, it's usually only other musicians that will notice -- a regular audience won't.

What's your take on it?

Great work and nice writeup. I went in wondering how you were handling instances and got my answer!

>easy for agents to write and beautiful for humans to review

What's left unspoken here, and something I've brought up in other threads that have mentioned Ruby + LLMs, is that they continue to struggle _comprehending_ Ruby (and Rails) style code. In a fresh project, agents writing code for humans to review is a solid approach, but when the codebase grows and the project starts suffering from the downsides of dynamic typing, you're not going to be able to lean on that LLM to aide you in refactoring.

LispWorks and Allegro are both interesting, but I've found their IDE offerings to be very limited. I haven't used either since I was playing around with CL during Covid, but from what I recall, even the basic IDE experience of writing code was severely lacking: poor autocomplete, poor syntax highlighting, clunky interfaces. In most discussions I see about them, they're only recommended for their compilers, not for their IDE offerings.

This is the perfect way to create a code-base that's incomprehensible. Claude may be good at generating Rails code, but every LLM I've tried to date has struggled immensely with parsing and understanding an existing Ruby on Rails code-base.

>...despite the protest of students...

I work closely with Northeastern CS students (via co-op program) and haven't heard anything but negative opinions about Racket.

I wonder if you could circumvent this by adding a thin appendage to whatever it was you're printing and then just snip it off post-print.

How can breaking a task into sub-tasks that themselves are measured in hours take longer than the implementation of those features?

I’ve found LLMs to be severely underwhelming. A week or two ago I tried having both Gemini3 and GPT Codex refactor a simple Ruby class hierarchy and neither could even identify the classes that inherited from the class I wanted removed. Severely underwhelming. Describing what was wanted here boils down to minima language and they both failed.