Amen, I've spent the last 3 years of my career working on an increasingly complicated Perl project and frankly, I've had enough. My pet projects now are all Haskell and I can't believe how fun it is.

I spend most of my time these days fixing bugs and regressions due to the sheer scale of the project, and I'm a running meme at work for saying "a type checker could have caught that!". I can't imagine going back to a dynamic language now.

Are you having fun because you switched to a statically typed language or are you having fun because you switched to a functional language? Would you be having less fun had you chosen Clojure?

I started a parallel implementation of a bunch of machine learning algorithms in Clojure and Scala. I figured the Clojure version would pull out ahead thanks to my previous lisp experience and lisp's history in that domain.

I was very surprised to discover that my Scala code was a lot easier to understand and maintain and had fewer bugs.

What do you attribute this to? The static typing of Scala or the libraries that you use?

Definitely typing. I wasn't using any libraries.

You know, I'm probably having fun because of both. I love the type system Haskell gives me for exploring a problem space without diving into a solution. I am enjoying working in a functional language because it forces me to work in really small pieces and slot them together. I try and do this in Perl too, of course, but it can sometimes be easier to just cargo cult some things and forget to come back to them.

I think what I enjoy most is the type system though, and the ability to make massive refactorings until stuff compiles. 9 times out of 10, things just work after that.

Seems to me that that's what static typing proponents have been saying for years (if not decades), and it still isn't true.

That said, I'm currently hacking on a compiler to see if I can come up with a design for a static language that's almost as pleasant to use as a dynamic one, so I'm not completely hopeless. But it certainly seems like the data point that until now no such superior type system (strict but flexible) has become widely popular should not be underestimated.

That's because it takes years or even decades to really get this right, like a lot of other sophisticated technology. Look how long it took to get the JVM to where it us today. This is fundamental research and hard stuff.

What you are looking at are not two variables (strict, flexible), but also "ease of use". Arguably dependent-typed languages are most strict, but also most flexible: you can write type of a function that only accepts primes on input. They are hard to use though. Dynamically-typed languages are flexible and easy to use, but not strict. Java-likes are strict and easy to use, but they're very unflexible.

So we're talking about type inference - which way are you going?

What dynamic language were you using and which language are you using now?

I pretty much lived in Rails from 2004-2011 but did a lot of Python and Perl before that.

These days it's mostly C++/Obj-C but I'm keeping an eye on Haskell for iOS.

> I'm keeping an eye on Haskell for iOS.

Really? Is that even possible? Can't imagine Apple being okay with that.

They've significantly relaxed their restrictions on iOS languages. It's not any weirder than running C# binaries via Mono.

Apple's fine with such things… provided you don't let arbitrary code run in your system. If all your VM/runtime runs is what is in the application, it's fine.

Sure, GHC is on ARM now.

I haven't heard of anybody suggest that static languages should allow lists to contain arbitrary types. Hmm, do tuples cover all the use cases for that feature?

If you want a list of heterogenous "things" you either a list of "I don't care about what's on list" and then it should work without much in languages like Haskell, ML and the rest or you actually have list of things with a common property, such as "I want to be able to turn these things into strings and sum them" or "These are either numbers or strings" -- all functional languages work well with the latter through ADTs and the first one can be solved easily in Haskell with existential types (I don't know about other languages)

>type systems that are both usefully strict but also flexible.

that's basically the design criteria behind Go's type system.

I think Go's type system is decades behind the state of the art. I can't believe they repeated the mistake of Boolean Blindness [1]. Sum types and pattern-matching are crucial for useful strictness with flexibility. This results in funny things like encoding the optional error result in Go as a type product rather than a sum, allowing reading of a result even if it does not exist due to an error.

[1]: http://existentialtype.wordpress.com/2011/03/15/boolean-blin...

No, did you read that article?

My problem with Go is that it does not have sum-types and pattern-matching. This means that branching (conditionals) in Go do not gain any type-information. And that means that programmers have to manually keep track of the invariants that hold true in each of their conditionals, and if they get them wrong, they get no help from the compiler.