I really like Clojure and I'm glad it is around, but I'll prefer something with strong types any day.
From the article I see a lot f reasons why:
> "Don't break things!" is part of the culture.
If you cannot have compile time guarantees on correctness, the discipline to not break things becomes a key feature. On the other hand, if you have strong correctness guarantees, you may more easily incur some breakage (and thus actually fix things).
> Some discipline required [...] with great freedom comes great responsibility.
There's always some discipline required, but without a type system discipline become more important.
> you often need to find specific places where a function or a piece of data is referenced [which is hard in Clojure] because there are no links established via a type system.
Yups. IDEs also like types to build their features on.
> Documentation becomes more important
I dont like documentation as a fix. Docs should tell me why some code is there, not what it does or how to use it (that is preferably obvious).
Again: I like the language a lot. I also like Ruby a lot. But when a new project with serious complexity requires me to pick language I go with something that has: no implicit nulls, strong type safety, sum types, exhaustivity checks.
If you constantly work on the same code base day-in, day-out, breakage through the language or libraries is much less of an issue. You can keep up with current developments in the language and/or libraries, and update as necessary. Incremental changes are not a big deal, since you’re always around when they happen.
If you tend to write code once, and come back to it months or years later, breakage is a huge issue - why is the code that was working perfectly well in 2019 broken today? Why do I have to now fix 4 dependencies in order to do what I actually wanted to do (make some small change). This is the reason that I tend to write all my own code in TypeScript projects, but for my Clojure/ClojureScript projects I am much more happy to pull in the occasional library.
I would say that the “don’t break things” culture is less about static vs dynamic types, and more about the style of software being written and the maintenance expectations.
> Again: I like the language a lot. I also like Ruby a lot. But when a new project with serious complexity requires me to pick language I go with something that has: no implicit nulls, strong type safety, sum types, exhaustivity checks.
> If you cannot have compile time guarantees on correctness, the discipline to not break things becomes a key feature. On the other hand, if you have strong correctness guarantees, you may more easily incur some breakage (and thus actually fix things).
Yes, and the result of that is cabal hell. Types aren't there to help you break your API. Once the API is out and it has users it is rude to break them. The linux kernel is a prime example how far can you get if you don't break your users.
Cabal hell is fixed with tooling. Part of that tooling is running tests, but a large part of it is "it compiled together so it should work together" (which is a safety dynamic typed langs dont offer).
No it is not. People still reach out from stack when a dependency has updates and it's not in stack yet.
Nobody cares if it compiles together. The point is if a new feature or a bug fix is introduced in a breaking way you cannot bump your dependency and start using it, or progressively move to the new API.
In my experience Stack solved all my cabal hell. I've come to accept some level of dependency juggling, as I had it with every languages.
In Haskell is was more laborious before Stack (the place known as cabal hell) and it got better than average after Stack. Sure, this is just my subjective experience.
> Nobody cares if it compiles together.
Well I didi. If Stack guarantees that a set of software compiles/tests together, then I dont have to do that work.
From the article I see a lot f reasons why:
> "Don't break things!" is part of the culture.
If you cannot have compile time guarantees on correctness, the discipline to not break things becomes a key feature. On the other hand, if you have strong correctness guarantees, you may more easily incur some breakage (and thus actually fix things).
> Some discipline required [...] with great freedom comes great responsibility.
There's always some discipline required, but without a type system discipline become more important.
> you often need to find specific places where a function or a piece of data is referenced [which is hard in Clojure] because there are no links established via a type system.
Yups. IDEs also like types to build their features on.
> Documentation becomes more important
I dont like documentation as a fix. Docs should tell me why some code is there, not what it does or how to use it (that is preferably obvious).
Again: I like the language a lot. I also like Ruby a lot. But when a new project with serious complexity requires me to pick language I go with something that has: no implicit nulls, strong type safety, sum types, exhaustivity checks.