Try Elm as a simple example (can be done in a weekend), it'll probably blow your mind. You don't have to write type annotations at all, but the compiler complains at build time if the same function is called with two different types in two places.

I find it kind of weird that we've normalized not being able to read the code outside of the proper program for it. Since those IDEs often cost money it starts to feel a bit like steps towards a walled garden to me, and I'm not sure its good for actual computer science.

Besides, the paper itself should optimise for clarity and global type inference languages allow type annotation where it might help. They simply let you skip type annotations which only add noise.

The reasons are simple: it's promoted by a big company. Same reason why C# and Go are popular.

Won't be back to static typing for a while unless I'll need higher precision and higher reliability module.

The funny .. or sad.. part is that the c#9 explicit ~verbose style would have been the only one accepted before. If you wrote implicitely typed variables people would get angry (I think there are many online articles about how java 9 `var` was bad)

It can be both. Type inference isn't a brand-new idea, but it still takes work to diffuse it into mainstream, practical languages, especially retrofitting it onto existing languages that weren't designed for it. That still counts as innovation in my book.

I still remember how ugly and tedious STL iterators were in C++. Now it’s just “auto”. LINQ also wouldn’t work without type inference.

    main = do
        putStrLn "Who are you?"
        name <- readLn
        putStrLn ("Hello, " ++ name)

Do you need to know how do syntax and the assignment operator <- works? Sure. But that has nothing to do with category theory. That's just syntax.

a. do notation is converted to haskell b. what the bind and return functions do, for IO

So you can figure out;

c. Why your types are not lining up

To understand Haskell in general you need to realise do, bind and return are generic and can be used for not just IO but say for Maybe, List etc.

Basically you need to know most practical things about monads!

I had a bad time writing Haskell do notation until I understood monads. I used to write imperative code, try =, try <-, always undo typing back to known working states etc. to try and magic the code into compiling.

I’m doing a take 2 now of getting into Haskell again but ignoring advanced language features (unless forced on me by a library) and ignoring category theory. The goal this time is using Haskell to just build stuff.