Comment by cm2187 | Hacker News Reader

Comment by cm2187 | Hacker News Reader

There was a nice video on F# 101 on MSDN recently:

https://channel9.msdn.com/Shows/On-NET/A-tour-of-F-with-Phil...

There are two passages that I found amusing.

First the guest mentions the merits of F#'s deep implicit typing, where the use of a function at the top may determine the typing of other nested functions. And as one would expect with this level of things happening implicitly, it is very easy to get lost in what is going on, which is exactly what happened to the guest at minute 27, where he couldn't figure out why the F# compiler wasn't implying the correct type.

Later on the guest mentioned that for all their API, they actually create a signature file (i.e. a header file) where you have to declare every function signature separately from the implementation. The host diplomatically mentions that perhaps this might maybe be a little bit cumbersome to maintain. The answer is that it's not a problem, as the program simply doesn't compile if you have a mismatch.... Hum.

I like certain aspects of it, not using too many special characters (kind of python/vb style), the immutability, etc. But I can't say I am sold and ready to switch though. And many of what are presented as key features are just not the kind of things I have any use for, like declaring lists of consecutive numbers (can't remember the last time I needed one) or F# type providers (I rarely have to deal with unexpected file data formats).

Yes, to be honest in languages with type inference you have to rely on your editor/IDE to show you types on demand. You do need that to be able to work smoothly on a day-to-day basis. Of course you can and should learn how to reason about the types, but you still need quick feedback about whether the compiler agrees with your reasoning.

To your second point, about the 'header' (interface) files in ML-family languages like F#--that is a really great feature because it lets you do abstraction and access control. The interface file specifies what callers are allowed to see, you can use them to make your types truly abstract and prevent access to your modules' internal functions.

About lists of consecutive numbers ... not sure what that is referring to exactly. About type providers ... yes, I agree with you that not everyone finds a use for them. In general, I will say that the killer feature of F# and other ML-family languages is that they dramatically increase code refactorability (low-ceremony static types) and dramatically reduce lines of code (simple, 'math-y' syntax).

For consecutive numbers I am talking about the [1..99] notation. Very useful in academics to make a demo when you don't have real data. But less so in the real world. What I mean is that many of these demos tend to address problems that I do not have personally.

Multithreading is a good example. It is hard to do at a low level. And I totally get why F#'s approach helps a lot. But I find that you get most of the benefits of multithreading by splitting your task in independant subtasks that are not thread safe but do not share writable data, and run a parallel.for at the top. Occasionally you need some locking if you have a common cache but that's easy to get right.

Sure you could optimize it a little bit more by making it multithreaded at a lower level but most of the time that's enough to get 90% of the performance benefit.

I am also a bit uncomfortable with the liberty F# takes with memory. To make everything immutable you create a lot of copies in memory. All the .net performance articles I have read mostly focus on taking it easy with the garbage collector and reducing the number of allocations. Intuitively it doesn't sound like an obvious trade off (thread safety vs more garbage to collect).

Oh, the range notation. It's a little convenience that can save a bit of typing here and there. Not a tremendously important feature, to be honest.

About multithreading, not sure what you mean but F# definitely has parallel collections in addition to its general async capability that lets you handle concurrency in a safe way. If you haven't already, check out the Hopac project (http://hopac.github.io/Hopac/Hopac.html , scroll down to the Description section).

About memory use, yes you create copies but at the same time immutability means you can have persistent data structures which share and thus save a lot of memory. Also, in general performance is good enough that you don't really have to worry about it, and when you do, you can always measure, profile, and see what's actually causing the memory pressure.

That said, it's true that functional programming languages have a different memory profile than imperative languages, and implementations which have been designed with this profile in mind perform really well. E.g. check out OCaml's performance in this GC pause benchmark: https://making.pusher.com/golangs-real-time-gc-in-theory-and...

It's true that it's easier to write and arguably harder to read code when types are not specified, or at least it's handy for public interfaces between modules. Luckily this is easy to do and often done:

https://fsharpforfunandprofit.com/posts/function-signatures/

It's the same deal with Haskell, you don't HAVE to specify the types of your code but it can help check your assumptions as to what the compiler is inferring. I've frankly found that a more frequent issue in Haskell because of pervasive use of Monads and other higher-order constructs.

Reply on news.ycombinator.com