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

71–80 of 246 posts

Re: A Farewell to FRP

#71

Post by jventura »

gjolund wrote: post #42

Doing away with signals is a great move, everything else about the elm architecture felt so intuitive. I'm excited to give elm another shot, and I yearn for the future he describes where web assembly makes elm a viable js replacement.

When I did the tutorials some weeks ago, I also had difficulty understanding Signals. In the time, it made more sense to me if it was called "Streams" instead, as I'm used to the concept of signals and slots from Qt, where a signal is an event that your widgets dispatch and slots are the functions that react to signals.

These subscriptions from Elm kind-of remind me the signals and slots mechanism of Qt..

Re: A Farewell to FRP

#72

Post by faizshah »

junke wrote: post #35

I am happy to see Elm evolving and it looks like a good framework, but there is a tendency in FRP articles to ignore prior work, as acknowledged at the end of the article: > Note: Interested readers may find Lucid Synchrone interesting. Unfortunately for me, I had no idea my thesis had so much in common with synchronous programming languages at the time, but the connections are quite striking. I might argue that Elm…

I was interested in the synchronous languages but never got around to reading more in depth about them. Can you recommend a book on the subject?

The two languages I was most interested in were Lustre and Esterel.

Re: A Farewell to FRP

#73

Post by daxfohl »

Wow, this is a surprise. Kind of like a Haskell headline "A Farewell to Immutability". But sounds like the pros and cons have been well thought out for the intended use case.

Re: A Farewell to FRP

#74

Post by masklinn »

dreamdu5t wrote: post #57

Looks like Elm moved closer to Pux's API by dropping the signals for `Html action`. Check out Pux if you're interested in the same architecture but for PureScript. https://github.com/alexmingoia/purescript-pux

Wow, the buttons demo looks very, very close: http://guide.elm-lang.org/architecture/user_input/buttons.ht...

The biggest difference is that the Elm version of "start a simple application" encapsulates more boilerplate, but I guess pux can do server-side rendering?

Re: A Farewell to FRP

#75

Post by hencq »

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…

There's Typed Racket [1] and for Clojure there's core.typed [2]which do pretty much that. For Clojure there's also Schema [3], which is a bit lighter weight (it's not a full type system), but still gets you some of the benefits like validation and documentation.

[1] https://docs.racket-lang.org/ts-guide/ [2] https://github.com/clojure/core.typed [3] https://github.com/plumatic/schema

Re: A Farewell to FRP

#76

Post by tormeh »

faizshah wrote: post #72
junke wrote: post #35

I am happy to see Elm evolving and it looks like a good framework, but there is a tendency in FRP articles to ignore prior work, as acknowledged at the end of the article: > Note: Interested readers may find Lucid Synchrone interesting. Unfortunately for me, I had no idea my thesis had so much in common with synchronous programming languages at the time, but the connections are quite striking. I might argue that Elm…

I was interested in the synchronous languages but never got around to reading more in depth about them. Can you recommend a book on the subject? The two languages I was most interested in were Lustre and Esterel.

Check out http://www.ceu-lang.org/

Then you can try it yourself.

Re: A Farewell to FRP

#77

Post by gohrt »

daxfohl wrote: post #73

Wow, this is a surprise. Kind of like a Haskell headline "A Farewell to Immutability". But sounds like the pros and cons have been well thought out for the intended use case.

Not quite that extreme. FRP has always been a very awkward way to express things, even within the functional/immutable world. FRP had already had it's (small) boom-bust before Elm came on the scene to give it a small revival.

This is a very good change for Elm.

Re: A Farewell to FRP

#78

Post by junke »

faizshah wrote: post #72
junke wrote: post #35

I am happy to see Elm evolving and it looks like a good framework, but there is a tendency in FRP articles to ignore prior work, as acknowledged at the end of the article: > Note: Interested readers may find Lucid Synchrone interesting. Unfortunately for me, I had no idea my thesis had so much in common with synchronous programming languages at the time, but the connections are quite striking. I might argue that Elm…

I was interested in the synchronous languages but never got around to reading more in depth about them. Can you recommend a book on the subject? The two languages I was most interested in were Lustre and Esterel.

Synchronous Programming of Reactive Systems, Halbwachs

Synchronous Languages for Hardware and Software Reactive Systems, Berry

Designing Embedded Systems with the SIGNAL Programming Language, Gamatié

The Synchronous Languages 12 Years Later (http://www-verimag.imag.fr/~halbwach/PS/iee03.pdf)

There are some resources at Verimag (http://www-verimag.imag.fr/Tempo,32.html?lang=en) and the Esterel website (https://www-sop.inria.fr/meije/esterel/esterel-eng.html). You can search the HAL database too (hal.inria.fr) and maybe have a look at SCADE (http://www.esterel-technologies.com/products/scade-suite/).

Re: A Farewell to FRP

#79

Post by millstone »

Can someone explain how the subscription API differs from signals, addresses, and ports? I'm not familiar with the "old" Elm so I can't judge what the change is like.

Re: A Farewell to FRP

#80

Post by [deleted] »

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…

[deleted]
Post reply on HN