Comment by plinkplonk | Hacker News Reader

Comment by plinkplonk | Hacker News Reader

Parent Full thread

"I for one can't wait for Typed FP to become mainstream as soon as possible."

This will never happen till there is a typed FP language that has solid tooling, documentation, solid libraries for most common programmer tasks, a welcoming and active community and at least one of a killer app, or framework (Rails for ruby), killer platform (objective c/swift for AppStore dev) or targets an underserved domain (Julia for Scientific Computing).

The existing typed FP language implementations (OCaml, Haskell, SML, not sure of F#) are full of cruft and/or are just lacking with respect to one or more of the above.

Haskell comes the closest I think, but that maybe because I've been using Haskell for decades, and so I am biased in its favor (and I'd still hesitate before using it on a large team + long timescale project).

Try writing a 'mainstream' application in any of the above, and you'll see what I mean. Yes you can write a typical web app /CRUD app/mobile app in (say) Haskell, but to be honest, Yesod (say) is no Rails.

Reason might be 'the one' I guess, at least in bringing TypedFP to the javascript ecosystem, especially with FB's corporate backing.

Rust gets/is getting most of the above right, but it isn't really an FP language.

OCaml or Haskell being the mainstream will never happen imho. If there is a TypedFP mainstream language in the future, it is yet to be invented (or is being invented right now! touch wood).

What is more likely to happen is some FP features moving into mainstream languages. Not sure if that counts as "typed FP becoming mainstream", but it likely to be a long wait ;-)

I honestly don't see any typed FP language ever having the success of say, Python, for at least a few decades yet.

(all imho, ymmv, as it should)

The killer app for OCaml is front-end webdev with Reason. Most new large-scale Javascript projects are using gradual typing with TypeScript, and the experience is not the same as having types natively. It gives you the safety and rigidity of types, but not as much the ability to think with types. These projects also toy around with immutability - using a library like Immutable.js which is a boxed data structure that needs explicit handling and conversion to and from native types, need to pick a state management library like Redux which implements a version of variants through constants and manual dispatch, and all these projects need large test suites to check for things that types would've caught and so on. A typed functional language eliminates almost all of these issues and grants more powers of abstraction. If not Haskell or OCaml, I suspect Elm has a good shot at it.

I'm all for new languages! If I remember correctly, the ideal one is Lispy with Hygienic macros, ML-like type system baked in, multi-core, good stdlib, and tools that don't stand in your way.

"The killer app for OCaml is front-end webdev with Reason."

I'll make a 1000$, 10 year bet with you that in 2028, if browsers still exist, ReasonML (or its successors) will be nowhere near mainstream status (which is the point we are discussing here). I like Reason, or at least the idea of it.

Javascript itself might incorporate more static typing in 2028 than today's version does, but I suggest the 'advances' will be relatively miniscule.

I hold hope, but not certainty!

I agree that JavaScript isn't going to change significantly, but fortunately it can be treated as a compiler's target platform, not only a source language.

We're not going to see any language supplant JavaScript in the browser. Dart got nowhere, and that was with the backing of Google. But there are already toolkits out there that compile down to JavaScript. GWT, for instance.

>We're not going to see any language supplant JavaScript in the browser. Dart got nowhere, and that was with the backing of Google.

Never say never (again. With apologies to Ian Fleming). Just because Dart couldn't do it (even with Google), doesn't mean that nothing else can. I, for one, hope something better does supplant JS.

https://en.wikipedia.org/wiki/Never_Say_Never_Again

https://en.wikipedia.org/wiki/Ian_Fleming

I think the problem here is that OCaml/ReasonML is a relatively large language - the flip side to the nice syntactic sugar, and there's a paucity of material to get people into ReasonML if they haven't touched FP before (which for FP to take off is the target audience).

It is definitely not ideal, but they are happening. A few helpful resources:

Nik Graf has a free ReasonML course on Egghead.io, which has a lot of positive reviews from the community. https://egghead.io/courses/get-started-with-reason

Dr. Axel Rauschmayer has written "Exploring ReasonML and functional programming" which covers the language comprehensively. http://reasonmlhub.com/exploring-reasonml/

Web Development with ReasonML by J. David Eisenberg, published by Pragmatic Bookshelfis in the works. I read a few sample chapters and they're excellent for beginners: https://pragprog.com/book/reasonml/web-development-with-reas...

Jane Street wrote a set of 24 runnable exercises that teaches OCaml, and we ported it to ReasonML. It has been used for workshops and individual study and will get you upto speed on the paradigm quickly. https://github.com/protoship/learn-reasonml-workshop

You also have textbooks on OCaml, a lot of them openly accessible, including the venerable Real World OCaml. They are all listed in the awesome-ocaml repository: https://github.com/rizo/awesome-ocaml#books

There is vramana's awesome-reasonml repository that covers similar ground for Reason itself: https://github.com/vramana/awesome-reasonml

