Good starter book for non-Windows F# ?

[mars0i]

I hate asking this kind of question, because it suggests that I don't want to do my own research, but I fear that my own research would involve a lot of wasted time at something that others could answer quickly.

I want to start learning F# from a good, up to date book.   I don't use Windows, I don't know C#, or .Net in any way.  I'm on OSX, and I have a lot of other unix experience.  I studied SML and a little bit of Haskell years ago, and have also started looking at OCaml recently, but for the most part I've been living in the Clojure world in recent years. 

So I'm not a beginner with functional programming, but if I can, I'd rather not waste time trying to extract pieces of information I need from discussions of Visual Studio, or find that I can't get any use out of info about graphical programming advice because it's all Windows-based.

Any books you'd particularly recommend for getting started with mono and .NET Core?

(For whatever it's worth, I'm a big IDE fan, but I'll use Xamarin or whatever's necessary if it's just a Bad Idea to do without it.  Call me crazy, but I do most of my work in vim, with repl handy if possible.)

Thanks!

[mars0i]

(And please forgive various bits of evidence of ignorance in my post. :-)

[Jimmy Burrell]

I was in a very similar place about 1.5 years ago, only with no FP experience at all.

I recommend Visual Studio Code for the Mac with the IonIDE plugin(s) for tooling. It's lightweight with a lot of IDE features.

No particular book recommendations, but I cut my teeth on the F# for Fun and Profit website: http://fsharpforfunandprofit.com/

Hope this helps,

Jim...

[mars0i]

Thanks Jimmy.  That's very helpful.

[Warren Young]

On Apr 12, 2017, at 1:18 PM, mars0i <mars...@logical.net> wrote:
>
> I want to start learning F# from a good, up to date book.

F# 4.1 only came out about a month ago, so the most up-to-date books are still those that cover F# 4.0.

Don’t worry about that, though: the changes in 4.1 are primarily pure additions which you can learn incrementally after you finish the F# 4.0 book you decide on.

> I don't use Windows, I don't know C#, or .Net in any way.

I’m roughly the same, except that I use all the major platforms. The first serious .NET code I ever wrote was in F# 3.0. That app only runs on Windows because it drives a third-party Windows-only program, but the second serious app I wrote in F# 4.0 runs on Windows, macOS, and Linux.

So, I’ve been on both sides of the fence. I don’t find using F# on non-Windows platforms any more difficult than using other similar tools on that same platform.

> I'd rather not waste time trying to extract pieces of information I need from discussions of Visual Studio

I’ve only read a few F# books, so perhaps there are books that are basically F#-flavored Visual Studio tutorials, but that has not been my experience.

Within my limited experience, I think the book most suited to your desires is the one by the language’s creator, _Expert F# 4.0_ by Syme et al. It barely touches on Visual Studio. The bulk of the material is concerned with the language itself and its libraries, which are the same on all platforms.

That also seems to be the case for _Functional Programming Using F#_ by Hansen, based purely on its table of contents. (Haven’t read it.)

The F# language and libraries are big enough to fill several books. Any book that spent any serious amount of its space on any particular tool chain would have to shortchange the discussion of the language and libraries, so you wouldn’t want to read it anyway.

> I can't get any use out of info about graphical programming advice because it's all Windows-based.

Some GUI libraries for .NET are cross-platform (e.g. WinForms), and some aren’t (e.g. XAML).

Then you have Xamarin.Forms which is an attempt by Xamarin to express the UI once portably and have it translate to native look and feel.

> ...getting started with mono and .NET Core?

Apples and oranges.

Mono is a nearly-complete reimplementation of .NET. There are a few areas it doesn’t cover at all; I’ll point out XAML here again, for example. There are also areas with only partial support, such as ASP.NET. See the Compatibility page for more info:

http://www.mono-project.com/docs/about-mono/compatibility/

.NET Core, however, is a purposely cut-down version of .NET that runs the same on all platforms it’s been ported to: Windows, macOS, Linux, and FreeBSD, at least. There are vast areas of .NET it doesn’t support, even on Windows. Neither of my major F# apps will port to .NET Core today; it’s not even a near thing.

I cannot recommend .NET Core for anything but certain classes of narrow uses at this time. One of those narrow use cases is learning the F# language, but if you choose this path, go into it realizing that even the non-comprehensive .NET library coverage in Syme’s book will run you into the .NET Core walls. If you’re focused more on the language than the library, this may not matter to you.

> (For whatever it's worth, I'm a big IDE fan

^ not?

> I'll use Xamarin

I suspect Xamarin Studio is on its way out, at least on Windows and macOS. It’s going to stay around at least until Visual Studio for Mac is stable, but I wouldn’t bet on how much longer after that.

They’ve already stopped accepting money for Xamarin Studio proper: they want you to buy Visual Studio Professional or Enterprise to get Xamarin Studio support now.

I wouldn’t be too surprised to see Xamarin Studio ceded back to the community as MonoDevelop, only.

> or whatever's necessary if it's just a Bad Idea to do without it.

F# is a language designed with strong editor support in mind.

The main area where this shows up is that Visual Studio does near-continuous background building of your project: every time you stop typing, the IDE silently rebuilds the changed modules; if it finds problems, it puts squiggly red underlines under the flagged bits of code, just like spell-checking in a modern word processor. If you hover your mouse cursor over the marked section of code, you get the compiler error in a popup.

This means you don’t have to formally build the software to get a list of errors and warnings. It also means that as you fix those problems, they disappear near-immediately without needing to do an explicit rebuild.

That feature is doubly helpful when learning a new language that is as strict as F#, because it visually chides you as soon as you start writing code that won’t compile. This builds good habits, as it encourages you to build up a solution one simple step at a time, rather than write a whole bunch of functions and then get a pile of errors all at once when you finally dare to start a build.

This does have a downside, which is that there is a point between when you start to express a thought and when you finish it where you know it won’t compile, but if you pause in your typing, it’ll start throwing red squiggly lines everywhere. This used to stress me out a bit, but now I just ignore it when I know I’m in the middle of expressing a thought. I only pay attention to the red squigglies when I think what I’ve typed is complete. If I still get red squigglies after completing the expression, I know I’ve got a real problem.

There is a popular Vim extension that has a similar effect, but it’s far more annoying for a couple of reasons:

1. It opens a new Vim window any time you have one of these errors, which as I’ve hinted above, happens frequently. Contrast Visual Studio, which takes up no additional screen real estate to show these errors.

2. It’s far less subtle than a pale red squiggly underline, making it more stressful.

The .NET Library is also rather difficult to use without an IDE. It’s easy to scoff at code completion and such when you’re dealing with a flat or nearly-flat library namespace (e.g. C, PHP, Perl…) but .NET is both wide *and* deep. You need code completion if only to avoid RSIs.

I recommend that you at use Visual Studio for Mac (!) at least long enough to get started, then you can consider switching back to Vim once you’ve ready to take off the training wheels.

https://www.visualstudio.com/vs/visual-studio-mac/

Alternately, you can try the VS Code + Ionide + amVim (or similar) combo. I have little experience with that, but some people like that better than either Vim or Visual Studio.

> I do most of my work in vim, with repl handy if possible.)

There are Vim-compatible extensions for Visual Studio for Windows, but Visual Studio for Mac only has a few extensions at this time. I hesitate to guess how long it will take for one or more of the Vim extensions for VSWin to get ported over.

Both versions of Visual Studio have F# REPL windows — called F# Interactive — with tight integration into the regular text editor. You can highlight a section of code and send it directly to the REPL, for example.

The version in Visual Studio for Mac seems somewhat broken at the moment, though:


/unknown(1,1): error FS1225: File '/Applications/Visual Studio.app/Contents/Resources/lib/monodevelop/AddIns/FSharpBinding/FSharp.Core.optdata' not found alongside FSharp.Core. File expected in /Applications/Visual Studio.app/Contents/Resources/lib/monodevelop/AddIns/FSharpBinding/FSharp.Core.optdata.
/unknown(1,1): error FS0229: Error opening binary file '/Applications/Visual Studio.app/Contents/Resources/lib/monodevelop/AddIns/FSharpBinding/FSharp.Core.dll': Exception of type 'Microsoft.FSharp.Compiler.ErrorLogger+StopProcessingExn' was thrown.
/unknown(1,1): error FS3160: Problem reading assembly '/Applications/Visual Studio.app/Contents/Resources/lib/monodevelop/AddIns/FSharpBinding/FSharp.Core.dll': Exception of type 'Microsoft.FSharp.Compiler.ErrorLogger+StopProcessingExn' was thrown.

[mars0i]

Warren, that is incredibly helpful.  Thanks for taking so much time.  I didn't expect so much help, but it's exactly what I needed.  (It deserves to be on a webpage somewhere.  I suppose it is--the one containing this discussion.)

On Thursday, April 13, 2017 at 11:23:25 AM UTC-5, Warren Young wrote:

> I can't get any use out of info about graphical programming advice because it's all Windows-based.

Some GUI libraries for .NET are cross-platform (e.g. WinForms), and some aren’t (e.g. XAML).

Ah, i thought WinForms was Windows-only.
 

Then you have Xamarin.Forms which is an attempt by Xamarin to express the UI once portably and have it translate to native look and feel.

> ...getting started with mono and .NET Core?

Apples and oranges.

I realized that later!  Feeling my way in the dark.  It's always like that at first when you explore a new language.

> (For whatever it's worth, I'm a big IDE fan

                              ^ not?

Yes, correct.

> or whatever's necessary if it's just a Bad Idea to do without it.

F# is a language designed with strong editor support in mind.

The main area where this shows up is that Visual Studio does near-continuous background building of your project: every time you stop typing, the IDE silently rebuilds the changed modules; if it finds problems, it puts squiggly red underlines under the flagged bits of code, just like spell-checking in a modern word processor.  If you hover your mouse cursor over the marked section of code, you get the compiler error in a popup.

This means you don’t have to formally build the software to get a list of errors and warnings.  It also means that as you fix those problems, they disappear near-immediately without needing to do an explicit rebuild.

That feature is doubly helpful when learning a new language that is as strict as F#, because it visually chides you as soon as you start writing code that won’t compile.  This builds good habits, as it encourages you to build up a solution one simple step at a time, rather than write a whole bunch of functions and then get a pile of errors all at once when you finally dare to start a build.

You are convincing me to use an IDE.  That's very nice.

This does have a downside, which is that there is a point between when you start to express a thought and when you finish it where you know it won’t compile, but if you pause in your typing, it’ll start throwing red squiggly lines everywhere.  This used to stress me out a bit, but now I just ignore it when I know I’m in the middle of expressing a thought.  I only pay attention to the red squigglies when I think what I’ve typed is complete.  If I still get red squigglies after completing the expression, I know I’ve got a real problem.

There is a popular Vim extension that has a similar effect, but it’s far more annoying for a couple of reasons:

1. It opens a new Vim window any time you have one of these errors, which as I’ve hinted above, happens frequently.  Contrast Visual Studio, which takes up no additional screen real estate to show these errors.

2. It’s far less subtle than a pale red squiggly underline, making it more stressful.

I can see how that would be true.

 

The .NET Library is also rather difficult to use without an IDE.  It’s easy to scoff at code completion and such when you’re dealing with a flat or nearly-flat library namespace (e.g. C, PHP, Perl…) but .NET is both wide *and* deep.  You need code completion if only to avoid RSIs.

:-)  Interesting.

I recommend that you at use Visual Studio for Mac (!) at least long enough to get started, then you can consider switching back to Vim once you’ve ready to take off the training wheels.

   https://www.visualstudio.com/vs/visual-studio-mac/

 

Alternately, you can try the VS Code + Ionide + amVim (or similar) combo.  I have little experience with that, but some people like that better than either Vim or Visual Studio.

> I do most of my work in vim, with repl handy if possible.)

There are Vim-compatible extensions for Visual Studio for Windows, but Visual Studio for Mac only has a few extensions at this time.  I hesitate to guess how long it will take for one or more of the Vim extensions for VSWin to get ported over.

I've never used a vi keys mapping in a non-vi that got it sufficiently right.  It's hard to do because there are so many keys to emulate, and the ones I use might not be included, or the functionality may be a little bit different).  (At some point after I went through my Emacs->Vi conversion years ago, I came back to Emacs, using its viper-mode vi emulation.  Eventually I gave up; it was too annoying.)

Given the benefits of VS that you're describing, I'm willing to try it anyway.
 

Both versions of Visual Studio have F# REPL windows — called F# Interactive — with tight integration into the regular text editor.  You can highlight a section of code and send it directly to the REPL, for example.

The version in Visual Studio for Mac seems somewhat broken at the moment, though:

I can just paste into a repl in a terminal.  It's what I'm used to anyway.

I was starting to feel that I wanted to study OCaml instead of F#, even though F# seems to have a bigger community and a richer set of libraries.  I feared that I'd just encounter too many Windows-Unix impedence mismatches--missing libraries, assumptions, etc.  Of course there will have to be some of that; it's in the nature of the situation.  And it's OK.  It's a question of degree.  I care about the ramp-up curve because I'm not full-time programmer.  Coding is something that I do for work (and play), and I'm willing to take some time to learn (because it's play, anyway), but it's a small part of my work, so I don't feel I can afford to undertake too big of a learning project.  OCaml has been embedded for many years in a world I know well; F# has moved here relatively recently.  Your post makes me feel a lot better about going with F#, though.   Thanks.

