Live data from Hacker News

Tour of F#

docs.microsoft.com

121–130 of 140 posts

Re: Tour of F#

#121

Earlier quoted context omitted.

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…

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

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.

Re: Tour of F#

#122
post #88

Earlier quoted context omitted.

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

It's going to be hard for any language to compete with the .NET ecosystem due to the hundreds of millions of dollars of funding it gets from industry compared to OCaml.

There's still room for both and they're still both great languages. That F# is quite similar to OCaml is a good thing... it means there must be some good ideas in there. :)

As for a MongoDB driver I found https://opam.ocaml.org/packages/mongo/mongo.0.67.2/ on OPAM in a few seconds. OPAM has been huge.

Re: Tour of F#

#123

Earlier quoted context omitted.

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

Obligatory prog21 article on that topic:

"A Worst Case for Functional Programming?"

http://prog21.dadgum.com/189.html

Previous HN discussion: https://news.ycombinator.com/item?id=7043644

Re: Tour of F#

#124

Earlier quoted context omitted.

For starters this is enough and less confusing IMHO: open System.IO for line in File.ReadLines("/path/to/file") do printfn "%s" line

If you could make about 50 more of these snippets...I'd be using F# everyday :)

boom http://fssnip.net/

Re: Tour of F#

#126

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.

Sounds like the same issue I had with Clojure and Scala. As soon as you touch anything Java or mutable, it's like WTF? Come to the Elixir/Erlang camp; our functional turtles go all the way down! The only jarring thing is having to write to a mutable database. They even borrowed the |> operator! And it has great pattern matching of course.

Yeah, Elixir or Haskell is probably the way I'll wind up going if I want to pursue functional programming again. I can do the basics enough to handle LINQ well and stuff, so I'm getting away without a strong knowledge for now.

One of the biggest disappointments in software development to me though is that practically all of the cool libraries these days are hitting the javascript ecosystem rather than those of all the interesting languages.

So if you want to interact with these great libraries, you have to tolerate a pretty shitty language with annoying tooling at best. So when I want to do something practical, I wind up going that way disappointingly often.

Re: Tour of F#

#127

Earlier quoted context omitted.

Sounds like the same issue I had with Clojure and Scala. As soon as you touch anything Java or mutable, it's like WTF? Come to the Elixir/Erlang camp; our functional turtles go all the way down! The only jarring thing is having to write to a mutable database. They even borrowed the |> operator! And it has great pattern matching of course.

Or use both: https://www.youtube.com/embed/HLs6WgAmX64

Holy crap. Interesting!

Re: Tour of F#

#128

Me while looking at the examples: Hmm F# looks like an easier version of Rust. I wonder how much of Rust was inspired by F# (since F# is older).

I don't know about any direct links, but they both have a common ancestor in Ocaml.

Re: Tour of F#

#129

Me while looking at the examples: Hmm F# looks like an easier version of Rust. I wonder how much of Rust was inspired by F# (since F# is older).

Not much directly, but they both took a lot of inspiration from OCaml, so that'd make sense! A family resemblance.

Re: Tour of F#

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

I've wrote a java REPL that runs locally but can upload to remote: http://jpad.io/example/1E/fetch-headlines-using-jsoup

My issue with the online editors is that it restricts your ability to access files, add dependencies and modify your local machine. If anyone would like an online version I'd be interested to hear why?

Post reply on HN