This release makes me very happy. I never really took a look at Elm but yesterday I've receive a bug report on a very old library of mine to parse GLSL. The author of Elm told me it was used in their WebGL work and pointed to that Thwomp example. I didn't know that library was actually used by anyone!
The Elm hackers continue to impress me. FRP, the interactive timeline debugger, and now functional 3D graphics. Functional game programming is a big interest of mine, and I've taken a lot of inspiration from Elm in my own personal project to create a 2D game engine for Guile Scheme.
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:
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!
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
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.
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.
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.
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 meaning which has not been demonstrated to be practical and therefore one must consider the possibility will never turn out to be practical. It is not out of the question there exists some fundamental mathematical problem with the strict definition of FRP and therefore it must inevitably turn into a family of techniques.
This strikes me as sort of like insisting that you don't have OO unless you fully support access control via "private", six months before the first release of anything that actually supports "private", and all along it turns out that access control is fairly orthogonal to OO anyhow.
If I am out of date and somehow FRP has settled on a consistent model (without this fact being trumpeted on /r/haskell, where I would have heard about it), then it is, at the very least, still awfully young to be getting this pedantic about what is The One True Definition; it could only have been proved to be not immediately impractical, not yet proved practical.
There are a ton of perfectly OO languages with little to no language-enforced encapsulation. You're sort of proving my point... if you're going to insist that if you don't have that you don't have OO, you've got an awful lot of language communities to go explain to them that their language isn't OO... hopefully you've got some explanation of what it actually is, too, that makes some sort of sense.
Encapsulation isn't just information hiding, though I guess that is how people usually grok it. The essence of an object is its identity, with identity you can own things like state, but then that state needs to be protected. In a pure system, this identity is problematic: all values are are identified simply by their structure, and state would be unheard of. We might try to fake it by providing identities manually (see immediate-mode UIs), but then you are just trying to build objects again anyways.
Do you have values that you can name and talk about independent of their structure or how you get a handle to them? Yep, those are objects. I think most languages that claim to have objects actually have objects, the bar is not high! What is more problematic are communities who claim not to have objects, like the entity component people, or the functional programming people who start passing around numeric/string based identifiers to "solve expressiveness problems." But they are just in denial in that they have recreated objects.
Note that information hiding, what we more generally understand as encapsulation, is not even meaningful without objects. So if your values don't have identity, it is only their structure that is important, and then it doesn't make sense to hide that structure without chopping it off of the value itself!
No, I've never dug in enough to understand. I'm much more in the "wait and see" camp about FRP... if it works, great, I'm glad someone's thinking about it, but the philosophical spirit in which it is being approached rubs me the wrong way (and after a few tries, I can't seem to write my characterization of that philosophy in way that doesn't sound insulting or sarcastic, so I'm going to have to leave it there, sorry). YMMV.
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.
If you are asked a question about some programming terminology, then I don't think going as deep as talking about denotational semantics is a good idea.
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 it, but at least there are sources listed and the basic idea is clearly presented: it's about values over time as first-class values and how they combine and compose.
Denotational semantics is a tool like many others, and he even provided a very simple explanation of what it is, before saying how it was useful - it was mentioned as a tool, not presented as something essential to FRP.
All in all it's rather informative and better than many other scientists would write. So, while I absolutely don't support what was said in deleted comment, I wouldn't hold this particular post against Conal.
> 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 <term> 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.
Often coming up with a lucid succinct definition of something requires an outsider. The principle is too deeply involved in the intricacies to have a frame of reference that matches the neophyte.
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?
The main effect was that I thought "why is this ML-style language not using type inference!". :) But now that you have explained why you've annotated the examples, I can see that it would be educational to see the types when the reader wouldn't have seen the library before.
The API expects triangles, but it is implemented to always use buffers under the hood. Basically, mesh data of 10 triangles with 4 attributes per vertex is converted to 4 buffers, each of length 30.
