Skip to content
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

Open
ffaf1 opened this issue Feb 3, 2023 · 6 comments
Open

VSCode suggestion in “Get Started” page #250

ffaf1 opened this issue Feb 3, 2023 · 6 comments

Comments

@ffaf1
Copy link
Contributor

ffaf1 commented Feb 3, 2023

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:

  • VS Code has some weird, proprietary licence (Wikipedia says: MIT, binaries built by Microsoft proprietary). This might steer away people who value open source software, and also means a number of technical problems (it is more difficult to find VS Code in distribution repositories if the user prefers so, thus increasing friction, etc.).
  • Along with that, VS Code collects telemetry data, and as far as I can see this is by default/opt-out. Again something which a sizeable portion of Haskell newcomers might dislike.
  • Taking a step back, do we really need to suggest a specific editor? There is much much value in a tool like 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:

  1. Be less assertive in the introductory section. Instead of

    Use VSCode as the editor, with the Haskell extension installed.

    we could write

    Have an editor ready. Any popular editor (emacs, vim, intellij, VS Code…) will do. Haven’t got one? Pick SuggestedEditor.

  2. 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.

@fgaz
Copy link

fgaz commented Feb 3, 2023

TL;DR: read this

I also appreciate the new streamlined guide, but got confused by the inclusion of proprietary tools.
I think it sets a dangerous precedent. Would we be ok with suggesting a proprietary compiler instead of GHC if it did its job well enough? This was already discussed by the Foundation in the past, with the conclusion that VSCode should not be included as the choice!

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.
For the second point, I recommend reading this article, that explains what is going on better than I could do in this comment.

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:

MIT, binaries built by Microsoft proprietary

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!

@Martinsos
Copy link
Contributor

Martinsos commented Feb 3, 2023

@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.

@tomjaguarpaw
Copy link
Collaborator

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.

@TikhonJelvis
Copy link
Member

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.

@ffaf1
Copy link
Contributor Author

ffaf1 commented Feb 4, 2023

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:

A complete Haskell development environment consists of the Haskell toolchain (compiler, language server, build tool) and an editor with good Haskell support. The quickest way to get this set up is to:

  1. Use GHCup to install and manage the Haskell toolchain.
  2. Use VSCode as the editor, with the Haskell extension installed.

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:

  • the answer to my doubts is one internet search away; and
  • this is not a problem users who already have VSCode as their editor of choice.

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:

A complete Haskell development environment consists of the Haskell toolchain (compiler, language server, build tool) and an editor with good Haskell support. The quickest way to get this set up is to:

  1. Use GHCup to install and manage the Haskell toolchain.
  2. An editor with good Haskell support (Vim, Emacs, VSCode…). Don’t have one? Use ExampleEditor.

would cover our bases better, being actionable/useful to many without risking losing anyone on the onboarding track.
This is regardless of what we will end up putting in for ExampleEditor, even though I partial to FOSS programs.

Does what I say make sense?

@tomjaguarpaw
Copy link
Collaborator

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants