Live data from Hacker News

A Farewell to FRP

elm-lang.org

111–120 of 246 posts

Re: A Farewell to FRP

#111
post #60
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…

How about Shen [1]?

A Lisp with types, built-in Prolog, optional lazy evaluation and more. It scratches my Lisp/Haskell love affair.

[1] http://shenlanguage.org/

Re: A Farewell to FRP

#112
post #8

Does Elm have any nice interfaces for common JS frameworks? (like reagent / om in clojurescript, or angular2 for dart / typescript)

Elm has JS interop via ports, which would allow you to mix or migrate towards elm. https://evancz.gitbooks.io/an-introduction-to-elm/content/in...

Emphasis on the migrate, you do not want to have app with both JS and Elm for a long term perhaps.

In the main article: "I do not expect to be compiling to JavaScript forever, especially with WebAssembly on the horizon. The smaller the interface between Elm and JS, the easier it will be to support other platforms."

While I don't want to sound doom and gloom, the JavaScript support according to article is anomaly of today's browsers. So if you want to rely on two parts JS and one parts Elm type of thing, it's good to know it maybe gone.

Re: A Farewell to FRP

#113

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.

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.

Re: A Farewell to FRP

#114

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.

You might be interested in the Crystal language. It's a statically-typed, Object-oriented, Ruby inspired language. It's Ruby with types, basically. You might also be interested in Elixir which ties in to the Erlang ecosystem, but if you are super into OOP (like me) you might find it slightly more difficult, but since you have experience with static-types, you probably know some FP stuff, and so it's not that bad. Eit…

It's odd how people are in their perspectives on static vs dynamic. I can't for the life of me understand how people tolerate static typing on the web. Every time I've tried it the experience has been so tedious.

I just figure, everything is coming in as a string no matter what. It's going back out as a string. The only place it needs to be anything other than a string is something interesting is being done with it and since dynamic typing lets you just worry about it in those cases, it removes a lot of unnecessary code.

On the flip side, outside of web work i can't imagine the reverse.

Re: A Farewell to FRP

#115
post #78

Earlier quoted context omitted.

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

I'm a huge INRIA fan so I decided to play with Esterel a while back. If people call Haskell an 'academic' language, I have no idea how an average person would describe Esterel. "Thinking in" Esterel is going to be a huge shift for the traditionally trained CS guy who's never touched a circuit. Half the people in our field didn't even go to go to school for CS[1]. Hell, I've got a decent amount of LabVIEW and Verilog experience, and even I have trouble with it.

That being said, it's interesting and those resources are definitely going on the Kindle. Do you have a link to your thesis ? (Judging by your comment history, it has a high likelihood of being quality).

[1] Not to denigrate those who were less traditionally educated. The brightest engineer I know is a high-school drop-out. They however were motivated enough to read Sipser, Gunter, B Peirce, and all the standard texts (again, not as a requirement to read All The Fancy Books, but just to enrich his own mind for the sake of knowledge - without that curiosity, one might have a difficult time being more than a code-monkey (not that there's anything wrong with that, but I personally have the scratch of "how does this work" that I need to keep on itching compulsively)).

Re: A Farewell to FRP

#117

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.

The new C++ Core Guidelines & Guidelines Support Library and related tools are interesting efforts to specifically solve those problems.

Re: A Farewell to FRP

#119

Earlier quoted context omitted.

You might be interested in the Crystal language. It's a statically-typed, Object-oriented, Ruby inspired language. It's Ruby with types, basically. You might also be interested in Elixir which ties in to the Erlang ecosystem, but if you are super into OOP (like me) you might find it slightly more difficult, but since you have experience with static-types, you probably know some FP stuff, and so it's not that bad. Eit…

It's odd how people are in their perspectives on static vs dynamic. I can't for the life of me understand how people tolerate static typing on the web. Every time I've tried it the experience has been so tedious. I just figure, everything is coming in as a string no matter what. It's going back out as a string. The only place it needs to be anything other than a string is something interesting is being done with it a…

What typed languages have you used and what aspects do you find tedious? I find that the experience of writing brittle type-checking logic and tests in dynamic languages is rather tedious in its own right.

Re: A Farewell to FRP

#120
post #46
post #33

Elm is very cool and pleasant to use compared to JavaScript, but I have some reservations. The limited typeclass system (for numbers and such) seems... questionable. The interaction of what looks like pure declarative syntax and what is actually impure imperative semantics is confusing to me. I understand that the author wants to avoid monads and other perhaps somewhat confusing staples of functional IO, but I'm not…

I don't think the semantics are any more imperative than IO in Haskell, it's just that there's a different abstraction used for dealing with it. Moreover, Tasks are absolutely monadic, with `andThen` being the bind operator. Elm just chooses to focus on the individual use-case, as opposed to focusing on the broader abstraction.

What does that mean? I'm not sure how you could get more imperative than IO in Haskell; that's literally how the language deals with effectful imperative sequencing.

Which abstraction does elm use? As far as I can see, there is no abstraction. This is the problem. Effectful code in elm looks syntactically just like pure code.

Post reply on HN