Hacker News Reader

Comment by gtycomb | Hacker News Reader

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

View on HN

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

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.

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.

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.

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.

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

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

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.

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.

Sorry, I read your comment before my coffee and misread "native compilation" as "static compilation", so I'm conflating two distinct things.

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

No support for multi-core parallelism. Strings are sequences of 8-bit characters, so crappy Unicode support. Weak support for non-Unix OSes.

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?

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.

Reply on news.ycombinator.com