Finally TCO!
Actually in my UI-heavy Elm programs it isn't that often that I have to write functions with large recursion depth. But it is really comforting to know that the compiler is analyzing my code and making it more efficient. :)
Chromium graphics engineer | Prezi (http://prezi.com) | Budapest (visa) or SF (visa) or remote (depending on your qualifications and needs)
Prezi is looking for an expert in web graphics to help us build our zooming rendering engine for modern browsers. You should have deep knowledge of the Chromium web browser and have experience building high-performance JavaScript apps using Canvas or WebGL.
Despite being a presentation tool, Prezi’s rendering needs are closer to a 3d game engine: 60fps zooming transitions, level of detail for vectors and images, and pixel-perfect rendering across platforms. On top of that, we have to provide high reliability because artifacts and dropped frames are incredibly painful for our users when they are presenting in front of hundreds of people on a big screen.
I think what you are looking for is called auto-lifting. That is, automatically lifting functions into reactive streams.
While it sounds like an awesome idea, things get crazy really fast. It's hard to explain briefly, but make it explicit and clear to the programmer which things are reactive streams and which are simply values makes it much easier to predict what the program is doing.
In my opinion, the current way of doing things with reactive mechanisms really doesn't make it clear what the program is doing. There's lots of things happening at the same time, and also glitches can occur (variables rapidly changing after eachother), and also non-optimal efficiency (things being recomputed unnecessarily).
If my program just gets re-evaluated in an optimal way (without any other side-effects) then that would make my life much simpler.
The research I linked to already states that it can be done. So I was wondering if there are any Javascript implementations yet out there.
SAC is quite different from reactive programming in the sense that it is not, well, reactive or interactive. SAC deals with incremental recomputation on change, whereas most reactive programming systems out their don't support incremental recomputation (maybe some DOM diffing and that's about it).
Check out Adapton though, which is trying to bridge the gap.
Glad you like it! I think your Elm framework has inspired alot of people. Elm and LightTable (the Clojurescript development environment) are my two big sources of ideas right now! Thanks to you! :)
This change is more about consistency than anything else.
The problem is that other things, like shapes, are specified in pixels. So if text size isn't, it makes it impossible to position any shapes relative to text.
Think about a title in a game; you don't want it to go off the screen and you don't want it to wrap either.
It seems the internet shares this opinion. My feeling was that `px` was a general solution, but I may have misunderstood the true meaning of em. I'd imagined code such as:
em = 16
title = Text.height (2*em) (toText "Title")
pic = image 400 (4*em) "yogi.jpg"
I can also imagine the definition of em depending on the user's settings or fonts. In any case, we'll definitely open this up for discussion on the lists again if people start running into problems :)
I think the idea here is that you aren't /forced/ into inversion of control. That is, if it is clearer to write things side by side, instead of separated into another callback function, you can keep them together.