[Karl Nilsson]

It is probably worth mentioning that the vim-fsharp plugin has type checking, completion and type inspection as well (sqigglies). I disagree you _need_ a full IDE to learn fsharp. IDE tooling is a double-edged sword. It can create dependencies that later are hard to shake (it took me years). That said having errors and types accessible in your editor is very useful when writing/learning fsharp.

https://github.com/fsharp/vim-fsharp

Cheers
Karl

--
--
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.

[Warren Young]

On Apr 14, 2017, at 12:32 AM, Karl Nilsson <kjni...@gmail.com> wrote:
>
> It is probably worth mentioning that the vim-fsharp plugin has type checking, completion and type inspection as well (sqigglies).

Note the Python dependency. Not all Vims are built with Python support.

Also, I’m pretty sure it was Syntastic that annoyed me with its popup window, referenced in the prior post.

Call me old-school, but I really dislike Vim splits, even for :help. I feel a compulsive need to close them as soon as they appear, which makes writing F# with Syntastic looking over my shoulder like taking care of someone’s diarrheic puppy.

IMHO. >:)

Once you start to “get” F#, you rarely need to see the actual text of the F# error message to understand what the problem is. The red squiggly underline suffices. It says, “This is wrong,” and you go, “Oh, yes, of course it is; the fix is…”