Going to plug a quick thing here :) I run a project called Byteconf - we have a free ReasonML conference coming up this Friday, streamed on Twitch: https://www.byteconf.com/reason-2018

> there's a paucity of material to get people into ReasonML

Believe it or not, it's even worse if you want to target native code and not JS.

I'm doing the ES6 + Immutable thing right now in some React apps. (I'd prefer to use TypeScript, but the codebases are too large to convert.)

It's an improvement over plain JS, but also a nightmare. For example, it's hard to create truly immutable classes. I ended up with this pattern:

  class Foo {
    #props
    
    constructor(props) {
      this.#props = Map(props)
    }

    get someField() {
      return this.#props.get('someField')
    }

    withSomeField(value) {
      return new Foo(this.#props.set('someField', value))
    }
  }

It works, but it's annoying. Then you have, as you say, all the coercion/conversions between Immutable and plain JS values.

TypeScript would help, but I think I'm going to look into Reason, too. I think I heard that it supports interoperating with ordinary JS. The problem with TS, last I tried it, was that while it supports JS, there are subtleties (like the lack of support for default imports) that mean it's not fully backwards compatible. You can't just run a JS codebase with the TS compiler and expect it to work, as I understand it.

You didn't mention Scala. It has access to all Java libraries, and it doesn't force you to into a single fixed mindset like Haskell's purity at all costs.

That said, it doesn't seem to have taken off, and it doesn't really look like it will. Not sure why, though I hear a lot of complaints about compile speeds.

"you didn't mention Scala"

my hypothesis (and it is only that) is that trying to unite FP and OO, as Scala tries to do, leads to unnecessary complexity in learning and usage. Also see 'tooling'.

That said, many impressive + widely deployed systems have been built with Scala, which is more than other typed FP languages can claim.

OCaml also tries to unite FP and OO, it is right there on its name.

Yes and no. It's possible to ignore the OO features and use OCaml purely as a functional language, in a way that you can't really do in Scala.

I've been doing Scala full-time for several years, so as far as I can see it's taken off pretty well. I can't really claim it has a welcoming community though (though many of the most unpleasant people are those who've apparently quit the language, but still hang around and hassle people).

Compile speeds are a problem of the past. When you use Scala 2.12+ together with incremental compilation with modern Zinc-based compile server, compiling Scala after each change takes a low few seconds. Sometimes less than a second. And Dotty (Scala 3) shall improve compile times even further.

I've been a Scala developer since 2012.

Not sure what "taking off" means in the context of programming languages, but for me it's been popular enough since 2012.

Several big companies use it and I've introduced Scala (and FP in Scala) at about 3 companies thus far ... it isn't a tough sell if the company is Java-friendly.

We also have a great, active community developing libraries. As a shameless plug here are the projects I've been working on:

1. https://monix.io

2. https://github.com/typelevel/cats-effect

Scala is one of the best languages for FP these days. Note I'm not saying that it's perfect. We can certainly improve it and a lot of improvements are coming in Scala 3.

Are you hiring in Bucharest office?

I use Scala quite a bit, and I just can't bring myself to regard it as a functional language. It's a kitchen sink language ("multiparadigm" when I'm in a polite mood) that happens to support a lot of nice things from FP, but with a distinctly object-oriented flavor.

There are add-on libraries like ScalaZ and Cats that are meant to make it easier to follow a more thoroughly functional style, but, even with those, I can't shake the feeling that I'm swimming against the current if I try to take a functional-first approach.

Rust isn't a FP language in the strict, traditional terms of Haskell and OCaml, but it's pretty damn close. If people started switching to Rust, they'd probably get 80% of the gains (concurrency, excellent typing, non nullability, etc.). If Rust gains traction, I wouldn't exactly complain; don't let perfect be the enemy of good, after all.

Could Kotlin or Swift do it? I like Python/Flask/Sqlalchemy for backend web dev, but I long for a modern, statically typed FP alternative that’s equally (or nearly as) practical and accessible. Just a pipe dream?

Kotlin doesn't belong in these discussions, no exhaustive pattern matching.

The language is not set in stone.

Have you tried Mypy? It certainly has limitations, but it provides some static typing to Python.

I've tried mypy, but it's still too immature (creates more issues than it solves). Specifically it's buggy and very limited (IIRC support for recursive types hadn't landed and many popular libraries--like SQLAlchemy--can't be annotated or stubbed).

There is hardly anything FP about Kotlin.

What about F#?

F# is pretty close. The tooling isn't up there with C# but it is close.

If microsoft would double the budget for tooling support I think it would get there quick, and that wouldn't be a ton of money.

It is more than just the budget.

F# isn't properly part of the .NET team, hence only VB.NET and C# get all the goodies.

They didn't even took F# requirements into consideration when doing .NET Native and the whole VS refactorings, leaving the F# team to play catch up on their own.

Reply on news.ycombinator.com