Why should someone unfamiliar with functional style programming be learning ReasonML rather than say, something like, haskell? Looking for concrete, technical answers.
Because Reason fully supports imperative and OOP style. You don't need to use functional style if you don't want to (of course, aside from using other people's code). Here's some classic OOP: class animal = {pub speak = "Animal noise";}; class cat = {inherit class animal; pub speak = "Meow!";}; class dog = {inherit class animal; pub speak = "Bark!";}; let speakTwice(animal: animal) = animal#speak ++ ", " ++ animal#sp…
Exploring ReasonML and functional programming
41–50 of 65 posts
Re: Exploring ReasonML and functional programming
#42Earlier quoted context omitted.
That's not correct. What you've described is Bucklescript (which has OCaml syntax). ReasonML is an attempt to "improve" the OCaml syntax to something more familiar to folks coming from C-style family of lanauges. ReasonML can be used with both the Bucklescript compiler (which compiles to JS) -or- the standard OCaml one (which compiles to native).
While that is technically true, most people nowadays use them interchangeably especially because Reason is focusing so much on its web story, so I wouldn't expect people to make this distinction very often.
Re: Exploring ReasonML and functional programming
#43Earlier quoted context omitted.
ReasonML has a much more advanced module system via Functors. As far as I know Elm has nothing like this. Despite a fair few arguments over incorporating type classes into Elm, the creator is pretty dead set against the idea. This does make Elm a lot more approachable, but after a while can feel quite restrictive. There is bucklescript-tea, which is the Elm architecture in for Bucklescript (and thus also Reason). It…
> Elm community is more mature which means there is more documentation and libraries available There's some excellent libraries but the Elm documentation is terrible compared to Reason.
Re: Exploring ReasonML and functional programming
#44Someone 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.
ReasonML's documentation also seems better (especially for a functional programming newbie)
Re: Exploring ReasonML and functional programming
#45Why 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 thin…
No it's not. The reason Mu is strict is that it was designed to target an existing strict runtime.
Re: Exploring ReasonML and functional programming
#46Earlier quoted context omitted.
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 thin…
I wrote this on my phone a couple hours ago, and I wanted to add a couple qualifiers that might be misleading to people. Laziness being hard to deal with isn't the only reason Standard Chartered uses their own compiler that's strict by default. However, they have noted that they do think strict haskell is a lot easier to deal with.
That's news to me. Where did they note that? Lennart Augustsson explicitly says "I don't think strict or lazy matters that much in practice; they both work fine".
http://augustss.blogspot.co.uk/2011/05/more-points-for-lazy-...
Re: Exploring ReasonML and functional programming
#47Someone 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.
Having recently started learning Elm, I am considering switching over to ReasonML. Elm's architecture is really great for front end development and the error messages are awesome, but the ecosystem is in its infancy, and development is driven by just one guy. I've seen a lot of open PRs and issues on Github with genuinely great features, but haven't been merged in yet. ReasonML's documentation also seems better (espe…
Re: Exploring ReasonML and functional programming
#48FYI 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…
Re: Exploring ReasonML and functional programming
#49Earlier quoted context omitted.
Because Reason fully supports imperative and OOP style. You don't need to use functional style if you don't want to (of course, aside from using other people's code). Here's some classic OOP: class animal = {pub speak = "Animal noise";}; class cat = {inherit class animal; pub speak = "Meow!";}; class dog = {inherit class animal; pub speak = "Bark!";}; let speakTwice(animal: animal) = animal#speak ++ ", " ++ animal#sp…
I guess it would be remiss to not mention that most Ocaml users shy away from the object oriented side of the language. Not because it's not well done (it is), but because modules work a lot better for many of the uses cases you'd want classes for.
Re: Exploring ReasonML and functional programming
#50Maybe 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