If it were otherwise, I’d say the Syntastic method is better, since it saves you from having to constantly grab for the mouse and do fine-motor-control guidance to hover the cursor over the latest in a long series of red squigglies.

Since it is not otherwise, that Syntastic window is almost always just taking up space for no good purpose.

If there’s a way to suppress Vim’s location list window, which I believe is the underlying implementation of Syntastic’s error list window, please let me know and I’ll give vim-fsharp another try.

> IDE tooling is a double-edged sword. It can create dependencies that later are hard to shake (it took me years).

Dependencies worse than Vim + Python + Pathogen + Syntastic + Mono + fsharpc + Fake + Paket/NuGet + Forge?

Maybe you’re lucky enough to have all of that in your OS’s package repo, but then how is that better than downloading the one-click Visual Studio Community installer? Is it just the difference in download and install time?

Understand, I *live* in Vim. I am not a particular fan of Visual Studio. But when writing F# code, I still pop back into VS because so far, it is a superior experience to any F#-in-Vim experience I’ve had.

[Warren Young]

On Apr 13, 2017, at 10:03 PM, mars0i <mars...@logical.net> wrote:
>
> It deserves to be on a webpage somewhere. I suppose it is--the one containing this discussion.)

Thus the industry-wide shift from tech support numbers to community support: each question only has to be answered once publicly for everyone to benefit.

