• 2 Posts
  • 37 Comments
Joined 5 months ago
cake
Cake day: December 16th, 2024

help-circle
  • This sounds like the antithesis to parse, don’t validate. It is possible to use just maps and strings and get a “stringly typed” program, but there’ a bunch of downsides to it too:

    • your typechecker can’t help you if you used the wrong dict[str, Any]; most of us want the typechecker to help us write correct code
    • there’s no public/private
    • everything you .get from a map is Optional; you need to be constantly checking and handling that rather than being able to have methods that return T, or even direct field access
    • you can derive or hand-implement a bunch of operations on (data)classes that you can’t on maps: Comparison, ordering, hashing so you can use the blob of information as a map key, …

    Ultimately while Hickey has a good point in the distinction between easy and simple, his ideals don’t seem particularly aligned with the programming world at large: For one thing, Clojure remains pretty small, but even other dynamic programming languages like Javascript and Python have been moving towards typechecking through Typescript and typing in Python.

    Doing a json.load into some dict[str, Any] is simple, but actually programming like that isn’t easy. Apparently a lot of programmers find value in doing the extra work to get some stdlib or pydantic dataclasses. Most of us get a confidence boost from using parsed data, and feel uneasy shuffling around stuff that’s just strings and maps.














  • Isn’t that sort of just the cost of doing business in C? It’s a sparse language, so it falls to the programmer to cobble together more.

    I do also think the concrete example of emails should be taken as a stand-in. Errors like swapping a parameter for an email application is likely not very harmful and detected early given the volume of email that exists. But in other, less fault-tolerant applications it becomes a lot more valuable.