4 ms·

At least in the case of Haskell, it is explicitly so. Haskell is a language that is meant to support programming language research, and you can see that manifes

At least in the case of Haskell, it is explicitly so. Haskell is a language that is meant to support programming language research, and you can see that manifest itself all up and down the design of its toolchain. It's a woefully under-appreciated factor in Haskell's famous learning curve. OCaml less so, but the Jane Street monoculture means that, if it's not itchy for a trading firm, it's not gotta get scratched. Trading's an odd industry, tech-wise. There are aspects of the OCaml ecosystem that eliminate any of my own desire to use the language that I would have seen as neutral or even strongly positive when I worked at a trading firm. (At least during working hours.) So, yeah, I do think that one of the big things that's missing from typed FP right now is a strong language that has similar semantics to an ML or (preferably) Haskell, but with a much more pragmatic focus. F# is really nice if .NET is an option for you, but I'd sure like to see something that is statically compiled and can produce C-friendly binaries, so that it can play nice with a wider variety of pre-existing codebases.

pjmlp 8y ago
In what concerns F#, there is Mono AOT, IL2CPP, eventually CoreRT and .NET Native might support F# native compilation as well.
- weberc2 8y ago
  Out of curiosity, how do these compare to `go build`? I'm jaded by years of C and C++ which of course can statically link, but doing so in practice is tedious and error prone and still often not possible (e.g., many popular libraries can't be statically linked or it's infeasible to do so).
  - pjmlp 8y ago
    Well, Xamarin applications for iOS use Mono AOT and Unity gameplay code gets compiled to native code for deployment on game consoles and iOS, optionally on Android. As for compilation time, Go compilers use very basic optimizations as such they tend to compile faster, but hardly impressive for those that ever used TP, C++ Builder, Delphi, Modula-2 and similar languages.
    - weberc2 8y ago
      Sorry, I read your comment before my coffee and misread "native compilation" as "static compilation", so I'm conflating two distinct things.
    - vram22 8y ago
      Some Borland language tools' compilation speeds were insane. I remember them claiming 100s of KLOC per second compilation speed for their BCC++ and Delphi. Anecdotal experience bears it out. Even TP used to compile real fast. I read somewhere that early TP versions were written in tuned assembly.
int_19h 8y ago
> There are aspects of the OCaml ecosystem that eliminate any of my own desire to use the language that I would have seen as neutral or even strongly positive when I worked at a trading firm. Can you give some examples? Really curious.
- bunderbunder 8y ago
  No support for multi-core parallelism. Strings are sequences of 8-bit characters, so crappy Unicode support. Weak support for non-Unix OSes.
  - int_19h 8y ago
    I'm curious as to why you'd consider them advantages in that specific line of work. I can see lack of threads as an advantage in that it doesn't let you write multithreaded code with shared state, and forces into some kind of multiprocessing with message passing. But why would you prefer strings as 8-bit-clean, or weak support for non-Unix?
    - bunderbunder 8y ago
      Multithreading is the stronger positive. I'm guessing 8-bit strings is a minor positive, on the basis that you really don't need to deal with non-ASCII text in that kind of setting, and there's probably some performance benefit to not supporting it. Even if you stick to characters from 7-bit ASCII in your own data, if the strings are technically UTF-8 or UTF-16, then the fact that it's a variable-length encoding means that more string operations will involve costly branch instructions. And if UTF-32, your strings will be 4x as big as they need to be. Not working on non-Unix is neutral. There's no benefit to it, but nothing was going to be running on Windows, anyway, so there'd have been no harm in it, either.

pjmlp 8y ago

In what concerns F#, there is Mono AOT, IL2CPP, eventually CoreRT and .NET Native might support F# native compilation as well.

weberc2 8y ago
Out of curiosity, how do these compare to `go build`? I'm jaded by years of C and C++ which of course can statically link, but doing so in practice is tedious and error prone and still often not possible (e.g., many popular libraries can't be statically linked or it's infeasible to do so).
- pjmlp 8y ago
  Well, Xamarin applications for iOS use Mono AOT and Unity gameplay code gets compiled to native code for deployment on game consoles and iOS, optionally on Android. As for compilation time, Go compilers use very basic optimizations as such they tend to compile faster, but hardly impressive for those that ever used TP, C++ Builder, Delphi, Modula-2 and similar languages.
  - weberc2 8y ago
    Sorry, I read your comment before my coffee and misread "native compilation" as "static compilation", so I'm conflating two distinct things.
  - vram22 8y ago
    Some Borland language tools' compilation speeds were insane. I remember them claiming 100s of KLOC per second compilation speed for their BCC++ and Delphi. Anecdotal experience bears it out. Even TP used to compile real fast. I read somewhere that early TP versions were written in tuned assembly.

int_19h 8y ago

> There are aspects of the OCaml ecosystem that eliminate any of my own desire to use the language that I would have seen as neutral or even strongly positive when I worked at a trading firm. Can you give some examples? Really curious.

bunderbunder 8y ago
No support for multi-core parallelism. Strings are sequences of 8-bit characters, so crappy Unicode support. Weak support for non-Unix OSes.
- int_19h 8y ago
  I'm curious as to why you'd consider them advantages in that specific line of work. I can see lack of threads as an advantage in that it doesn't let you write multithreaded code with shared state, and forces into some kind of multiprocessing with message passing. But why would you prefer strings as 8-bit-clean, or weak support for non-Unix?
  - bunderbunder 8y ago
    Multithreading is the stronger positive. I'm guessing 8-bit strings is a minor positive, on the basis that you really don't need to deal with non-ASCII text in that kind of setting, and there's probably some performance benefit to not supporting it. Even if you stick to characters from 7-bit ASCII in your own data, if the strings are technically UTF-8 or UTF-16, then the fact that it's a variable-length encoding means that more string operations will involve costly branch instructions. And if UTF-32, your strings will be 4x as big as they need to be. Not working on non-Unix is neutral. There's no benefit to it, but nothing was going to be running on Windows, anyway, so there'd have been no harm in it, either.