15 ms·

The Problem with F# Evangelism

131 points by asp_net 9y ago

jmull 9y ago
F# isn't generally solving problems... well, it can but rarely at the same level as it introduces problems. People can have awfully cavalier opinions about switching languages, but it's a very heavy-weight change with strong implications for existing code, dev training (new syntax, new patterns, new pitfalls), available frameworks (often resulting in more new patterns), technology stack (which can reverberate out to testing, scalability, etc.) Even if you assume F# is only better than C# and in no way worse, it's usually major investment to switch... typically at least an order of magnitude bigger than that bullet list of ways F# is better than C#.
TensorMetric 9y ago
The real problem with F# is that the .NET Native UWP runtime isn't .NET compliant, therefore doesn't allow F# code. See this link explaining the problem https://news.ycombinator.com/item?id=15026396 https://news.ycombinator.com/item?id=15026396 We wouldn't need to evangelize F#, if it just worked everywhere C# does with proper tooling support.
- toyotaboy 9y ago
  Barely anyone uses UWP. It's irrelevant.
  - TensorMetric 9y ago
    Nonsense, UWP is everywhere https://np.reddit.com/r/fsharp/comments/6tdrwq/after_so_many_years_still_no_net_native_nor/dlp0muc/ https://np.reddit.com/r/fsharp/comments/6tdrwq/after_so_many... https://np.reddit.com/r/fsharp/comments/6tdrwq/after_so_many_years_still_no_net_native_nor/dlpapbk/ https://np.reddit.com/r/fsharp/comments/6tdrwq/after_so_many... https://www.reddit.com/r/programming/comments/6tdqmv/after_so_many_years_still_no_net_native_nor/dlk0rl6/?context=3 https://www.reddit.com/r/programming/comments/6tdqmv/after_s...
  - pjmlp 9y ago
    Except for the people using Windows 10, developing with HoloLens, gaming on XBox ONE (after the latest firmware updates), or using Surface meeting boards.
hprotagonist 9y ago
404
- CodeCube 9y ago
  maybe try again? wfm
brianberns 9y ago
I'm the lone F# developer in a shop full of experienced and talented C# developers. I have clout, but not enough to convince any of them that F# is a better choice for many of our purposes. It's frustrating, but I try to understand that people are just naturally resistant to big changes like this.
- maxxxxx 9y ago
  Same for me. Do you think that in the end F# would be that much better for good C# devs? I am not so sure.
  - lmm 9y ago
    Having made the analogous switch from Java to Scala, I think it's the good devs that benefit the most. Functional languages give you more scope for factoring out commonality, avoiding repetition, reusing existing library functionality - exactly the things that make good devs better than bad devs.
  - brianberns 9y ago
    I do, because many of our requirements are purely functional. E.g. Turn a bunch of database queries into a user-friendly report. They're eager to use the latest enhancements to C# that come from the functional world (e.g. lambdas, await/async), but it's impossible to get them to give up their mutable variables and null pointers.
- toyotaboy 9y ago
  Get them to do a training course like "Fast Track to F#"
  - brianberns 9y ago
    Training isn't the issue. They've rejected F# based on its perceived weaknesses compared to C#.
maxxxxx 9y ago
Good article. F# would find much better adoption if there were more FP style libraries out there. I have tried to move to F# but it's a real uphill battle when pretty much all sample code and most libraries are in C#. I would do it if I was alone but it's hard to convince a team of the benefits.
- 201708throw 9y ago
  The problem is F# does not have a killer feature it has a list of nice features. Examples of killer features: Akka, RoR, browser monopoly.
Joe-Z 9y ago
I'm currently a C# developer, but have tried functional languages before. As mentioned in the article, I think a lot of people are satisfied with the functional capabilities C# already provides. I don't need to write functional code all the time, but if I can model a problem more elegantly using higher-order functions I will gladly do that. I'd be interested to read a more in-depth description of the recent project which the OP chose to implement with F#.
- mariusmg 9y ago
  Only thing is actually missing from C# now to be a "proper" functional language is a way to declare (and pass a function arguments) immutable objects.
sitkack 9y ago
The best way to get someone to tune out when you are trying to convince them to get out their . bubble is to casually introduce words that they don't know. By doing this, you separate yourself from the listener, giving a clear delineation between the noob and the l337 wizard. It also helps to feign surprise, "you dont know about monadic entropy lenses?" or use the word _just_ as in "Just run the parser combinator in reverse, its easy".
- KirinDave 9y ago
  It's unfortunate tho, because for example what word do I have for the generalization that we call "profunctor" other than a profunctor. Even the words we use to describe a profunctor are "contravariant and covariant" and these words OUGHT to be more applicable to programmers but are not. For many programmers, the axioms of what a function are (a calling point to code which is contravariant in a product and covaraint in a single return value), what objects are (a unique closure over functions values with a syntactically supported lookup of named values and a system-provided identity function) are so unvarying in their experience as to be synonymous with the word we use to describe it without needing further quantification. That gets tricky when you want to say, "Ah, but this unique way of thinking about this datatype lets us pretend it's a function and then we need to talk about what it needs and what it provides in more general terms." Since functional programming is actually all about completely tearing down the world to everything but a series of functions, it's unsurprising it needs different words. Finding a way to entice users to join in the functional party is really difficult because asking a programmer to do it is roughly akin to asking them to learn to program again. And don't get me wrong, I think you emerge from the other side of it better and more productive in every way, but it's difficult to prove that and more difficult still to convince people of it.
  - zwieback 9y ago
    Good points but I'm curious: once you "emerge from the other side of it", where are you? In a nuts-and-bolts programming world where you now write better code in a language like C# that has limited functional features or in a more idealistic environment where you write Haskell or OCaml? The latter always seems to be a niche available to few.
KirinDave 9y ago
I think F#'s larger problem is that it doesn't dip into many of the wells that even OCaml (its original inspiration) has dipped into. C# developers are wrong that C#'s functional facilities are just as good, but it's a big struggle to point to a place in F# and say, "THERE! THAT IS THE BEST BIT!" The closest I can get is type providers (which are cool and I wish for them elsewhere) but they're kinda specialist. Ocaml folks have these. Haskell folks have these. Heck, even psuedo-functional languages like Clojure and Scala have these. The other problem is one of tooling (disclaimer, last time I tried this was just over a year ago). F# not only has pretty obscure tooling, but in conventional tooling it introduces a total linear order to your entire source tree, and it's one YOU must maintain with a GUI list. What's more, the F# community is very keen to disseminate the language. I think F# would be more popular if it did more to differentiate itself from imperative programming. There is a longstanding argument that this is "unfriendly to data scientist", but I'm really not convinced by this, as I meet very few mathematicians outside of the stats world who don't on some way, shape or form espouse functional programming.
- Avshalom 9y ago
  Sure but Ocaml and Haskell don't have .Net. F# is .Net for people who feel a bit gross in C#, it's not (specifically) to make people jump ship from the JVM ecosystem.
  - KirinDave 9y ago
    This is very true, and Purescript and Eta are making big strides here precisely because they expose access to NPM and the world of Java, respectively.
    - DeepRote 9y ago
      Neither are making "big strides". They both are barely able to exist. Eta will never even approach Scala in terms of adoption, and I had only heard about Purescript a few weeks ago reading about Elm. Typescript will dominate functional JS-world (already is, tbh) and Scala is still crushing function JVM-world, and if Dotty ever actually materializes, adoption will get even better. Additionally, Scala-Native and ScalaJS are making progress and could eventually be real players. Not likely to take food away from Haskell or Typescript, but they will certainly maintain larger usage than PS or Eta. edit: I'll concede that Clojure matters a bit in JVM-world, but it's dying quickly.
