Live data from Hacker News

Exploring ReasonML and functional programming

reasonmlhub.com

21–30 of 65 posts

Re: Exploring ReasonML and functional programming

#21
post #3

Why should someone unfamiliar with functional style programming be learning ReasonML rather than say, something like, haskell? Looking for concrete, technical answers.

I view this as more of a general, why should somebody learn Ocaml instead of Haskell?

There's a couple of reasons. #1. Ocaml's type system is nearly as expressive as Haskell's and includes several features that Haskell's does not. Polymorphic variants and functors being notable ones.

#2. Laziness is very hard to get right in practice. I'm sure Haskell enthusiasts will not be very happy with that statement, but I think it's true. It's the reason why one of the biggest users of Haskell (and the most notable example of Haskell in industry), Standard Chartered, uses their own Haskell compiler that's strict by default.

#3. Less productive in practice. For example, long build times are a huge problem in practice. See https://www.reddit.com/r/haskell/comments/45q90s/is_anything...

for comments from the Haskell community, including GHC maintainers.

Really though, I don't think you can really go that wrong with either. Transferring from each language to the other one isn't very difficult, and they're both excellent languages.

Re: Exploring ReasonML and functional programming

#22

Someone will have to explain why I might pick ReasonML over Elm for front-end development. Elm's community seems very focused on making front-end development as intuitive and hassle-free as possible. ReasonML seems like Facebook just wanted to leverage a pre-existing community but couldn't bring themselves to adopt the syntax so rewrote it in-house.

I ran into this question a lot when speaking about ReasonML, and am quite a fan of Elm as well. I wanted to address it holistically, so (if you'll forgive the shameless plug), I did a talk on some of the motivations of ReasonML (as I see them) and a high-level comparison to Elm here https://vimeo.com/242081961

Re: Exploring ReasonML and functional programming

#23

Maybe not the right place to ask, but "Better standard library" appears in the section detailing future improvements that ReasonML might bring to the OCaml ecosystem. How do they plan on doing this, given that the major standard library camps seem relatively entrenched in OCaml today? Which one does the ReasonML community favor/intend to contribute to?

Base[1] is a good candidate for an OCaml standard library. It's got tons of functionality, results in binaries with small footprints, is cross-platform, and has a fairly stable API. It's also code that has been and continues to be battle tested every day in production systems at Jane Street. I'm biased, as I'm one of the maintainers, but trust me it's good, it's good. [1]: https://github.com/janestreet/base

How does Base compare to Core?

https://github.com/janestreet/core

Re: Exploring ReasonML and functional programming

#24

Someone will have to explain why I might pick ReasonML over Elm for front-end development. Elm's community seems very focused on making front-end development as intuitive and hassle-free as possible. ReasonML seems like Facebook just wanted to leverage a pre-existing community but couldn't bring themselves to adopt the syntax so rewrote it in-house.

Elm is cool, the BDFL seems like a great guy, but he's a bottleneck and the community is too small. I developed our internal Dashboard using Elm and we have already end-of-lifed it primarily for this reason. I think it's always going to be a niche product and I can't justify betting my business on that. Other larger communities are going to take these ideas and execute on them better.

The only way I see this changing is if Evan massively delegates responsibility, and I just don't see that happening. Elm is cool because it's small and tightly controlled, but that also limits its viability and growth potential.

Re: Exploring ReasonML and functional programming

#25

Earlier quoted context omitted.

Base[1] is a good candidate for an OCaml standard library. It's got tons of functionality, results in binaries with small footprints, is cross-platform, and has a fairly stable API. It's also code that has been and continues to be battle tested every day in production systems at Jane Street. I'm biased, as I'm one of the maintainers, but trust me it's good, it's good. [1]: https://github.com/janestreet/base

How does Base compare to Core? https://github.com/janestreet/core

Seems like Core depends on Base (https://github.com/janestreet/core/blob/master/core.opam)

Re: Exploring ReasonML and functional programming

#26

Earlier quoted context omitted.

Base[1] is a good candidate for an OCaml standard library. It's got tons of functionality, results in binaries with small footprints, is cross-platform, and has a fairly stable API. It's also code that has been and continues to be battle tested every day in production systems at Jane Street. I'm biased, as I'm one of the maintainers, but trust me it's good, it's good. [1]: https://github.com/janestreet/base

How does Base compare to Core? https://github.com/janestreet/core

Core depends on Base. The parts where they differ include: more data structure, and bindings for system calls and other functionality available from libc.

There's also core_kernel, which is core but without the libc support.

Re: Exploring ReasonML and functional programming

#27
I'm looking for a language for cross-platform mobile app development using React/Expo. Can anyone give their opinion on ReasonReact vs Clojurescript Reframe?

I like the familiar syntax of ReasonML, but Clojurescript has LISP mojo and is more mature (more learning resources etc).

Re: Exploring ReasonML and functional programming

#28

Someone will have to explain why I might pick ReasonML over Elm for front-end development. Elm's community seems very focused on making front-end development as intuitive and hassle-free as possible. ReasonML seems like Facebook just wanted to leverage a pre-existing community but couldn't bring themselves to adopt the syntax so rewrote it in-house.

Actually, the Reason team is basically made up of experienced OCamlers who wanted to attract the JavaScript community and figured that a familiar syntax would help a lot (I think they were right). See https://reasonml.github.io/docs/en/what-and-why.html#why-rea... for more details.

Re: Exploring ReasonML and functional programming

#29
post #4

FYI for anyone who was fuzzy on the license/patent situation with the project: https://github.com/facebook/reason/commit/e8fb73ec6ff7c31367... (As of 12/2017, relicensed to straight MIT from BSD+patent.) Rauschmayer's work here makes me interested in the language and motivated to learn it. After reading more, only wish I'd explored for a recent project where I was working to implement a lot of functional patterns in…

It's a good question. Reason includes some major syntactic conveniences that make the JavaScript interop more pleasant to work with. One of the biggest ones is that it introduces a first-class syntactic JavaScript object literal (i.e. a Reason/BuckleScript value which will compile down to a JavaScript literal) and which makes writing JS objects much more pleasant.

There are other conveniences as well, including the fact that Reason comes with a tool (refmt) that can autoformat your code to a standard style, wiping out style guide arguments etc.

Re: Exploring ReasonML and functional programming

#30

Someone will have to explain why I might pick ReasonML over Elm for front-end development. Elm's community seems very focused on making front-end development as intuitive and hassle-free as possible. ReasonML seems like Facebook just wanted to leverage a pre-existing community but couldn't bring themselves to adopt the syntax so rewrote it in-house.

Elm is the better language but the influence of Facebook has given ReasonML the momentum that Elm never had.

Even just Dr Rauschmayer's blog and now this book blow away anything I've ever found in the Elm ecosystem.

Post reply on HN