3 ms·

I worked almost exclusively in Ruby and Python over the last ten years and coming back to static languages after that long was a real eye-opener. A good type sy

I worked almost exclusively in Ruby and Python over the last ten years and coming back to static languages after that long was a real eye-opener. A good type system doesn't just help you catch a certain class of bugs. It completely changes the way you write code. Functions become self-documenting, aggressive refactoring becomes routine, the underlying architecture of your code emerges much more clearly. And you usually get much faster code for free. It's like having a genius savant pair partner. In my experience a good type system doesn't add much friction and the extra documentation you get from specifying types more than pays for itself in the long run.

pjmlp 15y ago
I used to like dynamic languages. Nowadays I will take a static language with automatic type inference over a dynamic language anytime, preferably one that with direct support for FP. The IDE support, code navigation and refactoring, and runtime performance just beat dynamic languages all the time. For the few use cases where dynamic types really make a difference, that can be supported by some kind of variant type or reflection.
- djhworld 15y ago
  Haskell isn't quite there in terms of IDE support (there is "Leksah") but I find myself writing most Haskelly code in emacs/vim with GHCI open in a separate terminal.
  - pjmlp 15y ago
    I just make use of EclipseFP, it is a very comfortable IDE for Haskell. http://eclipsefp.github.com/ http://eclipsefp.github.com/
- sanderjd 15y ago
  I'm at this point right now - what are the best static languages with type inference for the dynamic language crowd? Haskell? Scala? Go? Rust? Something I haven't heard of? All of the above?
dagw 15y ago
Pretty much same experience here. I'm currently working a pretty large and fairly old Python code base. And while I'd still consider python my favorite language, I no longer really feel comfortable recommending it (or any other equally dynamic language) for large, long lived, projects that's worked on by several developers. Sure, all problems can be solved in theory with things like meticulous documentation, rigorous coding standards that everybody follows and lots of detailed tests. But in practice those sort of informal constraints will break down over years as developers of varying skill levels come and go. Better to formally force as much of that as possible with a decent type system.

pjmlp 15y ago

I used to like dynamic languages. Nowadays I will take a static language with automatic type inference over a dynamic language anytime, preferably one that with direct support for FP. The IDE support, code navigation and refactoring, and runtime performance just beat dynamic languages all the time. For the few use cases where dynamic types really make a difference, that can be supported by some kind of variant type or reflection.

djhworld 15y ago
Haskell isn't quite there in terms of IDE support (there is "Leksah") but I find myself writing most Haskelly code in emacs/vim with GHCI open in a separate terminal.
- pjmlp 15y ago
  I just make use of EclipseFP, it is a very comfortable IDE for Haskell. http://eclipsefp.github.com/ http://eclipsefp.github.com/
sanderjd 15y ago
I'm at this point right now - what are the best static languages with type inference for the dynamic language crowd? Haskell? Scala? Go? Rust? Something I haven't heard of? All of the above?

dagw 15y ago

Pretty much same experience here. I'm currently working a pretty large and fairly old Python code base. And while I'd still consider python my favorite language, I no longer really feel comfortable recommending it (or any other equally dynamic language) for large, long lived, projects that's worked on by several developers. Sure, all problems can be solved in theory with things like meticulous documentation, rigorous coding standards that everybody follows and lots of detailed tests. But in practice those sort of informal constraints will break down over years as developers of varying skill levels come and go. Better to formally force as much of that as possible with a decent type system.