I wrote this to show off how to write a compact and powerful animation library. It turned out to be a nice case study in declarative programming as I wrote it! I'd love feedback on the API design, website design, and content as I'm trying to actively improve in all of these areas.
The unreasonable effectiveness of declarative programming
41–50 of 128 posts
Re: The unreasonable effectiveness of declarative programming
#42If you want to show off how simple your API is then I can think of several things that would improve clarity: 1. Don't use parentheses in comments. They make things more visually confusing when javascript imposes enough syntactic clutter as it is. 2. What's with /* */ ? Doesn't js allow keyword arguments? 3. Your method names are probably a little short for my taste. I'd be happier with sequence() and parallel() inst…
----
> 2. What's with /* */ ? Doesn't js allow keyword arguments?
It does since version 6. Example:
The function call anim_interpolated(ease, name, val, time) should be rewritten thus:
anim_interpolated({ease, name, val, time})
The corresponding function definition should be rewritten thus:
function anim_interpolated({ease, name, val, time}) { … }
Re: The unreasonable effectiveness of declarative programming
#43Highly recommended watch:
Re: The unreasonable effectiveness of declarative programming
#44I wrote this to show off how to write a compact and powerful animation library. It turned out to be a nice case study in declarative programming as I wrote it! I'd love feedback on the API design, website design, and content as I'm trying to actively improve in all of these areas.
I like the font used for the code, very readable. But underscoring keywords is superfluous and makes the code listing weird - bold font is enough. Also, the line numbers are jarring, they are too pronounced and they are not important to the reader. Maybe make them gray or put them on the right-hand side. This is a common problem with many blogs. I don't care about the line numbers!
The main text is hard to read - this font, a kind of an hybrid of serifs and tall quasi-monospace characters, is weird and hard to read. Try more usual sans-serif font with shorter-height characters, I think it will be much better both for readability and more distinct from the code listings.
The paragraph symbol is obsolete, I would lose that. At least don't make it look like a link, nothing happens when I click it.
Re: The unreasonable effectiveness of declarative programming
#45Earlier quoted context omitted.
> 2. What's with /* */ ? Doesn't js allow keyword arguments? No.
I couldn't remember if that was one of the things they fixed with ES6. I wonder if passing in a dict is a good alternative in this case. More syntax clutter but at least the params have some semantic meaning.
Re: The unreasonable effectiveness of declarative programming
#46Interestingly, if you watch the Erlang: The Movie ( https://www.youtube.com/watch?v=BXmOlCy0oBM ) they use the term 'declarative programming' to refer to what we would now call 'functional programming'. It's an interesting way of thinking about it - these sort of declarative interfaces are very simple in languages with first class function support.
Re: The unreasonable effectiveness of declarative programming
#47In Haskell, one can make more general combinators in the following way: type Anim a = (Duration -> a, Maybe Duration) -- Linear interpolation linear :: Anim Duration linear = (id, Nothing) -- Sequencing seq :: Anim a -> Anim b -> Anim (Either a b) seq (f, Nothing) g = (\t -> Left $ f t, Nothing) seq (f, Just df) (g, dg) = (\t -> if t Anim b -> Anim (a, b) par (f, df) (g, dg) = (\t -> (f t, g t), max df dg) -- Constan…
Animations are frames over time and can be composed using 'seqA' and 'parA' combinators.
Re: The unreasonable effectiveness of declarative programming
#48I wrote this to show off how to write a compact and powerful animation library. It turned out to be a nice case study in declarative programming as I wrote it! I'd love feedback on the API design, website design, and content as I'm trying to actively improve in all of these areas.
On being invoked, it sets out.v = field
should be: (…) out.field = vRe: The unreasonable effectiveness of declarative programming
#49Earlier quoted context omitted.
These are the type of blog posts I miss on HN. It used to be what was all over the homepage. Thanks for taking the time to write it. One bit of feedback: the sliders are almost impossible to click on with a mobile browser. The drag handle should be much larger. There’s also a horizontal scroll bar that appears partially above the bottom of the page, something is overlapping the main content body.
Which mobile browser? Android Chrome looks nice, draggable sliders, all animations working.
Re: The unreasonable effectiveness of declarative programming
#50Back in the day when I was making videogames ( http://www.mysterystudio.com ), I implemented something similar for my framework. Most of the framework was declarative. There were Sprite objects that had an associated Image and a position (among other things). The onUpdate(dt) method of the "screen" didn't explicitly draw things on the screen, it only updated positions and other attributes of the Sprites, and the rend…