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

31–40 of 41 posts

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

#31

Post by seanmcdirmid »

wheatBread wrote: post #29
seanmcdirmid wrote: post #26

Earlier quoted context omitted.

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!

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.

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

#32

Post by johnpmayer »

thu wrote: post #3

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!

John here. Having language-glsl available on hackage was a boon for the features in this release. Thank you!

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

#33

Post by kristianp »

wheatBread wrote: post #28
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 total…

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.

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

#34

Post by jerf »

seanmcdirmid wrote: post #25
jerf wrote: post #11

Earlier quoted context omitted.

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.

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.

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

#35

Post by jerf »

edwintorok wrote: post #19
jerf wrote: post #11

Earlier quoted context omitted.

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…

Can you expand on the contradictions? Is there a link where I could learn more about them?

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.

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

#36

Post by seanmcdirmid »

jerf wrote: post #34
seanmcdirmid wrote: post #25

Earlier quoted context omitted.

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

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!

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

#39

Post by conal »

wheatBread wrote: post #9
[deleted] wrote: post #8

Earlier quoted context omitted.

[deleted]

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…

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

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

#40

Post by sitkack »

Dewie wrote: post #27
klibertp wrote: post #18

Earlier quoted context omitted.

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

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.
Post reply on HN