What I appreciate about books like this is that they assume the reader is already familiar with programming, and so the book cuts to the chase and explains why this language is unique and how it is different from the languages the reader probably already knows. The author was smart enough to know that very few students of F# will have picked F# as their very first introduction to programming, so this makes a lot of sense. I get frustrated with programming language tutorials that take the opposite approach and expend multiple screenfuls carefully explaining what a variable is.
f* yeah lots of tutorials and books start saying "do as i say, write everything i ask you to do, i know more than you noob" specially those made by the author of "learn * the hard way".
I've been getting into F#, specifically for Monogame & Unity, and Scott's website, blog, and videos have been incredibly helpful in introducing F# and highlighting the strengths of the language.
I currently only use F# for fun and games. I hope to use it for an upcoming project however.
What are the limitations of using F# with Unity? Do you have full access to the Unity APIs? Can you write F# scripts and have them run in WebGL or iOS deployment targets? How does it work?
F# might just be the thing I'm looking for. And I love the idea of functional programming in unity.
Currently you can't target iOS, Windows store & WebGL with F#. For these platforms Unity uses an IL to C++ transpiler which doesn't work with F#. This might change in the future (one of the Unity devs submitted an IL2CPP issue in the F# github repo a few weeks back).
Desktop platforms work fine.
F# doesn't have the Unity editor and project support that C# & UnityScript have. In practice this isn't much of an issue.
There are few things to be mindful of:
1. The F# target platform must be changed to Unity's .net 3.5 equivalent. Similarly, full framework support must be enabled in Unity.
2. VS debugger support requires turning off optimisations and running a post build step to convert between Microsoft's pdb format and Mono's mdb. The debugger itself is actually far more stable for F# than for C#.
3. Unity profiler support requires adding the compilation symbol 'ENABLE_PROFILER' to the F# project.
The Mono runtime Unity uses is, I think, a fork of Mono 2.8. The tailcall op wasn't implemented in Mono until 2.10 (again, I think). The tailcall op is essentially ignored by Unity Mono.
To date, we haven't had a single stack overflow in our 10k LOC app.
I should mention that the style of programming we are using is alot more imperative than the typical F# program. Any potentially large collection is an Array, C# list or Dictionary. F# immutable lists (and maps) are still used in most areas where data sizes are known to be small and allocations are not so important.
The Mono runtime used by Unity has a very inefficient non generational garbage collector (conservative Boehm). A generational GC wasn't introduced until 3.x. Unfortunately this tends to lead to a less functional and more 'allocate once and reuse' style.
The Mono JIT also produces code which is often an order of magnitude slower than MS .net (which itself is slower than coreclr).
Despite these caveats - a significant proportion of code can be written in a purely functional style and good performance can still be achieved.
That's exciting to know. I hope to give F# and Unity a try sometime soon, then!
I remember the XNA C# runtime on the Xbox 360 required similar strategies with memory as well. It's nice to see garbage collectors improve as time goes on.
I hear it's particularly good for unit tests depending on the domain. I have a coworker who regularly writes his production code in C# and unit tests in F#. He says it's faster but I don't know enough F# to be able to say if that's true or if he just likes using both languages :)
Faster in what? They both compile to IL code, and there execution speed is relatively the same, C# has it beat on somethings F# wins in others. Development wise, once you get used to it, I find it much faster. I have to write less code, and it's generally more correct the first time due to the rules it enforces.
I was about to mention perhaps they mean faster to write, and also conceptualise, but you nailed it.
I find with F# that sure you are writing less actual code, like 1000 characters instead of 2000, but for me the biggest gains from using/thinking in a functional paradigm, and having access to functional tools is in the process of actually tackling problems. The conceptualisation, execution and testing of solutions for these problems for me has been less onerous and more enjoyable with F# than using C#.
This is fantastic. I like the progression in the table of contents. Something similar on the website might be helpful - it is packed chock full of useful information and great tutorials, but could perhaps use a little better organization.
edit: typo
edit 2: well I was a bit too eager to add the website just to find it to be the base for the linked GitBook- my bad- I just appreciated the content so much ;)
I love his videos. My girlfriend thinks I am a complete nut because the first time I watched this video 'Functional programming design patterns' (https://vimeo.com/113588389) I was crying with laughter. She just couldn't understand.
I do F# full-time at work, and I program with it for fun too. I'm a big fan of the language, and I think this site helped me make the full switch from C#. I've long been hoping for an ebook version--I must've printed out half of this site the last time I went on an international flight!
Sorry for the late response. I work in the utility industry writing internal web applications. Before I started, my former lead convinced our manager (who is generally hands-off) to let him work in F#
Is it just me, or are the links at [0] broken? That is, when you try to click through some of the examples such as "Use F# to explore the .NET framework interactively"?
You're correct. The table of content links didn't work. Fixed now if you want to try again (refresh browser cache first). The anchor part (to link directly to a header) doesn't seem to work in the frame, but does work if you open in a new tab. Thanks for the bug report!
I've recently been playing with F# on the side to learn more about functional programming and his website version has been a key part of what has kept me going. It's good to see an easy-to-read ebook version!
F# is impressive and so is the website. I highly recommend reading this if you are interested in F#/functional programming.
When I used F#, maybe three years ago, it was a good exercise in functional thinking. It was an interesting experience, siniliar to the experience of using C-Lisp. The worst part was the lack of documentation and community.
The main usable documentation is in the book Expert F# by Don Syme et all which demonstrates how to use all the nifty language features for real life code. I think it's a pattern with nearly all Microsoft products - you need to buy training (e.g. in the form of book) to use them properly.
That's been improving, though last I checked the documentation for the language's more advanced features - workflows, quotations and type providers - remains woefully lacking, and mostly just consists of a few blurbs of example code.
