[yummyfajitas]

...what's wrong with Erlang?

Strings:

    1> [98, 114, 111, 107, 101, 110] == "broken".
    true

Records are not real records, just compile time labels placed on top of tuples. The syntax, seriously, three different line terminators?

Python and Haskell both make great go-to languages, and you can solve a wide variety of problems in them. Erlang is the language you suffer with when you truly need massive concurrency and distribution.

[cageface]

Haskell seems to have too many rough edges to make it nice for real-world work. The inconsistent error handling (errors vs maybe vs either), weak record syntax, and ruthlessly strict stance on mutability don't sound like things I want to wrestle with on a large scale.

Scala, on the other hand, seems to strike more reasonable compromises on these points and has all the java stuff to draw on when you need it.

[kwantam]

> inconsistent error handling

I don't understand how offering several choices is synonymous with inconsistent. If you really really want "consistency", establish a policy for your code and stick with it. All three have distinct uses, and each is better for certain things than for others.

Anyhow, there's nothing particularly special about the Maybe or Either monads; you should be able to easily implement either of those yourself, and calling them a feature of the language---beyond the fact that they happen to be in the standard library---is somewhat specious.

[cageface]

Error handling is one thing you want to have handled consistently across all code, including third party libraries. I may be able to enforce a convention in my own code but the typical app uses a dozen or more libraries.

http://stackoverflow.com/questions/3077866/large-scale-desig...

[Robin_Message]

Consistent error handling is needed if you are returning 0 for success and -1 for failure. Or was it 1 for success and 0 for failure? But there's nothing wrong with a type signature that precisely describes what you can get back. Only argument I'd have with Either is it's not obvious which is the error (although left is the convention and baked into the monad), although in practice you'll be returning "Either ParseError ParseTree" which makes it rather obvious. Also, do-notation over the Maybe monad is just perfect for simple error handling, but sometimes you need to return more than None. Happily, you can switch to Either without changing a great deal. But you can't mix them easily, and that is a suckful thing about monads indeed.

[cageface]

So what do I do if I want to write a function that takes another function as a parameter, and some of the possible functions use Maybe and some use Either? What would this code look like?

[yummyfajitas]

f: (a -> m b) -> ... -> m Result

Maybe and Either are both monads and by convention Left errCode is the fail method of the Either monad. This will work exactly as you think it should. It will also work with, e.g., io actions that might fail.

[naradaellis]

If I understand you correctly, such a possibility can never arise in Haskell's type system. A possible function would be (a -> Maybe b) -> a -> b, and this won't accept anything that returns an Either.

[Robin_Message]

Okay, when I first saw that I thought it looked bad, like PHP or something. But then I realised strings are just [char], and that's not so bad. Compiling away the labels sounds like a good optimisation, especially given the wire format and evolvability. Three line terminators? Ugh, but no worse than "public static void".

If Erlang is suffering, why has no-one written a better front end compiler with saner syntax or a static type system?