4 ms·

I'm familiar with type theory and (often) a proponent of dynamic typing. It depends on what you're doing. If you're building cathedrals-- high-quality, perform

I'm familiar with type theory and (often) a proponent of dynamic typing. It depends on what you're doing. If you're building cathedrals-- high-quality, performance-critical software that can never fail-- then static typing is a great tool, because it can do things that are very hard to do with unit testing, and you only pay the costs once in compilation. There are plenty of use cases in which I'd want to be using a statically typed language like OCaml (or, possibly, Rust). If you're out in the bazaar-- say, building a web app that will have to contend with constant API changes and shifting needs, or building distributed systems designed to last decades without total failure (that may, like the Ship of Theseus, have all parts replaced) despite constant environmental change-- then dynamic typing often wins. What I like about Clojure is that, being such a powerful language, you can get contracts and types and schemas but aren't bound to them. I like static typing in many ways, but Scala left me asking the question, any time someone insists that static typing is necessary: which static type system?

augustl 13y ago
Interesting insights. Would love to read more aobut this. Usually the arguments are "I'm a bad programmer like everyone else so I need verification" or "the world is dynamic".
- runT1ME 13y ago
  The good arguments for static typing are much different than "I'm a bad programmer". Google "Theorems for free". One of the most life-altering CS papers I've read. :-)
hesselink 13y ago
I've heard this argument a lot, and I disagree. If your software is changing a lot, that is where types really shine. Refactoring is a breeze when you have types: you just change the code you want to improve, and all use sites are pointed to by the compiler. This is taken from daily experience: I work on a code base that is about 25K lines of Haskell and 35K lines of Javascript. Refactoring the Haskell is a pleasure. Refactoring the Javascript is something we dread, and always introduces bugs, some of which might linger for up to a year.
- Glide 13y ago
  I've actually had this experience a couple of times on a project like upgrading a library from one release to another when APIs were updated. The compiler would often "show the way" by highlighting every mistake between version x and y. I would go so far as to say one of the most evil things a person can do when designing an API for statically typed languages is using the equivalent of System.Object unnecessarily.
