F# Survey results discussion

[Scott Wlaschin]

Hi everyone,

I've made the F# survey results (link) public now. These are just the preliminary results of course -- I hope that many more people will participate over the next few days, so please spread the word!

I'm going to start a thread to discuss the results here.  What do you think of it so far?

First, a big caveat: that the data is set is probably strongly biased towards heavy F# users right now, so take the results with a pinch of salt! 

So I think it would be especially useful to get responses from F# newbies or "just curious" people, so if you know anyone like that, please forward the link to the survey: http://fsharpworks.com/survey.html 

Finally, we should really wait until we have a lot more responses before having a discussion, but it's interesting already I think.

======================

Here's my personal comments on the results that have particularly grabbed my attention so far. 

Experience: 

Most respondents have been programming for more than 10 years. 

Even with the bias noted above, I find this a bit surprising, as I thought younger people might be more into learning new things. 

How would you characterize your use of F# today? 

I'm surprised that half of the respondents actually use F# at work!  See also the "What is the status of F# in your workplace?" question.

Development environment: 

Visual Studio is much more dominant than I expected.

What stops your workplace from using F# more than it does now?

No one is saying "Too Windows-centric"  ;)

What has been the most frustrating thing for you in *learning* F#? 

"Not enough real-world code to learn from" is a winner so far -- so that's a really useful insight from this survey already.

Which other platform(s) would you be interested in using F# on?

Native and JS are currently winning this one. 

What do other people think?

[Stachu Korick]

And here I thought I'd have to wait a week to see any results!

Here are my thoughts so far:

- I always anticipated F# to be used more for data science, financial, or otherwise non-enterprise development. This seems to not be the case.

- The number of people with 4+ yrs of experience with F# is strange. I also assumed that the numbers would be very much leaning towards beginners.

- I need to get blogging.

- As I expected, not many people have a use for Units of Measure. I've yet to see a real-world use of this interesting feature.

[don...@fastmail.fm]

 

- As I expected, not many people have a use for Units of Measure.

 

FWIW I feel the data showed me something very different. 

 

F# Units of Measure and F# Agents both currently rate at 44% in the "I don't use this" response.  That says 56% of people didn't tick that box, which might indicate an actual usage rate of anywhere between 10% and 30% depending on question-non-answering bias. In both cases, that figure is higher than I personally expected.

 

For both of these features, we absolutely designed them to be 100% optional: they are not at the core of F# programming, but can be used when appropriate.  For units-of-measure, in truth I only actually only expected 5 or 10% of people to use the feature (you generally have to be dealing with numbers a lot to need this). If so, I would consider that a sign of success, both in the way we have made the feature so non-intrusive, and in the way some people are still using it when necessary. 

 

So I feel it's not quite right to call out this feature when you don't use it: if you don't use it and you don't notice it when you don't need it then that's a good thing and something to celebrate about the language.  If you search on google it's easy enough to find people who do use it, e.g. here.

 

Perhaps the survey question would be better phrased as "which of these features get in your way and make you or your team less productive". That would be really interesting data to have.

 

FWIW I think it would also be great if the survey could be expanded to focus less on the language and more on the broader F# ecosystem. The survery doesn't, for example, mention FSharp.Data, or the Visual F# Power Tools, or FsEye, or WebSharper, or Akka.NET or MBrace or indeed any of the F# ecosystem or broader exosystem presented on http://fsharp.org (e.g. http://fsharp.org/community/projects/ and the guides on that site).   F#'s health and success depends as much upon it's ecosystem/exosystem.

 

Kind regards,

Don

--

--

To post, send email to fsharp-o...@googlegroups.com

To unsubscribe, send email to

fsharp-opensou...@googlegroups.com

For more options, visit this group at

http://groups.google.com/group/fsharp-opensource

---

You received this message because you are subscribed to the Google Groups "F# Discussions" group.

To unsubscribe from this group and stop receiving emails from it, send an email to fsharp-opensou...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

 

[Stachu Korick]

[in response to units of measure]

My reaction was to that of it being the highest-rated feature of no use. Maybe I'm overestimating peoples' laziness in clicking checkboxes!

I'm sure people use it, I just haven't seen a use in my particular enterprisey development :)

Stachu

[Isaac Abraham]

Just my two cents – I’m in the camp who’ve used it rarely, but when I did it was incredibly useful. We were using it some months ago to compare AWS and Azure VM offerings in terms of costing, memory sizes, CPU core counts etc. – some of the data came in GB, some in MB, some in bytes etc. – having the UoM available saved us from an incredible amount of fluff.

[Stachu Korick]

