DEV Community

Discussion on: Why Clojure?

Collapse
 
ysangkok profile image
Janus Troelsen

At least in Python, I find that the "opt-in to types" model doesn't work well. For example, libraries like Mongoengine are so dynamic that the returned type effectively depends on a dict. Dicts can be too (TypedDict), sure, but it doesn't happen in practise.

So why not do it the other way around? Haskell has Data.Dynamic.

Collapse
 
kspeakman profile image
Kasey Speakman • Edited

Thanks for the comment and suggestion.

I believe Clojure's coding model is rather different than python's and can manage opt-in typing pretty well, from what I have seen. (We shall see.) It also resonates with what I do in F#. F# is statically typed but as with most languages, types match the underlying machine, not precise enough to exactly match the parameters of specific use cases. So I filter all requests through an extra validation function before proceeding, similar to Clojure's approach to typing.

The other alternative is to create a wrapping type to represent the more specific version of data, and have that type's constructor block creation unless data matches constraints. However, I find that approach to have a lot of overhead in dealing with the wrapping type. So I do not use it.

Regarding Haskell. Even if I use dynamic myself, it seems unlikely (from some prior research) that libraries I want to use will. Plus it seems to be common for some of the major libraries and samples to code on top of category theory abstractions. So any new person I bring on must first back-fill theoretical math knowledge before they can do meaningful work. (And memorize whatever custom operators the library chose to use.) I am all for them learning the math if they want, but it feels too much to require as a first step. (Last few hires had no prior experience, and we like it that way.)