Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tour of F#

docs.microsoft.com

Post reply on HN
Print view View original

81–90 of 140 posts

Re: Tour of F#

#81

Post by bsamuels »

sp33der89 wrote: post #68
bsamuels wrote: post #44

Earlier quoted context omitted.

Unit annotation is F#'s secret killer feature. I did a small video game in F# using unit annotation and was shocked at the number of bugs that unit annotation picks up at compile time. If you work with a lot of unit conversions (pixels, inches, whatever), I highly recommend giving F# a shot on a small project. Unit annotation + access to the .NET ecosystem has made this language a personal favorite for any project he…

How was your experience with F# and game development? I like F#'s syntax so much more than C#(plus some stuff like pattern matching are so nice). However I feel like FP isn't effective for gamedev.

The biggest gains I saw had to do with the units of measure and state management, with a big emphasis on the latter.

Nearly none of the traditional game-based OOP design patterns map cleanly into F# (or any functional lang for that matter) - I often had to get creative but the results were very interesting.

Take an OOP based game for an example; tracking where your game state is, how it's being mutated, and figuring out exactly what entities have been mutated can be a nightmare. With F# I ended up with a single large data structure to store the game state, and because of F#'s pedantic immutability, it's very easy to find where that game state is modified.

The only issue with the scheme above is that there are some cases where you NEED to store game state as a variable captured by a closure. That might sound really awful, but in practice variables captured by a closure are always read-only, so unless you're replacing that closure, you don't have to worry about some weird mutability sneaking up on you.

Here's my first F# minigame, a mostly-finished breakout clone: https://github.com/bsamuels453/BreakoutFSharp

Here's the second game that uses units of measure - it was supposed to be an asteroids clone but is mostly unfinished: https://github.com/bsamuels453/X81-Prototype

Type declarations for the units of measure/data structures I used: https://github.com/bsamuels453/X81-Prototype/blob/rts/X-81_P...

Re: Tour of F#

#82

Post by camus2 »

agentultra wrote: post #12

So much like OCaml... but I like the ability to annotate units! That's very cool.

Unfortunatly Ocaml has many drawbacks:

the developer experience isn't great, it's complicated to install and to get started with and the ecosystem related to web development is quite poor. That's not the case for F# and I really really hope it picks up steam. ML languages are really great when it comes to data modelling, domain driven design, writing algorithms and stuff like that. they are a nice compromise between pure FP and OOP.

Re: Tour of F#

#83

Post by pmarreck »

phillipcarter wrote: post #55
pmarreck wrote: post #50

Earlier quoted context omitted.

Is there a writeup somewhere of this feature?

There's an article here: https://docs.microsoft.com/en-us/dotnet/articles/fsharp/lang...

That actually looks really indispensable when you're working with units! I wonder if functional langs without this feature might be able to implement it via macros somehow which only run at build time...

Re: Tour of F#

#84

Post by rokob »

omni wrote: post #41

> /// Conditionals use if/then/elid/elif/else. The "elid" intrigued me and I tried to look it up but couldn't find anything. Is this just a typo?

+1 I was also intrigued by "elid", the other response to this comment solved the mystery.

Re: Tour of F#

#85

Post by agentultra »

camus2 wrote: post #82
agentultra wrote: post #12

So much like OCaml... but I like the ability to annotate units! That's very cool.

Unfortunatly Ocaml has many drawbacks: the developer experience isn't great, it's complicated to install and to get started with and the ecosystem related to web development is quite poor. That's not the case for F# and I really really hope it picks up steam. ML languages are really great when it comes to data modelling, domain driven design, writing algorithms and stuff like that. they are a nice compromise between…

I think the only complicated part of the developer experience is something Javascript developers have become accustomed to: multiple compilers and complicated build tools. But you get over it.

There are some nice tools as well: merlin, utop, and friends.

As to the ecosystem, I beg to differ: the ocsigen suite of tools (lwt, server, js_of_ocaml), Core, Bucklescript, etc. They're all amazing, well documented, and open source.

I think both languages are quite nice honestly. F# has become a lot more attractive now that .NET is more readily available on more platforms. I hope it gains more steam too!

Re: Tour of F#

#86

Post by Rapzid »

smortaz wrote: post #24
kornish wrote: post #2

One observation from watching Go and Rust gain popularity is that having an online code evaluation tool like https://play.rust-lang.org/ or https://play.golang.org/ can do wonders for adoption. People can experiment in a sandbox without having to hop into a development environment, and peers have an easier time debugging by easily sharing and reproducing problems. For anyone interested in trying out F# online, looks…

