3 ms·

I’m glad to see that the language is moving forward in these areas, but I don’t think you understand how F# implements units of measure. It’s not just another d

by jolux 6y ago

I’m glad to see that the language is moving forward in these areas, but I don’t think you understand how F# implements units of measure. It’s not just another data type, they’re fully inferred and checked and work with generics: https://stackoverflow.com/questions/21538563/can-f-units-of-measure-be-implemented-in-ocaml https://stackoverflow.com/questions/21538563/can-f-units-of-... Type providers are a native feature, no plugins required. I have no animosity towards OCaml (in syntax and semantics, I prefer it!) but this is a bit of a stretch. I don’t think anyone would say Haskell does multicore the “wrong” way, and OCaml as you say has had decades to solve these problems. I love the language but the community is very small and the language evolution has been extremely conservative for the most part.

yawaramin 6y ago
> I don’t think you understand how F# implements units of measure. It’s not just another data type, they’re fully inferred and checked and work with generics Yes, units of measure are really cool, and I understand they support dimensional analysis out of the box. It's quite unique, and I fully agree that abstract types don't fully replace them. Just saying that that's what people do in OCaml. > I don’t think anyone would say Haskell does multicore the “wrong” way And it certainly is not something that I said. > OCaml as you say has had decades to solve these problems. The 'problems' being the lack of multicore support? As I said, this is not really stopping people from getting real work done in industry–see everyone using OCaml currently in highly concurrent and multi-process parallelized applications, or in fact even people using NodeJS, Python, Ruby. > the community is very small Correct, but it is definitely growing. > and the language evolution has been extremely conservative for the most part. Not so correct. There have been massive amounts of changes in the last few years: https://www.ocamlpro.com/2019/09/20/a-look-back-on-ocaml/ https://www.ocamlpro.com/2019/09/20/a-look-back-on-ocaml/ And this is not even taking into account the features which OCaml had before then beyond F#: - Polymorphic variant types - Structural subtyped object types - Named arguments - Optional arguments - Functors
- jolux 6y ago
  F# has named and optional arguments and I named everything else as real differences in my initial comment in this thread. I’ve interviewed with Jane Street and gotten an offer on the basis of my OCaml and F# skills. I understand where these ecosystems differ. I rest my case.
  - yawaramin 6y ago
    From https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/parameters-and-arguments#named-arguments https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe... > Named arguments are allowed only for methods, not for let-bound functions, function values, or lambda expressions. > ... > Optional parameters are permitted only on members, not on functions created by using let bindings.
    - jolux 6y ago
      I concede that point.

by jolux 6y ago

yawaramin 6y ago

> I don’t think you understand how F# implements units of measure. It’s not just another data type, they’re fully inferred and checked and work with generics Yes, units of measure are really cool, and I understand they support dimensional analysis out of the box. It's quite unique, and I fully agree that abstract types don't fully replace them. Just saying that that's what people do in OCaml. > I don’t think anyone would say Haskell does multicore the “wrong” way And it certainly is not something that I said. > OCaml as you say has had decades to solve these problems. The 'problems' being the lack of multicore support? As I said, this is not really stopping people from getting real work done in industry–see everyone using OCaml currently in highly concurrent and multi-process parallelized applications, or in fact even people using NodeJS, Python, Ruby. > the community is very small Correct, but it is definitely growing. > and the language evolution has been extremely conservative for the most part. Not so correct. There have been massive amounts of changes in the last few years: https://www.ocamlpro.com/2019/09/20/a-look-back-on-ocaml/ https://www.ocamlpro.com/2019/09/20/a-look-back-on-ocaml/ And this is not even taking into account the features which OCaml had before then beyond F#: - Polymorphic variant types - Structural subtyped object types - Named arguments - Optional arguments - Functors

jolux 6y ago
F# has named and optional arguments and I named everything else as real differences in my initial comment in this thread. I’ve interviewed with Jane Street and gotten an offer on the basis of my OCaml and F# skills. I understand where these ecosystems differ. I rest my case.
- yawaramin 6y ago
  From https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/parameters-and-arguments#named-arguments https://docs.microsoft.com/en-us/dotnet/fsharp/language-refe... > Named arguments are allowed only for methods, not for let-bound functions, function values, or lambda expressions. > ... > Optional parameters are permitted only on members, not on functions created by using let bindings.
  - jolux 6y ago
    I concede that point.