jimbokun 9y ago
Very nice list of very practical problems functional languages like F# are meant to address. After a certain amount of experience, pretty much every OO developer will have experienced these problems, so makes for a good entry point to describe the benefits of a functional language.
DeepRote 9y ago
I've experienced sort of a diagonal problem to this. F# is way too entwined with .NET to be immediately useful to programmers familiar with Ocaml or Scala or Haskell, etc. Some of the basic List., Array. stuff is simple enough, but then you start talking about interfaces and classes and members and all this stuff that doesn't really translate from C#->sanity very well. I know people love it, but I've long considered C#/Java to be kludge languages on platforms they don't deserve. The JVM might be the most impressive software engineering marvel I can think of, and yet on top of that christmas tree stands a tall, stinky shit. I'd love to see F# as a F#-first platform, and offer .NET interop as a secondary language feature. I've also noticed a concerning trend in F# circles that """diversity""" should be celebrated. There is no merit in your skin color or your genitals. If you can hack well, you deserve to do so. End of story. A counterpoint to the F# being poisoned by .NET is Clojure. Look how well Clojure did Java interop and how "not a big deal it is." Immutability everywhere, functional by default, and it feels painful to do things the Java way in Clojure. F# doesn't mind at all if you sink to .NET trickery and in some cases require it. I could think of more, but off the top of my head, the .split instance method comes to mind. I have a Markov Chain kata that I spring on new hires to see how they do things, and .split is an instance method, which is counter-intuitive to how functional problems are solved because you don't just |> into it. I'm waiting to see where Clojure goes with core.type before I abandon F#. I really WANT to keep riding the F# train but it causes quite a few headaches. Not more than it solves, but more than other solutions that I've considered. To balance this out, I'll say something I really love about F#. Units of measure. Few languages have this, and the kind of numerical work we do means we really get our mileage out of UoM. I always see finance horror stories or like the excel rounding bug, it makes me wonder exactly how much money UoM has saved us from losing through some innocent type somewhere. Debugging money code is way easier when you can verify all the conversions separately from the logic. It feels like cheating, to be totally honest. I know there are big shops out there that don't have UoM in their tools, and I used to feel bad for them, but now that we have it, I can't help but NOT feel bad for them. Anyways, yeah, F# isn't perfect. There's plenty to be said also for the amount of progress they make with language updates. It grows a crazy amount between major versions, and I haven't had too much problems yet taking old F#3.0 code and revitalizing it. Very pleasant experience in that regard as well.
- 9y ago
phillipcarter 9y ago
I actually work on F# at Microsoft. I've had success and some failures when it comes to evangelizing F# through Microsoft (but mostly success if my measures are accurate). I strongly believe that it can be boiled down to one major thing: Programmers learn how to program with C-style languages. C, C++, Java, C#, JavaScript, Python (sorta) . . . they're all in the same family. People, especially while learning, associate programming with specific constructs and idioms of C-style languages. It's incredibly difficult to break that barrier. I think that functional programming is on the rise, and that more and more developers are starting to realize that the types of bugs that hold them back can be reduced by using a more powerful language. But it's got a very long way to go, because there is a lot of unlearning to do. The article alludes to this a bit. For example, immutability is one of the key concepts in nearly every FP language. Functional programmers take it for granted, but it's transformational and completely changes the way you have to solve a problem. This hump is often too big for many people to get over, at least in their first trial with a functional programming language. It's hard to solve a task you know how to solve when you now need to re-think your approach because the language doesn't let you change x in-place. Additionally, I believe that many programmers aren't necessarily aware of all of the problems they're having. The next time you hear someone say, "and make sure to check for null here", watch them to see if they're seeing that as a general problem hurting their ability to get bits out the door or not. In my experience, it's not usually viewed that way. Yes, null is a necessary evil in many environments, but it's one that can be tamed, and different languages have already figured out how to do that. But unless it's seen as a problem by people at large, they won't see that as a carrot when you wave things like Optional types in front of them. Overall, I'm still excited. Jet.com is a billion-dollar company that built their stuff with F#. There are similar stories of companies successful with F# (and other functional programming languages), and it feels as though this is happening more often. And as the mainstream (read: C-style languages) adopt more functional programming techniques, I think this will only get better. I think that people will see the value, then see a language which does it better, and give it a try.
- rottyguy 9y ago
  "...realize that the types of bugs that hold them back can be reduced by using a more powerful language." I hear this a lot with FP but would love to see some real world examples of this if anyone has any links.
