It became easier recently with droping a dependency on libgdiplus.

IIRC you just need to install mono, python, jupyter and ifsharp: https://github.com/fsprojects/IfSharp

All but last one should be on brew, for last one, you should be able to build it out of box with mono installed.

Don't hesitate to report issue on the repository if that fails.

Thing is that putting together short helpers for the "nasty" bits often revolve around 1 line helpers.

You can do so along the way without focusing so much on doing idiomatic FP and achieve both pragmatic and palatable results.

Designing solutions with the type system enabled by F# and it's ability to interop with whole .NET ecosystem is really a powerful combination.

It's very hard to do it along the way if you aren't familiar with C# either. Now you're struggling to get your head around both paradigms as well as however the thing you're trying to do works.

I doubt I would have ever stuck with Clojure longer than a day, for example, if it wasn't for this library. It's not very long and all the functions are very short, but it meant that everything I needed from the file system was a 30s peek at the documentation and exactly what I expected rather than ~30+ minutes futzing with Java and forgetting what I was doing in the process https://github.com/Raynes/fs

> It's very hard to do it along the way if you aren't familiar with C# either.

Which I keep overlooking with so many years of C#, I'm so sorry about that :(

That being said, looking at the .NET framework documentation and hanging out on fsharp.org's slack might be a good way to make up for what you are missing to get started.

If I ever get up the nerve to give it a real try, I will certainly test the slack's patience for stupid questions :)

The .NET reference is useful if you are reading through code and maybe to modify it slightly, but I find it (and class hierarchy style docs in general) to be close to useless if you are writing new code and new to the library. Using a new library in Python (especially one that's heavily object oriented), I often find it easier to learn from tests instead of the docs. Reference docs are often inaccurate or too verbose or show no sense of importance or are just poorly written. Tests are straight to the point, include examples, and tend to focus on the most important parts of the library.

The MSDN docs have quite a bit of "How do I..." content, but unfortunately F# is seemingly always blank as an example.

Combine this with a huge proportion of commonly used third party libraries being .NET rather than F# libraries, and so much of the .NET infrastructure you need to use being C# focused, and as a newcomer you are paralyzed.

If F# is serious about building a community of more than just C# converts, they need to recognize that the convenience of .NET for people who already know it carries a commensurate tax for everyone who doesn't. It's harder for me to learn .NET as an F# user than a C# user. It's harder for me to learn to use NuGet as an F# user than a C# user. It's harder for me to learn to use Visual Studio as an IDE with F# than C#. In everyone of these scenarios, you're running up hill because examples and documentation and interfaces are all for the majority, which you won't be.

These are some excellent points. There's no organised, searchable F# package index. We rely heavily on NuGet, which is a generalised .Net mishmash. And we suffer from the same problems that almost every other non-dominant language does when targeting a runtime dominated by another language.

The best I can offer you right now for F#-specific packages is http://fsharp.org/community/projects/ --and the advice that, if you have questions, ask away! F# people will be, I think, extremely ready to answer any questions because we're desperate to see people use the language. Try the mailing list ( https://groups.google.com/forum/#!forum/fsharp-opensource ), https://fsharp.reddit.com/ and the Functional Programming Slack at fpchat.com (well, this one will be back online in a few days--they recently had some drama, which they settled, but they had to disable new signups to let everyone cool down).

If they're desperate, please tell someone to write a book for noobs. I opened The Book of F# and recoiled in horror. The whole book was basically if you're a C# expert, here is how F# is different...or at least a lot of it.

Sorry, you picked the wrong book to start with. Its blurb page says: 'If you're a traditional .NET developer used to C# and Visual Basic, discovering F# will be a revelation that will change how you code.... Break free of that old school of programming.'

Try Pickering & Eason's Beginning F# 4.0; its intro has a 'Who Is This Book For?' section, which says: 'This book is aimed primarily at IT professionals.... A working knowledge of the .NET framework ... would be nice, but it's not necessary.'

Lol I learned that very fast while reading through :)

Isn't 4.0 pretty far out of date now?

Just putting it out there for the next person who sees this :-)

F# 4.0 is not really out of date. The language is fairly fixed now--apart from fixing buggy behaviour actually.

Part of it is that the general ML syntax is pretty timeless--all ML books share this advantage. As for F# specifically, all the headline functionality--type providers, quotations etc.--has been there for a while. I expect books covering 4.0 to be remarkably future-proof.

Thanks!

there is also http://try.websharper.com/ for toying with the language and websharper.

The other thing is footprint of codebase, despite almost 15 years of using C#, after only two years, I consistently write F# which is 1/3 of equivalent C# code, writing idiomatic code that any F# developers would grasp.

There are ways a C# aficionado would take to try to not be so verbose, but those solutions won't be considered idiomatic by 99% of C# developers.

At the end of the day, codebase size matters a lot.

They will still remain generally more painful and more exposed to their issues and choices:

* mutable by default

* OO by default

* null by default

* structural equality a pain to implement

* immutable types a pain to implement

* verbose syntax / failing at the DRY principle

* statement based rather than expression based

* large codebase following those idioms

I don't think they'll not remain popular, but I think a more important share of people will eventually "get it" that there are alternative approaches which are sound, same or greater potential to achieve and thriving eco-system.

Managers don't care about those bullet points.

If you want to sell a language to the upper layers, you need a list of business reasons, not language features.

See if testimonials help: http://fsharp.org/testimonials/

As for me, I also use the awareness of manager to the developer needs to be productive, give best ROI and would definitely use that to select a job.

I am aware of them, my comment was more a kind of heads up, because I have been in too many meetings about technology adoption, whose presenters though an endless list of features was the best approach.

I see what you mean.

Really reduced codebase size and features like type provider which increase safety and saves from writing boiler plate code do save on the bottom line, especially in maintenance.

Also, if you are using vanilla C# for math computation, you can save CPU/energy by translating it to F#, it tends to run significantly faster, that also impacts the bottom line in some contexts.

Try fsharp with interactive, with paket it is also very easy to depend on complex graph of nuget dependencies.

Try defining an instance member with var in C#

better type inference for anonymous functions, better type inference for instance members.

Another big feature is code layout being more compact and consistent than in C# codebases.

Thanks!

Cobra language solved this and compiles to C#, they can introduce non nil references, but yes they can't scrap the BCL which is nil ridden.

Seems to go against null propagation operator though :)

Consider contributing to a type provider for the database engine of your choice, I use SQL Server and F# is a better choice than C# in this regard anyday because of the type provider library that was created by community.