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

211–220 of 246 posts

Re: A Farewell to FRP

#211

Post by naasking »

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…

> My thesis was related to synchronous programming languages and articles about FRP tend to have too little to say about them, for my taste.

What would you expect them to say exactly? Synchronous languages are first-order reactive programming, but FRP is about higher-order reactive programming.

Re: A Farewell to FRP

#212

Post by naasking »

iamwil wrote: post #188

I found that while things worked once it compiled, I spend most of my time staring at compilation errors, especially as I refactored. So I'm mostly trading time spend debugging subtle state errors with fixing compile type errors. It feels not as productive, since I'm usually looking at errors. Also, I'm still new to FP, so if you go outside of the Elm architecture, you're going to run into problems, which you're use…

> So I'm mostly trading time spend debugging subtle state errors with fixing compile type errors. It feels not as productive, since I'm usually looking at errors.

Strange, because debugging subtle state errors seems far more time consuming to me than fixing compile-time errors. You have to launch debugging sessions or insert logging commands and step through reams of code, where compile-time errors tell you exactly where the problems are.

Re: A Farewell to FRP

#213

Post by ccapndave »

tunesmith wrote: post #94

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

I suppose if anything it is the customer subscribes. But actually, in practice, it doesn't really feel quite like this because in FP you just have a bunch of functions and there isn't the concept of things 'owning' other things like you have in more OO based language. What actually happens is that you add a (sort of) listener to the subscription that fires a message in a particular update function, which manipulates some part of the model.

Re: A Farewell to FRP

#214

Post by vijayr »

zalmoxes wrote: post #5

As someone who is just getting started with frontend development, I decided to go with Elm instead of learning JS and React. I found the whole experience very pleasant, even as a beginner. Not only is the elm code I write reliable, but I've found that adding more features does not bloat my code. Refactoring a codebase as it grows in elm is pleasant, and following the Elm Architecture guides me on the correct structur…

What resources are you using to learn Elm?

Re: A Farewell to FRP

#215

Post by kyllo »

Gaelan wrote: post #179
SomeCallMeTim wrote: post #171

Earlier quoted context omitted.

Funny. I managed to get Haskell to crash within about 20 minutes of first trying it out. OCaml is supposed to be pretty fast, but so far Haskell hasn't impressed me with performance either.

What code did you write?

Something like `main = head []` probably, lol.

Re: A Farewell to FRP

#216

Post by marcosdumay »

rubber_duck wrote: post #206
marcosdumay wrote: post #164

Earlier quoted context omitted.

Well, I find that when my C++ compiles When I first learned Java, still in my undergrad, my first impression (and nearly everybody's) was that when it compiles it works. It was still more work than Perl, Lisp, Prolog, and everything, but didn't require the annoying C debugging cycle. But, anyway, all that is kids play near Haskell.

>didn't require the annoying C debugging cycle Are we talking C or C++ ? C compiler is basically useless for compile time error checking because C type system is ridiculously weak. C++ on the other hand can buy you a lot of things with templates, richer type semantics, etc. And also keep in mind that C++11 and onward is very different from C++ of yore and it catches a lot of errors at the compile time - move semantic…

Both languages have approximately the same problems for debugging. Explicit memory references are hard to follow, lack of overflowing protection requires a lot of extra caution to catch the errors, and failures lead to an unforgiving stop with at most a core dump. C++ is much better for statically catching errors, but templates and copy/move semantics make it even harder to debug.

And yes, I imagine C++11 is much better. Unfortunately, I didn't write anything big in C++ since then.

Re: A Farewell to FRP

#217

Post by marcosdumay »

danek wrote: post #196
powersurge360 wrote: post #184

Earlier quoted context omitted.

Hello! I don't know if English is your first language or not, but that last sentence was significantly confusing that I wanted to correct it for you and others who may read it. The two idioms are 'child's play' & 'next to'. The words are correct synonyms but the usage is unusual enough that I read as having a totally different meaning my first time.

I was also confused by it. However I read the last sentence as the author making a meta-point by using purposefully incorrect grammar, a sort of reversal of the first sentence about c++ code compiling but leading to segfault--like an artistic statement. If it was an accident, then all the better!

:)

English is not my first language, and it is a rare construct. I thought it was correct.

Out of curiosity, how should it read?

Re: A Farewell to FRP

#219

Post by wtbob »

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…

> Wondering if you could make a lisp where `lambda` or `fn` required type annotations

…

> Someone implemented it in Common Lisp in the 80s I'm sure.

Even better, it's a standard part of Common Lisp: functions default to being 'typed' to take the universal type, but annotations can be used to declare any types you want (to include types like (integer 3 27), which specifies an integer between 3 and 27), which can be compiler-enforced.

I really don't understand why Common Lisp doesn't see more use. It's modelling clay for computation.

Re: A Farewell to FRP

#220

Post by krakensden »

vvanders wrote: post #172
SomeCallMeTim wrote: post #170

Earlier quoted context omitted.

Rust does sound interesting, but it doesn't seem to be focused on the areas that I need right now. Go has GoRoutines, which are light threads; they can be executed on multiple CPU threads, but by default Go only allocates one CPU thread per physical CPU, even if you allocate tens of thousands of GoRoutines. For the kind of networking server code I'm writing, light threading is far more efficient than using an OS thre…

Ah, sounds like Erlang/Elixir would be a better fit since the BEAM is the king of lightweight threads/processes. You said C++ so that's why I suggested Rust, generally a GC tends to preclude spaces where C++ excels which is why I would think you'd want to try something other than Go. On the Rust side there's things like mio for fast io but coroutine/light threads aren't really a focus afaik. I would still think you c…

You just can't be happy if someone else is using Go, can you.
Post reply on HN