jasim 9y ago
How can you help someone see the beauty and benefit of Typed FP without asking them to just trust you and spend a few months with it? I used to dismiss this as academic noodling till I got tired of OO and started going back to my procedural roots with just plain functions organized into namespaces. I was pretty happy with it till the codebase grew to a point I couldn't keep track of the flow of data. Objects help you to some extent here since they group related values into one instance, but I didn't want objects anymore. This was when I started seeing references to OCaml, especially "Why ML/OCaml are good for writing compilers" (http://flint.cs.yale.edu/cs421/case-for-ml.html http://flint.cs.yale.edu/cs421/case-for-ml.html), and also saw a presentation by a programmer I respected where he built a general game playing engine in OCaml. Seeing someone use it for practical, advanced programming was the first catalyst. Then Jordan Walke mentioned somewhere that he first prototyped React in OCaml, and shortly after they released ReasonML. The type system was amazing. All values are typed, even complex nested structures have a type. There are variants which mean I can express different shapes of the same value using types, and the compiler will tell me if I ever forget to handle a particular case of this variant. I've been programming with Reason/OCaml for about six months now, and Typed Immutable Programming still takes me more time than just gluing together a pack of cards with imperative code. But once the code is written, it sits on an iron-clad foundation. Most systems as they grow start to fold under its own weight, but here the accretion of code is an almost unmitigated good thing. It means my system's cognitive wealth is increasing without an exponential increase in maintenance cost. But how can you help someone understand all this in a single conversation? A lot of people come to this because they worked on systems with pain points that Typed FP can address. But for most others who haven't had that sort of clarifying experience, what can you tell them to give it the non-trivial amount of effort it requires?
- frou_dh 9y ago
  I'm not in the Typed FP world, but I found the concept of pervasive use of Sum Types making invalid states (according to the project domain) of composite structures _unrepresentable_ to be a pretty compelling nugget to chew on. A lot of debugging is: This <object> has ended up in a weird state. Whereas the alternative could be that if the code compiles then it's impossible for that <thing> to ever be in a weird state.
systems 9y ago
I honestly don't think there much wrong or a problem with F# I do follow F# somehow, and compared to other languages .. it actually seem to have a very pragmatic and active community The F# community build a lot of interesting frameworks, suave, websharper, type providers ... to name a few I dont think, anything will look popular, when compared to Java , C# or Python .. but compare it to Haskell, Ocaml, Clojure.. Dart, D, Nim .. and the plethora of languages that compile to javascript , and you will see F# is not doing so bad
- systems 9y ago
  I will just make one criticism ... it is sadly somewhat awkward to install F# even on windows and they do need a good ide if you go to the F# .org site, installing F# without installing visual studio, is a 4 step process .. and when I tried it on windows 7 it just didnt work for me i eventually gave up and install visual studio on linux, thing seems better, but .. still missing a solid ide
  - talyian 9y ago
    The first class IDE for F# is VS Code + Ionide. The language service backend for F# is also very well supported for emacs.
    - TensorMetric 9y ago
      The first-class IDE for F# is the full Visual Studio, not VS Code + Ionide.
      - toyotaboy 9y ago
        VS Code is now recommended by Microsoft for F# + .NET Core. Get with it, you're behind the times.
        TensorMetric 9y ago
        It's only recommended temporarily, until the issues get ironed out. It doesn't make it THE first-class F# IDE.
nickpeterson 9y ago
This article retreads common complaints about the F# experience for outsiders that I've seen numerous time. I'm going to go a different direction. The problem with the F# community is that they keep asking how to convince C# developers to use F#. I'm convinced that is not the right way to grow the F# ecosystem. Most C# developers tend to come from enterprise and have a set of values and practices that is generally at odds with open-source, functional languages. They are used to producing codebases that can never be open-sourced, using tooling provided by a single vendor. They don't tend to be the ones contributing interesting or new libraries. In fact, this is a large issue with .NET in general. Most strong libraries are spiritual or literal copies of something from the JVM world. This urge hurts in other ways. For instance, Don Syme has indicated he doesn't want to put things like Type Classes or Dependent types into the language because it adds a cognitive load to the language that's hard to balance vs the gains in productivity. But their absence means that many of the dev's you actually want contributing to the ecosystem, just use other languages. They adopt Haskell/Idris/Scala/whatever and start contributing blog posts, tweets, libraries, conference talks, etc. I actually think a large part of this decision is that many of these things would make F# pretty incompatible with C#, which is trumpeted as a feature, but again, it waters down the language to the point that C# dev's look at it and say, "Why bother? It's compatible like VB is, so C# can already accomplish the same things." And in the meantime, it prevents new features that would attract others. What sounds more enticing to developers, "More Functional C#" or "Haskell With Better Tooling"? What's more, there are even examples of how some of these features could be implemented (both Type Classes and Dependent Typing exist in some capacity through feature requests and F*, an experimental Microsoft language). Basically, F# should be more about being different than the rest of .net, than trying to be ".net through an OCaml set of glasses".
- throwaway7645 9y ago
  Yes...F# for a non C# dev is a major pain.
- rubber_duck 9y ago
  I disagree with this, you can sell F# to C# developers - things like type providers for SQL checking their query strings in compile time and no extra build step to produce SQL type definitions vs monstrosities such as Entity Framework... if they've been burned by ORMs to drop to stuff like Dapper they'll love F# type providers. Immutable data is also becoming a common pattern even in C# but it's tedious as hell to write. Functional programming is also seeping in but again tons of boiler plate. Biggest problem with F# is that it has it's own warts + it's a big upfront switching cost and a steep learning curve but it offers many marginal improvements - when you sum those improvements it ends up being worth it IMO but that's a very hard sell.
d--b 9y ago
F# problems from a C# developer point of view: #1 tooling: visual studio integration of F# is poor. You don't get cross language usage reference, so you lose all the benefits of static typic. Projects and references are a mess. Being primarily a scripting language, it feels like a toy language #2 compatibility with C# is poorly done. That F# functions cannot be consumed as C# lambda is a real mess. Boxing / unboxing doesn't feel FP ish at all. You often need to implement classes with interfaces to interact with C#'s core libraries.
- phillipcarter 9y ago
  > #1 tooling: visual studio integration of F# is poor. You don't get cross language usage reference, so you lose all the benefits of static typic. Projects and references are a mess. Being primarily a scripting language, it feels like a toy language Could you clarify what you mean here? Although things like Go to Definition and Find all References don't work across C#/F# boundaries (yet), but you absolutely get IntelliSense and the benefits of static typing. F# isn't a scripting language, although it does support F# scripts.
  - smithkl42 9y ago
    It's the "Go to Definition" and "Find all References" pieces that are so annoying to me, and slow me down tremendously. It means that (practically) you have to do your whole solution in one language for it to feel like a unified solution, and that makes it hard to start by bolting an F# project onto an existing solution.
  - smithkl42 9y ago
    And FWIW, I remember complaining about this to Don Syme something like 5+ years ago, and while he gave lip service to the idea that F# needed better tooling (and better tooling interop with C# specifically), I don't think he was really convinced.
  - d--b 9y ago
    You get intellisense alright. But using C#, I never need to #open the namespaces myself for it to find the types I am using or the extension methods I need. (Maybe this is because I use resharper, but still, it really slows me down). Also the benefits of static typing are that it makes it easy to refactor. Here if I change things in C#, I need to grep my F# scripts for usage, it's a real pain.
zubspace 9y ago
Good post. I really hoped for some f# code after listing all those scenarios where c# fails. Anyway. I work in a c# shop with a large monolithic code base developed by a small team with lots of fluctuations over more than 10 years. I have no functional programming experience at all. I love c# because we actually try to keep the code as simple and linear as possible and only introduce complexity in certain areas if performance requires it. Yes there are hacks and dirty code passages, but if you stick to basic code constructs they are easy to decipher. If your facing more than 10 million lines of code you start to appreciate simple code. Moreover if different developers, which come and go, are working on it. Living without refactoring and inspection capabilities of resharper is nearly unthinkable to me. Now, how would you convince someone like me to try out f#? There are only drawbacks: Obscure things we would need to learn (type classes? monads? xyz?). Probably hard to read, 'clever' code. A mixture of c# and f#. Unknown library, build and deployment issues. And I guess, f# developers are rare around here. Even after reading this post, there's unfortunately no convincing reason for me and management to give f# a try...
- lmm 9y ago
  As someone on the JVM side: I find the biggest advantage of functional programming is being able to replace "magic" - reflection, bytecode manipulation, AOP - with plain old code. If you can get everything you need to get done in plain old C#, you should probably stick with that. But if the most error-prone parts of your program are the cross-cutting concerns and the not-quite-C# you use to handle them - things like error handling, transaction boundaries, audit records, access control, that tend to be done with a "magic" API that doesn't follow the normal rules of the language - then maybe F# could help you by letting you replace those things with normal code. Slightly fiddly code, perhaps, but I'll take fiddly normal code over AOP-style magic any day. Trivial example: what if you could do away with exceptions but still be able to "bubble up" errors in a lightweight way, so that your error handling still wouldn't get in the way of your straight-through business logic code? "Everyone knows" to never use exceptions as control flow, but it happens by accident anyway - have you hit bugs because of that? (I have). If you could avoid having them in the language, wouldn't that make things simpler? You have less need to learn things like monads because they're just plain old library code; if need be you can click through to the function definition, just like any other function you call. That for me is one of the big things FP is about: reduce what's in the core language, push stuff out into libraries instead. There are a few language features to learn, sure, but they're language features you wanted anyway. Type classes are a small feature, and boil down to just a slight bit of extra syntax support for the strategy pattern. (Indeed I find most of the FP features come down to taking classic OO principles - SOLID, composition over inheritance, and the like - and actually following through on them). And maybe as you get comfortable with it you'll be able to turn those 10 million lines into 5 million, or 1 million, or less (and maybe those lines are slightly more complex than the lines they replace, but that's a good tradeoff). Certainly that's what using Scala has felt like for me.
sremani 9y ago
Not pertinent to the article but I guess to the people interested in this discussion. The first in person F# conf in North America (to my knowledge) Open Fsharp Conf. is on Sept 28, 29 in SFO. (http://openfsharp.org/ http://openfsharp.org/). My only association is I bought ticket for it.
pjmlp 9y ago
I lost faith in F# the moment Microsoft decided it is not worthwhile to delay Visual Studio 15.3 to properly support it pushing devs to VSCode, and the lack of roadmap for .NET Native/UWP. So first make F# a first class citzen on .NET and maybe many C# devs will look again to it.
bernadus_edwin 9y ago
F# evangelism should start with small thing. Start as library or component. The main project is still c#. Just like react approach
galkk 9y ago
I think that the problem with F# is that it feels more or less abandoned by MS itself. It's already F# 4.x, but I can't remember any significant new features in last 3 releases at least, neither in language nor in the standard library.
- toyotaboy 9y ago
  That's because F# 1.0 was bascially a more powerful language than C# 10.0 (C# still doesn't have proper pattern matching for example, or discriminated unions) For features added see https://en.wikipedia.org/wiki/F_Sharp_(programming_language) https://en.wikipedia.org/wiki/F_Sharp_(programming_language) Named union type fields Extensions to array slicing Type inference enhancements Printf on unitized values Extension property initializers Non-null provided types Primary constructors as functions Static parameters for provided methods Printf interpolation Extended #if grammar Support for 'fixed' Tailcall attribute Multiple interface instantiations Optional type args Params dictionaries Struct tuples which inter-operate with C# tuples Struct annotations for Records Struct annotations for Single-case Discriminated Unions Underscores in numeric literals Caller info argument attributes Result type and some basic Result functions Mutually referential types and modules within the same file Implicit "Module" syntax on modules with shared name as type Byref returns, supporting consuming C# ref-returning methods Error message improvements
  - toyotaboy 9y ago
    For library, see https://github.com/fsharp/fslang-design/blob/master/FSharp-4.0/ListSeqArrayAdditions.md https://github.com/fsharp/fslang-design/blob/master/FSharp-4...
    - TensorMetric 9y ago
      All those features mean nothing to seasoned .NET developers when you can't use the language natively on Microsofts primary application platform.
      - toyotaboy 9y ago
banashark 9y ago
I usually don't try to sell F# as compared to C# as noted in many other responses here. Since most of my friends work in other languages I usually just use python as my reference. #ME: "Hey that stuff at pycon was pretty cool, huh?" #FRIEND: "Yeah it's interesting the directions they're going with the language." #ME: "Yeah the optional types could help clean up big code bases, and open up the door for quickcheck-like fuzzy testing." #FRIEND: "Yeah." #ME: "And some of the functional programming stuff is pretty neat too, I know it's easier for me to test." #FRIEND: "It's so much easier." #ME: "And the asyncio stuff is gonna be really nice to work with when it catches on more." #FRIEND: "Yeah it seems a lot more ergonomic of a solution." #ME: "And the binary distributable packaging tools look like they might actually work this time." #FRIEND: "Probably not, but we can hope." #ME: "I think I should introduce you to my friend F#." Then just do some stuff in fsx with a type provider or some other neat stuff and at least you've got the message across. People get excited about solutions to their problems. If you start giving them more problems then you're only adding to the constant subconscious cognitive load that they bear in regards to software development. If you show it to them in terms of problems that they already have, you're reducing the cognitive load. Everybody loves having less stress. But this is just how I approach it. F# is like Python4 for me.
- DeepRote 9y ago
  Have you ever looked at Julia? I mention it just because I've had almost a carbon-copy of that conversation but I showed them Julia and now that person actually is writing Julia for their startup. That person is doing technical chemical engineering stuff, so the fit is a bit more pronounced, but I think it's a neat language aside from that. Parametric types and multiple dispatch and lisp-macros, oh boy!
deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
strayamaaate 9y ago
I’m a C# developer, love the language and how easy it is to express what’s in my head as code. I recently had a chance to play with F#. After being completely lost for a bit, I found I had to really rethink how I was reasoning about problems and the right way to solve them. But that’s the point I want to make. I don’t expect to be good at FP for a while - it’s going to take time to grow, along with the tooling and community. But I appreciate having a way of framing a problem differently, and like the direction F# is headed. It doesn’t mean I’m going to drop C# any time soon, I’ll likely just use both - e.g. my more math heavy libraries will be F#, and my networking and Web API code in C#.
MichaelGG 9y ago
Microsoft promoted this idea that F# is for mathematicians and engineers, so its no wonder that people pick this up. And I'm not sure who is pushing this idea that F# is not fine for OO work. It has all those features. So starting with F# as a "better C#" -- there's nothing wrong with that. Over time I think people will come to view OO as suboptimal, but in the mean time F# is just a better language to use than C#. MS hasn't funded F# enough, and has crippled the marketing on it to continue to push C# rather than admit they've made mistakes. The tooling issues and other random incompatibilities are why I don't use it as much as I used to - it's too much friction.
- toyotaboy 9y ago
  No one who knew what they were talking about at Microsoft said F# was for mathematicians and engineers. It's a myth pushed by C# programmers and idiots. It's nonsense and you shouldn't repeat it. People at Microsoft repeatedly said "Simple Code for Simple Problems". C# programmers don't like repeating that.
  - MichaelGG 9y ago
    Doesn't matter if they didn't know what they're talking about, that was what was written on the Microsoft sites when comparing C#, VB, F#. F# was always pigeonholed into scientific and financial categories, never aimed at general code. I'm only repeating it to point out that MS itself did poor marketing for F#, clearly favouring C#.
    - toyotaboy 9y ago
      Microsoft didn't promote that idea. Some random people at Microsoft did, a very long time ago. Just forget about it and move on.
