HLS/Visual Studio Code -- what's so great about it?

Learn
#1

I see on this thread “HLS … a delightful editor experience”, “HLS is a real success story”.

I’ve been through the docos for HLS on github; I’ve looked for intro videos on youtube; I see only a handful of q’s on StackOverflow.

Is it HLS inside Visual Studio Code that @rae is using for those Tweag videos? Like Wordle #2 Setting up a Haskell project ? [**] I’d describe that series of videos as ‘telling’ rather than informative – as in telling me what a [expletive deleted] awful developer experience Richard’s toolset is giving, full of messages popping up all over the place, making suggestions half of which are wrong [ :woozy_face:], failing to make the suggestions that would be useful, fighting Cabal hell-with-bells-on. It seems to be a mess of unnecessary complexity.

I don’t get why anybody wants to work like that. Is there a video or doco that would encourage me to use this stuff? Don’t suggest something from a ‘brogrammer’ who starts with “'s’up guys”; don’t suggest something from a YouTuber with poor English who’s churning out stuff for the advertising revenue. (I do appreciate social media is difficult for those with English not as a first language; but if I’m trying to understand complex material, I don’t want an extra layer of complexity to understand an accent or strange grammar.) And is it too much to ask I should be able to read the screen? – If the screen content is what the presenter wants me to look at. Black mode might be all very well for moles in broom cupboards. My programming environment isn’t that.

[**] I hasten to say Richard’s videos before the Wordle excursion did give valuable insights in a kind of ‘Random Notes from a Compiler-Writer’s Diary’. (For those, I listened to the explanations/didn’t bother to try reading the screen.) I see also on that thread Richard is having to prune his time engaged with Haskell – then could I suggest don’t do any more Wordle videos. I’ve persevered with them up to a point, but so far I’ve abandoned every one at barely half way through, because the developer environment is so counter-productive to whatever programming point Richard is trying to make. (If Richard can hear somebody yelling at the screen, that’s me.)

[ :woozy_face:] I understand better now why AllowAmbiguousTypes is causing so many questions on StackOverflow: GHC suggests to switch it on; VSCode makes it just too brainless to apply; newbie confusion ensues.

#2

Not Visual Studio but rather Visual Studio Code. Microsoft has two different software products with (perhaps confusingly) similar names.

2 Likes
#3

(Thanks, I editted the q to correct that. Yes it is confusing: VS also includes a text editor that is source language-aware, and supports plug-ins.)

#4

The main reasons to use HLS for me are (1) errors and warnings are shown directly in the editor itself and (2) getting type information of identifiers and holes from inside the editor. Both of these save me time having to go outside the editor to the command line, running the compiler manually, and linking the results back to locations in the editor.

Arguably (1) could be done in a much simpler way by just parsing the error messages that the compiler produces, but (2) does really require tight integration with the compiler.

Then there are niceties that HLS provides like formatting, linting, managing imports, wingman, and automatic fixes for some errors and warnings (which sometimes do work).

6 Likes
#5

I don’t think the wordle videos are using HLS.

The reason I like HLS so much is that it just gives an IDE experience that at least I didn’t know how to get with Haskell before.

Say I want to write a new function foo. I might write a definition for foo, and then HLS will automatically suggest a type and actually add it to the code. If foo had e.g. an undefined somewhere in it, I can mouse over that to see its inferred type. Then I search that type in hoogle (no need to go to a browser, it’s integrated in vscode) and find that e.g. sortOn is the function I want. I then substitute undefined for sortOn but now a red underline appears and when I mouseover, it says that this function isn’t in scope. I hit ctrl . , and vscode automatically imports sortOn from Data.List.

If I do a case statement, wingman automatically completes it for me. If I have an hlint issue, like writing fmap a . fmap b instead of fmap (a . b), vscode corrects it for me. If I have unused variables, vscode tells me. If my type requires a language extension like RankNTypes, vscode tells me. These suggestions are really helpful for learning more about the type system.

If a type signature needs a constraint that it doesn’t have like Ord e => ..., vscode can automatically add it. When I need to refactor my code, and imports change, vscode makes that easy too. It also runs ghcid in the background, so the moment I change my code to introduce a type error, I know. No more cycles from recompiling, fixing and recompiling again.

