|
> When everything is "just data", you spend a lot of time ... trying to figure out ... shape the data ...
> you spend lots of time debugging nasty type errors far from the place where bad data entered the program. I've been using Clojure for over a decade in various domains, different projects, diverse teams, etc., and quite honestly I don't even remember the last time it felt to me that way. Briefly, for a few weeks in the beginning perhaps it did. But at some point, maybe the REPL-driven workflow model internalized or something - I just don't ever feel like the way you describe. You're looking at the data as you build, so "far from where bad data entered" rarely happens - you watched it enter. If anything, Clojure has spoiled me - I get annoyed having to dig through confusing type/data mismatch in some other languages, despite their sophisticated type systems. Uniform data structures mean your mental model transfers everywhere. You're not learning 50 bespoke APIs, you're learning map, filter, get, assoc. The real question is what failure modes you'd rather have. Clojure's tend to be runtime, but local and observable. Some type systems trade that for compile-time errors that are... also confusing, just differently. At the end of the day, sorry for a cliché, but it is a "skill issue". I can endlessly complain about my confusion with type systems, but a seasoned Haskell developer doesn't feel lost in types, just like I don't feel lost in Clojure without explicit type annotations. |