4 ms·

> The biggest impediment I see is that these language communities are more concerned about the abstract mathematical properties of the language and things like

> The biggest impediment I see is that these language communities are more concerned about the abstract mathematical properties of the language and things like tooling get neglected Is it really so. I am only asking. A mathematical model allows deeper insight on structure (backed by hundreds of years of prior mathematical thought), and we then sugar it appropriately for users. Just like civil engineers who learn Strength of Materials etc mathematically before they design the bridges we drive over daily. Tooling is one of my gripes also. There was a time decades ago when I couldn't go beyond compiling the simple hello world example. This has gotten much better after many years. Same with Haskell. Is this due to difficulties in getting the necessary financial support.

bunderbunder 8y ago
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.
weberc2 8y ago
I don’t know for sure, but I’ve never had a project fail for lack of monads or functional purity, but they’ve often failed because I couldn’t figure out the tooling quickly enough or there was some critical library missing or the documentation was shit or etc. And the economics of bridges and web apps aren’t comparable (I can’t redeploy a bridge in an hour and no one dies if one of my routes 500s when the user passes unexpected input).
- gtycomb 8y ago
  I feel the pain as I read your line. One great disaster in my career early on was my going into Haskell, and also Prolog, after frustration with Java (remember Java Beans etc?) in an enterprise project. Whereas Perl5 (this was in the biotech/genomics industry) and later Python did the real work. Still I cannot forget the impressive functional power while coding Ocaml.
- tikhonj 8y ago
  Projects fail because of bad code quality and architecture all the time. Monads and functional purity are simple tools that help tame and manage these issues. I've seen a number of projects (often in JavaScript or Python) fail because of poor effect management—but if you don't have much experience with functional programming, you'd see it as yet another project failing because of bad development practices or lack of discipline. With experience, it became pretty clear that what we needed were not iron-willed, self-disciplined developers but just better tools, of which effect management (ie monads) and functional programming are some of the most powerful.
  - weberc2 8y ago
    This seems like a reasonable hypothesis, but I don't perceive a clear signal that indicates that projects which use monads or pure FP are more successful than their counterparts. I think your hypothesis actually jives with mine and with my observation from the previous sentence--that monads and functional purity could help, but if the language neglects things like documentation, high quality libraries, and tooling to productionise and operationalize your code, then it's a non-starter.

bunderbunder 8y ago

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.

weberc2 8y ago

I don’t know for sure, but I’ve never had a project fail for lack of monads or functional purity, but they’ve often failed because I couldn’t figure out the tooling quickly enough or there was some critical library missing or the documentation was shit or etc. And the economics of bridges and web apps aren’t comparable (I can’t redeploy a bridge in an hour and no one dies if one of my routes 500s when the user passes unexpected input).

gtycomb 8y ago
I feel the pain as I read your line. One great disaster in my career early on was my going into Haskell, and also Prolog, after frustration with Java (remember Java Beans etc?) in an enterprise project. Whereas Perl5 (this was in the biotech/genomics industry) and later Python did the real work. Still I cannot forget the impressive functional power while coding Ocaml.
tikhonj 8y ago
Projects fail because of bad code quality and architecture all the time. Monads and functional purity are simple tools that help tame and manage these issues. I've seen a number of projects (often in JavaScript or Python) fail because of poor effect management—but if you don't have much experience with functional programming, you'd see it as yet another project failing because of bad development practices or lack of discipline. With experience, it became pretty clear that what we needed were not iron-willed, self-disciplined developers but just better tools, of which effect management (ie monads) and functional programming are some of the most powerful.
- weberc2 8y ago
  This seems like a reasonable hypothesis, but I don't perceive a clear signal that indicates that projects which use monads or pure FP are more successful than their counterparts. I think your hypothesis actually jives with mine and with my observation from the previous sentence--that monads and functional purity could help, but if the language neglects things like documentation, high quality libraries, and tooling to productionise and operationalize your code, then it's a non-starter.