Live data from Hacker News

A Farewell to FRP

elm-lang.org

131–140 of 246 posts

Re: A Farewell to FRP

#131
post #101

Earlier quoted context omitted.

> I have found the whole Elm experience quite mindblowing; if it compiles, then it just seems to work. My mindblowing experience was facilitated by referential transparency where I had a page of code that became half a page after extracting some functions and restructuring the code and then have that half page collapse into several lines of boring code because I realized that the functionality can be re-expressed in…

Care to share more about that? It would be really helpful for people looking at the language to see your progression. Could be something as simple as a gist with the code in your different stages.

I tried to look through the commits of that project but could not find something that captures this. Maybe it happened between commits.

Maybe I'm remembering it wrong. Maybe my mind exaggerated the memory. It happened last year while I was implementing Challenge No. 5:

https://github.com/pdamoc/elmChallenges

Re: A Farewell to FRP

#132
post #113

Earlier quoted context omitted.

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

Give it another year and the new batch of hotshot developers will reinvent static typing and perhaps one or two other features from the 1970s, but it'll have some cool name and only implement 50% of the functionality.

Modern static typing isn't remotely related to typing from the "1970's"

Re: A Farewell to FRP

#133

Stupid question from an interested outsider: how's a "subscription" different from a good ol' callback?

I think it is worthwhile stopping by the Elm slack channel to ask this. You have framed the question in a weird way. The answer is kind of "these things are not really related in any direct way" but I feel like you are asking a different question. Point is, ask on the slack channel and folks will help clarify :)

Re: A Farewell to FRP

#134
post #65
post #50

Earlier quoted context omitted.

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…

Elm incoperates CSS the same way Clojurescript and React incorporates CSS.

Thanks, good to know.

Re: A Farewell to FRP

#135

Earlier quoted context omitted.

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

Rust has some really good compile-time checking, it really makes you express everything in a completely non-ambiguous way. C++ on the other hand compiles stuff that may or may not work at all, it doesn't care, which can lead to all sorts of undefined behaviour down the road. Compilers are not all created equal.

Huh. I find that when my C++ compiles, it almost always works. Correctly.

But I used the language for nearly 20 years, so maybe it's experience and the patterns I've learned?

Not that Rust or Elm aren't better options; don't know, really. Despite feeling like I'm an expert in C++, I don't actually like the language much. I've used Go some, and I like it, but I haven't tried Rust or Elm yet.

Re: A Farewell to FRP

#136
post #113

Earlier quoted context omitted.

Give it another year and the new batch of hotshot developers will reinvent static typing and perhaps one or two other features from the 1970s, but it'll have some cool name and only implement 50% of the functionality.

Modern static typing isn't remotely related to typing from the "1970's"

Well, depends on what you mean with modern static typing. In some ways, mainstream programming is finally catching up with ML, which is from the 1970s.

If you mean cutting edge PL research it's a different story of course.

Re: A Farewell to FRP

#137

Earlier quoted context omitted.

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.

After reading the article, I went into their IRC chan to post this question (i.e. are they leveraging all the research from really-smart(TM) PhD's at Microsoft Research & production testing that Rx has behind it). This guy has a doctorate, so I'd imagine there was a reason why RxJS wasn't leveraged, especially since it seems like a natural fit especially with Typed.*. And n general the Elm/Haskell community is way le…

> And n general the Elm/Haskell community is way less fan-boi-trendy-node-js-macbooks-Rails-flavor-of-the-wheel guys who will nay-nay anything that is Microsoft.

This really hasn't been the case for RxJS at all. It's been praised and version 5 is largely a community effort rather than just an MS effort. You got Ben Lesh and Andre Staltz putting in the most work and neither are MS.

The only thing from MS people don't seem to give a chance is .NET. Everything recent (VS Code, open sourcing stuff, Chakra engine, etc) has been met positively and not dismissed.

Re: A Farewell to FRP

#138
post #14

Earlier quoted context omitted.

Elm doesn't really "need" interfaces to react/angular/whatever, the Elm Architecture defines a standard way to write a reactive application in pure Elm (in a style similar to react/redux).

So Elm is only usable for new projects (or rewrites from scratch) and can't be "tried out" if you have some existing mess of a code and want to replace some especially ugly chunk of it (or write a new feature) - just to see how it goes?

We use Elm inside Angular in production. On https://circuithub.com/projects/ti/TIDA-00230 most of the drawing is Elm.

Re: A Farewell to FRP

#139

Earlier quoted context omitted.

Rust has some really good compile-time checking, it really makes you express everything in a completely non-ambiguous way. C++ on the other hand compiles stuff that may or may not work at all, it doesn't care, which can lead to all sorts of undefined behaviour down the road. Compilers are not all created equal.

Huh. I find that when my C++ compiles, it almost always works. Correctly. But I used the language for nearly 20 years, so maybe it's experience and the patterns I've learned? Not that Rust or Elm aren't better options; don't know, really. Despite feeling like I'm an expert in C++, I don't actually like the language much. I've used Go some, and I like it, but I haven't tried Rust or Elm yet.

> But I used the language for nearly 20 years, so maybe it's experience and the patterns I've learned?

It definitely is. This is not the usual C++ experience. You are probably sidestepping all sorts of undefined behavior due to experience alone.

Re: A Farewell to FRP

#140
Since people in this thread are likely to be elm enthusiasts and know what's going on in the ecosystem, what is the largest high quality elm app you know about and what is the largest high quality elm app that is open-source that you know about?

I've been doing backend work for a while and I'd like to see what is possible these days with elm.

Post reply on HN