Live data from Hacker News

Tour of F#

docs.microsoft.com

61–70 of 140 posts

Re: Tour of F#

#61
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…

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. One of the things Go does right is the download-hello-world-compile-run experience. Especially now, since they now default GOPATH. One of the things that Go does wrong for popularity is the opinionated directory structure base…

What's the default behavior now? This greatly annoyed me when I first started with Go.

Re: Tour of F#

#62
post #58

Earlier quoted context omitted.

F# works fine for me on linux. what is it you're after?

well i mean there's all this stuff i vaguely see about .NET Core not being as good as the offering on windows but that eventually it will be? i don't know C# but i'm interested. i guess i'm just wondering if i should make the leap to starting to learn it even though i develop solely on linux.

F# works well on Mono, well enough to start learning/developing on until .NET Core gets to real production-grade status on Linux. (I've only toyed with .NET Core on Mac/Linux - it worked well enough for some simple stuff - but haven't tried to run any heavy apps on it yet.)

Re: Tour of F#

#63

I realize that .NET is F#'s biggest strength from the perspective that Microsoft probably holds of trying to push C# more functional, and trying to attract talent from R, Ocaml, Rust, Julia, Haskell, etc, but it also feels like its biggest weakness. I'd love to see some sort of bootstrapped version that makes use of .NET Native or CoreRT or whatever they use today, and I'd REALLY like to see a strong Stdlib for F# th…

Edit: just before somebody starts whining about it, I ain't got no problems with NET on its own, but the barrier to proficiency in it from a functional universe is needlessly high, and if F# had a stronger core it would be something non NET programmers could pick up along the way rather than continuously bash their heads into while doing rather menial work. I don't want to sound whiny either but it's such a punch in…

What is needed is new blood among F# users, not coming from C# background and not too snob about F# not having most advanced type system when compared to Haskell or other similar ML languages.

Then, effort on making functionally orientated base libraries (without relying on baking those things in FSharp.Core, but as set of small libraries) wrapping undelrying .NET APIs, taking inspiration from what is there in Haskell and other similar languages.

Most F# users today are fine relying on mostly .NET libraries + fresher F# libraries, but most projects will be done with a mix of paradigms (which is manageable in F#) which is not most appealing to people with significant FP background.

Re: Tour of F#

#64

The problem I had going into this without a strong functional background is that often times to do practical things you're forced to work with .NET libraries - these .NET libraries are not nice functional libraries and don't encourage you to think functionally. Eventually I felt like everything I wrote was wrong and I just gave up on it.

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 attempts to build a mental model of what you're learning because of the strange inconsistency.

Sometimes the answer is just so obvious to people who have that foundation knowledge that no one else has bothered to ask on reddit/stackoverflow and you are googling into the wind. Sometimes the only thing you can find is several years old and giving advice that's no longer correct. I'm not sure which is worse.

I had the same trouble trying to build a learning project in Clojure. I remember when starting, I had only used pip and apt-get (and not knowing them well), I didn't even recognize Leiningen as a package manager. It worked so differently from what I thought I needed (and billed itself as a "project automation and configuration tool") that I didn't even recognize it was the solution to my problem.

It's just so easy to take for granted how many things are obvious to us that make solving problems in our comfort zone easy for us and paralyzing for another person, and I think this bias finds its way into the documentation and mindset of entire communities. This makes it harder and harder for something to be approachable if you don't fit in that same box. I'd love to love F#, (I read F# for fun and profit and worked through the F# Koans, but haven't made anything), but I'm not sure if I'll ever get over the hump unless I find myself working somewhere that's already using it. My feelings on Python are somewhere between ambivalent and bitter by now, but the work gets done, I know what to expect, and I never feel lost.

What would really help me, I think:

- More "idiomatic" wrapper libraries around .NET libraries, even if they're slower or have less features/customization.

- Pure F# libraries of typical utilities or ports of popular libraries in other languages, even if they are slower or have less features/customization.

- Content about F# project management from the perspective of someone who uses Python. This is how you do it in Python, this is how you do it in F#, this is why, these are the pros, these are the cons, these are just different because that's the way it is.

Re: Tour of F#

#65
post #60

Earlier quoted context omitted.

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. One of the things Go does right is the download-hello-world-compile-run experience. Especially now, since they now default GOPATH. One of the things that Go does wrong for popularity is the opinionated directory structure base…

> If Go had some way of mitigating that and the lack of generics, then the Hello World experience would be better for more people. Does the lack of generics really impact the experience of "Hello World"? I don't think I've ever seen generics used in a "Hello World" example even in languages that have them.

No, but if you believe the ramblings of the standard HN commenter who complains about Go, very soon afterwards the lack of generics has driven them to gnashing teeth and rending hair.

Re: Tour of F#

#66
post #19

The problem I had going into this without a strong functional background is that often times to do practical things you're forced to work with .NET libraries - these .NET libraries are not nice functional libraries and don't encourage you to think functionally. Eventually I felt like everything I wrote was wrong and I just gave up on it.

I had the same feeling with Clojure. I'm not sure it's due to not having a strong functional background; I think it might be the reality of interop between very different languages.

Definitely. Understanding Clojure/Java interop to consume a library requires that you understand both Clojure and Java far more than you would need to if you were to consume a library native to whatever you were using.

Re: Tour of F#

#67

Earlier quoted context omitted.

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. One of the things Go does right is the download-hello-world-compile-run experience. Especially now, since they now default GOPATH. One of the things that Go does wrong for popularity is the opinionated directory structure base…

What's the default behavior now? This greatly annoyed me when I first started with Go.

GOPATH now defaults to $HOME/go or the equivalent for your OS.

Re: Tour of F#

#68

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

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.

Re: Tour of F#

#69

The problem I had going into this without a strong functional background is that often times to do practical things you're forced to work with .NET libraries - these .NET libraries are not nice functional libraries and don't encourage you to think functionally. Eventually I felt like everything I wrote was wrong and I just gave up on it.

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

Re: Tour of F#

#70

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.

Curious about this also. Last time I took a peek at F# I wanted to make a simple game, but all the compatible tools seemed like C# tools that allegedly work for F# as well. Wound up using Lua/LOVE instead.
Post reply on HN