magnumkarter 9y ago
For me, I only got into .NET because of F#, and even then I pretend C# doesn't exist. I tried learning OCaml, it has cool features, like parametric modules and GADTs. But I always ran into the issue of irreproducible builds. This didn't happened in F#. I eventually tried F# because it was close enough to OCaml and while I was learning OCaml I always referred to this site http://fsharpforfunandprofit.com http://fsharpforfunandprofit.com I'm definitely an F# evangelist at work, but we are not a .NET shop. But I was would say that the introduction of ML features in other languages, (Swift, Rust) are good for F# evangelism, because it makes these concepts more familiar. I think the focus should be on moving F# away from .NET because F# itself, it is much more accessible that its cousins OCaml and Haskell. And if Microsoft won't give proper support, the community should move to other platforms. Some discussions are already happening here https://github.com/fsharp/fssf-ask-the-board/issues/4 https://github.com/fsharp/fssf-ask-the-board/issues/4
- pjmlp 9y ago
  The difference being that Apple is quite vocal that Swift is the future of app development on their platforms, while Microsoft is trying to push UWP as the future of Windows apps (supported languages VB, C#, C++ and JavaScript).
  - yawaramin 9y ago
    UWP supports JavaScript? Cool, in that case a bunch of transpilers should work (once bindings are written) ... people can just use their preferred languages: OCaml/BuckleScript, F#/Fable, TypeScript, PureScript, et al. I've actually written and run JScript scripts on Windows Script Host with BuckleScript, it's really nifty. You write strongly-typed code and get a JS artifact that can run on your target platform. For the curious, an example: https://github.com/yawaramin/wsh-bs-test https://github.com/yawaramin/wsh-bs-test
AnimalMuppet 9y ago
I'll go a step further. There's a problem with language evangelism. There is no "one best language" or even "one best programming style". Functional has worked for some people to address the problems they have, but not everyone has those problems. For example: I once worked on a video switcher for TV stations. You have maybe 100 video sources, maybe 80 video destinations, and you can connect any to any. You also have about six different sources of commands to make connections. For responsiveness, each source has its own thread. So the nature of the problem is one giant shared mutable state. The functional people come along, and they say "shared mutable state is evil; don't do that". Yeah, well, that's actually not bad advice, but it doesn't help me at all with this situation, since I can't avoid it here. There are other places where FP isn't the answer: Situations where you care about memory layout (high performance computing or just memory constrained), where one of the main concerns is sequencing (some industrial control operations, maybe robotics), where predictable timing is important (real time systems), maybe others. Use the right tool for the job. FP is not the right tool for every job. Nothing is. The problem with evangelism is when it says "this is the One Right Way", instead of the humbler assertion "in some situations, this can help you with some of the problems that are slowing you down". Don't get me wrong. FP has a good story. (Even if you don't use FP, learn its deepest lesson: Control your state space or die.) But FP is not always the answer. Evangelists might get further if they recognized that.
m_cubed 9y ago
I built Tsunami IDE. It is a F# IDE. I built it before VSCode or VS Community came out. I built it as a test to see if cost of Visual Studio was blocking adoption of F# and the ideas that F# codifies. The experiment was successful, I got my answer, and the answer is no. Even with free tools people have a hard time adopting F#. First let me address those who are asking for Type Classes and Dependent Types. These would make the compiler too slow. The F# compiler works in the 100s of ms and the 100s of MBs ram. Where Scala is in the 1000s of seconds and the GBs of ram. People will give up on code completion if it takes more than 500ms and they generally don't like waiting longer than 200ms. Separately Martin Odersky (the creator of Scala) laments that the more advanced language features attracted the wrong type of people to the language and flooded the internet with overly academic tutorials. I put a lot of the blame for the lack of F# adoption on Microsoft. Part of this is to do with the Dev Div vs Windows war that almost deprecated the whole .Net ecosystem. If Windows 8 wasn't such a disaster it's likely .Net would have been deprecated and would never had been open sourced. (at least something good came from Windows 8). Part of this war also ended with a lot of the best .Net people leaving to go to Facebook. This brain drain has really hurt Microsoft and I doubt they'll ever recover. Most of the old hands that know better are aging out and the new people at Microsoft don't know any better. As for tooling, Microsoft has done and continues to do a bad job with F# tooling. There is is a not invented here culture at Microsoft Redmond which includes being hostile to Microsoft Research. Visual Studio is a bucket of bandaids and it takes an army of people just to keep it going. F# is given a low priority. It's worse with the latest release because they've gone overboard with compiler features with the Rosario release and have made it dog slow and painful to use. I hope they can fix it with updates but who knows. You can still get older versions. It's very possible to build a really good IDE around the F# compiler but unfortunately Microsoft refuses to do so. Thankfully, it looks like there are some good alternatives becoming available. In comparing Scala and F# adoption, Scala has Hadoop/Spark which is a killer product that can earn a consultant a lot of money. The fact that C# is a better language that Java means there are more Java refugees going to Scala than there are C# refugees going to F#. Thankfully Don Syme has made F# completely open source. Now with .Net being open source we no longer have to worry about Microsoft shooting itself in the foot again. I make my money writing a product written in F# and can attest that F# is one of my big competitive advantages. I highly recommend it.
sklivvz1971 9y ago
The problem is that people who are drawn to F# tend to be a certain kind of people: generally stronger in CS, but also more prone to think that changing programming language is a solution to a wide variety of problems. Many people are not like that, and stuff like a small community, worse tools and toolkits and less programmer availability are actually a huge deal, capable of tanking a good project, whereas having a 10% better language isn't a huge gain. It's that simple.
alkonaut 9y ago
Businesses and developers generally won't switch languages. Evangelism makes people curious which means new businesses and new projects some times picks a new language. I'm a C# dev since 14 years (single project) hoping my next project will be an F# one. That might mean I have to switch jobs - and I hope there are enough F# shops when I need one.
tcard 9y ago
A great take on this topic is a talk by Evan Czaplicki, creator of Elm, another functional language: Let's be mainstream! [1] The conclusions are more or less the same than the article, but Evan goes into a lot more depth. And in my opinion, as a result, Elm does very good in this regard. [1] https://www.youtube.com/watch?v=oYk8CKH7OhE https://www.youtube.com/watch?v=oYk8CKH7OhE
nlawalker 9y ago
The problem with F# evangelism is that it doesn't exist. No one is evangelizing F#; everyone is evangelizing functional programming. F# is the Python of .NET - it's multi-paradigmatic and you can do whatever you want. Sell it to people that way, and let them get into functional concepts later, or never. F# has a huge opportunity in the enterprise. A ton of enterprise C# code is not object oriented at all, it's big, poorly thought out clumps of imperative script wrapped in methods and classes so it can be compiled or fit into the framework that's calling it. Sometimes it'll get a quick last pass run on it to make it "more object oriented", because that's what C# code is supposed to be; this usually just makes it worse. It's written in a scripting mindset: the developer needs to get things done, and adds code and bangs on stuff until it compiles and looks right when it runs in the debugger. F# is actually well suited to this style of development, but it's hard to find anything about it, because every F# tutorial, book and blog post is actually about functional concepts, functional design, functional thinking and functional programming, including this one. If you want to sell F# to enterprise developers, show them how they can write their C# code in it without having to pretend that it's object oriented anymore, and how that's a good thing.
- sickbeard 9y ago
  Asking businesses to rewrite apps in a different language is a non-starter. It adds no value. The app is already there, written in c#. Why rewrite it in f#? There has to be some reason to write something in F#, usually the reason is functional programming, which excels in manipulating data. However most programs rarely manipulate data. They show a UI, get some input from a user or server, save, retrieve, re-display in a different form. These kinds of programs work very well when written in imperative languages compared to functional ones.
- pjmlp 9y ago
  > If you want to sell F# to enterprise developers, show them how they can write their C# code in it without having to pretend that it's object oriented anymore, and how that's a good thing. As enterprise consultant, for the types of customer projects I work with, lack of tooling support for Blend, WPF, UWP, EF, ASP.NET is a no-go to move from C# into F#.
macca321 9y ago
We're singing from the same hymn sheet https://github.com/mcintyre321/OneOf https://github.com/mcintyre321/OneOf https://github.com/mcintyre321/ValueOf https://github.com/mcintyre321/ValueOf

