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

Elm at Pacific Health Dynamics

mordrax.gitbooks.io

Post reply on HN
Print view View original

21–30 of 57 posts

Re: Elm at Pacific Health Dynamics

#21

Post by byw »

spraak wrote: post #18
ghayes wrote: post #12

Earlier quoted context omitted.

Yeah, we've had a great time writing Elm for a fairly complex single-page Ethereum dApp. It's conceptually a lot simpler than Haskell, which made it easy for the team to pick up. I only wish it had a better system (Tasks) for JavaScript interop instead of ports.

ReasonML could be a good middle ground there.

One of the biggest complaints of Elm is the lack of typeclass. I'm not aware of a similar abstraction in OCaml. Does Reason have similar limitations, or are there ways to get around it?

Re: Elm at Pacific Health Dynamics

#22

Post by rs86 »

byw wrote: post #21
spraak wrote: post #18

Earlier quoted context omitted.

ReasonML could be a good middle ground there.

One of the biggest complaints of Elm is the lack of typeclass. I'm not aware of a similar abstraction in OCaml. Does Reason have similar limitations, or are there ways to get around it?

First class modules. And yes, not having typeclasses is a bit of a turn off too...

Re: Elm at Pacific Health Dynamics

#23

Post by deboboy »

ghayes wrote: post #12
sridca wrote: post #6

I never enjoyed frontend programming until I came across Elm. Not only that Elm turned out to be a gateway drug to Haskell. Now I write frontend and mobile apps in Haskell using Functional Reactive programming (FRP).

Yeah, we've had a great time writing Elm for a fairly complex single-page Ethereum dApp. It's conceptually a lot simpler than Haskell, which made it easy for the team to pick up. I only wish it had a better system (Tasks) for JavaScript interop instead of ports.

What's your fairly complex dapp about/for?

Re: Elm at Pacific Health Dynamics

#24

Post by mordrax »

fwip wrote: post #8

The lead paragraph is a bit worrying. > Since July 2017, I’ve been leading the frontend rewrite of their flagship product. The codebase was at 16k LoC when I started. Since then, I’ve rewritten the various subsystems at least once (I'm looking at you generic form component). Now we hover around 45k LoC with most of the common SPA structures stabilizing. We are about a third of the way to completion. I don't know if i…

Correct, the initial 16k LoC was not complete. In fact ( no metrics ), I deleted large portions of redundant files/code and at one stage we were back at about 11k LoC.

The comment about 16k -> 45k LoC was to give an idea of how much we had added to the product over the last 10 months.

Re: Elm at Pacific Health Dynamics

#25

Post by crystalPalace »

sridca wrote: post #16
crystalPalace wrote: post #14

Earlier quoted context omitted.

What framework or library are you using to write frontend and mobile apps in Haskell?

Reflex http://docs.reflex-frp.org/

Thanks for replying! This looks very useful with good documentation and a small but dedicated community. I've worked with Purescript and some other frontend functional languages/frameworks and haven't been as productive as I believe functional allows you to be. But this and Miso seem very promising. I'm really excited about potentially using one language and paradigm for web, mobile, and backend.

Re: Elm at Pacific Health Dynamics

#26

Post by always_good »

spraak wrote: post #20
Patrick_Devine wrote: post #2

Took me a while to realize this wasn't about the Elm email client https://en.wikipedia.org/wiki/Elm_(email_client)

https://hn.algolia.com/?query=elm%20email&sort=byPopularity&... Seems like at least a few others have over time as well

Notice how there isn't a single submission about the Elm email client. I think I'm dead-on with my signaling hypothesis.

It died 12 years ago.

Re: Elm at Pacific Health Dynamics

#27

Post by mordrax »

lolc wrote: post #4

I've only used Elm for a hobby project. Given how much I enjoyed the experience of web app programming for once, it's nice to read how well it scales to a large application.

It definitely scales. There is an 'adjustment period' where I went from a nested to a flat, decoupled architecture. But as most things are one to two levels deep (state), complexity also grows fairly linearly. This is really great from a developer's pov when trying to grapple with how to add new features.
Post reply on HN