Hacker News Reader

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.

Dont break things merely exaggerated as a requirement in dynamic typed langs.

In real life projects, you end up doing type checking at runtime, meaning you also need a test for the code path

Exactly! More developer discipline required.

What ever can be checked by the compiler, as part of the language, is automatic free productivity to me.

The counter argument is that in clojure you can do (merge {:a 1} {:b “yo”}) without defining new types.

> 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.

Which language is that?

Haskell, OCaml, Elm

> 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.