131 points by asp_net 9y ago

F# isn't generally solving problems... well, it can but rarely at the same level as it introduces problems. People can have awfully cavalier opinions about switching languages, but it's a very heavy-weight change with strong implications for existing code, dev training (new syntax, new patterns, new pitfalls), available frameworks (often resulting in more new patterns), technology stack (which can reverberate out to testing, scalability, etc.) Even if you assume F# is only better than C# and in no way worse, it's usually major investment to switch... typically at least an order of magnitude bigger than that bullet list of ways F# is better than C#.

TensorMetric 9y ago

The real problem with F# is that the .NET Native UWP runtime isn't .NET compliant, therefore doesn't allow F# code. See this link explaining the problem https://news.ycombinator.com/item?id=15026396 https://news.ycombinator.com/item?id=15026396 We wouldn't need to evangelize F#, if it just worked everywhere C# does with proper tooling support.

toyotaboy 9y ago
Barely anyone uses UWP. It's irrelevant.
- TensorMetric 9y ago
  Nonsense, UWP is everywhere https://np.reddit.com/r/fsharp/comments/6tdrwq/after_so_many_years_still_no_net_native_nor/dlp0muc/ https://np.reddit.com/r/fsharp/comments/6tdrwq/after_so_many... https://np.reddit.com/r/fsharp/comments/6tdrwq/after_so_many_years_still_no_net_native_nor/dlpapbk/ https://np.reddit.com/r/fsharp/comments/6tdrwq/after_so_many... https://www.reddit.com/r/programming/comments/6tdqmv/after_so_many_years_still_no_net_native_nor/dlk0rl6/?context=3 https://www.reddit.com/r/programming/comments/6tdqmv/after_s...
- pjmlp 9y ago
  Except for the people using Windows 10, developing with HoloLens, gaming on XBox ONE (after the latest firmware updates), or using Surface meeting boards.

hprotagonist 9y ago

404

CodeCube 9y ago
maybe try again? wfm

brianberns 9y ago

I'm the lone F# developer in a shop full of experienced and talented C# developers. I have clout, but not enough to convince any of them that F# is a better choice for many of our purposes. It's frustrating, but I try to understand that people are just naturally resistant to big changes like this.

maxxxxx 9y ago
Same for me. Do you think that in the end F# would be that much better for good C# devs? I am not so sure.
- lmm 9y ago
  Having made the analogous switch from Java to Scala, I think it's the good devs that benefit the most. Functional languages give you more scope for factoring out commonality, avoiding repetition, reusing existing library functionality - exactly the things that make good devs better than bad devs.
- brianberns 9y ago
  I do, because many of our requirements are purely functional. E.g. Turn a bunch of database queries into a user-friendly report. They're eager to use the latest enhancements to C# that come from the functional world (e.g. lambdas, await/async), but it's impossible to get them to give up their mutable variables and null pointers.
toyotaboy 9y ago
Get them to do a training course like "Fast Track to F#"
- brianberns 9y ago
  Training isn't the issue. They've rejected F# based on its perceived weaknesses compared to C#.

maxxxxx 9y ago

Good article. F# would find much better adoption if there were more FP style libraries out there. I have tried to move to F# but it's a real uphill battle when pretty much all sample code and most libraries are in C#. I would do it if I was alone but it's hard to convince a team of the benefits.

201708throw 9y ago
The problem is F# does not have a killer feature it has a list of nice features. Examples of killer features: Akka, RoR, browser monopoly.

Joe-Z 9y ago

I'm currently a C# developer, but have tried functional languages before. As mentioned in the article, I think a lot of people are satisfied with the functional capabilities C# already provides. I don't need to write functional code all the time, but if I can model a problem more elegantly using higher-order functions I will gladly do that. I'd be interested to read a more in-depth description of the recent project which the OP chose to implement with F#.

mariusmg 9y ago
Only thing is actually missing from C# now to be a "proper" functional language is a way to declare (and pass a function arguments) immutable objects.

sitkack 9y ago

The best way to get someone to tune out when you are trying to convince them to get out their . bubble is to casually introduce words that they don't know. By doing this, you separate yourself from the listener, giving a clear delineation between the noob and the l337 wizard. It also helps to feign surprise, "you dont know about monadic entropy lenses?" or use the word _just_ as in "Just run the parser combinator in reverse, its easy".

KirinDave 9y ago
It's unfortunate tho, because for example what word do I have for the generalization that we call "profunctor" other than a profunctor. Even the words we use to describe a profunctor are "contravariant and covariant" and these words OUGHT to be more applicable to programmers but are not. For many programmers, the axioms of what a function are (a calling point to code which is contravariant in a product and covaraint in a single return value), what objects are (a unique closure over functions values with a syntactically supported lookup of named values and a system-provided identity function) are so unvarying in their experience as to be synonymous with the word we use to describe it without needing further quantification. That gets tricky when you want to say, "Ah, but this unique way of thinking about this datatype lets us pretend it's a function and then we need to talk about what it needs and what it provides in more general terms." Since functional programming is actually all about completely tearing down the world to everything but a series of functions, it's unsurprising it needs different words. Finding a way to entice users to join in the functional party is really difficult because asking a programmer to do it is roughly akin to asking them to learn to program again. And don't get me wrong, I think you emerge from the other side of it better and more productive in every way, but it's difficult to prove that and more difficult still to convince people of it.
- zwieback 9y ago
  Good points but I'm curious: once you "emerge from the other side of it", where are you? In a nuts-and-bolts programming world where you now write better code in a language like C# that has limited functional features or in a more idealistic environment where you write Haskell or OCaml? The latter always seems to be a niche available to few.

KirinDave 9y ago

I think F#'s larger problem is that it doesn't dip into many of the wells that even OCaml (its original inspiration) has dipped into. C# developers are wrong that C#'s functional facilities are just as good, but it's a big struggle to point to a place in F# and say, "THERE! THAT IS THE BEST BIT!" The closest I can get is type providers (which are cool and I wish for them elsewhere) but they're kinda specialist. Ocaml folks have these. Haskell folks have these. Heck, even psuedo-functional languages like Clojure and Scala have these. The other problem is one of tooling (disclaimer, last time I tried this was just over a year ago). F# not only has pretty obscure tooling, but in conventional tooling it introduces a total linear order to your entire source tree, and it's one YOU must maintain with a GUI list. What's more, the F# community is very keen to disseminate the language. I think F# would be more popular if it did more to differentiate itself from imperative programming. There is a longstanding argument that this is "unfriendly to data scientist", but I'm really not convinced by this, as I meet very few mathematicians outside of the stats world who don't on some way, shape or form espouse functional programming.

Avshalom 9y ago
Sure but Ocaml and Haskell don't have .Net. F# is .Net for people who feel a bit gross in C#, it's not (specifically) to make people jump ship from the JVM ecosystem.
- KirinDave 9y ago
  This is very true, and Purescript and Eta are making big strides here precisely because they expose access to NPM and the world of Java, respectively.
  - DeepRote 9y ago
    Neither are making "big strides". They both are barely able to exist. Eta will never even approach Scala in terms of adoption, and I had only heard about Purescript a few weeks ago reading about Elm. Typescript will dominate functional JS-world (already is, tbh) and Scala is still crushing function JVM-world, and if Dotty ever actually materializes, adoption will get even better. Additionally, Scala-Native and ScalaJS are making progress and could eventually be real players. Not likely to take food away from Haskell or Typescript, but they will certainly maintain larger usage than PS or Eta. edit: I'll concede that Clojure matters a bit in JVM-world, but it's dying quickly.

jimbokun 9y ago

Very nice list of very practical problems functional languages like F# are meant to address. After a certain amount of experience, pretty much every OO developer will have experienced these problems, so makes for a good entry point to describe the benefits of a functional language.

DeepRote 9y ago

I've experienced sort of a diagonal problem to this. F# is way too entwined with .NET to be immediately useful to programmers familiar with Ocaml or Scala or Haskell, etc. Some of the basic List., Array. stuff is simple enough, but then you start talking about interfaces and classes and members and all this stuff that doesn't really translate from C#->sanity very well. I know people love it, but I've long considered C#/Java to be kludge languages on platforms they don't deserve. The JVM might be the most impressive software engineering marvel I can think of, and yet on top of that christmas tree stands a tall, stinky shit. I'd love to see F# as a F#-first platform, and offer .NET interop as a secondary language feature. I've also noticed a concerning trend in F# circles that """diversity""" should be celebrated. There is no merit in your skin color or your genitals. If you can hack well, you deserve to do so. End of story. A counterpoint to the F# being poisoned by .NET is Clojure. Look how well Clojure did Java interop and how "not a big deal it is." Immutability everywhere, functional by default, and it feels painful to do things the Java way in Clojure. F# doesn't mind at all if you sink to .NET trickery and in some cases require it. I could think of more, but off the top of my head, the .split instance method comes to mind. I have a Markov Chain kata that I spring on new hires to see how they do things, and .split is an instance method, which is counter-intuitive to how functional problems are solved because you don't just |> into it. I'm waiting to see where Clojure goes with core.type before I abandon F#. I really WANT to keep riding the F# train but it causes quite a few headaches. Not more than it solves, but more than other solutions that I've considered. To balance this out, I'll say something I really love about F#. Units of measure. Few languages have this, and the kind of numerical work we do means we really get our mileage out of UoM. I always see finance horror stories or like the excel rounding bug, it makes me wonder exactly how much money UoM has saved us from losing through some innocent type somewhere. Debugging money code is way easier when you can verify all the conversions separately from the logic. It feels like cheating, to be totally honest. I know there are big shops out there that don't have UoM in their tools, and I used to feel bad for them, but now that we have it, I can't help but NOT feel bad for them. Anyways, yeah, F# isn't perfect. There's plenty to be said also for the amount of progress they make with language updates. It grows a crazy amount between major versions, and I haven't had too much problems yet taking old F#3.0 code and revitalizing it. Very pleasant experience in that regard as well.

