I think Idris' bang notation for performing effects in a do-block is pretty, it could look like this:
main = do putStrLn ("You said: " ++ !getLine)
Today, you'd have to come up with a new variable name or figure out the right combinator names:
main = do line <- getLine; putStrLn ("You said: " ++ line)
main = putStrLn . ("You said: " ++) =<< getLine
But unfortunately there are more complicated cases:
main = do print (True || !getLine == "foo")
In a strict language with built-in short-circuiting logical operations the getLine would never be performed, but in Haskell || is just a normal function that happens to be lazy in its second argument. The only reasonable way to implement it seems to be to treat every function as if it was strict and always perform the getLine:
main = do line <- getLine; print (True || line == "foo")
Do you think this is confusing? Or is the bang notation useful enough that you can live with these odd cases? I'm not very happy with this naive desugaring.
The changes seem pretty modest as the costs and drawbacks section also says. But I wouldn't know how complicated it is to combine normal constraints with dependent types, let alone linear constraints.
It's great to see windows TUI support so soon after the vty release! Especially since Windows users are not known for their fondness of command lines. I hope this has lowered one barrier to entry to Haskell and will give a more pleasant experience to many Windows users.
It's still going strong. It's a pretty unique language. I use it among many other hobbyists and academics. Some well known companies like GitHub, Meta, and Tesla and of course many smaller companies use it too. Why aren't you using it?
I'm not sure which options you are referring to, I had three options: a JS-style number type (with two suboptions for indexing: throwing errors or rounding), separate types, or a fixed set of classes and instances.
Your first point seems to be against the error throwing approach to array indexing with a JS-style number type. I kind of agree, but then we should also handle out of bounds indexing in a type safe way. I still don't see the problem with rounding to an integer, I think that's also what beginners intuitively expect if they write e.g. xs !! (length xs / 2).
Your second point seems to be against having separate types and separate instructions like + and +.. I think I'd agree that semantically it is not much simpler, but programming is more than just semantics. For example, error messages will be much simpler if there's no Num type class involved (at least the error messages that GHC gives). Perhaps it is possible to develop a better error reporting mechanism for type classes, but that would require more research.
There are so many options to work around type classes. As you say, we could be looser with our types and have one general number type that includes integers and floats. (And I don't even think array indexing is much of a problem, it could just throw an error or automatically round to an integer.)
Another option is to just have separate number types with separate functions for addition and multiplication etc. For example OCaml has + and +..
Perhaps more of a stepping stone towards full type classes would be a limited system where only a few pre-defined classes and instances exist. Then you'll never run into the dreadful could not deduce Num (a -> b) error message, but you can still use a nice overloaded + for both Int and Double.
I'm not suggesting you should never explain type classes. I simply want to avoid having to explain type classes before I can explain how to add two integers. And more importantly, I don't want error messages to mention type classes until they have been understood.
Type classes are a big cause of confusion among newcomers, and even parametric polymorphism.
If you want to see how simple a language can really get you should check out Hedy: https://www.hedycode.com/. It even removes string quotes (let alone variables) at the simplest level. Although it is too imperative for my taste.