Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Exploring ReasonML and functional programming

reasonmlhub.com

Post reply on HN
Print view View original

51–60 of 65 posts

Re: Exploring ReasonML and functional programming

#51

Post by chillee »

tome wrote: post #46
chillee wrote: post #33

Earlier quoted context omitted.

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.

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

I was basing off of this CUFP report regarding Standard Chartered's use of Haskell.

http://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf

> Their experience with strict semantics has been positive. Particularly useful is the ease of obtaining meaningful stack traces, tracking resource usage, debugging and exception propagation. The chief downside of strict semantics, in their experience, is the increased difficulty of modular composition

FWIW, I am a bit jealous of how laziness makes it easier to achieve function composition, and that was something that I wish was easier in strict semantics.

Re: Exploring ReasonML and functional programming

#52

Post by dllthomas »

chillee wrote: post #21
nafizh wrote: 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 thin…

For those who don't already know an ML, just saying "functor" isn't helpful (the term is too overloaded). "Parameterized modules" might be a better term for that context.

For those who don't know, ML-style modules are significantly more interesting than most module systems, and let you pass modules as arguments to modules at import.

Re: Exploring ReasonML and functional programming

#53

Post by frou_dh »

sgrove wrote: post #22
lewisinc wrote: post #10

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

Thanks for that. The Pit-of-Success concept is intriguing.

Re: Exploring ReasonML and functional programming

#54

Post by tome »

chillee wrote: post #51
tome wrote: post #46

Earlier quoted context omitted.

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

I was basing off of this CUFP report regarding Standard Chartered's use of Haskell. http://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf > Their experience with strict semantics has been positive. Particularly useful is the ease of obtaining meaningful stack traces, tracking resource usage, debugging and exception propagation. The chief downside of strict semantics, in their experience, is the increased diffic…

Unless I've missed something there is no claim in that document about why SCB chose Mu to be strict.

Re: Exploring ReasonML and functional programming

#55

Post by lilactown »

hnzix wrote: post #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).

It depends. IMO Cojure is a much more mature and stable foundation for building apps today - ReasonML is a good bet for the next 5 years, though.

My team recently weighed Clojure(Script) & ReasonML and chose Clojure, because we need to ship and it's not going anywhere.

Re: Exploring ReasonML and functional programming

#56

Post by dllthomas »

tome wrote: post #54
chillee wrote: post #51

Earlier quoted context omitted.

I was basing off of this CUFP report regarding Standard Chartered's use of Haskell. http://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf > Their experience with strict semantics has been positive. Particularly useful is the ease of obtaining meaningful stack traces, tracking resource usage, debugging and exception propagation. The chief downside of strict semantics, in their experience, is the increased diffic…

Unless I've missed something there is no claim in that document about why SCB chose Mu to be strict.

The quoted passage can be interpreted as one - presumably the implication is that it had those attributes relative to alternative semantics (and might have been expected to do so).

Re: Exploring ReasonML and functional programming

#57

Post by tome »

dllthomas wrote: post #56
tome wrote: post #54

Earlier quoted context omitted.

Unless I've missed something there is no claim in that document about why SCB chose Mu to be strict.

The quoted passage can be interpreted as one - presumably the implication is that it had those attributes relative to alternative semantics (and might have been expected to do so).

It's unfortunate that a short passage from an article not even written by either of the authors of Mu would be taken as evidence that SCB thought that strictness was better than laziness.

Re: Exploring ReasonML and functional programming

#58

Post by lewisinc »

deathtrader666 wrote: post #40
lewisinc wrote: post #10

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 would also like to know if ReasonML makes some "guarantees" of zero runtime errors like Elm does. That's one reason what makes Elm attractive to me, though I haven't programmed much in it.

It does not. sgrove posted this above https://vimeo.com/242081961 which is a talk he gave. Ended up watching it all the way through and came away being happier with ReasonML than I was before (eh, preconceptions because Facebook). It is a good talk, but please ignore the graphs because they aren't scientific in any sense of the word - more emotional appeal statements.

Re: Exploring ReasonML and functional programming

#59

Post by chillee »

tome wrote: post #57
dllthomas wrote: post #56

Earlier quoted context omitted.

The quoted passage can be interpreted as one - presumably the implication is that it had those attributes relative to alternative semantics (and might have been expected to do so).

It's unfortunate that a short passage from an article not even written by either of the authors of Mu would be taken as evidence that SCB thought that strictness was better than laziness.

I mean, if you want a direct quote from Lennart Augustsson, here's a quick transcription of the relevant parts of the relevant video.

https://www.youtube.com/watch?v=hgOzYZDrXL0

> So strictness is really fantastic, I must say. Stack traces work. When something goes wrong, you can say "so you call things from there to there to there". It's the single most time saving thing from Mu compared to Haskell, because things do go wrong from now and then, and it's so great to know exactly what went wrong... And strict languages have what I call resource composition. So if you understand the complexity of 2 parts you can stick them together and nothing weird happens. They add up. That's not true in lazy languages. And debugging, it's sensible in strict languages. And exceptions, they actually work! Strictness is great. It's terrible, also. So it has nice resource composition but it doesn't compose nicely semantically. So laziness has some good things as well. I think laziness is a much nicer way of programming except for these pesky resources. You definitely need some lazy functions, even C has lazy functions.

And then he goes on to talk about the ways that they allow laziness in a strict language, and when they need laziness.

Screenshots of relevant slides. Considering that the report was pretty much a summary of the talks given at CUFP, I don't know why you would cast doubt on its legitimacy.

https://i.imgur.com/fqr5P8g.jpg

https://i.imgur.com/HieskA0.jpg

Re: Exploring ReasonML and functional programming

#60

Post by tome »

chillee wrote: post #59
tome wrote: post #57

Earlier quoted context omitted.

It's unfortunate that a short passage from an article not even written by either of the authors of Mu would be taken as evidence that SCB thought that strictness was better than laziness.

I mean, if you want a direct quote from Lennart Augustsson, here's a quick transcription of the relevant parts of the relevant video. https://www.youtube.com/watch?v=hgOzYZDrXL0 > So strictness is really fantastic, I must say. Stack traces work. When something goes wrong, you can say "so you call things from there to there to there". It's the single most time saving thing from Mu compared to Haskell, because things d…

It seems we have have got a bit off track and my quite precise claims have got lost. My claims are that

1. It is incorrect to claim that "Laziness is very hard to get right in practice. ... It's the reason why ... Standard Chartered, uses their own Haskell compiler that's strict by default."

2. Rather, the reason Mu is strict is that it was designed to target an existing strict runtime (I offer this claim without proof but I was told this directly by one of the authors of Mu).

3. It is incorrect to claim that Standard Chartered "think strict haskell is a lot easier to deal with"

4. Rather, Lennart Augustsson holds that each has their upsides and downsides. He says "I don't think strict or lazy matters that much in practice; they both work fine" and "I think laziness is a much nicer way of programming except for these pesky resources."

Post reply on HN