Hacker News new | ask | show | jobs
by wheatBread 4412 days ago
Whoa, I'm surprised to hear that I "didn't know anything about FRP when I made Elm". A huge part of developing Elm was doing literature review and making new contributions to FRP ( http://people.seas.harvard.edu/~chong/abstracts/CzaplickiC13... ) and "making things up as I went along" was certainly not how we ended up with a nice system. I don't know why you didn't talk to me at BayHac before making statements like this.

Conal and I definitely disagree about what is important to emphasize. FRP is a term that is used in many different ways, in the same way that FP is a term that is used in many ways. I see this as a testament to the power of the idea, and it seems like claiming that this and that are not really FRP is limiting the impact of the original work. We definitely need more precise terms though!
2 comments
conal 4411 days ago
Indeed I misinterpreted your remarks on Sunday about the origin of Elm. I now understand that while you had an independent inspiration about time-varying values, your design of Elm was strongly influenced by FRP papers. I really do like your work (and you personally). Such good taste in design is rare, in my experience.

I'm sorry that I missed the deleted remarks that touched off this discussion, though I can try addressing the two snippets you shared. As for "making things up as I went along", it's not a phrase I would use. Besides, I value creativity in the highest esteem. About "didn't know anything about FRP when I made Elm", I did think you'd had your key ideas on your own, and retrospectively related them to the FRP literature. Now I understand that the FRP influence was more substantive than I knew.

I've posted a correction on that ReactiveCocoa page (https://github.com/ReactiveCocoa/ReactiveCocoa/pull/1344#iss...): "Correction. I misinterpreted some recent remarks by Evan Czaplicki (@evancz) about the origin of Elm. While his initial idea was independent (to his credit), the design of Elm itself was indeed influenced by the FRP literature. I'm glad you kept the Elm references. I'll apologize to Evan." I also posted (terser) correction to a reply I made on Twitter (https://twitter.com/conal/status/469005649645281280): "I mistook @czaplic's remarks on #elmlang origin. Independent inspiration; design quite influenced by FRP lit. Sincere apologies, Evan! :(". If I see my misinformation spreading, I'll do my best to correct it.

Again, my sincere apologies, Evan! Regards, - Conal

link
seanmcdirmid 4412 days ago
I've glanced at the PLDI paper and would definitely consider Elm to be FRP, more in Conal's vision than say Flapjax. But I don't get what new contribution Elm makes to push-based FRP beyond being a nice implementation of it?
link
wheatBread 4411 days ago
The most novel stuff was about how to handle asynchrony and concurrency without unexpected/unwanted glitches, though I think formulating things in a way that is simple, accessible, and efficient was important too. My thesis ( http://www.testblogpleaseignore.com/wp-content/uploads/2012/... ) goes through all of the previous literature that I could find at the time. It frames my view on Elm fits into prior work and how I understood things at that time, but that section got cut from the PLDI version unfortunately.
link
seanmcdirmid 4411 days ago
Ok, fair enough. I never tried calling my work FRP before since...well, I threw out the functions and embraced glitches. You should have a look at Conal's vertigo work if you haven't already. It will give you cool things to do functionally with your GPU support.

http://conal.net/Vertigo/

link
wheatBread 4411 days ago
Ah, cool! I think he told me about this work when we chatted at ICFP last year, but wasn't able to find it. So thanks for the link!
link
seanmcdirmid 4411 days ago
One thing that this work requires is some from of symbolic differentiation. Basically, given some expression e, you have to compute, via a symbolic analysis on e's structure, a derivative for e, e'. e' can then be used to compute normals used for shading, replacing the need for a hand crafted normal map (you can also approximate normals via sampling, but if you have a functional definition of a surface, why not just use derivatives!).

This definitely requires some compiler support, but the purity of Elm should be helpful in that regard.

link