The following response was taken out of [http://www.reddit.com/r/fsharp/comments/32ffxz/the_first_annual_f_survey/]

Very interesting and a great idea but disappointingly puritanical.

 * Functional programming is largely irrelevant as F# is only marginally more functional that C#. Union types and pattern matching are just as important.

 * I'm about as expert as they come but I fall into the "learner" category because I still use mutation.

 * "Functional but can be tweaked to perform well".

 * "Immutable by default". The most fundamental data structure, arrays, are not immutable by default.

Reaction:

 - [fyi] Puritanical is a big word. Apparently it basically means religious (or, in this case, seemingly strict in judgment)

 - The final bullet is strange to me. From my perspective, lists are 'more fundamental' data structure than arrays. (and I certainly wouldn't claim any to be the MOST)

[Simon Cousins]

Big thumbs up for units of measure in the enterprise from me!

I work in the energy industry. When we were a C# shop the most common class of bugs were caused by nulls. The second most common class of bugs were caused by incorrect units of measure.

For example, the business users in this domain are very lax in their use of the term "megawatt". Sometimes they mean megawatt the unit of power and sometimes they mean megawatt over some time period which is a unit of energy. To them it is obvious what they mean from the context but this imprecise use of language often caused bugs in code. The UK energy market works at a half-hour granularity so whenever we saw a calculation involving MW, MW hour and MW half-hour that was a factor of two out it was almost inevitably a unit of measure issue somewhere in the calculation.  

Using F# I type all my calculation libraries with units of measure and units of measure errors are gone. I can also show the business F# code and walk them through the calculations showing them the units of measure at any point. On more than one occasion this has revealed bugs in their specifications.

Simon

[Jack Fox]

@Stachu once you realize the utility of Units of Measure for design-time strong typeing, you will use it a lot. Eliminates all possibility of confusion among ints and floats.

[Warren Young]

On Apr 13, 2015, at 4:01 AM, Scott Wlaschin <swla...@gmail.com> wrote:
>
> First, a big caveat: that the data is set is probably strongly biased towards heavy F# users right now,

Not “probably,” *certainly*. There’s a strong self-selection bias going on here.

This is why ~15% of the respondents say they’ve been using F# for 4+ years. That 15% amounts to only 61 people. Either we have to believe there are only 61 people worldwide with long experience with F#, or we believe this survey isn’t representative of the F# user base. :)

> Most respondents have been programming for more than 10 years.
> Even with the bias noted above, I find this a bit surprising, as I thought younger people might be more into learning new things.

A huge chunk of the young programmers are going to be on the vo-tec path: they want learn Java or Python or C++ or Objective C, because they’re trying to become employable.

It isn’t until you get professionally established that you start to take some risks with tech complicated enough that it takes you a year or two to learn.

When you go walking in public next time and see some young rebel, take a second look. I think you’ll see that they look like all the *other* young rebels. :) Very few young people are actually striking off in some new direction.

> I'm surprised that half of the respondents actually use F# at work!

Have you read this?

http://ericsink.com/entries/fsharp_chasm.html

I think this survey tells us that there are a lot of pragmatists in pain.

I think a lot of these pragmatists have been programming in some non-Windows-centric environment, then have to write something for Windows and get a choice between C#, C++, and VB.net as first-class languages on Windows, and go “NOPE!”

There are many complaints in the survey comments about F# tooling, but it seems like a lot of whining to me. F# is far better integrated with MSDN and Visual Studio than, say, Perl is with Vim, yet no one complains that Vim should have more refactoring tools for Perl. No one will be impressed if you tell them that you managed to write some Perl using Vim, yet we get people acting like it’s a huge hardship to write F# in Visual Studio 2013 without plugins.

These people are not F#’s target audience. They will make excuses no matter how powerful the F# tooling gets.

F# isn’t only going up against C#, it’s also going up against the likes of IronPython, Boo, and the Windows Haskell Platform. It is these third- and fourth-class languages that F# is beating the pants off of today. This is where the audience is.

So yeah, F# may be *second*-class on Windows, but that’s actually a pretty enviable position.

> Visual Studio is much more dominant than I expected.

Again, it’s the second-class syndrome: Yes, F# support in VS could be a lot better, but F# in VS is worlds better than in any other tool:

- SharpDevelop dropped F# support in its most recent version, and it didn’t work very well when it *was* “supported.” The GUI builder didn’t work with F#, the debugger was half-broken, I had to complain on the forum to get it to allow mixed C# and F# projects, etc.

- Xamarin costs twice as much as Visual Studio Professional for most organizations, and you have to re-up every year, whereas you can coast for years on a perpetual VS license. And that’s only if you only want Windows. If you want in on Xamarin’s multi-platform promise, you double or triple that cost. You’ve got to be a pragmatist in a *lot* of pain to put up with that.

- Your Favorite Text Editor is not going to fly with most of the Windows developer crowd.

- YFTE *will* fly with some of the Linux and OS X users, but since they represent about 5% of the total computing market together, that tail ain’t gonna be waggin’ any dogs.

> No one is saying "Too Windows-centric" ;)