But mostly, it’s super easy to set up, and so makes Haskell accessible to beginners.

Some problems I have with it (that I should probably post as issues):

  • crashes more than it should
  • imports of pattern synonyms and a few other things are broken
  • sometimes suggests importing a function from the same file, creating a circular import
1 Like
#6

Thanks but hmm? In the videos, something is compiling the source and popping up suggested missing extensions; clicking on the -XWhatever in the error message adds it into the {-# LANGUAGE #-} pragma.

I have a usual set of extensions that I paste in to the top of a source before writing any code. If GHC goes suggesting further extensions that’s a ‘wot?’ moment: probably I’ve miscoded. I certainly don’t want GHC brainlessly switching on module-wide extensions that will thereby fail to point out other miscodings.

Say I want to write a new function foo: the first thing I do is write its type decl. (Unless it’s a small helper function inside a where decl, then I probably don’t want the clutter of a type signature.)

There’s perhaps a difference in programming approach coming out here: @rae seems to be ‘Extreme programming’ in the sense of throwing randomish ideas at the compiler, and seeing what compiles and runs a test. If it doesn’t work, throw some other randomish code, fix the type errors, rinse, repeat. It’s like a video game.

The later Wordle videos then run into some serious design issues of not coping with repeated letters in the words. (That ‘thinkware’ was missing from video #1 discussing an algorithm.) I would have anticipated more of the design/‘business requirements’ before sharpening my coding pencil – including deciding the main functions, and their types.

I’d also plan which packages I’m importing, and find those on Hoogle – not that it’s hard to keep a browser tab open on Hoogle.

Is it? So easy that nobody’s bothered to post a step-by-step video? I think you mean super-easy for somebody who’s already using VS Code?

VIdeo #2 seems to be mostly battling Cabal and versioning. Is there some way beginners could sidestep that until they’re more confident in their Haskell coding, and can focus on wider-scale project set-up?

Most of the StackOverflow q’s seem to be bugs in HLS (and you mention some possible bugs/crashes). I’m worried at the number of times in the Videos Richard blames something on a bug – either in HLS (if it’s that) or in GHC. It seems a lot like a bad worker blaming their tools. Is that a good intro for beginners? If a newbie is shaky on their understanding of types, won’t the HLS experience only exaggerate their nervous cluelessness?

#7

“I have a usual set of extensions that I paste in to the top of a source before writing any code. If GHC goes suggesting further extensions that’s a ‘wot?’ moment: probably I’ve miscoded. I certainly don’t want GHC brainlessly switching on module-wide extensions that will thereby fail to point out other miscodings.”

I should clarify that whenever I say that HLS “automatically” does something in the above, I mean: if you hit ctrl ., it gives you a list of options like import Foo or add this extension or disable this warning. It doesn’t just do things without you asking. So for example, if I write some code that needs DeriveGeneric, the offending code will be underlined in red and if I hit ctrl ., it will say (paraphrasing): it seems like you might want to be using DeriveGeneric, do you? And you can select that option and it will add it to the file header.

I also don’t generally write code without type signatures, but actually sometimes it is pretty handy for it to be automatically (again, at a click) produced, especially when the type signature is complex enough that I can’t work it out off the top of my head.

I don’t think this really has anything to do with throwing random ideas at the compiler - it’s just super convenient to have your editor provide smart language aware suggestions to fix problems in your code.

Re difficult of usage, I’d say I’m really bad at setting up software (I struggle with even basic stuff), and I found it easy. VSCode is, for me at least, self explanatory to use, and you just download HLS in the extensions manager and it works out of the box.

Now there are caveats: as you note, it’s buggier than I’d like, for example, and a really clear walkthrough on how to set it up would only help, I agree. (Maybe I’ll try to make a document like that). But I think it’s good to focus on the positives, because for me at least, it represents a sea change in my productivity when coding in Haskell.

But I should say, I totally agree that HLS should have a link to a very foolproof step by step walkthrough of how to set it up on an example project, linked at the top of its documentation. I would definitely like that.

3 Likes
#8

I have a usual set of extensions that I paste in to the top of a source before writing any code.

If you are adding to most industrial code bases this seems like it wouldn’t work since you would have useless extensions. Actually even for your workflow - HLS automatically removes redundant pragmas - which seems useful when understanding the code imo.

I certainly don’t want GHC brainlessly switching on module-wide extensions that will thereby fail to point out other miscodings.

Why would it do that? You have to add the extension yourself - you just don’t have to go through the work of going to the top of the file, finding the right place to add the extension, typing the pragma and returning to where you were… It’s hard to say that this workflow is anything but better…

Say I want to write a new function foo : the first thing I do is write its type decl.

If you do that then Wingman can help you in the implementation of said function by, for example, automatically completing case statements to be total.

Is it? So easy that nobody’s bothered to post a step-by-step video? I think you mean super-easy for somebody who’s already using VS Code?

Yes for someone using VSC, it’s as simple as installing the Haskell extension - that really is it for most use cases. No one has made a video because the video would install the Haskell extension and Haskell isn’t big enough for the newbie-dev targeted start a project videos.

It seems a lot like a bad worker blaming their tools.

Well Richard is often banging against the edges of GHC, and so will run into more bugs than 99% of Haskellers both in GHC and HLS. I have not experienced an HLS issue in weeks now, whereas I used to run into them hourly. At this point, the HLS experience is imo comparable to my IntelliJ Java IDE without the helpful metaprogramming commands.

If a newbie is shaky on their understanding of types, won’t the HLS experience only exaggerate their nervous cluelessness?

I get what you’re saying but it seems you’re presupposing that no-type-info doesn’t have costs for a newbie. Being overwhelmed with info is costly sure, but getting high latency feedback could be arguably worse (I would probably agree you but with almost no conviction). Nowadays it is quite common for newbies to learn with an IDE. There’s tradeoffs.

Overall - I recommend trying it out. You’re not really going to find many people (maybe none) giving you what you’re looking for - someone showing you why IDEs are great in a way that appeals to your requirements (namely good English, not a brogrammer, not in black mode which is more common than white bg, not making the video just for money, you probably prefer Haskell also). Almost everyone I know buys into IDEs nowadays - anyone I’v enecountered who doesn’t use an IDE is in the “I know its better but old dogs” camp. Installing HLS is pip-squeak and most coding in 2022 is done with an IDE. You could maybe find someone explaining IDEs such here.

Have you tried HLS? It’s one thing to watch one person using HLS, especially when that person is Richard, who is certainly in the fat part of the programmer normal curve as a researcher; it’s another to try it out and see if it helps your workflow.

6 Likes
#9

@AntC2, I can’t help thinking that the answer to your question is most easily determined by just trying it yourself. The VS Code installation process is simple on most platforms. Then you install the Haskell extension through the VS Code plugin menu.

Is the issue that you are baffled that other people have different preferences to you? Well, I’m afraid they do. There’s no accounting for taste.

Or are you genuinely trying to understand the mind of another and what they find valuable? If so that is a worthy goal but, if I might be so bold, I recommend a less adversarial and aggressive tone. The forum participants seem to be a patient bunch but I’m increasingly sceptical that their patience will last given that many of your interactions on this forum come across as you picking fault with the work of others.

16 Likes
#10

Wordle #7 video is up. In the first minute, @rae is confirming some of the guesses above:

  • Yes he’s using HLS inside VS Code; except
  • maybe not for all of the series; because
  • VS Code for Mac installs the wrong version of HLS; so
  • some of what Richard struggled with in earlier videos was bugs/version mis-match in HLS.
  • (If even Richard didn’t realise all that at first, is it really safe to put a newbie into such an environment?)

Addit: (I should have watched more of the video before posting the above.) At 4:00 “Oh I thought I’d fixed that.”. Sorry Richard, there’s just too many of your distractions getting in the way of me learning anything. I’m giving up (again).

HLS doesn’t/soon won’t support GHC before v 8.10. “(HLS) is highly tied to the ghc api. This imposes a high maintenance cost:” – which I quite understand. I much prefer GHC v7.10, because it’s a smaller language.

Yes, in particular what work practices VS Code/LSP is expecting – I suspect most of my q’s relate to the Protocol rather than Haskell specifically. But I didn’t figure that out until asking here. So thank you for everyone’s answers.

I think for me there’s a prior question: if I install VS Code then don’t like it, will it have wrapped its tentacles so tight round all my projects I won’t be able to rid myself of it? That’s happened with every Microsoft and Google product I’ve tried. In the end a couple of years ago I wiped my machine and re-installed from the Operating System upwards.

Work in whatever colourway you like, yes black mode is what I see in most programming shops. Richard is presenting for educational purposes, then the first requirement is for your viewership to be able to view. I notice, for example, Graham Hutton’s (excellent) FP series are in whitescreen.

#11

then the first requirement is for your viewership to be able to view.

On that axis - using the most common color (black mode) would be the obvious first choice…

2 Likes
#12

Not other “preferences” exactly and not other coding approaches exactly: I am baffled that Richard has waded into coding; and we’ve got to episode #7; and he still hasn’t analysed the problem domain (even though he identified the occurrence of repeated letters as a surprise a couple of episodes ago, and that only more-or-less by accident). I can’t help but feel that playing the VS Code ‘video game’ with all its unnecessary complexity and ease of running tests is exhibiting what a wise-head told me early in my career: “running fast is not the same as getting somewhere”.

I am reminded of a project I was brought in to rescue. It was an (allegedly) simple interface between two business systems with a kind of request-response workflow between the two owning organisations. The team had already coded a prototype to get the go-ahead; they’d estimated 6 weeks to complete; I was called in after 5 months. They were working to a two-week release cycle. Since they claimed to be ‘nearly done’ I observed and probed the bugfix process while a couple more release cycles went by. Still just as many bugs, different ones.

I pulled the whole coding team away from their manic obsession with tweaking code; put them in a room with a whiteboard; and a key user from the requesting organisation; and a key user from the responding organisation. Turned out the organisations’ workflows were completely different. The human responders knew it was no good reacting immediately to requests: the originating system would send follow-up information on a later message (possibly intermingled with a fresh but related request). Likewise when the human requester received a response, they knew there was probably more to come.

So the ‘bugs’ were merely timing mis-matches; and reacting instantaneously/manically to a mis-match just created another mis-match going the other direction. (This hadn’t come to light in the prototype, because the team had been modelling the opening of a request, not the 17-responses deep workflow.) So we had to layer a whole message-pending-status over the data model. (Something of a kludge but we’d run out of time/budget to do it properly.)

Wordle is a request-response workflow. The content of the response tunes the next request. There might be repeated letters in the request (guess) or response (target) or both. Analysing the problem domain (as in playing the game/observing its scoring) before starting coding would have identified that. Or … after encountering surprises, trying a few probes for those scenarios. But no, Richard “prefers” to just throw more code at it.

Then I’m sorry I’m appearing to criticise Richard ad hominem – that wasn’t my intent when I started this thread. I’ve observed many similar malaises in coding projects. (But then, like a Doctor, I only get called in when the patient is already sick.) I daresay many projects go smoothly despite :wink: using VS Code or IDE’s.

won’t fix the coder’s misunderstanding of the problem domain. I’m all for technology (IDE’s) smoothing over the pernickety bureaucracy of versioning/compiling/testing. What seems to be happening is the technology helps you run so fast, you don’t have time to see you’re going in the wrong direction.

#13

The point about analysing the domain thoroughly before coding is well taken. But in my opinion that’s a somewhat orthogonal concern to whether IDEs are good. For example, I’m working on a complex project where I mostly want to think hard and not code, as you say. But when I do want to do a big refactor, my experience is that it’s much quicker to do it with an IDE. Like an order of magnitude. And being able to mouseover and see types, which sounds like a small thing, is really helpful for me when I’m e.g. writing a complicated recursion scheme.

if I install VS Code then don’t like it, will it have wrapped its tentacles so tight round all my projects I won’t be able to rid myself of it?

I also worried about this, but I don’t think it’s the case. VSCode is really just a plaintext editor, with highlighting and suggestions. If I wanted to stop using it today, there would be no problem (except that I’d be sad). It’s hard to see what tentacles there are there.

Anyway, I think it’s a best of both worlds situation, but I understand your concern: you’re worried that using IDEs encourages a bad style of coding. I’m not sure that’s true. Smart suggestions won’t fix a coder’s misunderstanding of a problem domain, as you say, but it’s still very useful for other reasons.

2 Likes
#14

I see two mostly unrelated threads here: one about IDEs and HLS in particular, and another about my videos. I’ll address them separately.

Why I like HLS

Coding with HLS working is simply easier than it is without. Specifically, most of my actual coding is in GHC, a large codebase.

With HLS working (and some editor configuration in VS Code), I can press Ctrl+D to jump from an occurrence of an identifier to its definition. Without HLS, I had to grep for the identifier; either I manually wrote, say, :: at the end of the grep query (which didn’t always work) or I had to visually scan the results looking for the line that defines the identifier in question. It’s harder for types: do I write data Foo or type Foo (and enjoy the fact that type is a suffix of newtype)? HLS means I don’t have to worry about this.

I can press Ctrl+R to get a set of all references to a particular identifier. This also works with grep, but now I can distinguish between types and terms, something that was previously impossible – very annoying when there is a pun involved!

When I’m in a complicated function, I can point to a variable and see its inferred type – helpful when I’m trying to figure out what to type next.

When I type an identifier that’s not in scope – but it’s defined somewhere in my project – HLS allows me, with a click, to add a new import. I don’t have to scroll up to the top of the file.

When I use a language feature I have not enabled, HLS allows me, with a click, to add a new language extension. Again, no need to scroll up.

It has other features beyond this, but these are the ones I regularly use. I haven’t yet gotten to the point where I regularly use HLS to, say, fill out case expressions for me (though I do this when programming in Agda), but this may change.

All of these are simply conveniences. I can program fine without HLS. But using HLS saves me time, keystrokes, and (small) context switches.

There are two notable caveats here:

  • HLS has quite a few bugs still. On newer (M1) Macs, the VS Code extension installs the wrong version of HLS, and this was hard for me to discover. And in all circumstances, I’ve found HLS to be rather flakier than I’d like. I’ve reported some bugs, and I know the HLS team is striving to make improvements. I find these bugs frustrating – precisely because HLS is so useful when it’s actually working. (If HLS didn’t help me, I would just turn it off and be happy!)
  • HLS sometimes gets in my way when making videos. In particular, I like to point at identifiers with my mouse cursor, and HLS will sometimes produce e.g. a type signature when I don’t want one. These perhaps clutter my videos. But this has never happened against my will when actually programming.

My environment is strange in a number of ways. And so I don’t know whether my experience says anything at all about whether HLS would work for a newbie.

My videos

If you think it would be a productive use of your time, @AntC, start a thread critiquing my videos. I don’t think the critique really fits here. I’ll just make a few points here:

  • The videos are not intended for newbies – and especially not for people new to programming in general. I’d say the intended audience is the intermediate Haskeller, but one weakness of the whole video series is that there is not a stable intended audience. If I had more time to devote to this, I would have a larger plan, but I don’t have that time.
  • The Wordle series is turning out to be much longer than I had intended. I’m hoping one more video will wrap up basic implementation, and then we can get to optimization and (maybe) some type-level shenanigans.
  • The mistake around multiple letters was genuine – and it occurred after a decent amount of off-camera forethought. I had thought that four yellows was equivalent to one green, but this is false. But I don’t actually mind having made the mistake: we all make mistakes, and I think it’s instructive in the videos to see how property-based testing finds the mistake so easily. Maybe others don’t make such mistakes and I am a bad programmer – you can decide that for yourself.
  • This series is intended to show live programming, with mistakes and backtracking. It is not meant to be a curated learning experience – which would indeed be tighter. Despite these videos being much longer than my usual fare, they actually take me less time to produce, because there is no prep. If you find the real-life, dirty aspects unappealing, there is no need to watch them.
17 Likes
#15

I thought the property test finding that bug was pretty cool.

Also, I saw the issue on HLS + GHC in which you participated but it seemed to lead nowhere. How did you get HLS working for GHC? Do the default settings work out of the box for you in VSCode? that could be a reason for me to move there when working on GHC (or find a different lsp client… or evil emacs … aha)

#16

I agree that critiques of your video series itself is nominally outside of the scope of this thread, so what I’m about to say is probably just adding more noise, but since it is being brought up I wanted to express my appreciation for the series.

There are so many people who post on here, Reddit, and elsewhere who have finished a book on Haskell and want to take the next step to completing a project but don’t know where to start. I believe that live programming videos like your series are one of the most valuable resources available to people in those positions, and I think the community needs a lot more of them in general. There have been many threads pointing out that we have an abundance of introduction-to-functional-programming type material, and an abundance of type-level advanced material, but not nearly enough of production related material. Live programming sessions where a project is taken from start to finish in an organic setting and includes things like testing, managing the file structure, Hoogle searching and using Hackage, etc. is, I think, one of the best ways that the lack of material can be addressed. Overtly scripted and prepared versions of live programming aren’t as useful because they don’t show the usual pitfalls that come with the territory or the thinking out loud. Watching someone realize what they need, Hoogle for it, and then use it is much more instructive for intermediate language users than the video author having already found it beforehand and just using it. And I believe firmly as well that making mistakes and including them is important and part of the process, because like you said, mistakes will always happen. I would hope that everyone would agree that showing honest mistakes to an intermediate level language user when they happen, catching them, explaining the issue, and showing the fix, is good for their overall learning experience. It’s also a very coarse situation for the video author because they open themselves up to criticism and having tens if not more people repeating to them over and over again that they made a mistake, so I understand why many people wouldn’t want to subject themselves to it.

So I just wanted to say that I really like the video series. I hate Wordle itself, I have the word muted on Twitter and have taken many steps to avoid it, but I’m still watching your videos because I find the educational value exponentially larger than my annoyance with the topic.

Something that has been inexpressibly useful to me that I learned from the videos is that you can just restart HLS from the command palette. HLS does not like literate Haskell files and will often get stuck in a loop and become unresponsive when editing in one (at least for me, but I’ve had it happen across Windows, Mac, and Linux. I doubt there are enough people out there using HLS with literate Haskell for it to be a much noticed issue.), and I’ve spent more time than I care to admit restarting VS Code to get HLS to restart. ctrl+shift+p then enter is a lot faster hahah.

9 Likes
#17

HLS sometimes gets in my way when making videos. In particular, I like to point at identifiers with my mouse cursor, and HLS will sometimes produce e.g. a type signature when I don’t want one.

It seems that VSCode allows you to disable automatic hover. Also, hover tooltips can be manually triggered using Ctrl+K then Ctrl+I—although in my case I remapped editor.action.showHover to Ctrl-Q.

(Edit: oh, I think I misread. Richard wasn’t really talking about automatic hover. Oh well.)

Besides the conveniences of HLS that have already been mentioned, I find “Show Call Hierachy” tremendously useful for exploring big codebases. One of the features I missed most from Java IDEs like Eclipse or IntelliJ.

#18

Thank you Richard, I appreciate (and certainly didn’t expect) such a comprehensive reply. Yes, this thread rather wandered from toolset to work-practices using that toolset to work-practices in general. I’ll try to stick to comments re the toolset; I know work-practices are very much a question of personal taste.

Why [Richard] likes HLS

In my editor (NotePad++), I double-click on the name; it highlights all the occurrences. (If the code is punning on it, that must be for some reason. I rather prefer seeing both types and expressions – which are distinguishable by syntactic context.)

And yet I noticed (in the Wordle videos) you quite often needed to scroll to the top of the file. (Sometimes because GHC doesn’t always recognise when the problem is a missing extension.) Not wanting to scroll up is a reasonable ‘business requirement’. I tackle it like this/can VS Code?:

  • Split the editting window with a horizontal separator, so you get two scrollable panels/views into the source.
  • Keep a small upper one positioned at the head of the file/ LANGUAGE, import.
  • Then you can keep position at your editting ‘hot spot’ as well as tinkering with imports.
  • Or keep in view both a decl site and a usage.

(Split view is a very old idea in editors: I was using it with character-mode terminals on IBM System/38 and Honeywell DPS/7. NotePad++ also offers side-by-side split view so you can see more context/at cost of probably needing to scroll each right-left. OTOH I see the VS Code window already has too many sub-panels – which I find distracting – perhaps there ain’t room for more.)

“with a click” “saves me … keystrokes” seems to me a gimmick (what’s wrong with a couple of clicks and bit of typing?), and reinforces the ‘video game’/manic panic look and feel. Also supporting it needs too many buttons/toolbars festooning the viewing space. Isn’t most time in coding actually reading and thinking rather than churning out text?

Yes this might explain a lot; and from what I’ve seen of the code inside GHC it looks a very stylised form of code, not much like the ‘recreational’ Haskell I write.

Are you saying you often need to adjust LANGUAGE and import in the GHC codebase? You might need to in ‘thrown-together’ code for an ad-hoc experiment (perhaps the Wordle excursion is that), but for an established codebase, or before starting coding for a large-scale codebase, wouldn’t you nut that all out in advance?

Oops but now I’m straying into work-practices.

#19

I agree, @AntC, that there are other ways of accomplishing the goals HLS accomplishes for me. I have been programming GHC for over 10 years now. I like doing it with HLS more than without. I have offered my reasons why – and I don’t think I need to defend my personal preferences. So I won’t.

12 Likes
#20

I find this thread fascinating and I have free time so I’ll comment.

First thank you @rae - great videos with Wordle. I only watch the advanced stuff regarding Haskell’s heavier features and compiler implementation etc, but those videos fill a gaping hole :slight_smile: . Imo, it would be worth it for HF to hire an editor for <10k a year to make your videos great, not just good. Having figures that can be made into role models (which I think you can fill) is one of the critical steps to success for a community. The impact that Simon and yourself have on the community has without doubt contributed to my interest in Haskell and my future contributions would not likely exist without them. Imo, your influence is more important than your code at this point - I, for example, was recently comforted on your context surrounding the HF departure, or your proposals for GHC. In my opinion - keep leading, and code when you can (I still want Dependent Haskell :wink: )

Regarding @AntC2…

I truly don’t understand what you want from this thread. Multiple hours of time have been spent on this thread that you could have just tried out HLS for yourself. You make comments like:

And yet I noticed (in the Wordle videos) you quite often needed to scroll to the top of the file.

in response to someone saying something they like - imports. Anyone would admit that it’s not perfect - they’re saying they like it and it’s an improvement for them. If someone tells you something positive, but you then ask for clarification because it doesn’t appear that way to you, I can understand apprehension. But given that at least 3 people have told you they like this feature, and you haven’t tried HLS… perhaps you need to, you know, try HLS? You could watch someone take acid for hours and doubt their experience - but you’ll never understand it without trying. Experience is complex and incommunicable - if you don’t trust others vouches (either the person or the specific vouch) don’t go around asking someone to convince you. I can’t insert the feeling of using HLS into your brain - I can only tell you the things I like, and HLS is pretty much universally loved (like I know a bunch of Haskellers offline and everyone loves it).

“with a click” “saves me … keystrokes” seems to me a gimmick (what’s wrong with a couple of clicks and bit of typing?)

It’s comments like these. I could say “a 2 hour commute, what’s wrong with some driving”… Many of us code for a day job (perhaps you do). Inefficiencies that happen during the primary thing we do are frustrating (that is why many of us, likely including you, like Haskell). If you don’t see value to more productive coding - why are you asking whether VS Code + HLS is more productive? The process of communicating with the computer is a key part of productivity, this is what an IDE helps.

Then you spend 154 words and three paragraphs “And yet I noticed (in the Wordle videos) … perhaps there ain’t room for more.)” asking whether you can have multiple panels. I really can’t interpret this charitably. I search “vs code multiple panels” and get visual studio code - VSCode: Multiple horizontal and vertical panels - Stack Overflow as the first result. If your goal is to have fun and socialize here - please take a more jovial tone. The way your writing reads is hostile and confrontational (this is not the first time that I have seen this said about your writing so you’ve heard it before). If you just want to chat - this community will take you up for fun, but you’re writing doesn’t communicate that at all - it often looks like you’re invalidating others reasonable experiences and opinions (see @rae: “I don’t think I need to defend my personal preferences” and my remarks). Also I recommend Discord - it may be that you can engage more actively there in a more social way - I expect this forum will largely give you information and discussion rather than the social aspects of Haskell’s community.

If you would like to elaborate on why your tone comes across that way - I would be happy to give feedback on it. I expect you mean well and just want to have a good Monday night. We do too. I would be happy to help you share good Monday nights with us in the future. I’m also happy for you to point out how my writing reads if you’d like to do so - I have found myself miscommunicating in the past as well…

6 Likes