-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a "Start Coding" section. #207
Comments
For reference, a couple of related issues: |
So, Is haskell.org willing to review such a change if I PR it? (I am not a web developer, so I am only making a draft.) @tomjaguarpaw |
I’d love to see a PR for this. I do expect that it might take a while to land because there will probably be a lot of input from the community, but I do feel like this is really high value. |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi. It isn't a secret that newcommers have problems setting up a Development environment. The reason is that there is no single place within haskell.org,
hls
documentation norghcup
documentation where you can find a minimal, clear and strightforward guide (MCSG from now on).Just to be clear and avoid unproductive discussion. Let me explain what a MCSG is:
vscode
? ok, let me point you to "other editors" link, but such a link shouldn't be part of the guide itself.Some consequences of having a MCSG is that you need to select sensible defaults hence being biased towards tooling. In the Haskell case, the alternative which has proved better consistency is
ghcup
+ghc
+cabal
+hls
+vscode
. This isn't an opinion.hls
is biased towardsvscode
andstack
does not integrate well withhls
unless you configure it properly (usingsystem-ghc
).If we were about to choose other editors or
stack
as default options, then we would need to provide extra configuration instructions for them, hence It wouldn't be minimal. If we were about to let the user decide betweenstack
andcabal
orvim
/emacs
/vscode
then It wouldn't be straightforward. Lastly, if we don't useghcup
it would be clear because downloading each tool manually and configuring each of them to work properly and not break on updates is difficult if you aren't an experienced user.The benefits of having a MCSG are clear. Many developers (In my experience, much more than I would have expect) do not know what a language server is, do not know or care about unix philosophy, do not want to read documentation, do not actually read documentation if they can copy paste a command in the terminal. If these developers come to haskell.org and find different ways of installing haskell, not mention about editors, many different tools, etc... the most probable outcome is "I will just installed pycharm and be happy". Actually, this is what I found helping newcommers (objectively, not a huge sample: a few people over cardano's discord and five co-workers).
In Discourse I posted a link to a github gist having a three step guide which is commited to MCSG as defined here. Whether it should be on
hls
home page or haskell.org is debatable, that's why I am opening this issue. If you consider this belongs tohls
just tell me. In my opinion, haskell.org should provide this information, because is very unlikely that newcommers now what a language server is, hence there is low probability of them searching forhaskell language server
instead of justhaskell
.The guide ifself is only the first markdown header. There are two more sections including
hls
documentationstack
integration, because it is still a widely used tool.by the way,
stack
instructions are a little bit verbose because there is a surprisingly high amount ofstack
user who don't know howstack
works. Every now and then there is a question in SO asking "why stack doesn't build my project"The text was updated successfully, but these errors were encountered: