6 ms·

Community-led tooling for F# in Visual Studio

90 points by numo16 11y ago

salimmadjd 11y ago
I'm probably the minority here, as I'm a visual thinker. But when I see "Visual" in the headline and click on it. The first thing I want to see is something visual (I understand it's a product name). But on this post, everything above the fold is just text which I don't want to read. I'm actually very curious about F# and anything functional these days, however, aesthetically was turned off for some reason. Show me your best feature upfront and then I'll want to read more. update: Looks like the moderator or the OP changed the headline to something more appropriate. So my comment is less relevant now.
- nightski 11y ago
  They aren't trying to sell you on something. It's a community run project (in fact it is a guest post not even by Microsoft themselves). I don't think there is one magical screenshot that can sum it up. If you take 1s to scroll down you can see screenshots of each individual feature. This is just complaining for complaining's sake.
- cbd1984 11y ago
  So far as I know, nothing under the Microsoft "Visual" brand name has ever supported visual programming as such; it's all always been text-based source and other normal IDE stuff. The most visual part would probably be the drop-down menus you get with tab-completion in the editor.
  - UK-AL 11y ago
    References the visual GUI editors
- tpetricek 11y ago
  This is about community plugin for Visual Studio. You can find more on the project web site: http://fsprojects.github.io/VisualFSharpPowerTools/ http://fsprojects.github.io/VisualFSharpPowerTools/ Not sure this qualifies as visual, but they have lots of pictures of what the plugin can actually do :-). If you want a visual introduction to F#, check out (shameless plug) www.fun3d.net
smithkl42 11y ago
I'm a long-time C# developer, and several years ago tried out F# for a project for which it seemed like a reasonable fit. However, after a month or so, I switched back to C#. I missed the very strong type inference of F# and pattern matching, and C# suddenly seemed very verbose and awkward to me. But C#'s tooling was just head and shoulders ahead of F#, and that made a huge difference in my productivity. But most of what I was complaining about, it looks like the F# community has addressed. I'll be looking for ways to go back and play with it.
- it_learnses 11y ago
  I'm also a long time C# developer and I would love to try out F#. what types of projects is F# really good for? Any cool open source projects that you'd recommend?
  - JackMorgan 11y ago
    Been using C# for a while now for shrinkwrapped winforms database application and web site. We started intermixing F# in the last year. I've found F# to be better than C# in everything except a few fringe cases where libraries have done things specific to C#. For example, F# has a better ORM framework than anything in C# with Type Providers.... unless you need to support two databases in the same dll. Then when trying to use nHibernate, we found that Nhibernate mappings expect virtual properties, which F# didn't easily do. So we have a C# project with a few C# classes used by the ORM, then a conversion layer into F# domain objects, which we would've done anyway, because ORM classes are terrible at expressing the domain compared to F# records and unions. Other than a few weirdnesses like that, we've found it to be great and otherwise a drop in replacement for C#.
    - bargl 11y ago
      Oh man I don't know where you are working but it sounds like you have some really good leads/architects where you are at. I like my current job, a LOT, but it isn't a development shop and they don't want to use F# because they are trying to limit the languages they support right now (Too many legacy apps). Which I understand, but at the same time I think we are really missing out. Especially because they are developing the front end to be a very Functional Typescrip SPA. Anyway I've been learning F# in my spare time just for the heck of it.
lemming 11y ago
It's great that the community is stepping up to provide this functionality, but most of these features are things that I'm very surprised that the default tooling from MS doesn't already provide. No rename at all? No find references? I was led to believe that the VS tooling for F# was actually pretty good but those two are very basic things I expect from an IDE, especially for a static language.
- MichaelGG 11y ago
  MS simply doesn't invest in F# tooling like they do for C#. One reason is probably the user base, but that's a bit of a catch-22. The other likely reason is politics/saving face.
ropman76 11y ago
As a c# dev I started to learn F# on a whim. Now I find myself being sucked down the F# rabbit hole. The pattern matching was mind blowing. To any fellow c# or VB devs learning F# is worth the time invested.
hravnx 11y ago
I really, really like the F# language, but the tooling is so bad (compared to C#) that it's a real struggle to continue to justify using it. I admire the effort put in to F# Power Tools development (I've been using it for a long time and is currently on 2.0), but TBH it's like a slow, buggy implementation of a quarter of the C# tooling. Don't get me wrong, the effort is commendable and I know you're not supposed to criticize OS projects unless you're involved yourself, but from a practical day-to-day point of view, it's not working well. The demos that Tomas Petricek and others in the community do are nice, but in real-world applications of even moderate complexity you almost invariably run into impedance mismatches and annoyances. I'm currently working on a F# backend for a service with a WebAPI 2 front-end. - We had to create a C# glue project to be able to publish it as a web app on Azure. This works, but dependency tracking across language barriers in .Net is flaky, so we have to remember to add all Nuget packages to the glue project manually, or we get run time errors in production (not during compilation or locally in test, but in production) as the assemblies are not published. - Go to definition does not work across language barriers, even when the projects are in the same solution. So you're in F# code, place the cursor on a data tyope defined in a c# file and press F12 to navigate to the source and you get an F# view of the data structure, instead of going to the source. - The async models are famously different between F# and C#, so you have to marshall back and forth between them, resulting in a lot of `|> Async.StartAsTask` and `Async.AwaitTask` in the F# code, and don't get me started on how to convert an f# async computation to a .Net Task in C#. Pretty, it aint. - While you can easily create WepAPI controllers in F#, there are basic things that you just can not do. One that bit me recently: having optional query string parameters. Super easy in C#, impossible in F#. Ended up writing a C# controller just for the endpoints that require this, so now I have controllers in the same API surface written in two languages. Neither of these things are the end of the world, but they do add up, so for me personally it is not a given that I will use F# for my next project.
- Hakeashar 11y ago
  Yup, it's a bit unfortunate, but that's how it is most of the time. I found myself using F# for core libraries with clearly defined boundaries between APIs and assemblies - IMO that's where the language shines right now. You can have your core logic contained in a library with a separate, C#-compatible API. Using F# for WPF, ASP.NET MVC or ASP.NET WebAPI development wasn't quite as stellar experience, also because of the state of the tooling. I'm even wary about type providers, when they work - it's great, when they don't - you're pretty much screwed with no real recourse. In case of relational DB access, most .NET libraries (both full-ORMs and micro-ORMs) are C#-oriented. Therefore, after including all the annoyances you listed, it's hard to justify anything more than 'handle core libraries in F# with C#-compatible API, do the rest in C# - it's good enough' to the business...

90 points by numo16 11y ago

I'm probably the minority here, as I'm a visual thinker. But when I see "Visual" in the headline and click on it. The first thing I want to see is something visual (I understand it's a product name). But on this post, everything above the fold is just text which I don't want to read. I'm actually very curious about F# and anything functional these days, however, aesthetically was turned off for some reason. Show me your best feature upfront and then I'll want to read more. update: Looks like the moderator or the OP changed the headline to something more appropriate. So my comment is less relevant now.

nightski 11y ago
They aren't trying to sell you on something. It's a community run project (in fact it is a guest post not even by Microsoft themselves). I don't think there is one magical screenshot that can sum it up. If you take 1s to scroll down you can see screenshots of each individual feature. This is just complaining for complaining's sake.
cbd1984 11y ago
So far as I know, nothing under the Microsoft "Visual" brand name has ever supported visual programming as such; it's all always been text-based source and other normal IDE stuff. The most visual part would probably be the drop-down menus you get with tab-completion in the editor.
- UK-AL 11y ago
  References the visual GUI editors
tpetricek 11y ago
This is about community plugin for Visual Studio. You can find more on the project web site: http://fsprojects.github.io/VisualFSharpPowerTools/ http://fsprojects.github.io/VisualFSharpPowerTools/ Not sure this qualifies as visual, but they have lots of pictures of what the plugin can actually do :-). If you want a visual introduction to F#, check out (shameless plug) www.fun3d.net

smithkl42 11y ago

I'm a long-time C# developer, and several years ago tried out F# for a project for which it seemed like a reasonable fit. However, after a month or so, I switched back to C#. I missed the very strong type inference of F# and pattern matching, and C# suddenly seemed very verbose and awkward to me. But C#'s tooling was just head and shoulders ahead of F#, and that made a huge difference in my productivity. But most of what I was complaining about, it looks like the F# community has addressed. I'll be looking for ways to go back and play with it.

it_learnses 11y ago
I'm also a long time C# developer and I would love to try out F#. what types of projects is F# really good for? Any cool open source projects that you'd recommend?
- JackMorgan 11y ago
  Been using C# for a while now for shrinkwrapped winforms database application and web site. We started intermixing F# in the last year. I've found F# to be better than C# in everything except a few fringe cases where libraries have done things specific to C#. For example, F# has a better ORM framework than anything in C# with Type Providers.... unless you need to support two databases in the same dll. Then when trying to use nHibernate, we found that Nhibernate mappings expect virtual properties, which F# didn't easily do. So we have a C# project with a few C# classes used by the ORM, then a conversion layer into F# domain objects, which we would've done anyway, because ORM classes are terrible at expressing the domain compared to F# records and unions. Other than a few weirdnesses like that, we've found it to be great and otherwise a drop in replacement for C#.
  - bargl 11y ago
    Oh man I don't know where you are working but it sounds like you have some really good leads/architects where you are at. I like my current job, a LOT, but it isn't a development shop and they don't want to use F# because they are trying to limit the languages they support right now (Too many legacy apps). Which I understand, but at the same time I think we are really missing out. Especially because they are developing the front end to be a very Functional Typescrip SPA. Anyway I've been learning F# in my spare time just for the heck of it.

lemming 11y ago

It's great that the community is stepping up to provide this functionality, but most of these features are things that I'm very surprised that the default tooling from MS doesn't already provide. No rename at all? No find references? I was led to believe that the VS tooling for F# was actually pretty good but those two are very basic things I expect from an IDE, especially for a static language.

MichaelGG 11y ago
MS simply doesn't invest in F# tooling like they do for C#. One reason is probably the user base, but that's a bit of a catch-22. The other likely reason is politics/saving face.

ropman76 11y ago

As a c# dev I started to learn F# on a whim. Now I find myself being sucked down the F# rabbit hole. The pattern matching was mind blowing. To any fellow c# or VB devs learning F# is worth the time invested.

hravnx 11y ago

I really, really like the F# language, but the tooling is so bad (compared to C#) that it's a real struggle to continue to justify using it. I admire the effort put in to F# Power Tools development (I've been using it for a long time and is currently on 2.0), but TBH it's like a slow, buggy implementation of a quarter of the C# tooling. Don't get me wrong, the effort is commendable and I know you're not supposed to criticize OS projects unless you're involved yourself, but from a practical day-to-day point of view, it's not working well. The demos that Tomas Petricek and others in the community do are nice, but in real-world applications of even moderate complexity you almost invariably run into impedance mismatches and annoyances. I'm currently working on a F# backend for a service with a WebAPI 2 front-end. - We had to create a C# glue project to be able to publish it as a web app on Azure. This works, but dependency tracking across language barriers in .Net is flaky, so we have to remember to add all Nuget packages to the glue project manually, or we get run time errors in production (not during compilation or locally in test, but in production) as the assemblies are not published. - Go to definition does not work across language barriers, even when the projects are in the same solution. So you're in F# code, place the cursor on a data tyope defined in a c# file and press F12 to navigate to the source and you get an F# view of the data structure, instead of going to the source. - The async models are famously different between F# and C#, so you have to marshall back and forth between them, resulting in a lot of `|> Async.StartAsTask` and `Async.AwaitTask` in the F# code, and don't get me started on how to convert an f# async computation to a .Net Task in C#. Pretty, it aint. - While you can easily create WepAPI controllers in F#, there are basic things that you just can not do. One that bit me recently: having optional query string parameters. Super easy in C#, impossible in F#. Ended up writing a C# controller just for the endpoints that require this, so now I have controllers in the same API surface written in two languages. Neither of these things are the end of the world, but they do add up, so for me personally it is not a given that I will use F# for my next project.

Hakeashar 11y ago
Yup, it's a bit unfortunate, but that's how it is most of the time. I found myself using F# for core libraries with clearly defined boundaries between APIs and assemblies - IMO that's where the language shines right now. You can have your core logic contained in a library with a separate, C#-compatible API. Using F# for WPF, ASP.NET MVC or ASP.NET WebAPI development wasn't quite as stellar experience, also because of the state of the tooling. I'm even wary about type providers, when they work - it's great, when they don't - you're pretty much screwed with no real recourse. In case of relational DB access, most .NET libraries (both full-ORMs and micro-ORMs) are C#-oriented. Therefore, after including all the annoyances you listed, it's hard to justify anything more than 'handle core libraries in F# with C#-compatible API, do the rest in C# - it's good enough' to the business...