shoot me an email, which is on my profile. I can help. I honestly was where you were a few years ago, and worked through it.
A few direct observations based upon what you said:
- working with monads takes some practice and understanding. There are several things that need to be learned to work with them, none of which really are directly addressed by educational materials. My advice here is to find someone who is willing to help you work through direct, concrete problems you're having, and/or work though a well-designed resource, such as haskellbook.com. You will still likely need another resource to talk to about issues tho.
- re: entire program understood before writing any code: I am not sure specifically what you mean here, but I think you're talking about how making a change in haskell can necessitate quite a large refactoring, where in another language it might be a trivial change. This is... indeed sad at times, but otoh, this is intractably linked with _other_ notions in haskell: functions should be total, side effects should be isolated, etc. So you _will_ need to do a refactor if you need to introduce side effects to a new part of your program. This is how you get the benefit of having isolated effects.
- re understanding the entire standard library: yeah, this is part of the unfortunate reality. Haskell is an active research language, and that research has borne fruit. So, practices have changed, which means that there is a lot of legacy gotchas around. Not only that, but things that you might do trivially in another language may require using a seemingly esoteric functionality in haskell (traversable imo is the canonical exemplar). Overall this means that learning haskell is a much larger effort than it could otherwise be.
Thus, I think there is certainly room for a haskell successor that addresses these issues, however, this doesn't exist yet, and haskell is still the best option we have at this point.
A few direct observations based upon what you said:
- working with monads takes some practice and understanding. There are several things that need to be learned to work with them, none of which really are directly addressed by educational materials. My advice here is to find someone who is willing to help you work through direct, concrete problems you're having, and/or work though a well-designed resource, such as haskellbook.com. You will still likely need another resource to talk to about issues tho.
- re: entire program understood before writing any code: I am not sure specifically what you mean here, but I think you're talking about how making a change in haskell can necessitate quite a large refactoring, where in another language it might be a trivial change. This is... indeed sad at times, but otoh, this is intractably linked with _other_ notions in haskell: functions should be total, side effects should be isolated, etc. So you _will_ need to do a refactor if you need to introduce side effects to a new part of your program. This is how you get the benefit of having isolated effects.
- re understanding the entire standard library: yeah, this is part of the unfortunate reality. Haskell is an active research language, and that research has borne fruit. So, practices have changed, which means that there is a lot of legacy gotchas around. Not only that, but things that you might do trivially in another language may require using a seemingly esoteric functionality in haskell (traversable imo is the canonical exemplar). Overall this means that learning haskell is a much larger effort than it could otherwise be.
Thus, I think there is certainly room for a haskell successor that addresses these issues, however, this doesn't exist yet, and haskell is still the best option we have at this point.