9y ago

phillipcarter 9y ago

I actually work on F# at Microsoft. I've had success and some failures when it comes to evangelizing F# through Microsoft (but mostly success if my measures are accurate). I strongly believe that it can be boiled down to one major thing: Programmers learn how to program with C-style languages. C, C++, Java, C#, JavaScript, Python (sorta) . . . they're all in the same family. People, especially while learning, associate programming with specific constructs and idioms of C-style languages. It's incredibly difficult to break that barrier. I think that functional programming is on the rise, and that more and more developers are starting to realize that the types of bugs that hold them back can be reduced by using a more powerful language. But it's got a very long way to go, because there is a lot of unlearning to do. The article alludes to this a bit. For example, immutability is one of the key concepts in nearly every FP language. Functional programmers take it for granted, but it's transformational and completely changes the way you have to solve a problem. This hump is often too big for many people to get over, at least in their first trial with a functional programming language. It's hard to solve a task you know how to solve when you now need to re-think your approach because the language doesn't let you change x in-place. Additionally, I believe that many programmers aren't necessarily aware of all of the problems they're having. The next time you hear someone say, "and make sure to check for null here", watch them to see if they're seeing that as a general problem hurting their ability to get bits out the door or not. In my experience, it's not usually viewed that way. Yes, null is a necessary evil in many environments, but it's one that can be tamed, and different languages have already figured out how to do that. But unless it's seen as a problem by people at large, they won't see that as a carrot when you wave things like Optional types in front of them. Overall, I'm still excited. Jet.com is a billion-dollar company that built their stuff with F#. There are similar stories of companies successful with F# (and other functional programming languages), and it feels as though this is happening more often. And as the mainstream (read: C-style languages) adopt more functional programming techniques, I think this will only get better. I think that people will see the value, then see a language which does it better, and give it a try.

rottyguy 9y ago
"...realize that the types of bugs that hold them back can be reduced by using a more powerful language." I hear this a lot with FP but would love to see some real world examples of this if anyone has any links.

jasim 9y ago

