31–40 of 128 posts
The unreasonable effectiveness for toy examples to ignore real world complexity.
Where do you feel this is likely to break down? What would a better approach look like? Is it intractable or can one have both simplicity and power? I suspect the answer is "yes" in which case OP deserves a better response.
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.
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.
Interestingly, 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.
C has first-class functions support, but I don't think it's very easy to define such interfaces in C. Closures and automatic memory management seem to be the "magic dust" that makes this nice to use, first-class functions are necessary but not sufficient.
If 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…
No.
If 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…
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.
I can see that the names of the functions are declarative in style but the code is a series of function calls that seem to be giving instructions to the javascript interpreter to perform a sequence of operations. For example, you describe the code as follows:
1. anim_const(name, val) to set a constant value val to name name.
2. anim_interpolated(ease, name, val, time) to change to a named value with name
name to value val in duration time.
3. anim1.seq(anim2) to run anim2 once anim1 has completed.
4. anim1.par(anim2) to run anim2 in parallel with anim1.
5. anim_delay(time) to do nothing for time time.
Do you mean something else by "declarative"? Could you say what you mean by "declarative"?
The unreasonable effectiveness for toy examples to ignore real world complexity.
Earlier quoted context omitted.
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 h…
This would be an error in a language with immutable data structures. Declarative and immutable are not the same thing and there is nothing that says a declarative language must have immutable data structures.
If 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? No.
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.
Interestingly, 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.
In Prolog, everything is either a fact or a rule involving facts. If you leave some variables unbound, you get what we think of as a program, where the system tries to infer values.