> i thought WinForms was Windows-only.

Nope: http://www.mono-project.com/docs/gui/winforms/

> You are convincing me to use an IDE. That's very nice.

*shrug* It’s not my first choice, either, but it’s the best option I’ve come across.

> I've never used a vi keys mapping in a non-vi that got it sufficiently right.

I’ve run into many incomplete Vim-alikes myself. My go-to test is ZZ. If it doesn’t get that right, I uninstall it and look at the next option.

I only come back to the rejected options if all Vim plugins for that text editor fail the ZZ test or do something even worse like fail to implement /-Enter or global search-and-replace. (Seen both!)

Nevertheless, there is a gray zone between “unusably broken” and “faithful Vim clone” where it’s worth tolerating a given Vim-alike because it saves you from hitting Esc-: too many times in the other editor when alt-tabbing between real Vim and the other editor, as when writing a client program in F# for a Linux server app in C, and both pieces are in active development.

> > The version in Visual Studio for Mac seems somewhat broken at the moment, though:
>
> I can just paste into a repl in a terminal.

Unfortunately, no, you can’t.

One of the downsides of F#’s “light” syntax (as opposed to the OCaml-like syntax F# originally used) is that it requires whitespace for proper interpretation.

https://blogs.msdn.microsoft.com/dsyme/2006/08/23/lightweight-syntax-option-in-f-1-1-12-3/
https://docs.microsoft.com/en-us/dotnet/articles/fsharp/language-reference/verbose-syntax

Since F# Interactive is line-oriented, being a REPL, this means you have to rewrite F# code in the OCaml-like syntax for it to work as expected. This applies even to trivial expressions like “1 + 1”: you have to follow it with “;;” before the REPL will interpret it.

Visual Studio’s F# Interactive integration does this for you. It’s slightly magical, in the sense that you may not even realize that something clever had to happen between Ctrl/Alt-Enter and “it just works.”

> I was starting to feel that I wanted to study OCaml instead of F#, even though F# seems to have a bigger community and a richer set of libraries.

The .NET libraries are also a generally more internally consistent than OCaml’s libraries, being from a single source. Excepting the F# aliases for .NET native types, they’re all consistently camel-cased, for example, whereas OCaml libraries use camel-case, leading-cap (e.g. Nativeint instead of NativeInt) and underscores (e.g. Big_int) for module names, apparently at the author’s whim. And then for function names inside modules, it’s all-lowercase and underscores!

Let’s use *all* the styles! Then we’ll be totally styley!

(Yes, I know my stone just hit my glass Perl house. I’ll take that.)

> I feared that I'd just encounter too many Windows-Unix impedence mismatches--missing libraries, assumptions, etc.

Unless you’re going to stick with POSIX type platforms only, you’ll have to deal with that in OCaml as well.

F#’s solution to platform compatibility is generally is to abstract Windowsisms sufficiently to let them cover Unix idioms. For example, System.IO.Path’s public interface doesn’t even talk about drive letters. To get that, you call GetPathRoot(), which returns “X:” on Windows, but “/“ on POSIX type platforms when you initialize the object with an absolute path.

