3 ms·

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

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

cm2187 9y ago
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).
- yawaramin 9y ago
  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 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-practice/ https://making.pusher.com/golangs-real-time-gc-in-theory-and...

cm2187 9y ago

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

yawaramin 9y ago
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 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-practice/ https://making.pusher.com/golangs-real-time-gc-in-theory-and...