> Doing exploratory data analysis in a static, strongly-typed language, for example, is extremely painful. As bullish as I normally am on static typing, I agre

> Doing exploratory data analysis in a static, strongly-typed language, for example, is extremely painful. As bullish as I normally am on static typing, I agree with that wholeheartedly—today. I'm also completely convinced that a language with good enough record row-subtyping will take over as being far better for EDA than any dynamic language within the next 5 years. That's the thing about research in types—it's almost always about discovering new techniques to appropriately structure and represent more complex programming techniques. It can lag for reasons of sophistication, but once it's in place it'll be hard to beat. Already I feel it's absolutely the case that good static types (Haskell I'm most familiar with, but I imagine it's the case with Scala, OCaml, F#) are a win for short, one-off scripts. The difference is that the types you use are looser than the ones you'd use for a super robust application. The typing ends up looking a lot more like the typing you'd implicitly apply to a Python program [0]. So, "use the right tool for the job" applies to typing technology as well. Static types, I believe, will eat the use cases of dynamic types. [0] This is essentially an extension of the "unityped argument". If you program in Haskell in a "always IO, frequently ambiguous" fashion then you can get all the flexibility you're used to in scripting in Python with little overhead.