I was able to use cljs in my first week for a production project but trying to find something the other team members are excited about with similar productivity benefits, but that’s a discussion for another time 😛

> It skirts too close to calling this a fundamental limitation of type systems, suggesting that it is not simply inconvenient but impossible to model such systems in a nominal, static type system. It's possible to write the same programs in turing complete languages regardless of whether they are statically or dynamically typed. Generally, which language is the best fit is more about how a language makes a program easy to express or how a language makes a program difficult to express. I think a more compelling argument for dynamic languages like clojure is that the tools for parsing, verification, validation, etc. are available a la carté, usually as libraries. The programmer has the flexibility to parse, verify, and validate whenever, wherever, and however they choose. Typically, statically typed languages have less flexibility. I've attempted to try Haskell multiple times and the main roadblock I've run into is that I've never been able to set up a REPL friendly dev environment. The constraints on when, where, and how types are specified make REPL driven hard! (I haven't tried lately, would love to know if things have changed.) Another argument I've heard is that the static type systems often don't express constraints that are important for a domain. The common example is that [a] -> [a] provides little value, but makes the type checker happy. In Clojure, when you express constraints, you have several options to choose from. For example, spec allows arbitrary predicates. Since I don't know Haskell that well, I'd love to hear if this argument actually holds water. This doesn't apply to all dynamically typed languages and programs, but it's more common in dynamically typed languages to program using Plain' Ol' Data. If you use a library, you don't really have to worry that it will return a data type that can't be easily passed to another library. If you want to split up your program, distribute it across a network, or simply store some intermediate results to disk, it's straightforward serialize your data. Again, I'm not particularly familiar with Haskell, so maybe Haskell makes that easy, but it's usually a pain in Java or C++. I think the static typers would argue that two different libraries are unlikely to have compatible data and that static typing would actually help you coerce comparable data types, but I'd much rather coerce a nested clojure map than a nested Java class. How does Haskell handle collecting data? If want to package A, B, and C in clojure, I can do {:a A, :b B :c C} . Would that require a new type in Haskell? If later I also wanted to provide D? What happens?

He isn't wrong in any way I see. Im just not happy having to learn every person's implementation of whatever Login/Foo/Bar types they made. Let me just use a map. And I for one choose happiness. I did like reading this though.

I particularly like the way he explained how to look at types. As an expression of assumptions.

@UGFL22X0Q I think the author is a she, which in many reflects the discussions we are having. Dynamic languages make a lot of assumptions on the underlying data without validating them. This seems easier at first but as the programs grows larger especially within a team it becomes incredibly hard to reason about data across function boundaries.

Oh my bad, didn't even read the name 😅

Clojure to some extent helps by having immutable values and repl workflows.

But a larger programs still would be served better by a static language, we have know this from the 80s, languages like Ada with their focus on strict type checking were designed to build programs for the military which had to be reliable and work exactly as intended.

oh woops