Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elm 0.12.3 – Hardware accelerated 3D rendering with WebGL

elm-lang.org

Post reply on HN
Print view View original

21–30 of 41 posts

Re: Elm 0.12.3 – Hardware accelerated 3D rendering with WebGL

#21

Post by wheatBread »

seanmcdirmid wrote: post #16
wheatBread wrote: post #9

Earlier quoted context omitted.

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

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?

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.

Re: Elm 0.12.3 – Hardware accelerated 3D rendering with WebGL

#23

Post by 3rd3 »

klibertp wrote: post #18
Dewie wrote: post #14

Earlier quoted context omitted.

So the contention is what Conal Elliot means by FRP ? If that's the case, it might be that most of us might as well be left in the dark about what FRP really means, because it seems that Mr. Elliot can be quite obtuse about giving a simple definition of a term. https://stackoverflow.com/questions/1028250/what-is-function... If you are asked a question about some programming terminology, then I don't think going as de…

This is an answer from a scientist (or at least it looks like it, I don't know anything about Conal Elliott, not even if he actually is a scientist). People like these think and speak on a level of abstraction which may be a little higher than what most people are used to. As a response from a scientist, his post is as good as you could hope, I think - you still need a fair share of googling and reading to understand…

The deleted comments claimed that Elm would not fit into the usual definition of FRP (giving references to Conal Elliot).

Re: Elm 0.12.3 – Hardware accelerated 3D rendering with WebGL

#25

Post by seanmcdirmid »

jerf wrote: post #11
[deleted] wrote: post #8

Earlier quoted context omitted.

[deleted]

Before I'm willing to concede a particular, very restrictive definition about what "FRP" is, it would be nice to first see a model of it that does not contain fundamental logical contradictions acknowledged by the author. Last I knew nobody had a continuous, perfectly sensible model of FRP in theory. Further, given the lack of extant model, it's very silly to get pedantic over the term, and end up insisting on a mean…

Encapsulation (and it's twin sibling identity) is completely essential to OO, otherwise you are just using objects as poor man modules.

Re: Elm 0.12.3 – Hardware accelerated 3D rendering with WebGL

#26

Post by seanmcdirmid »

wheatBread wrote: post #21
seanmcdirmid wrote: post #16

Earlier quoted context omitted.

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?

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…

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/

Re: Elm 0.12.3 – Hardware accelerated 3D rendering with WebGL

#27

Post by Dewie »

klibertp wrote: post #18
Dewie wrote: post #14

Earlier quoted context omitted.

So the contention is what Conal Elliot means by FRP ? If that's the case, it might be that most of us might as well be left in the dark about what FRP really means, because it seems that Mr. Elliot can be quite obtuse about giving a simple definition of a term. https://stackoverflow.com/questions/1028250/what-is-function... If you are asked a question about some programming terminology, then I don't think going as de…

This is an answer from a scientist (or at least it looks like it, I don't know anything about Conal Elliott, not even if he actually is a scientist). People like these think and speak on a level of abstraction which may be a little higher than what most people are used to. As a response from a scientist, his post is as good as you could hope, I think - you still need a fair share of googling and reading to understand…

> This is an answer from a scientist (or at least it looks like it, I don't know anything about Conal Elliott, not even if he actually is a scientist).

He is the (or one of the two) inventor of FRP.

> People like these think and speak on a level of abstraction which may be a little higher than what most people are used to.

I don't care what 'level of abstraction' someone normally works on. When you're supposed to explain things to other people, you're supposed to explain it their level, not the level of someone who already knows FRP or who is also a programming language theorist/implementer. That was StackOverflow, not Lambda the Ultimate.

> As a response from a scientist, his post is as good as you could hope, I think

A lot of scientists are educators, and so they have to descend from their 'lofty towers of abstractions' to explain what a for-loop is to first year students. I have certainly seen many scientists, by whom I couldn't read and comprehend a single paragraph of their research paper, be able to explain things much more straightforwardly than him.

> you still need a fair share of googling and reading to understand it,

SO answers should try to be self contained. A general rule, but certainly doable for a question of the type "what does mean?"

> Denotational semantics is a tool like many others,

A tool for prog. language theory and implementation. A tool for StackOverflow answers? Maybe, if you also consider answering SO questions of the type "what does this Scala program do" by converting it to an intermediate representation in lambda calculus, or answering "why won't this type check" by explaining with a type deduction in some sequent calculus, or by answering the question "what value will this formula give", by manipulating it as some algebra over some arithmetic signature.

It might be beneficial to describe a language by some canonical semantic representation. For a SO answer? If you manage to write several paragraphs without even giving one introductory explanation/example/intuition about what it is, and then you catch yourself writing something like " If this description is gibberish to you, consult (a) Denotational design with type class morphisms,"... you should probably admit to yourself that you've become so accustomed to what is being asked for that you can't even imagine or sink down to the level of a person who has never been in touch with it.

Re: Elm 0.12.3 – Hardware accelerated 3D rendering with WebGL

#28

Post by wheatBread »

kristianp wrote: post #24

I'm curious, why isn't type inference used in the examples? For example: http://elm-lang.org/edit/examples/WebGL/Triangle.elm Edit: ok, the language has full type inference, but not the webgl examples.

Type inference works on all Elm programs, but it's best practice to add type annotations.

In the WebGL examples, I felt it made things a bit clearer since folks are probably not familiar with how WebGL works. Once you get comfortable reading types, it helps you see how things fit together, and they definitely helped me learn John's API when I was new to it :)

But if you don't need/want type annotations, you can totally take them all away and they'll be inferred! How did having them effect your experience of looking at the examples?

Re: Elm 0.12.3 – Hardware accelerated 3D rendering with WebGL

#29

Post by wheatBread »

seanmcdirmid wrote: post #26
wheatBread wrote: post #21

Earlier quoted context omitted.

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…

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/

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!

Re: Elm 0.12.3 – Hardware accelerated 3D rendering with WebGL

#30

Post by seanmcdirmid »

myko wrote: post #20
davexunit wrote: post #7

Earlier quoted context omitted.

>Elm isn't FRP What do you mean? http://elm-lang.org/learn/What-is-FRP.elm

I'm no FRP expert but Conal Elliot seems to agree with the now deleted comments: https://github.com/ReactiveCocoa/ReactiveCocoa/pull/1344 (Conal Elliot is one of the authors of what is, AFAIK, the earliest paper on FRP: http://conal.net/papers/icfp97/ )

Here is Conal's comment duplicated for prosperity:

> All of these changes so far look good to me. They definitely helps reduce confusion! Under "Here are some resources for learning about FRP", I'd drop the "Principles of Reactive Programming on Coursera" and the two Elm references, as they're both quite different from (the original) FRP. Based on the Coursera description, I'm guessing that it is about Rx. Elm is a system conceived independently from (not even "inspired by") FRP, which bears some superficial similarities, but doesn't have either of the two fundamental properties I mention in the StackOverflow posts (precise & explicit denotation and continuous time). I've spoken with Elm's author, and we'll hopefully get that confusion sorted out.

He is definitely right about Rx, but Meijer also never claimed as much (since they are also WG 2.8 members, I'm sure they talk a lot). One of the tenants of FRP is continuous time, and you lose that once you update only at discrete events, which IMHO, is a very sane choice to make. This divergence with classical FRP first appears with Cooper et al's FatherTime work and the later Flapjax work by the same authors. Conal has made some effort to combine the pull (sampling) and push (demand-driven) versions of FRP:

http://conal.net/papers/push-pull-frp/

But still, it makes a lot of sense to go full on discrete. Krishnswami provides some good results in this direction:

http://www.mpi-sws.org/~neelk/popl074-krishnaswami.pdf

I'm not sure, however, what Conal thinks of his work.

Post reply on HN