Things VsCode Didn’t Tell Me About Programming in F#

Hello dog cat

This took four hours. I’m happy with the time spent. Other developers probably will not be.

I think I’m done with Visual Studio. Vs Code has been around long enough to warrant giving it a shot. .NET Core is getting past its birthing pains (I think). It’s time to to a more full-featured, robust coding and deployment environment, something that will plug in to a possibly more-complex delivery pipeline. So I downloaded the latest VsCode and decided to write “Hello World”.

Four hours. Not the download — I did all the downloading last week while I was doing other stuff. It took four hours after bringing up the IDE to get the 4-line app to work. Since people who use stuff a lot rarely are able to realize what it’s like for newcomers, here are the things I realized in those four hours:

Getting a ton of silly plugins before I started probably saved me the most time in the end. Other developers are fretted also, so they write plugins. I went looking for cool plugins and just downloaded a bunch, inadvertently solving a bunch of usability problems I didn’t know I had.

My A-team plugin list? Bookmarks; Bootstrap 4; Color Picker, Copy Markdown as HTML, Copy relative path (This was what I needed!), Color Syntax, Debugger for Chrome, ESlint, Git Project Manager, Git Lens, highlight matching tag, Ionide with FAKE, fsharp, paket (You can’t do any F# without this); markdown lint; open in GitHub; Paste JSON as code; Path intellisense; prettier; sftp; settings sync; trailing spaces; and vscode icons.

Since I’m a noob to VsCode, I have no idea whether any of these are good or not. But I’m finding that when I need one, I really need it.

The old VS build system has been torn apart and exposed as JSON files. Awesome if you know JSON and build systems. Probably really sucky if you’re new to programming.

I didn’t believe it. I finally made a new project and saw that I was supposed to start tweaking JSON files? Seriously? It didn’t make sense. When you make a new project using an IDE, well, it should just work. You should push a button and it does something. That’s the entire point of an IDE. What the hell kind of program acts like it’s accomplishing your goal but only goes half-way and then bails out, expecting you to finish stuff up? It took me a bit for this to really sink in. It just didn’t jive with any other IDE I’d worked with. Creating a project/solution doesn’t necessarily mean you can run or debug it yet. Surprise!

tasks.json and launch.json are your new best friends. Want to build stuff, copy files around, pick your nose? You need to add stuff to tasks.json. What goes in there? Beats me. I imagine a future where developers keep special versions of these files, with things in them they’ve tweaked over the years. That’s really cool — but it’s also completely different from the old VS days. I finally found an online resource for tasks, but it looks like just the tooltips you get hovering over stuff. Still, it’s useful to see it all in one place.

My first Vs Code task.

launch.json controls all of the other, well, launch stuff. You know, the targets in VS: debug, build type, and so on. I guess it does more. Beats me. I got it working, so I’m happy. The docs look good, so there’s that.

Click order matters. If you’re a coder, you know this pain. User clicks through the app one way, all is happiness. Click using a different order? Much pain. But it’s not clear to the user why it would make any difference one way or another what the order of the clicks were. You do that enough and people will hate you.

Click on the debug button? Didn’t debug for me. Go to the “Command Palette” (a nice pickup from ST)? Choose F# debug default project? Debug works fine. This is starting to feel like I have to hold my elbow a certain way to write code. Not the feeling you want. (I guess I need to figure out what’s going on later. It says “The target process exited without raising a CoreCLR started event” — although the F# menu item seems to find the signal just fine. Hmmm.)

Where you are in the tree navigator on the left is important for many things. Editing a source file? Sometimes you can do stuff, sometimes you can’t. It’s both related to the file and where you are in the navigator over on the left. I was used to universal shortcuts. That’s weird.

It’s all command-line stuff thinly-wrapped in an IDE. This was amazing to me. I love it. But it was a good two hours before I actually grokked that I’m just using json to run command line stuff. That’s it. This more than anything else was my turning point between flailing and feeling like I was getting a little bit of traction. If I know the general theory of what the UI and architecture are trying to do, I can guess missing missing pieces, figure out how it should work.

Help is consistently crap. I wanted to start with a simple console app because that’s how I like starting with a new tool. I found two or three examples online of F# console apps in Vs Code. All of them had you create a dll, then create an exe, then join them up, then configure debugging, then…

What? Why do I need a dll? Is that a new change related to .NET Core? Can I only attach to things with dlls? In a new environment, people don’t know. It’s not that they just don’t know about your app. After enough frustration, they start questioning everything. I got it working without the dll, so I know you can do it, but I had to figure it out on my own. A basic console app that you struggle with? There wasn’t even one of those YouTube videos out there on it. It’s an odd welcome to a new environment that’s supposed to be productivity-enhancing.

Many things are lazy load. This has been needed for a long time. Way cool. But be aware — if you have a spotty or slow internet connection, you could be stuck needing to code and not being able to. Get everything you need when your connection is good.


Want help? Here’s a nice picture for you.

I’m sure a lot of this looks trivial, even pedantic to people who use Vs Code all of the time. That’s because you guys have already gone through all the suffering. After a little while it’ll seem moronic to me also. That was why it was important to capture my impressions as I fired it up the first time and tried to get something useful done with it. Like a good New Year’s party, I won’t remember any of this in a week. (grin)

I really, really like Vs Code. I like the look-and-feel, I like the overall architecture, I like the responsiveness. It’s about time VS was retired, and this looks awesome. I’m looking forward to a lot of fun with it in the future. Yay!

Having said that, there are a lot of odd gaps. It looks a bit incestuous, where cool developers write tools for other cool developers, meeting each other at conferences and telling one another how awesome they are. If F# is going to grow, and I want it to, I’m not sure this is the right tool to convince the vast numbers of un-cool developers that it’s time to make the switch. Don’t get me wrong: I don’t think this has anything to do with the coders involved. This a program management issue. It’s the work where you take a market on one side and a large-scale effort on the other and match them up so everybody is happy and the right stuff gets done. Just guessing, looks to me like they’re missing some people, a business vision, and some work needs to be done on things like on-boarding and UX. That stuff is important — and it just isn’t here. It’s an architecture astronaut wonderland, though. I’m sure all the guys who live and breathe coding are enjoying the heck out of it.

Heck, I love it so far. I’m going to use it. I just can’t figure out where it belongs in my toolkit of introducing new stuff to developers, and that makes me sad.

Follow the author on Twitter

August 25, 2018

7 responses to Things VsCode Didn’t Tell Me About Programming in F#

  1. John said:

    VS Code is _not_ an IDE. It’s a highly extensible text editor. (Like Atom or Sublime or Vim or Emacs)

    If you want it to do more than edit text then prepare yourself for some toolsmithing.

  2. thelazydogsback said:

    I don’t think VS is going to be retired – they are largely for different audiences.

    VSCode (being an essentially a JS Electron app) is written both in and primarily for front-end development technologies. You’re still going to do your heavily multi-threaded/tasked, cloud and enterprise integrated, containerized, heap/perf checked, etc., back-end heavy-lifting in VS, prob. w/Resharper.

    I agree that configuration and painful and brittle in these environments – this is inherited from the web dev culture of wanting everything to be zero-cost and infinitely tweakable.

  3. thelazydogsback said:

    I don’t think VS is going to be retired – they are largely for different audiences.

    VSCode (being an essentially a JS Electron app) is written both in and primarily for front-end development technologies. You’re still going to do your heavily multi-threaded/tasked/async, heap/perf checked, cloud and enterprise integrated, databased, multi-language/product, etc., back-end heavy-lifting in VS, prob. w/Resharper.

    I agree that configuration and painful and brittle in these environments – this is inherited from the web dev culture of wanting everything to be zero-cost and infinitely tweakable.

  4. James said:

    I realize you’re experienced, so this doesn’t apply to you, but…people pushing VSCode and the F# plugins to newbies are doing them a disservice. Trying to figure out how all this stuff works PLUS write a simple hello world is a nightmare. Tooling in F# is in an awful state right now, turning away anyone interested in dipping their toes into the language.

    • admin said:

      I completely agree, James.

      We have to find some kind of middle ground. We teach language basics, we demo simple projects in complex environments — and then we expect junior developers to figure out how to get from point A to point B. And if they make it? Then they’d better hope nothing goes wrong. It must feel like standing on a tower of cards. Any little thing could send you crashing down.

      • thelazydogsback said:

        Well, if you started with F# 12 years ago as I did (though I only spend a smallish % of my time w/it), I can tell you F# tooling is the best it’s ever been – you’re living in the golden age :)

        You basically have three choices – use a plain text editor (emacs or vim or whatever) and the CLI, use a highly extensible editor/environment like VSCode, or use VS (or one of it’s alternatives such as Rider).

        Remember it’s the nature of F# and the implicit/inferred typing in F#’s Hindley–Milner style type system that you simply aren’t going to get the same type of hand-holding experience as you’re going to get in most other languages where you declare everything up front – though it’s pretty darn good at this point. (Significant whitespace doesn’t help either, which typical parsers you may find in simple 3rd party add-ins don’t handle very well.) Of course, you are free to declare everything, which may help the intellisense experience, but it will be less ideomatic code.

        The VS experience for F# is pretty good, so why not stick with that – should be write code and hit F5 just as you desire.

        • admin said:

          You are definitely correct. It’s a golden age indeed — and for a pretty cool tool.

          I’m looking to upgrade my IDE game. I have been for some time. If you look at VSCode and Ionide as sort of the “emacs” version of Visual Studio, where it’s mostly text-based and there are a lot of pre-done macros for you to use, it rocks. It even offers a lot of extra stuff like language compiler support. Who can live without those dot-lookups that happen? Or the loved and feared squiggly lines?

          But that starts making it feel like it should be a full-fledged IDE competing with VS.

          Full IDE or souped-up text-based project editor?

          It’s a little of both. It’s a little of neither.

          I said I loved it, and I do. Visual Studio needs to either become this or this needs to become VS. Right now, however, it makes me wonder if I wouldn’t be better off taking the huge hit in productivity and just learning Emacs and mastering the lisp underbelly. Hand-rolling projects and deployments shouldn’t be the end of the world for a developer, and my gut tells me that the more everything looks the same – development, testing, deployment, network config, and so on – the easier a lot of other jobs become.

          Meh. Just thinking aloud.

Leave a Reply

Your email address will not be published. Required fields are marked *