A more recent Microsoft offering for trying F# (or Python, R) is: https://notebooks.azure.com Click on the Intro to F#. Or try the user contributed notebook: https://notebooks.azure.com/library/HorsesForCourses [msft]

Sadly I'm neither able to clone or open an existing clone for the F# notebook :(

Re: Tour of F#

#87

Post by agentultra »

sp33der89 wrote: post #68
bsamuels wrote: post #44

Earlier quoted context omitted.

Unit annotation is F#'s secret killer feature. I did a small video game in F# using unit annotation and was shocked at the number of bugs that unit annotation picks up at compile time. If you work with a lot of unit conversions (pixels, inches, whatever), I highly recommend giving F# a shot on a small project. Unit annotation + access to the .NET ecosystem has made this language a personal favorite for any project he…

How was your experience with F# and game development? I like F#'s syntax so much more than C#(plus some stuff like pattern matching are so nice). However I feel like FP isn't effective for gamedev.

> However I feel like FP isn't effective for gamedev.

Oddly, in my limited experience, it is very effective.

I can't say it's the right pattern for every game but for the current roguelike I've been working on in my spare time it's been the best thing since sliced bread. I use the Reader and State Transformer monads in a pattern similar to the Elm Architecture that results in my engine being completely deterministic.

This allows me to dump all of the initial state of the game and all of the serialized inputs to it. I can then take that dump and step through that entire game session. This is great for debugging with friends and stuff: when they encounter an error or something they don't like they can just send me the dump file and I can replay their entire session. It's been pretty cool being able to do that.

Another thing I didn't understand at first was that immutability seemed like an egregious waste of resources. It might still be for some applications but it has much better performance characteristics than my intuition had led me to believe... because structural sharing. You can have this big blob of state that looks like it's being copied every where but it's not -- under the hood you're actually sharing 99% of the previous state and not copying anything.

It's not likely you're going to be writing a bleeding-edge rendering engine in a pure FP language on any current generation hardware platforms but you can get quite far with it.

Re: Tour of F#

#88

Post by camus2 »

agentultra wrote: post #85
camus2 wrote: post #82

Earlier quoted context omitted.

Unfortunatly Ocaml has many drawbacks: the developer experience isn't great, it's complicated to install and to get started with and the ecosystem related to web development is quite poor. That's not the case for F# and I really really hope it picks up steam. ML languages are really great when it comes to data modelling, domain driven design, writing algorithms and stuff like that. they are a nice compromise between…

I think the only complicated part of the developer experience is something Javascript developers have become accustomed to: multiple compilers and complicated build tools. But you get over it. There are some nice tools as well: merlin, utop, and friends. As to the ecosystem, I beg to differ: the ocsigen suite of tools (lwt, server, js_of_ocaml), Core, Bucklescript, etc. They're all amazing, well documented, and open…

> I think the only complicated part of the developer experience is something Javascript developers have become accustomed to: multiple compilers and complicated build tools. But you get over it.

With Javascript all that bullshit is optional, it's not with Ocaml. The JS asset pipeline is totally irrelevant here, and certainly not a good example of how an ecosystem should be.

> But you get over it.

no you really don't, and you shouldn't.

> As to the ecosystem, I beg to differ: the ocsigen suite of tools (lwt, server, js_of_ocaml), Core, Bucklescript, etc. They're all amazing, well documented, and open source.

Now Compare with .NET ecosysem . I was looking for a good MongoDB driver in Ocaml the other day, didn't any good one.

Re: Tour of F#

#89

Post by jackmott »

throwaway7645 wrote: post #74
orderlyoctopus wrote: post #64

Earlier quoted context omitted.

I definitely agree. Trying to jump into F# without any knowledge of .NET just requires so much mind-juggling. As a beginner, so much of the difficulty and frustration comes from the fact that you are missing so much foundation knowledge that you don't know what to ask or look for, and may not even recognize the answer. Interop won't look or behave or be optimized how you expect and will just wreak havoc with your att…

I can't upvote your comment enough. Learning F# w/o .NET and Clojure without JVM knowledge is next to impossible. There is no good doc despite what people say (and I own several books in this space). Scott W's F# articles are great for foundational FP, but neither that, any of the F# books, or any of the online tutorials show me how to do even simple things like iterate through a file. I'd love to see "Basic Office P…

https://gist.github.com/jackmott/988b4742394cf5e7d331e31c0ee...

Re: Tour of F#

#90

Post by orderlyoctopus »

smoothdeveloper wrote: post #75
orderlyoctopus wrote: post #69

Earlier quoted context omitted.

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 wa…

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

Post reply on HN