2 ms·

I am myself not 100% sold on it, except immediately after any Rich talk (honestly, that man could sell me anything :D), but it was eye opening to me that static

by kaba0 3y ago

I am myself not 100% sold on it, except immediately after any Rich talk (honestly, that man could sell me anything :D), but it was eye opening to me that static typing is not an end goal in itself -- it might be a local optimum, but there are many more things it can't express than it can. Also, in case of Clojure you usually handle FP code with no side effects, written in a REPL-driven, interactive style. This combination is not as prone to typing errors in my opinion than "traditional" dynamic languages like Python and JS. Another aspect might be the one being touched in the 'Maybe Not' talk: Static types operate on a closed-world basis, where the sum of all relevant code is available at the same time. While this is common for certain kinds of programs, it is not really true of systems which have to interoperate with services owned by different companies alltogether, having to support many different versions of other interfaces at the same time. In that case you want to be liberal in what you accept, and arguably, dynamic types are better fit for this job. I am not 100% sold on this part, mostly just reiterating what I've seen others claim, notably Oilshell's author is a big proponent of this thought.

tumdum_ 3y ago
I have the same reactions to his talks. Yet, long term, I've never been able to convince myself that clojure, common lisp or more popular ruby/python, are good choices for me in case of long running projects. I'm not sure how being liberal in what you accept is at odds with static typing. Static typing is about encoding the rules and shapes of the data that your program *knows* how to work on. It's not preventing some other data that you don't care from existing alongside. Even if I'm missing something, that doesn't change the fact that in most static typed languages you can fallback to some sort of "any" types. Seems to me it's better to have option to use static or dynamic types in the same program, instead of being forced to do *everything* in dynamically typed way.
- kaba0 3y ago
  Well, spec is there, so it is not only typed vs untyped but static types vs contracts. With the added ability to generate test data, I think the field is much more equal, but as I said, I also tend to fallback to statically typed languages, but that’s mostly just out of conform.

by kaba0 3y ago

tumdum_ 3y ago

I have the same reactions to his talks. Yet, long term, I've never been able to convince myself that clojure, common lisp or more popular ruby/python, are good choices for me in case of long running projects. I'm not sure how being liberal in what you accept is at odds with static typing. Static typing is about encoding the rules and shapes of the data that your program *knows* how to work on. It's not preventing some other data that you don't care from existing alongside. Even if I'm missing something, that doesn't change the fact that in most static typed languages you can fallback to some sort of "any" types. Seems to me it's better to have option to use static or dynamic types in the same program, instead of being forced to do *everything* in dynamically typed way.

kaba0 3y ago
Well, spec is there, so it is not only typed vs untyped but static types vs contracts. With the added ability to generate test data, I think the field is much more equal, but as I said, I also tend to fallback to statically typed languages, but that’s mostly just out of conform.