- tel 13y ago
  I think on top of this the self-documenting properties of a nice statically typed system push back the onset of code ossification quite a lot. I always trust my type documentation while I tend to be a skeptic of documentation that's more than a few months old unless it's being actively refactored regularly.
  - Periodic 13y ago
    A strong type system can give you a lot of "free" documentation and I love it! I long for a search engine like Hoogle in other languages (http://www.haskell.org/hoogle/ http://www.haskell.org/hoogle/). Most functions are very obvious from their signature and name. My favorite example are two functions with the signatures: fun1: a -> a fun2: Int -> Int You might think the first is more powerful because it takes any type and returns that type, but ultimately, that function can only be the identify function (barring unusual things like exceptions, undefined values and runtime introspection). With the second function it could do all sorts of things. It might increment, it might decrement, it might divide by two and round down if the argument is a multiple of three. I'll go further to say that it's very frustrating in languages like C++ and Java to have to deal with statics and objects. They have a lot of hidden state that isn't obvious from the type signature of their methods. Particularly the fact that some methods must be called before others—e.g. initializers—can make the behavior and side-effects non-obvious.
- zenbowman 13y ago
  Exactly. A strong type system enables more rapid iteration than a weak one, just like writing unit tests. I was a fan of dynamic languages until I used Haskell and Scala, and saw how powerful types could be when they allowed you to express intention rather than getting in your way. Now I relegate dynamic languages to writing single file scripts or less.
coolsunglasses 13y ago
Hum, no. I use Clojure at work and the single biggest drain on my productivity is a lack of a sensible, static type system. Yearn for Haskell big time. I'd use Rust if I had to really get down and dirty, otherwise Haskell would be my first choice. OCaml isn't that great at all in practice.
- michaelochurch 13y ago
  Have you looked into Prismatic's Schema? I fully agree that if you're working on a large project, you'll need something that is "type-like" in terms of enforcing interface integrity. Where there's an open question is how necessary compile-time typing is for most problems. (Few would disagree with the claim that types are a good thing.) Clojure (esp. without types) seems to favor smaller projects (libraries over frameworks) and modularity in the extreme, almost implicitly. When you get "into the large" and need checks like types or contracts, there are various libraries that are available. I like Haskell a lot, but my experience going between the dynamic and static styles of programming and languages (these things are as much about coding style as the language itself, which is why Scala can be beautiful or horrid depending on how it is used) is that the grass often seems greener on the other side. Haskell's great in many ways, and designed by some of the most brilliant computer scientists and logicians alive right now, but it's not without some painful warts (although my knowledge is 3-4 years out of date).
  - coolsunglasses 13y ago
    Yeah, it's not interesting. I use Clojure a lot at home and work. I'm an active participant in the community. I've also discussed core.typed with Ambrose to my satisfaction. If you do Clojure web development, there odds aren't terrible you're using a library I've either made or worked on. (Korma, lib-noir, Selmer, luminus, Revise, bulwark, blackwater, trajectile, clj-time, brambling) https://github.com/bitemyapp?tab=repositories https://github.com/bitemyapp?tab=repositories I'm tired of tracking down type errors in Clojure. I'm tired of increased source->sink distances in runtime errors compared to compile-time errors. I want to be able to refactor my code fearless, period, end of story with static assurances. Record (product) types handle statically verifying schematic use of data. I'd rather have that work statically so that I can minimize source->sink distance. That obviates the need for a "schema" library. I'm a very active Clojure user, I end up having to explain the same things over and over as to why I'm moving my stuff over to Haskell. The most thorough way to go is to do what I did and just learn Haskell to decide for yourself. Don't try to paper over the problems with 1/4 solutions.

augustl 13y ago

Interesting insights. Would love to read more aobut this. Usually the arguments are "I'm a bad programmer like everyone else so I need verification" or "the world is dynamic".

runT1ME 13y ago
The good arguments for static typing are much different than "I'm a bad programmer". Google "Theorems for free". One of the most life-altering CS papers I've read. :-)

hesselink 13y ago

I've heard this argument a lot, and I disagree. If your software is changing a lot, that is where types really shine. Refactoring is a breeze when you have types: you just change the code you want to improve, and all use sites are pointed to by the compiler. This is taken from daily experience: I work on a code base that is about 25K lines of Haskell and 35K lines of Javascript. Refactoring the Haskell is a pleasure. Refactoring the Javascript is something we dread, and always introduces bugs, some of which might linger for up to a year.

Glide 13y ago
I've actually had this experience a couple of times on a project like upgrading a library from one release to another when APIs were updated. The compiler would often "show the way" by highlighting every mistake between version x and y. I would go so far as to say one of the most evil things a person can do when designing an API for statically typed languages is using the equivalent of System.Object unnecessarily.
tel 13y ago
I think on top of this the self-documenting properties of a nice statically typed system push back the onset of code ossification quite a lot. I always trust my type documentation while I tend to be a skeptic of documentation that's more than a few months old unless it's being actively refactored regularly.
- Periodic 13y ago
  A strong type system can give you a lot of "free" documentation and I love it! I long for a search engine like Hoogle in other languages (http://www.haskell.org/hoogle/ http://www.haskell.org/hoogle/). Most functions are very obvious from their signature and name. My favorite example are two functions with the signatures: fun1: a -> a fun2: Int -> Int You might think the first is more powerful because it takes any type and returns that type, but ultimately, that function can only be the identify function (barring unusual things like exceptions, undefined values and runtime introspection). With the second function it could do all sorts of things. It might increment, it might decrement, it might divide by two and round down if the argument is a multiple of three. I'll go further to say that it's very frustrating in languages like C++ and Java to have to deal with statics and objects. They have a lot of hidden state that isn't obvious from the type signature of their methods. Particularly the fact that some methods must be called before others—e.g. initializers—can make the behavior and side-effects non-obvious.
zenbowman 13y ago
Exactly. A strong type system enables more rapid iteration than a weak one, just like writing unit tests. I was a fan of dynamic languages until I used Haskell and Scala, and saw how powerful types could be when they allowed you to express intention rather than getting in your way. Now I relegate dynamic languages to writing single file scripts or less.

coolsunglasses 13y ago

Hum, no. I use Clojure at work and the single biggest drain on my productivity is a lack of a sensible, static type system. Yearn for Haskell big time. I'd use Rust if I had to really get down and dirty, otherwise Haskell would be my first choice. OCaml isn't that great at all in practice.

michaelochurch 13y ago
Have you looked into Prismatic's Schema? I fully agree that if you're working on a large project, you'll need something that is "type-like" in terms of enforcing interface integrity. Where there's an open question is how necessary compile-time typing is for most problems. (Few would disagree with the claim that types are a good thing.) Clojure (esp. without types) seems to favor smaller projects (libraries over frameworks) and modularity in the extreme, almost implicitly. When you get "into the large" and need checks like types or contracts, there are various libraries that are available. I like Haskell a lot, but my experience going between the dynamic and static styles of programming and languages (these things are as much about coding style as the language itself, which is why Scala can be beautiful or horrid depending on how it is used) is that the grass often seems greener on the other side. Haskell's great in many ways, and designed by some of the most brilliant computer scientists and logicians alive right now, but it's not without some painful warts (although my knowledge is 3-4 years out of date).
- coolsunglasses 13y ago
  Yeah, it's not interesting. I use Clojure a lot at home and work. I'm an active participant in the community. I've also discussed core.typed with Ambrose to my satisfaction. If you do Clojure web development, there odds aren't terrible you're using a library I've either made or worked on. (Korma, lib-noir, Selmer, luminus, Revise, bulwark, blackwater, trajectile, clj-time, brambling) https://github.com/bitemyapp?tab=repositories https://github.com/bitemyapp?tab=repositories I'm tired of tracking down type errors in Clojure. I'm tired of increased source->sink distances in runtime errors compared to compile-time errors. I want to be able to refactor my code fearless, period, end of story with static assurances. Record (product) types handle statically verifying schematic use of data. I'd rather have that work statically so that I can minimize source->sink distance. That obviates the need for a "schema" library. I'm a very active Clojure user, I end up having to explain the same things over and over as to why I'm moving my stuff over to Haskell. The most thorough way to go is to do what I did and just learn Haskell to decide for yourself. Don't try to paper over the problems with 1/4 solutions.