Sure, because Visual Studio and .NET are not problems that Mono ecosystem needs to overcome. Windows doesn’t have to lose for Linux and Mac OS X to win.

I think the main problem is that Mono is so dependent on Xamarin, and Xamarin is paying a living wage to dozens of Silicon Valley residents. That buys us all the “open core” problems that hold back so many other F/OSS projects.

(Consequence: MonoDevelop exists for Linux, but not Mac OS X or Windows. Why? Because they want to nudge you towards Xamarin Studio.)

Anyone thinking I’m wrong here probably also doesn’t understand why the world needed LibreOffice, MariaDB, and CentOS when it had OpenOffice, MySQL, and RHEL+Fedora.

> What has been the most frustrating thing for you in *learning* F#?
> "Not enough real-world code to learn from" is a winner so far -- so that's a really useful insight from this survey already.

Yes. When most F# code visible on the web is toy code, that leaves the impression that F# can only solve toy problems.

> Which other platform(s) would you be interested in using F# on?
> Native and JS are currently winning this one.

I wonder if those voting for JS are unaware of FunScript:

http://funscript.info/

I’m also not sure why LLVM and Native got two separate options. I mean, I realize why someone developing the compiler has to make a decision whether to use LLVM as the backend or write their own native code generator, but why are potential end users of that compiler being asked for their opinion? IMHO, all that matters is whether such a thing exists.

The biggest challenge to a “native” F# is prying it apart from the .NET class library. I think if someone were to reimplement maybe 80% of what ships with OCaml, and provide a strong FFI mechanism that lets you link to C-compatible libraries for everything else, you’d have a success, though.

I’d *love* to see F# quietly displace OCaml on all platforms. :)

[Daniel Fabian]

About the real-world code, I’d assume it has also a lot to do with when people use F#. I have now seen quite a few applications of F# for some very core components in an enterprise setting or for things like our GPU compiler or the likes of what we read earlier about solutions for energy. That said, from those projects, it won’t be easy to see code as those are usually part of the uniqueness of the company building them so it is not going to be open-sourced for instance.

Also, in a corporate environment, where you have say mostly C#, introducing F# for certain parts (because you can’t just flip an existing code base to F#), causes additional effort. People need to deal with double code bases, learn the language (for an imperative programmer this takes time), etc. Companies will (and do) go for it, but only if it yields a large enough benefit. Especially if it gives them a competitive edge, but again, you won’t see that that code…

​

[Warren Young]

On Apr 14, 2015, at 11:32 PM, Daniel Fabian <daniel...@integral-it.ch> wrote:
>
> About the real-world code...GPU compiler...solutions for energy...not going to be open-sourced for instance.

I don’t think anyone’s expecting to see piles of F/OSS line-of-business apps and secret-sauce tools appearing on Github.

However, you do have to ask why so many NuGet libraries don’t have any F# samples, and how few of the libraries up there are actually written in F#.

Just having all that sample code driving useful libraries would be a big help on its own: it solves the “F# can only solve toy problems” problem.

But more than that: it would also implicitly force library developers to “think functional” when designing their APIs.

I spent a few hours yesterday working through the dozens of libraries on NuGet/CodePlex/Github/etc. that all do a single task. (Parse a command line, if you must know. Why, oh why does .NET not have a simple equivalent of getopt()?) It took a lot longer than it had to because I had to translate all the C# example code to F# in my head before I could decide whether each candidate was even suitable.

If most NuGet libraries had an F# example beside their C# usage example, as most MSDN API pages do, you could make such decisions using a simple heuristic: if the corresponding F# sample is longer than the C# one, skip that library, because it’s clearly jumping through a lot of hoops to cater to some C#-ism. (e.g. Collection initializer lists.)

It would also be nice to occasionally run across some open source app that just *happens* to be written in F#, and which happens to have a bug or missing feature that I want, forcing me into the code.

I’m only aware of *one* widely-used open-source non-developer .NET app in the Linux world, and it isn’t in F# and I don’t use it anyway. (Tomboy.)

I think the reasons for that are:

1. There are many barriers to to use of Mono that I don’t need to enumerate here, because we all know them.

2. Outside the developer community, “free” Windows .NET programs are far more likely to be some kind of closed-source freeware rather than true open source as in the Linux world. I believe this is because .NET provides a stable, cross-platform API and ABI. If the executable runs everywhere, why do you need the source? By refusing to provide stable APIs and ABIs, Linux strongly encourages the availability of F/OSS.

In the end, there just aren’t many reasons why you would casually stumble across someone else’s F# code. That’s a problem.

> Also, in a corporate environment, where you have say mostly C#, introducing F# for certain parts (because you can’t just flip an existing code base to F#), causes additional effort. People need to deal with double code bases, learn the language (for an imperative programmer this takes time), etc.

I think there’s a lot of potential in F# libraries. They’re easily consumed by C# code, and the C# programmers don’t need to dig deeper than the API, if they don’t want to.

I think a lot of pure C# programs would be better off stripped to a C# GUI driving an F# core.

The reverse is a problem, as I brought up above. In addition to C#-isms, you have problems like OO- and mutable-centric interfaces that are just plain clumsy to use from F#.

[Daniel Fabian]

On 15 April 2015 at 22:14, Warren Young <tan...@west.etr-usa.com> wrote:

> Also, in a corporate environment, where you have say mostly C#, introducing F# for certain parts (because you can’t just flip an existing code base to F#), causes additional effort. People need to deal with double code bases, learn the language (for an imperative programmer this takes time), etc.

I think there’s a lot of potential in F# libraries.  They’re easily consumed by C# code, and the C# programmers don’t need to dig deeper than the API, if they don’t want to.

Yes and no; F# libraries are easily consumed by C# code, when they are designed to. We recently broadened our GPU compiler from being F#-only to being fully IL compatible. In that, we refactored our code to be more easily accessible from C#. F# most certainly can be written in such a way, that using an API from C# is a joy and you can take good advantage of C# type inference and you can end up with a very clean and even quite functional and fairly type-safe API. That said, it is not for free and you have explicitly design it that way.

Problematic for a C# API include F# data structures (even simple lists), modules, DUs, even records to a certain degree, usually tuples and almost always F# function values. Or with other words, writing idiomatic F# code without caring about C# will likely cause a C# unfriendly API.

I think a lot of pure C# programs would be better off stripped to a C# GUI driving an F# core.

The reverse is a problem, as I brought up above.  In addition to C#-isms, you have problems like OO- and mutable-centric interfaces that are just plain clumsy to use from F#.

While, I definitely agree, this also is part of the reason, I think, why F#’s adoption is not too high (yet) for simple business applications. When you have fairly simple business apps with little business logic along some validation but mostly CRUD, really, then what is the point in using an F# core with a C# GUI? For MVC, the story is I think much better as there is no C#-heavy designer and as far as I understand F#’s adoption is better. For WPF or WinForms, we would need something to make them easy from F#. That is, some designer which allows for F# code interaction (might not even need F# generation, just interaction should be fine). And some good blog posts, MSDN tutorials and general best practices how to deal with say a WPF API from F#; I’m thinking something like: “I feed you nice immutable records and you’ll notify the view of whatever it needs to know”, some nice event sinks and event sources for the UI

[Isaac Abraham]

I would have thought that MVC one of F#s weaker areas as there is no story around Razor AFAIK unlike with WPF where there's a good XAML type provider.

Regarding F# to C# translation - agreed with ask those points aside from Modules - they just show up as static classes in C# and are usually easy to consume?

---

From: Daniel Fabian
Sent: ‎16/‎04/‎2015 06:08

To: fsharp-o...@googlegroups.com
Subject: Re: F# Survey results discussion

[Daniel Fabian]

Well, the module thing can get a pain, when you have types in modules as you then need to fully qualify the name. In F# we just open the module like a namespace. That said, this one might be fixed in C# 6.0, though I am not sure if you can open classes in C# 6.0 with respect to nested classes.

​

[Isaac Abraham]

I would actually like that feature in F# as well i.e. opening up static classes, not just modules.

 

From: fsharp-o...@googlegroups.com [mailto:fsharp-o...@googlegroups.com] On Behalf Of Daniel Fabian
Sent: 16 April 2015 10:00
To: fsharp-o...@googlegroups.com
Subject: Re: F# Survey results discussion

 

Well, the module thing can get a pain, when you have types in modules as you then need to fully qualify the name. In F# we just open the module like a namespace. That said, this one might be fixed in C# 6.0, though I am not sure if you can open classes in C# 6.0 with respect to nested classes.

 

[TP]