OCaml, on the other hand, seems to take the inverse option, which is to assume everything is Unix and hope nothing breaks. Drive letters may mean nothing to OCaml, but I assure you, they do mean something special to Windows.

[mars0i]

On Friday, April 14, 2017 at 1:05:39 PM UTC-5, Warren Young wrote:

On Apr 13, 2017, at 10:03 PM, mars0i <mars...@logical.net> wrote:

 

> I can just paste into a repl in a terminal.

Unfortunately, no, you can’t.

One of the downsides of F#’s “light” syntax (as opposed to the OCaml-like syntax F# originally used) is that it requires whitespace for proper interpretation.

    https://blogs.msdn.microsoft.com/dsyme/2006/08/23/lightweight-syntax-option-in-f-1-1-12-3/
    https://docs.microsoft.com/en-us/dotnet/articles/fsharp/language-reference/verbose-syntax

Since F# Interactive is line-oriented, being a REPL, this means you have to rewrite F# code in the OCaml-like syntax for it to work as expected.  This applies even to trivial expressions like “1 + 1”: you have to follow it with “;;” before the REPL will interpret it.

I didn't really understand this until now.  Thanks once again for all of the many helpful comments. 

I'm a fan of good code formatting, of course, but I'm not sure I like indentation-based syntax.  Delimiters seem easier to understand despite their noisiness, and they more flexible formatting (within the limits of clarity).  I've been around long enough that I can look at most languages for the first time and have good guesses about what's going on.  The first time I looked at Python it was very confusing. 

Of course F# is in good company with Haskell.  Sounds like I can choose verbose syntax, but that most code that I encounter will be in lightweight, so I need to deal with it.  Probably a small matter, though. I'd get used to it.

> I was starting to feel that I wanted to study OCaml instead of F#, even though F# seems to have a bigger community and a richer set of libraries.

The .NET libraries are also a generally more internally consistent than OCaml’s libraries, being from a single source.  Excepting the F# aliases for .NET native types, they’re all consistently camel-cased, for example, whereas OCaml libraries use camel-case, leading-cap (e.g. Nativeint instead of NativeInt) and underscores (e.g. Big_int) for module names, apparently at the author’s whim.  And then for function names inside modules, it’s all-lowercase and underscores!

Let’s use *all* the styles!  Then we’ll be totally styley!

I agree this seems like a point against OCaml.  (In Clojure the conventions are pretty consistent.  That's what I'm used to.  When someone violates the standard conventions, it really jumps out at you and looks ugly.)

I've been reading sample chapters of the books you mentioned, both of which seem good.  Syme's very first example used OO syntax for for some very basic functionality in several cases (e.g. on strings), i.e. myvariable.methodname .   I'm assuming that's the normal and perhaps required way to perform those operations.  For me this is a small point in favor of OCaml, which afaik doesn't put basic functionality into OO syntax.  I can get over it.  (I'm used to Clojure where Java interop is done with lisp-ey syntax.)
 

> I feared that I'd just encounter too many Windows-Unix impedence mismatches--missing libraries, assumptions, etc.

Unless you’re going to stick with POSIX type platforms only, you’ll have to deal with that in OCaml as well.

Well I can probably afford to stick with unixes.
(I say that now.  It's not hard to imagine scenarios where I regret it.  So more flexibility is better, other things being equal.)
 

F#’s solution to platform compatibility is generally is to abstract Windowsisms sufficiently to let them cover Unix idioms.  For example, System.IO.Path’s public interface doesn’t even talk about drive letters.  To get that, you call GetPathRoot(), which returns “X:” on Windows, but “/“ on POSIX type platforms when you initialize the object with an absolute path.

Yeah, that sounds nice.
 

OCaml, on the other hand, seems to take the inverse option, which is to assume everything is Unix and hope nothing breaks.  Drive letters may mean nothing to OCaml, but I assure you, they do mean something special to Windows.

Wait, but shouldn't everything be unix?  Why isn't it?
Kidding, obviously.