The unreasonable effectiveness of declarative programming
bollu.github.io
The unreasonable effectiveness of declarative programming
1–10 of 128 posts
Re: The unreasonable effectiveness of declarative programming
#2I 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.
Re: The unreasonable effectiveness of declarative programming
#3I believe this library would be very useful for simple animations. The small size and simple API should make this usable in many cases.
As for more sophisticated animations, I can think of reanimate [1], which outputs animations in SVGs, and should work on the web with wasm if integration is needed [2][3].
I completely agree that declarative programming (and functional-style programming) shines for composing animations. Imperative programming does not show the intent as clearly, and makes it hard to reason about or time travel animations.
[1]: https://reanimate.readthedocs.io/en/latest/glue_tut/
Re: The unreasonable effectiveness of declarative programming
#4I 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.
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.
Re: The unreasonable effectiveness of declarative programming
#5I 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.
Very cool. I overall very much like both your library, and your presentation.
That said, I found the abbreviations initially confusing. For variable names and symbol/strings, maybe hold off until not the first example? For the functions themselves, can you do a non-abbreviated alias?
I also missed the `par` in `seq((...).par(...))` the first time. And, personally, I think `par([...,...])` would be clearer, and allow for some beneficial constructs - is there a way to allow both?
Particularly, I really admire the time travel aspects; that you can, what that means, and what allows that to happen.
It reminds me a lot of what I've tried to do (not as elegantly, so I might come crib from you!) with the pattern renderer in https://github.com/rangerscience/butterfly
Re: The unreasonable effectiveness of declarative programming
#6Interesting read. Until safari on my iPhone 7 crashed.
Could it be a memory leak? Or simply too many animations for my ageing phone to handle?
Re: The unreasonable effectiveness of declarative programming
#7I 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.
Not that I want to disparage as the library looks neat and clear, but is that what declarative means in 2020 ? The code looks like mainly a builder pattern for an animation datastructure.
I've always heard declarative as a sort of synonym to programs defined in terms of equational reasoning such as Lustre for instance - a rule of thumb to separate declarative languages from imperative languages is that in declarative languages
x := 1
y := x + 1
x := 2
e.g. it's not enough to just construct a graph-like datastructure for things to be declarative, the language has to do it itself.
Also, note that the par / seq model (https://en.wikipedia.org/wiki/Series-parallel_graph) is not as powerful as a general dag as things such as the K4 graph cannot be represented in it - even though it may make sense in some animation scenarios.
Re: The unreasonable effectiveness of declarative programming
#8I don't like weird sounding headlines. Why they keep inventing them?
Re: The unreasonable effectiveness of declarative programming
#9I don't like weird sounding headlines. Why they keep inventing them?
What's wrong with it? Besides maybe not knowing these words
Re: The unreasonable effectiveness of declarative programming
#10I 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.
Not that I want to disparage as the library looks neat and clear, but is that what declarative means in 2020 ? The code looks like mainly a builder pattern for an animation datastructure. I've always heard declarative as a sort of synonym to programs defined in terms of equational reasoning such as Lustre for instance - a rule of thumb to separate declarative languages from imperative languages is that in declarative…
IMHO in a declarative language your example should be an error. You defined x twice. Intentionally or not, this is confusing, for others and for you in a week when you have to look at the code again.
Also, why should the second binding override the first? You introduced a temporal dimension where later lines of code somehow override earlier lines of code. That is not a necessity in a declarative language. It may be how we humans read text (from top to bottom), but it does not mean the computer has to process it in the same way.