On Wed, Apr 15, 2015 at 1:14 PM, Warren Young <tan...@west.etr-usa.com> wrote:
> I spent a few hours yesterday working through the dozens of libraries on NuGet/CodePlex/Github/etc. that all do a single task. (Parse a command line, if you must know. Why, oh why does .NET not have a simple equivalent of getopt()?) It took a lot longer than it had to because I had to translate all the C# example code to F# in my head before I could decide whether each candidate was even suitable.

OT but what library did you finally decide on to parse a command line
in a F# program?

[Robin Neatherway]

I usually use NDesk.Options.

[Leaf Garland]

If you are using F# then https://nessos.github.io/UnionArgParser/ is really easy to use (it has all its examples in F#...)

[Warren Young]

NDesk.Options, primarily because it’s liberally licensed, it allows a sensible command line format, and it’s fairly straightforward to use from F#:

let main argv =
// Declare option values with defaults
let help = ref false
let limit = ref 0
let src = ref None

// Set up the parser
let os = new OptionSet()
let p = os.Add("?|h|help", fun _ -> help := true)
.Add("n|limit=", fun v -> limit := int(v))
.Add("s|src=", fun v -> src := resolveAddress(v))

// Parse the command line
let nonOptionArgs =
try p.Parse(argv).ToArray()
with _ -> usage(“bad option given”); exit(1)

You have to use ref cells for the parsed values because they’re set from lambdas, which in F# 3 prevents use of mutable. I gather that F# 4 will fix this, promoting mutable to ref in this case.

And yes, I do plan on sending a sample like the above to the NDesk people at some point, so that hopefully they will put it alongside their C# one. :)

[Scott Wlaschin]

+1 for UnionArgParser -- it's da bomb!

[Jon Wood]

Not enough real-world code to learn from

This is definitely true for learning certain stuff.

Awesome info, though! Very interesting. 

[Steven Taylor]

I've found FParsec to be pretty versatile for command line args.  

--

[Matthew Moloney]

Dito - I use FParsec for this

Sent from my iPhone

[Robert Jeppesen]

That sounds complicated. Can you (Matthew or Steven) share an example? 

I've used UnionArgParser, and it works well, but brings that dreaded MethodNotFoundException that every F# project has to deal with. :) 

[Gauthier Segay]

Furthering the OT, have you all guys looked at docopt facade for F#?

https://groups.google.com/forum/#!searchin/fsharp-opensource/docopt/fsharp-opensource/G9W5Gj5o_VQ/5pFtNZkCgnkJ

The base implementation is geared to look like haskell's docopt, and
Ross Mc Kinlay clued some very nice active patterns to make matching
of set of arguments a breeze.

I've been using it and find it easy to use:
* write the doc string using docopt grammar
* put few pattern matching expressions and get all the things needed
parsed properly

no need for OO api to describe the option parser etc.

If docopt doesn't work for you (the grammar is probably more
constrained than all what those libraries allow) I understand that
other libraries might have appeal.

[Steven Taylor]

On 17 April 2015 at 09:44, Robert Jeppesen <roj...@gmail.com> wrote:

Matthew

Hi Robert,

a few points: 

1. over time configuration becomes a kind of language -- somewhere in this 4 hour 2006 3 part podcast, Van makes a comment on this ;-).  I think Van is quoting someone from the fabled Sun Microsystems if memory serves correctly http://javaposse.com/java_posse_082_interview_with_van_simmons_on_jini_and_compute_cycles_part_1).  

2. after being delighted with args framework X, I just about always find some case where I want to pass something through the args interface that wont go through elegantly.  That's never a problem with FParsec.  I can quickly edit a script rather than go through the NuGet discover / test cycle (again), or the GitHub pull request cycle.  Once you have a time investment in a certain framework, hiccups like this become more costly / annoying.  

3. on the language of configuration, it's nice to carry a style / philosophy all the way through / as far as possible rather than compromise because you aren't the framework creator.  I know Matt has some good guiding ideas and principles here all his own.  In short, there's additional friction caused when you have to jump through needless hoops (polyglot, XML, JSON).  When it's something I need to fluidly comprehend (even occasionally or heaven forbid, in an emergency), then I go in the "configuration is a kind of language" direction when I can.  It's an extension of DSL based reasoning if you will (its maybe even a type provider anti-pattern).  Could a mistake like gmail being down for half a day due to something as simple configuration have been avoided?  I wonder what that post-mortem review looked and sounded like?  

FParsec isn't burdensome, and especially not for minor cases like command line args. 

If Matt, Phil, or Thomas don't beat me to it (often the case), I'll post an example up for you.

UnionArgParser is quite neat (I was curious, so I code surfed it about four months ago).  I even like a bunch of their choices on conventions.  However, I'm a happy FParsec user, so...

cheers,

-Steven