How can you help someone see the beauty and benefit of Typed FP without asking them to just trust you and spend a few months with it? I used to dismiss this as academic noodling till I got tired of OO and started going back to my procedural roots with just plain functions organized into namespaces. I was pretty happy with it till the codebase grew to a point I couldn't keep track of the flow of data. Objects help you to some extent here since they group related values into one instance, but I didn't want objects anymore. This was when I started seeing references to OCaml, especially "Why ML/OCaml are good for writing compilers" (http://flint.cs.yale.edu/cs421/case-for-ml.html http://flint.cs.yale.edu/cs421/case-for-ml.html), and also saw a presentation by a programmer I respected where he built a general game playing engine in OCaml. Seeing someone use it for practical, advanced programming was the first catalyst. Then Jordan Walke mentioned somewhere that he first prototyped React in OCaml, and shortly after they released ReasonML. The type system was amazing. All values are typed, even complex nested structures have a type. There are variants which mean I can express different shapes of the same value using types, and the compiler will tell me if I ever forget to handle a particular case of this variant. I've been programming with Reason/OCaml for about six months now, and Typed Immutable Programming still takes me more time than just gluing together a pack of cards with imperative code. But once the code is written, it sits on an iron-clad foundation. Most systems as they grow start to fold under its own weight, but here the accretion of code is an almost unmitigated good thing. It means my system's cognitive wealth is increasing without an exponential increase in maintenance cost. But how can you help someone understand all this in a single conversation? A lot of people come to this because they worked on systems with pain points that Typed FP can address. But for most others who haven't had that sort of clarifying experience, what can you tell them to give it the non-trivial amount of effort it requires?

frou_dh 9y ago
I'm not in the Typed FP world, but I found the concept of pervasive use of Sum Types making invalid states (according to the project domain) of composite structures _unrepresentable_ to be a pretty compelling nugget to chew on. A lot of debugging is: This <object> has ended up in a weird state. Whereas the alternative could be that if the code compiles then it's impossible for that <thing> to ever be in a weird state.

systems 9y ago

I honestly don't think there much wrong or a problem with F# I do follow F# somehow, and compared to other languages .. it actually seem to have a very pragmatic and active community The F# community build a lot of interesting frameworks, suave, websharper, type providers ... to name a few I dont think, anything will look popular, when compared to Java , C# or Python .. but compare it to Haskell, Ocaml, Clojure.. Dart, D, Nim .. and the plethora of languages that compile to javascript , and you will see F# is not doing so bad

systems 9y ago
I will just make one criticism ... it is sadly somewhat awkward to install F# even on windows and they do need a good ide if you go to the F# .org site, installing F# without installing visual studio, is a 4 step process .. and when I tried it on windows 7 it just didnt work for me i eventually gave up and install visual studio on linux, thing seems better, but .. still missing a solid ide
- talyian 9y ago
  The first class IDE for F# is VS Code + Ionide. The language service backend for F# is also very well supported for emacs.
  - TensorMetric 9y ago
    The first-class IDE for F# is the full Visual Studio, not VS Code + Ionide.
    - toyotaboy 9y ago
      VS Code is now recommended by Microsoft for F# + .NET Core. Get with it, you're behind the times.
      - TensorMetric 9y ago
        It's only recommended temporarily, until the issues get ironed out. It doesn't make it THE first-class F# IDE.

nickpeterson 9y ago

This article retreads common complaints about the F# experience for outsiders that I've seen numerous time. I'm going to go a different direction. The problem with the F# community is that they keep asking how to convince C# developers to use F#. I'm convinced that is not the right way to grow the F# ecosystem. Most C# developers tend to come from enterprise and have a set of values and practices that is generally at odds with open-source, functional languages. They are used to producing codebases that can never be open-sourced, using tooling provided by a single vendor. They don't tend to be the ones contributing interesting or new libraries. In fact, this is a large issue with .NET in general. Most strong libraries are spiritual or literal copies of something from the JVM world. This urge hurts in other ways. For instance, Don Syme has indicated he doesn't want to put things like Type Classes or Dependent types into the language because it adds a cognitive load to the language that's hard to balance vs the gains in productivity. But their absence means that many of the dev's you actually want contributing to the ecosystem, just use other languages. They adopt Haskell/Idris/Scala/whatever and start contributing blog posts, tweets, libraries, conference talks, etc. I actually think a large part of this decision is that many of these things would make F# pretty incompatible with C#, which is trumpeted as a feature, but again, it waters down the language to the point that C# dev's look at it and say, "Why bother? It's compatible like VB is, so C# can already accomplish the same things." And in the meantime, it prevents new features that would attract others. What sounds more enticing to developers, "More Functional C#" or "Haskell With Better Tooling"? What's more, there are even examples of how some of these features could be implemented (both Type Classes and Dependent Typing exist in some capacity through feature requests and F*, an experimental Microsoft language). Basically, F# should be more about being different than the rest of .net, than trying to be ".net through an OCaml set of glasses".

throwaway7645 9y ago
Yes...F# for a non C# dev is a major pain.
rubber_duck 9y ago
I disagree with this, you can sell F# to C# developers - things like type providers for SQL checking their query strings in compile time and no extra build step to produce SQL type definitions vs monstrosities such as Entity Framework... if they've been burned by ORMs to drop to stuff like Dapper they'll love F# type providers. Immutable data is also becoming a common pattern even in C# but it's tedious as hell to write. Functional programming is also seeping in but again tons of boiler plate. Biggest problem with F# is that it has it's own warts + it's a big upfront switching cost and a steep learning curve but it offers many marginal improvements - when you sum those improvements it ends up being worth it IMO but that's a very hard sell.

d--b 9y ago

F# problems from a C# developer point of view: #1 tooling: visual studio integration of F# is poor. You don't get cross language usage reference, so you lose all the benefits of static typic. Projects and references are a mess. Being primarily a scripting language, it feels like a toy language #2 compatibility with C# is poorly done. That F# functions cannot be consumed as C# lambda is a real mess. Boxing / unboxing doesn't feel FP ish at all. You often need to implement classes with interfaces to interact with C#'s core libraries.

phillipcarter 9y ago
> #1 tooling: visual studio integration of F# is poor. You don't get cross language usage reference, so you lose all the benefits of static typic. Projects and references are a mess. Being primarily a scripting language, it feels like a toy language Could you clarify what you mean here? Although things like Go to Definition and Find all References don't work across C#/F# boundaries (yet), but you absolutely get IntelliSense and the benefits of static typing. F# isn't a scripting language, although it does support F# scripts.
- smithkl42 9y ago
  It's the "Go to Definition" and "Find all References" pieces that are so annoying to me, and slow me down tremendously. It means that (practically) you have to do your whole solution in one language for it to feel like a unified solution, and that makes it hard to start by bolting an F# project onto an existing solution.
- smithkl42 9y ago
  And FWIW, I remember complaining about this to Don Syme something like 5+ years ago, and while he gave lip service to the idea that F# needed better tooling (and better tooling interop with C# specifically), I don't think he was really convinced.
- d--b 9y ago
  You get intellisense alright. But using C#, I never need to #open the namespaces myself for it to find the types I am using or the extension methods I need. (Maybe this is because I use resharper, but still, it really slows me down). Also the benefits of static typing are that it makes it easy to refactor. Here if I change things in C#, I need to grep my F# scripts for usage, it's a real pain.

zubspace 9y ago

Good post. I really hoped for some f# code after listing all those scenarios where c# fails. Anyway. I work in a c# shop with a large monolithic code base developed by a small team with lots of fluctuations over more than 10 years. I have no functional programming experience at all. I love c# because we actually try to keep the code as simple and linear as possible and only introduce complexity in certain areas if performance requires it. Yes there are hacks and dirty code passages, but if you stick to basic code constructs they are easy to decipher. If your facing more than 10 million lines of code you start to appreciate simple code. Moreover if different developers, which come and go, are working on it. Living without refactoring and inspection capabilities of resharper is nearly unthinkable to me. Now, how would you convince someone like me to try out f#? There are only drawbacks: Obscure things we would need to learn (type classes? monads? xyz?). Probably hard to read, 'clever' code. A mixture of c# and f#. Unknown library, build and deployment issues. And I guess, f# developers are rare around here. Even after reading this post, there's unfortunately no convincing reason for me and management to give f# a try...

lmm 9y ago
As someone on the JVM side: I find the biggest advantage of functional programming is being able to replace "magic" - reflection, bytecode manipulation, AOP - with plain old code. If you can get everything you need to get done in plain old C#, you should probably stick with that. But if the most error-prone parts of your program are the cross-cutting concerns and the not-quite-C# you use to handle them - things like error handling, transaction boundaries, audit records, access control, that tend to be done with a "magic" API that doesn't follow the normal rules of the language - then maybe F# could help you by letting you replace those things with normal code. Slightly fiddly code, perhaps, but I'll take fiddly normal code over AOP-style magic any day. Trivial example: what if you could do away with exceptions but still be able to "bubble up" errors in a lightweight way, so that your error handling still wouldn't get in the way of your straight-through business logic code? "Everyone knows" to never use exceptions as control flow, but it happens by accident anyway - have you hit bugs because of that? (I have). If you could avoid having them in the language, wouldn't that make things simpler? You have less need to learn things like monads because they're just plain old library code; if need be you can click through to the function definition, just like any other function you call. That for me is one of the big things FP is about: reduce what's in the core language, push stuff out into libraries instead. There are a few language features to learn, sure, but they're language features you wanted anyway. Type classes are a small feature, and boil down to just a slight bit of extra syntax support for the strategy pattern. (Indeed I find most of the FP features come down to taking classic OO principles - SOLID, composition over inheritance, and the like - and actually following through on them). And maybe as you get comfortable with it you'll be able to turn those 10 million lines into 5 million, or 1 million, or less (and maybe those lines are slightly more complex than the lines they replace, but that's a good tradeoff). Certainly that's what using Scala has felt like for me.

sremani 9y ago

Not pertinent to the article but I guess to the people interested in this discussion. The first in person F# conf in North America (to my knowledge) Open Fsharp Conf. is on Sept 28, 29 in SFO. (http://openfsharp.org/ http://openfsharp.org/). My only association is I bought ticket for it.

pjmlp 9y ago

I lost faith in F# the moment Microsoft decided it is not worthwhile to delay Visual Studio 15.3 to properly support it pushing devs to VSCode, and the lack of roadmap for .NET Native/UWP. So first make F# a first class citzen on .NET and maybe many C# devs will look again to it.

bernadus_edwin 9y ago

F# evangelism should start with small thing. Start as library or component. The main project is still c#. Just like react approach

galkk 9y ago

I think that the problem with F# is that it feels more or less abandoned by MS itself. It's already F# 4.x, but I can't remember any significant new features in last 3 releases at least, neither in language nor in the standard library.

toyotaboy 9y ago
That's because F# 1.0 was bascially a more powerful language than C# 10.0 (C# still doesn't have proper pattern matching for example, or discriminated unions) For features added see https://en.wikipedia.org/wiki/F_Sharp_(programming_language) https://en.wikipedia.org/wiki/F_Sharp_(programming_language) Named union type fields Extensions to array slicing Type inference enhancements Printf on unitized values Extension property initializers Non-null provided types Primary constructors as functions Static parameters for provided methods Printf interpolation Extended #if grammar Support for 'fixed' Tailcall attribute Multiple interface instantiations Optional type args Params dictionaries Struct tuples which inter-operate with C# tuples Struct annotations for Records Struct annotations for Single-case Discriminated Unions Underscores in numeric literals Caller info argument attributes Result type and some basic Result functions Mutually referential types and modules within the same file Implicit "Module" syntax on modules with shared name as type Byref returns, supporting consuming C# ref-returning methods Error message improvements
- toyotaboy 9y ago
  For library, see https://github.com/fsharp/fslang-design/blob/master/FSharp-4.0/ListSeqArrayAdditions.md https://github.com/fsharp/fslang-design/blob/master/FSharp-4...
  - TensorMetric 9y ago
    All those features mean nothing to seasoned .NET developers when you can't use the language natively on Microsofts primary application platform.
    - toyotaboy 9y ago

banashark 9y ago

I usually don't try to sell F# as compared to C# as noted in many other responses here. Since most of my friends work in other languages I usually just use python as my reference. #ME: "Hey that stuff at pycon was pretty cool, huh?" #FRIEND: "Yeah it's interesting the directions they're going with the language." #ME: "Yeah the optional types could help clean up big code bases, and open up the door for quickcheck-like fuzzy testing." #FRIEND: "Yeah." #ME: "And some of the functional programming stuff is pretty neat too, I know it's easier for me to test." #FRIEND: "It's so much easier." #ME: "And the asyncio stuff is gonna be really nice to work with when it catches on more." #FRIEND: "Yeah it seems a lot more ergonomic of a solution." #ME: "And the binary distributable packaging tools look like they might actually work this time." #FRIEND: "Probably not, but we can hope." #ME: "I think I should introduce you to my friend F#." Then just do some stuff in fsx with a type provider or some other neat stuff and at least you've got the message across. People get excited about solutions to their problems. If you start giving them more problems then you're only adding to the constant subconscious cognitive load that they bear in regards to software development. If you show it to them in terms of problems that they already have, you're reducing the cognitive load. Everybody loves having less stress. But this is just how I approach it. F# is like Python4 for me.

DeepRote 9y ago
Have you ever looked at Julia? I mention it just because I've had almost a carbon-copy of that conversation but I showed them Julia and now that person actually is writing Julia for their startup. That person is doing technical chemical engineering stuff, so the fit is a bit more pronounced, but I think it's a neat language aside from that. Parametric types and multiple dispatch and lisp-macros, oh boy!

deleted 9y ago

[deleted]

deleted 9y ago

[deleted]

strayamaaate 9y ago

I’m a C# developer, love the language and how easy it is to express what’s in my head as code. I recently had a chance to play with F#. After being completely lost for a bit, I found I had to really rethink how I was reasoning about problems and the right way to solve them. But that’s the point I want to make. I don’t expect to be good at FP for a while - it’s going to take time to grow, along with the tooling and community. But I appreciate having a way of framing a problem differently, and like the direction F# is headed. It doesn’t mean I’m going to drop C# any time soon, I’ll likely just use both - e.g. my more math heavy libraries will be F#, and my networking and Web API code in C#.

MichaelGG 9y ago

Microsoft promoted this idea that F# is for mathematicians and engineers, so its no wonder that people pick this up. And I'm not sure who is pushing this idea that F# is not fine for OO work. It has all those features. So starting with F# as a "better C#" -- there's nothing wrong with that. Over time I think people will come to view OO as suboptimal, but in the mean time F# is just a better language to use than C#. MS hasn't funded F# enough, and has crippled the marketing on it to continue to push C# rather than admit they've made mistakes. The tooling issues and other random incompatibilities are why I don't use it as much as I used to - it's too much friction.

