• esa@discuss.tchncs.de
    16·
    3 days ago

    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.

    • Kache@lemm.ee
      4·
      3 days ago

      For me, the more relevant adage here is “a bad abstraction is worse than no abstraction”.

      IMO many abstractions in Java are terrible in this regard, either via commonly proliferated patterns or via language design issues. Abstractions large and small are all forcibly locked into place very early on in the name of formalism and safety, ultimately leaving us with poor versions of the former and weakened versions of the latter. Where is “encapsulation” when certain classes only work when hooked up in very particular ways to other distant classes? Where is “type safety” when certain methods simply raise “not implemented for this sub/super-type”?

      These faults are often hand-waved as “all ecosystems have rough patches”, but my point is that Java’s bad abstractions in particular are supremely more stubborn and persistent in comparison with other ecosystems. I understand many consider this a strength aka stability, but IMO at the extreme being unable to shed the past means negatively hindering progress. I think modern Java versions show a budding shift in mentality, but I’ve already moved on – it’s just not for me.

      • esa@discuss.tchncs.de
        1·
        2 days ago

        Also not having used Java for decades I’ll not comment on the state of their abstractions, but

        IMO at the extreme being unable to shed the past means negatively hindering progress. I think modern Java versions show a budding shift in mentality

        both reminds me of similar complaints against C++ (and with a sizeable amount of users wishing for an ABI break), and how weird it is to get both complaints like that and over the fact that so many shops are on ancient versions. They’ve moved slowly, but it doesn’t seem like anything was slow enough for a lot of shops, which indicates they likely could’ve moved faster without changing which versions users would be at today.