Hacker News Reader

Comment by ARandomerDude | Hacker News Reader

> Clojure...[has] no (broadly-accepted, successful) static typing system.

I've used Clojure exclusively for 7 years and actively work on a Clojure + ClojureScript codebase of more than 500K LOC. The lack of a robust type system is my number one frustration. Many people point out that Clojure is expressive, lets you go fast, and generally just gets out of the way. I agree. It also lets you have some nasty runtime errors that can be hard to reproduce and debug.

If there were a broadly-accepted, successful static typing system Clojure would be amazing. As it is, I think it's pretty decent if you like Ruby or Python and want more power. At this point I'm wondering if Go is the way.

View on HN

You can integrate another JVM language like Kotlin into your Clojure project in places where you have measured that static typing would help.

Snarky response, but semi-serious too: I've measured my own productivity and software performance and have determined that static typing helps everywhere. I've yet to measure and find any places that dynamic typing would help.

(I say this as someone who has already spent the considerable time needed to understand static typing. For newer programmers or someone who doesn't program enough to make the investment worth it, I totally see the value proposition of dynamic types.)

> static typing helps everywhere

I think "Structure and Interpretation of Classical Mechanics" is a good example of the kind of software a dynamically-typed Lisp is superior at, beyond the usual suspects like SQL, R, Python, etc.

Here's an example of SICM in Clojure: https://github.com/mentat-collective/emmy

Go here to give it a try: https://nextjournal.com/try/samritchie/sicmutils

And here's a conference talk about it's implementation: https://www.youtube.com/watch?v=7PoajCqNKpg

---

More broadly, I think Rich Hickey (Clojure creator) makes a reasonable case that for information processing systems in particular, static typing has negative value: https://www.youtube.com/watch?v=2V1FtfBDsLU

That's also been my experience.

In which programming languages did you measure?

How do people measure whether static typing would help or not in any particular section of code?

> How do people measure whether static typing would help or not in any particular section of code?

Whether or not you are getting bug reports in production that static typing would have caught prior to deployment *merely by adding types* to your existing functions/implementations, and where adding trivial-to-write dynamic type checks/assertions is too onerous.

Dynamic type assertions are nice because they progressively insert static typing (they are caught by unit test == compile time) into dynamic languages, without having the full overhead of a static type checker. As a bonus, the technique can be used for assertions that are still research areas for static typing.

Separately, there are a lot of way language-supported static typing can help by completing changing the nature of the solution to a problem—see Haskell for what that looks like.

In my experience though, if I'm going to go through the trouble of adopting static typing everywhere, I just bite the bullet and go to full model checking with something like Alloy or TLA+. Different developers have different experiences, it's very dependent on the kind of code you write.

Reply on news.ycombinator.com