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

A Farewell to FRP

elm-lang.org

Post reply on HN
Print view View original

91–100 of 246 posts

Re: A Farewell to FRP

#91

Post by mst »

hkjgkjy wrote: post #60
timroy wrote: post #7

This looks very cool. In ClojureScript, we have the re-frame pattern/framework, which is built on Reagent, which is a ClojureScript wrapper of React. re-frame is all about subscriptions, using a "big atom" to hold application state client-side. Seeing Elm implement the same subscription pattern makes it look pretty tempting. My understanding is that ClojureScript and Elm have some similarities - functional, pleasant…

Elm is typed, Clojurescript is homoiconic. 2 great features. Wondering if you could make a lisp where `lambda` or `fn` required type annotations, such as (defn add [int -> int -> int] ;; type annotation [x y] ;; arguments list (+ x y)) Then it would be homoiconic - something that has saved me hundreds of lines of code (and the less code, the less bugs as a rule of thumb). Then every function down to the very basic li…

This is why (ignoring the batshit syntax) I'm quite fascinated by urbit's language hoon, since it handles type signatures by evaluating the function with type objects rather than straight arguments, so the above without the annotation would already be strongly typed and valid across anything that supported +

Re: A Farewell to FRP

#92

Post by pseudonom- »

timroy wrote: post #50
jiyinyiyong wrote: post #12

Earlier quoted context omitted.

Might be off topic but I was interested in the "a big atom". Reagent is using a big atom and some small atoms to simulate component state -- which breaks hot code swapping. And I tried a way to abstract out component states into a single atom to fix it by building my own React like library. Now it's "two big atoms" on my side.

Yeah, after the app grew a bit, I had state scattered here and there. re-frame solves this with a big atom, and avoids expensive rendering every time the big atom updates with subscriptions. Subscriptions hold reactions, which only update if the underlying value changes. The re-frame readme is epic and worth reading just for its own sake: https://github.com/Day8/re-frame Not to get off-topic though! I am used to work…

Can you talk a little more about your thoughts on one big atom? I've been looking at Redux and they also seem to follow this approach. The re-frame readme quotes the Elm Architecture as justification, but that same document goes on to describe nesting https://gist.github.com/evancz/2b2ba366cae1887fe621#nesting.

I come from a Haskell perspective and having one big blob of state sounds to me like it makes your type signatures less informative and increases the scope for error.

Re: A Farewell to FRP

#93

Post by nilkn »

What I really want is a language with Elm's type system, simplicity, and syntax, but aimed for backend software instead of HTML apps and with strong support for an Erlang-style actor model of multicore, distributed concurrency. Basically something like Elixir, but with Elm's syntax and type safety. In the meantime Elixir will do for me, but I'd really like more type safety without going full Haskell.

Re: A Farewell to FRP

#94

Post by tunesmith »

Say a magazine company wants to regularly send issues to a customer, and the customer signs up. Who has the subscription, the customer, or the magazine company? Which one subscribes?

According to Rx, it's the magazine company. Which one subscribes? The magazine company subscribes. It took me a while to realize this when trying to learn Rx concepts, which made it really confusing, since I've always seen the customer as being the subscriber, subscribing and owning the subscription.

It looks like Elm is the other way around compared to Rx, I think.

Re: A Farewell to FRP

#95

Post by knewter »

I'm super excited for this change. I've been watching and waiting for a few weeks. It's a big ordeal for me personally, because I've got 10 weeks of daily elm tutorial content I've written so far at http://dailydrip.com/topics/elm that I'm now re-writing, but the changes are all for the better and the language adoption is bound to go up over time.

If you haven't yet tried Elm, give it a shot. A co-worker (hi Heath!) showed it to me 4(?) years before I got interested in it, and I brushed it off as a toy because I was against Functional Programming at the time for terrible reasons. It's actually one of the 'this feels like the future' technologies that's re-shaping how I think about programming these days. Huge kudos for the release!

Re: A Farewell to FRP

#97

Post by knewter »

nilkn wrote: post #93

What I really want is a language with Elm's type system, simplicity, and syntax, but aimed for backend software instead of HTML apps and with strong support for an Erlang-style actor model of multicore, distributed concurrency. Basically something like Elixir, but with Elm's syntax and type safety. In the meantime Elixir will do for me, but I'd really like more type safety without going full Haskell.

Then you'll probably be very excited to read about http://package.elm-lang.org/packages/elm-lang/core/4.0.0/Pro...

Re: A Farewell to FRP

#98

Post by desireco42 »

ccapndave wrote: post #43

I moved from React/Redux/Typescript to Elm a few months ago, and I'm now on my second serious project with it, making mobile application with Cordova. I've found it an absolute pleasure to use, and I especially like that you can be pragmatic about it; if there is something that is annoying to do in Elm then you can simply drop into Javascript/Typescript using ports. Coming from languages like Actionscript/Javascript/…

Thank you for this endorsement. I am learning Elm, I like it a lot so far, but there are times where I question if this is really all necessary.

So first person experiences like yours help me continue and understand where I can be if I continue on the path I am.

Also, I would like to add that I really liked Signals and felt that they are good abstraction, but looking at Subscriptions and they also on surface level make sense.

Re: A Farewell to FRP

#99

Post by WorldMaker »

e0m wrote: post #32

There's also a lot of similarity with Rx.JS and observable based (aka "Reactor") patterns: Rx.Observable.fromTime().subscribe(tick) Rx.Observable.fromSocket(mySocket).subscribe(handleEvent) https://github.com/Reactive-Extensions/RxJS Regardless of the exact library or pattern, the broader concept of treating data sources as asynchronous event streams you can subscribe and react to definitely simplifies data flow and…

I think that's my biggest question reading the article here: Has Elm been ignoring the work going on with Rx all this time?

These Elm subscriptions sound like "half" of Rx, and from what I can is still 'missing' thus far some of the "higher order" Observable tools such as filter, chain, map, throttle, et al.

Re: A Farewell to FRP

#100

Post by cpdean »

embwbam wrote: post #44
Keats wrote: post #9

I like Elm but its development really seems to rely on a single person. I saw this post on elm-discuss which is a pretty good summary of my thoughts https://groups.google.com/forum/#!topic/elm-discuss/AmxE3qAm...

Evan wants to design Elm as thoughtfully as he can, and has been deliberately resisting community evolution. Eventually it will get too big and too useful, and he'll lose the ability to make big breaking changes easily. So he's tried to maintain control of the direction of the language and community during these early years while he figures it out. He's trying to reduce the feedback loop and come up with the best pos…

for what it's worth, the compiler helps you find those breaking changes pretty quickly.

much better than having bugs sneak up on you in production

Post reply on HN