toyotaboy 9y ago
No one who knew what they were talking about at Microsoft said F# was for mathematicians and engineers. It's a myth pushed by C# programmers and idiots. It's nonsense and you shouldn't repeat it. People at Microsoft repeatedly said "Simple Code for Simple Problems". C# programmers don't like repeating that.
- MichaelGG 9y ago
  Doesn't matter if they didn't know what they're talking about, that was what was written on the Microsoft sites when comparing C#, VB, F#. F# was always pigeonholed into scientific and financial categories, never aimed at general code. I'm only repeating it to point out that MS itself did poor marketing for F#, clearly favouring C#.
  - toyotaboy 9y ago
    Microsoft didn't promote that idea. Some random people at Microsoft did, a very long time ago. Just forget about it and move on.

magnumkarter 9y ago

For me, I only got into .NET because of F#, and even then I pretend C# doesn't exist. I tried learning OCaml, it has cool features, like parametric modules and GADTs. But I always ran into the issue of irreproducible builds. This didn't happened in F#. I eventually tried F# because it was close enough to OCaml and while I was learning OCaml I always referred to this site http://fsharpforfunandprofit.com http://fsharpforfunandprofit.com I'm definitely an F# evangelist at work, but we are not a .NET shop. But I was would say that the introduction of ML features in other languages, (Swift, Rust) are good for F# evangelism, because it makes these concepts more familiar. I think the focus should be on moving F# away from .NET because F# itself, it is much more accessible that its cousins OCaml and Haskell. And if Microsoft won't give proper support, the community should move to other platforms. Some discussions are already happening here https://github.com/fsharp/fssf-ask-the-board/issues/4 https://github.com/fsharp/fssf-ask-the-board/issues/4

pjmlp 9y ago
The difference being that Apple is quite vocal that Swift is the future of app development on their platforms, while Microsoft is trying to push UWP as the future of Windows apps (supported languages VB, C#, C++ and JavaScript).
- yawaramin 9y ago
  UWP supports JavaScript? Cool, in that case a bunch of transpilers should work (once bindings are written) ... people can just use their preferred languages: OCaml/BuckleScript, F#/Fable, TypeScript, PureScript, et al. I've actually written and run JScript scripts on Windows Script Host with BuckleScript, it's really nifty. You write strongly-typed code and get a JS artifact that can run on your target platform. For the curious, an example: https://github.com/yawaramin/wsh-bs-test https://github.com/yawaramin/wsh-bs-test

AnimalMuppet 9y ago

I'll go a step further. There's a problem with language evangelism. There is no "one best language" or even "one best programming style". Functional has worked for some people to address the problems they have, but not everyone has those problems. For example: I once worked on a video switcher for TV stations. You have maybe 100 video sources, maybe 80 video destinations, and you can connect any to any. You also have about six different sources of commands to make connections. For responsiveness, each source has its own thread. So the nature of the problem is one giant shared mutable state. The functional people come along, and they say "shared mutable state is evil; don't do that". Yeah, well, that's actually not bad advice, but it doesn't help me at all with this situation, since I can't avoid it here. There are other places where FP isn't the answer: Situations where you care about memory layout (high performance computing or just memory constrained), where one of the main concerns is sequencing (some industrial control operations, maybe robotics), where predictable timing is important (real time systems), maybe others. Use the right tool for the job. FP is not the right tool for every job. Nothing is. The problem with evangelism is when it says "this is the One Right Way", instead of the humbler assertion "in some situations, this can help you with some of the problems that are slowing you down". Don't get me wrong. FP has a good story. (Even if you don't use FP, learn its deepest lesson: Control your state space or die.) But FP is not always the answer. Evangelists might get further if they recognized that.

m_cubed 9y ago

I built Tsunami IDE. It is a F# IDE. I built it before VSCode or VS Community came out. I built it as a test to see if cost of Visual Studio was blocking adoption of F# and the ideas that F# codifies. The experiment was successful, I got my answer, and the answer is no. Even with free tools people have a hard time adopting F#. First let me address those who are asking for Type Classes and Dependent Types. These would make the compiler too slow. The F# compiler works in the 100s of ms and the 100s of MBs ram. Where Scala is in the 1000s of seconds and the GBs of ram. People will give up on code completion if it takes more than 500ms and they generally don't like waiting longer than 200ms. Separately Martin Odersky (the creator of Scala) laments that the more advanced language features attracted the wrong type of people to the language and flooded the internet with overly academic tutorials. I put a lot of the blame for the lack of F# adoption on Microsoft. Part of this is to do with the Dev Div vs Windows war that almost deprecated the whole .Net ecosystem. If Windows 8 wasn't such a disaster it's likely .Net would have been deprecated and would never had been open sourced. (at least something good came from Windows 8). Part of this war also ended with a lot of the best .Net people leaving to go to Facebook. This brain drain has really hurt Microsoft and I doubt they'll ever recover. Most of the old hands that know better are aging out and the new people at Microsoft don't know any better. As for tooling, Microsoft has done and continues to do a bad job with F# tooling. There is is a not invented here culture at Microsoft Redmond which includes being hostile to Microsoft Research. Visual Studio is a bucket of bandaids and it takes an army of people just to keep it going. F# is given a low priority. It's worse with the latest release because they've gone overboard with compiler features with the Rosario release and have made it dog slow and painful to use. I hope they can fix it with updates but who knows. You can still get older versions. It's very possible to build a really good IDE around the F# compiler but unfortunately Microsoft refuses to do so. Thankfully, it looks like there are some good alternatives becoming available. In comparing Scala and F# adoption, Scala has Hadoop/Spark which is a killer product that can earn a consultant a lot of money. The fact that C# is a better language that Java means there are more Java refugees going to Scala than there are C# refugees going to F#. Thankfully Don Syme has made F# completely open source. Now with .Net being open source we no longer have to worry about Microsoft shooting itself in the foot again. I make my money writing a product written in F# and can attest that F# is one of my big competitive advantages. I highly recommend it.

sklivvz1971 9y ago

The problem is that people who are drawn to F# tend to be a certain kind of people: generally stronger in CS, but also more prone to think that changing programming language is a solution to a wide variety of problems. Many people are not like that, and stuff like a small community, worse tools and toolkits and less programmer availability are actually a huge deal, capable of tanking a good project, whereas having a 10% better language isn't a huge gain. It's that simple.

alkonaut 9y ago

Businesses and developers generally won't switch languages. Evangelism makes people curious which means new businesses and new projects some times picks a new language. I'm a C# dev since 14 years (single project) hoping my next project will be an F# one. That might mean I have to switch jobs - and I hope there are enough F# shops when I need one.

tcard 9y ago

A great take on this topic is a talk by Evan Czaplicki, creator of Elm, another functional language: Let's be mainstream! [1] The conclusions are more or less the same than the article, but Evan goes into a lot more depth. And in my opinion, as a result, Elm does very good in this regard. [1] https://www.youtube.com/watch?v=oYk8CKH7OhE https://www.youtube.com/watch?v=oYk8CKH7OhE

nlawalker 9y ago

The problem with F# evangelism is that it doesn't exist. No one is evangelizing F#; everyone is evangelizing functional programming. F# is the Python of .NET - it's multi-paradigmatic and you can do whatever you want. Sell it to people that way, and let them get into functional concepts later, or never. F# has a huge opportunity in the enterprise. A ton of enterprise C# code is not object oriented at all, it's big, poorly thought out clumps of imperative script wrapped in methods and classes so it can be compiled or fit into the framework that's calling it. Sometimes it'll get a quick last pass run on it to make it "more object oriented", because that's what C# code is supposed to be; this usually just makes it worse. It's written in a scripting mindset: the developer needs to get things done, and adds code and bangs on stuff until it compiles and looks right when it runs in the debugger. F# is actually well suited to this style of development, but it's hard to find anything about it, because every F# tutorial, book and blog post is actually about functional concepts, functional design, functional thinking and functional programming, including this one. If you want to sell F# to enterprise developers, show them how they can write their C# code in it without having to pretend that it's object oriented anymore, and how that's a good thing.

sickbeard 9y ago
Asking businesses to rewrite apps in a different language is a non-starter. It adds no value. The app is already there, written in c#. Why rewrite it in f#? There has to be some reason to write something in F#, usually the reason is functional programming, which excels in manipulating data. However most programs rarely manipulate data. They show a UI, get some input from a user or server, save, retrieve, re-display in a different form. These kinds of programs work very well when written in imperative languages compared to functional ones.
pjmlp 9y ago
> If you want to sell F# to enterprise developers, show them how they can write their C# code in it without having to pretend that it's object oriented anymore, and how that's a good thing. As enterprise consultant, for the types of customer projects I work with, lack of tooling support for Blend, WPF, UWP, EF, ASP.NET is a no-go to move from C# into F#.

macca321 9y ago

We're singing from the same hymn sheet https://github.com/mcintyre321/OneOf https://github.com/mcintyre321/OneOf https://github.com/mcintyre321/ValueOf https://github.com/mcintyre321/ValueOf