Hey! Glad you're getting into Haskell. Haskell is definitely not dying, the Haskell Foundation was just created and funded to promote the language in more corporate settings. I've been working in Haskell for 6 years now, and its developed substantially in that time, and the contributors who developed it are still working hard and contributing to the community. It seems like you eventually understood the reason for why stack asks you to place your extra dependencies in the stack.yaml, but to be clear, its because you're extending the resolver (a consistent set of packages fixed in compatible versions) with an extra dependency that is not know to compile with the rest of everything. There are many great projects I've worked on with many package.yamls for different pieces of the project, but one stack.yaml. In this context, the advantage for the separation becomes clear. With respect to the installing external binary dependencies that will be linked into your program, there are packaging systems which abstract that away and are used widely in the Haskell community, Nix being far and away the most popular one. The two other concerns I'll admit I feel a bit similar to you about. Many impressive Haskell projects end up dead because they are the brainchild of only one or a few people and they don't have the type of commercial usage to acquire a life of their own. Most of the commonly used packages are maintained well enough, and are small enough that I could imagine myself and a small team taking on a significant part of the labor, that I feel comfortable depending on them. Many people fork a substantial part of the Haskell ecosystem to do their work, and I dislike this approach, but the fact that it is viable speaks to the simplicity of the language and ecosystem. As for documentation, many of us who write libraries (I maintain a few) find it really fun to write code and play with nice ideas, but maybe find it less fun to exposit our ideas in clear, beginner friendly language. You'll find that many libraries have sufficient, minimal haddocks, but not tutorial level documentation. If people want that sort of documentation, people need to work harder, myself included, to make our documentation better.
Thanks for the explanation (about stack.yaml)... yes, that's what I understood. This behaviour makes sense once I understood why those files are here, but I had to dig deep in stack documentation to understand that.
To me, the issue here is that as a begginer, I must learn how Stack resolves dependencies, and how it is managing multiple packages repositories in order to understand what I should do to install a simple dependency.... that is quite useless, and frankly quite a lot to learn, when just trying to write 30 lines of Haskell in a toy project.
As awsome and sensible as Stack might be, I think it should have a "degraded" behaviour, sensible defaults that do not leak those advanced use cases on simple projects, thus matching other package managers behaviours...
As for the documentation thing, I think that detailed tutorials are a bit overkill, but showing at least a few snippets of the most common or most simple use cases is quite enjoyable to understand what a lib does, and where to start when trying to understand it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hey! Glad you're getting into Haskell. Haskell is definitely not dying, the Haskell Foundation was just created and funded to promote the language in more corporate settings. I've been working in Haskell for 6 years now, and its developed substantially in that time, and the contributors who developed it are still working hard and contributing to the community. It seems like you eventually understood the reason for why stack asks you to place your extra dependencies in the stack.yaml, but to be clear, its because you're extending the resolver (a consistent set of packages fixed in compatible versions) with an extra dependency that is not know to compile with the rest of everything. There are many great projects I've worked on with many package.yamls for different pieces of the project, but one stack.yaml. In this context, the advantage for the separation becomes clear. With respect to the installing external binary dependencies that will be linked into your program, there are packaging systems which abstract that away and are used widely in the Haskell community, Nix being far and away the most popular one. The two other concerns I'll admit I feel a bit similar to you about. Many impressive Haskell projects end up dead because they are the brainchild of only one or a few people and they don't have the type of commercial usage to acquire a life of their own. Most of the commonly used packages are maintained well enough, and are small enough that I could imagine myself and a small team taking on a significant part of the labor, that I feel comfortable depending on them. Many people fork a substantial part of the Haskell ecosystem to do their work, and I dislike this approach, but the fact that it is viable speaks to the simplicity of the language and ecosystem. As for documentation, many of us who write libraries (I maintain a few) find it really fun to write code and play with nice ideas, but maybe find it less fun to exposit our ideas in clear, beginner friendly language. You'll find that many libraries have sufficient, minimal haddocks, but not tutorial level documentation. If people want that sort of documentation, people need to work harder, myself included, to make our documentation better.
FYI there are quite a few more comments on reddit 😊
Thanks for the explanation (about stack.yaml)... yes, that's what I understood. This behaviour makes sense once I understood why those files are here, but I had to dig deep in stack documentation to understand that.
To me, the issue here is that as a begginer, I must learn how Stack resolves dependencies, and how it is managing multiple packages repositories in order to understand what I should do to install a simple dependency.... that is quite useless, and frankly quite a lot to learn, when just trying to write 30 lines of Haskell in a toy project.
As awsome and sensible as Stack might be, I think it should have a "degraded" behaviour, sensible defaults that do not leak those advanced use cases on simple projects, thus matching other package managers behaviours...
As for the documentation thing, I think that detailed tutorials are a bit overkill, but showing at least a few snippets of the most common or most simple use cases is quite enjoyable to understand what a lib does, and where to start when trying to understand it.