-
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
VSCode suggestion in “Get Started” page #250
Comments
TL;DR: read this I also appreciate the new streamlined guide, but got confused by the inclusion of proprietary tools. I wholeheartedly agree with @ffaf1's suggestion. We are lucky enough to have an excellent LSP implementation, so the editor shouldn't make a difference, and we should let the user choose and/or give a recommendation that respects them. Now for the spicy part of my comment... I'm not writing this just because of an abstract FOSS ideology. I think VSCode is actively harmful, more so than typical proprietary editors such as sublime text. VSCode was marketed in a deceiving manner and is designed to subvert. Regarding the first point, VSCode is heavily marketed as "open source" while it's not! In fact, when you look carefully at the website and marketing material, it's always defined as "based/built on open source". By that logic, so are Windows and OSX. Even Wikipedia makes that mistake:
VSCode is the binary. Build from source and you won't get the same functionality. You won't get the extension marketplace. You won't get VSCode! The name of the source repo is, again, deceiving. For an example of proper naming, look at Chromium and Chrome. Please consider whether you want to support this! |
@ffaf1 and @fgaz , this all makes perfect sense to me, but the main reason why I put VSCode as the default is because it is the most used editor/IDE on the market today, actually it is dominating it: https://survey.stackoverflow.co/2022/#section-most-popular-technologies-integrated-development-environment . The goal of get-started page was to be as simple and as practical as possible, with a focus to make it easy for newcomers to Haskell to get started. That means it should be approachable, modern, show that Haskell is up to date, and that it is well supported in the tools they use -> and since newcomers are probably most juniors, VSCode is probably even more represented there. To add to this, the fact is that Haskell has a bit of reputation as academic / old / overly-complicated language. I would really like to paint it more as innovative, at-the-edge, smart but approachable, mind-opening language, that is alive and relevant, and I feel that the not mentioning support for most popular editor but instead for open source alternatives doesn't go in that direction. The thing is, most newcomers will still use vscode, even if we recommend vscodium or smth else, so why not recommend what they use. Maybe it comes down to question what is more important in the get started guide -> promoting open-source as a movement or making Haskell approachable. p.s. I personally use Emacs, I am not advocating VSCode here because of personal affection. |
Like @ffaf1 and @fgaz I am a big proponent of free software. I try to minimise my dependency of proprietary software. I also appreciate the rationale that @Martinsos gave for recommending VS Code. I'm not sure what the correct decision is, but I think the paramount aim should be to make it easy for new Haskellers to get started. |
Yeah, my impressions match @Martinsos: VSCode is currently the "default" choice for people who don't care about their editor, so we're just reflecting the state of things on the ground. It seems like most visitors to the "getting started" page already use an editor so the recommendation does not have a large effect, while recommending VSCodium can look a bit odd or confusing (since people might read that as "normal" VSCode not supporting Haskell). It would be great if some fully FOSS option was the default, but that isn't the case, and my experience has been that recommending a less-mainstream option in an unrelated context—like a programming language page—is ultimately counterproductive. |
Thanks everyone for your feedback. I think my suggestion overshadowed part of what I wanted to say, so let me repeat this question: do we really need to suggest a specific editor? This is at the top of the “Get Started” page:
As a new user I would be resistant to switching editors. The wording is firm and maybe I would come to think point 2. implies that I need to get VSCode to start working with Haskell. Of course:
But it still creates friction in our landing page for some users — if a minority of them. Hence why I think a less assertive and more ecumenic intro:
would cover our bases better, being actionable/useful to many without risking losing anyone on the onboarding track. Does what I say make sense? |
Yes, that makes sense. If we can find some wording that conveniently explains that there are some editors that work well with HLS (is it just Emacs, Vim, VSCode/Codium?) but that VSCode is the most easy to use if you're not already familiar with one, then that would be fine by me. |
Hello. I have just finished reading Get Started. It is an excellent, clear, newcomer-friendly addition to haskell.org. Many thanks @Martinsos for this very useful addition.
One thing that I am not sure about is suggesting VS Code:
ghcup
: not using it and relying on your distribution GHC/cabal will lead to painful experiences in your Haskell learning path. But the editor of choice? I took part in some live “Let’s start with Haskell” workshops, and seldom we had to instruct or help newcomers with editors, they were good on their own.(Compare this situation with Agda one, where — I believe — Emacs and similar editors provide a much more user friendly experience with the language. Haskell toolchain instead works fine with a number of editors.)
Now that I highlighted what I feel the problems are, my proposed solution:
Be less assertive in the introductory section. Instead of
we could write
Select VSCodium as our recommended choice. VSCodium is an open source project that provides freely-licenced, telemetry-free binaries for VS Code.
I would have written a patch myself, but since this change is important I would like to hear feedback from the community.
The text was updated successfully, but these errors were encountered: