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

51–60 of 246 posts

Re: A Farewell to FRP

#51

Post by riffraff »

vvanders wrote: post #22
zachrose wrote: post #19

I haven't dabbled in Elm much, but subscriptions look a lot like ordinary JS event handlers: Time.every second Tick vs. Time.on('everySecond', tick) Beyond baking an event emitter into the Time module and having a nice looking API, is there something I'm missing?

First page of the Elm guide covers it pretty well: http://guide.elm-lang.org/ > No runtime errors in practice. No null. No undefined is not a function. > Friendly error messages that help you add features more quickly. > Well-architected code that stays well-architected as your app grows. > Automatically enforced semantic versioning for all Elm packages.

to be fair, all these things do not seem to be dependent on this new Subscriptions thing, as in fact they were there even before.

I am sure the new idea is good, but as grandparent said, the examples fail to convey why this is better than what we had before.

Re: A Farewell to FRP

#52

Post by timroy »

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/…

"if it compiles, then it just seems to work" Man, now that is tempting. Also, how easy are the ports? In ClojureScript you can use JavaScript pretty directly, but I often got a bit hung up translating the syntax (it's not that hard, it was just me).

Re: A Farewell to FRP

#53

Post by methehack »

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…

It seems like communicating this approach to the community might be helpful for some. The poster's perspective is not unique (see the links in this thread). An evolution from benevolent dictatorship to democracy has advantages and precedent. Communicating with the community these intentions is important and a sign of respect and maturity. I think in itself it would be stabilizing.

Re: A Farewell to FRP

#54

Post by masklinn »

zachrose wrote: post #19

I haven't dabbled in Elm much, but subscriptions look a lot like ordinary JS event handlers: Time.every second Tick vs. Time.on('everySecond', tick) Beyond baking an event emitter into the Time module and having a nice looking API, is there something I'm missing?

`Time.every second Tick` returns a time-varying value it doesn't call a side-effecting callback. It generates a filtered event emitter if you will. Semantically it has almost no relation to your JS version, aside from both being function calls.

Re: A Farewell to FRP

#56

Post by christophilus »

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/…

>> if it compiles, then it just seems to work

This. I spent the first 14 years of my career in statically typed languages and only this year began working professionally on a Rails app... I really miss the compiler.

Re: A Farewell to FRP

#58

Post by masklinn »

riffraff wrote: post #51
vvanders wrote: post #22

Earlier quoted context omitted.

First page of the Elm guide covers it pretty well: http://guide.elm-lang.org/ > No runtime errors in practice. No null. No undefined is not a function. > Friendly error messages that help you add features more quickly. > Well-architected code that stays well-architected as your app grows. > Automatically enforced semantic versioning for all Elm packages.

to be fair, all these things do not seem to be dependent on this new Subscriptions thing, as in fact they were there even before. I am sure the new idea is good, but as grandparent said, the examples fail to convey why this is better than what we had before.

The "new Subscriptions" thing replaces signals, which is not what GP thinks is "what we had before".

Re: A Farewell to FRP

#59

Post by redka »

d0m wrote: post #34

One thing I'm wondering with elm is how does it deal with state across different components? I.e. where would you put the settings of the current user and how would you access that within one component? (By component I mean the (init,update,view,subscription))

Since with The Elm Architecture parent always takes care of it's children you can create a "Context" and pass it along.

Re: A Farewell to FRP

#60

Post by hkjgkjy »

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 lisp functions would have types. Dunno how doable this is - but it doesnt matter. Someone implemented it in Common Lisp in the 80s I'm sure.

Post reply on HN