News for hackers. Stuff that matters.
Re:The unreasonable effectiveness of declarative programming by jcelerier on Tuesday May 19, 2020 @04:37AM (#23232676)
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
y will be 3 as "y := x + 1" must hold.

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 by wereHamster on Tuesday May 19, 2020 @04:45AM (#23232727)
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.

Re:The unreasonable effectiveness of declarative programming by jcelerier on Tuesday May 19, 2020 @05:21AM (#23232915)
> 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.

c'mon, this is an example in a forum post ! of course it doesn't make sense in real life. real life is

   distance := computeDistanceToCenterOfScreen(cursorPosition)
   text := "the current distance is: " + distance
but that just muddies the waters needlessly

> 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.

yes, some languages work like that, but it's not the point - either you assume that you can update values in your declarative bindings like that, or you have to define your binding in terms of some external behaviour that will change in magic ways, which again would not be very nice to do as a simple forum post example

Re:The unreasonable effectiveness of declarative programming by YeGoblynQueenne on Tuesday May 19, 2020 @08:01AM (#23233879)
>> IMHO in a declarative language your example should be an error. You defined x twice.

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.

Re:The unreasonable effectiveness of declarative programming by sp332 on Tuesday May 19, 2020 @09:39AM (#23234747)
I think the idea is that declarative statements use "equals" like math uses equals, not as assignment. If you say x = 1 and then later say x = 2, that is a contradiction. Usually if you evaluate each statement in order from top to bottom, that is procedural programming. And if you don't do that, it's hard to assign multiple values to one variable because you need a way for the compiler to know when the variable has each value.
Re:The unreasonable effectiveness of declarative programming by the_af on Tuesday May 19, 2020 @01:40PM (#23237729)
> This would be an error in a language with immutable data structures

It's an error from the point of view of equational thinking; (im)mutabilty is not involved.

The name `x` cannot be 1 and 3 simultaneously. It's either 1 or 3. So in the allegedly declarative program, the programmer first claimed name `x` is bound to the value 1, but later claimed it's 3. That's the error.

This has nothing to do with mutating data structures. Like the sibling comment notes, there is not "first-this-then-that" order of evaluation, so you cannot read this as "first `x` means 1, but later it means 3", because there are no notions of "first" and "later".

Re:The unreasonable effectiveness of declarative programming by Aqueous on Tuesday May 19, 2020 @06:50AM (#23233443)
there’s a lot of different perspectives on what declarative actually means but in my view it means creating a description of what you want rather than how you want it done. in that sense I think the article qualifies. what you have above is also declarative in the sense that you are describing rules, not how to solve for them. i believe this is kind of declarative is ‘constraint programming’ and also qualifies.
Re:The unreasonable effectiveness of declarative programming by naringas on Tuesday May 19, 2020 @10:59AM (#23235565)
I agree, my go-to example of declarative programming is SQL

you say what you want, and the DB figures out how best to get it.