Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The unreasonable effectiveness of declarative programming

bollu.github.io

Post reply on HN
Print view View original

61–70 of 128 posts

Re: The unreasonable effectiveness of declarative programming

#61

Post by chmod775 »

mD5pPxMcS6fVWKE wrote: post #60

In non-declarative way it would look shorter and clearer anim_set("cx", 100); anim_set("cr", 0); anim_interpolate(ease_cubic, "cr", / val= /10, / time= /3)); etc don't know what are you trying to achieve here

First off, this part:

>anim_interpolate(ease_cubic, "cr", /val=/10, /time=/3)

is still declarative.

In any your example is incomplete and proves nothing because the end result should be a function that takes t and returns cy and cr. Not sure what your code is supposed to be really.

Secondly, the author explained at length what the advantages of their approach are (purity, composition, time travel debugging, ...).

I'm not sure what you're trying to achieve with your comment except trying to make yourself look smarter by deriding others.

Re: The unreasonable effectiveness of declarative programming

#62

Post by uryga »

reuben364 wrote: post #25
uryga wrote: post #23

Earlier quoted context omitted.

pedantic stuff: typo here: seq (f, Maybe df) (g, dg) t s/Maybe/Just/ and `par` should be par :: Anim a -> Anim b -> Anim (a, b) par (f, df) (g, dg) = (\t -> (f t, g t), max df dg) --- i'm not sure about `par` - if my understanding of Anim is right, it'll take the shorter animation over its specified duration. what if it was something like: par a@(_, da) b@(_, db) = (ab, max da db) where ab t = (a `at` t, b `at` t) at…

Replying to your edit: As I was writing it my headspace was that the duration was for seq to know when to switch. I wasn't really thinking about stopping the animation too. (I also notices that my seq is wrong. The subsequent animation should start at the beginning, so it should be `g (t - df)`, not `g t` I believe you are correct. Your implementation is more at the heart of what I wanted to show. . The main point I…

it's a nice idea, i was just in a nitpicky mood :)

Re: The unreasonable effectiveness of declarative programming

#63

Post by mrfredward »

BiteCode_dev wrote: post #59

Declarative is great, and I wish more people created clean declarative API with regular languages instead of writting yet another DSL. But remember that the problem with a declarative syntax, is that it needs a runtime, which typically the end user doesn't touch. And if the runtime doesn't take into consideration one use case, the user is stuck. Don't forget to provide an escape hatch.

The other problem with declarative code on a runtime you didn't create is traditional forms of debugging go out the window. You can't set a breakpoint, or single step, or even printf debug declarative code directly, though you can peek behind the scenes a little if you control the runtime.

Re: The unreasonable effectiveness of declarative programming

#64

Post by klysm »

BiteCode_dev wrote: post #59

Declarative is great, and I wish more people created clean declarative API with regular languages instead of writting yet another DSL. But remember that the problem with a declarative syntax, is that it needs a runtime, which typically the end user doesn't touch. And if the runtime doesn't take into consideration one use case, the user is stuck. Don't forget to provide an escape hatch.

Declarative code doesn’t need a runtime if you have a compiler

Re: The unreasonable effectiveness of declarative programming

#65

Post by reuben364 »

Lemmih wrote: post #47
reuben364 wrote: post #14

In 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…

This is almost exactly how reanimate generates animations with Haskell: https://github.com/Lemmih/reanimate Animations are frames over time and can be composed using 'seqA' and 'parA' combinators.

One thing I realized that seq'ing too many things might be bad for performance. As I understand it,

   foldr1 (\x y -> ((x `par` delay 1) `seq` y)) $ map pure [1..]
Would require more and more comparisons over time. Is there some sort of codensity like trick that you can do? Or is this something the user of the library would worry about if it came to that. Or just have a redundant API.

Re: The unreasonable effectiveness of declarative programming

#66

Post by naringas »

Aqueous wrote: post #27
jcelerier wrote: post #7

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…

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.

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.

Re: The unreasonable effectiveness of declarative programming

#67

Post by cool-RR »

Looking at the first code sample, I wouldn't call it declarative at all. For me, the defining feature of declarative code, is that it doesn't have a list of actions to be performed one after another. That code sample is such a list of actions, which for me makes it imperative code, meaning "first do this, then do that, then do the other thing."

The "list of actions" approach is what makes code complexity grow exponentially, because whenever you look at a series of 10 instructions, you have to think "what state was created by the combination of the first 7 instructions, and does the eighth instruction depend on that state?"

Re: The unreasonable effectiveness of declarative programming

#68

Post by Trufa »

cool-RR wrote: post #67

Looking at the first code sample, I wouldn't call it declarative at all. For me, the defining feature of declarative code, is that it doesn't have a list of actions to be performed one after another. That code sample is such a list of actions, which for me makes it imperative code, meaning "first do this, then do that, then do the other thing." The "list of actions" approach is what makes code complexity grow exponen…

So you would call:

  arr
    .map(x => x + 2)
    .filter(x => x % 3)
    .map(x => other(x))
Imperative?

Re: The unreasonable effectiveness of declarative programming

#69

Post by BiteCode_dev »

mrfredward wrote: post #63
BiteCode_dev wrote: post #59

Declarative is great, and I wish more people created clean declarative API with regular languages instead of writting yet another DSL. But remember that the problem with a declarative syntax, is that it needs a runtime, which typically the end user doesn't touch. And if the runtime doesn't take into consideration one use case, the user is stuck. Don't forget to provide an escape hatch.

The other problem with declarative code on a runtime you didn't create is traditional forms of debugging go out the window. You can't set a breakpoint, or single step, or even printf debug declarative code directly, though you can peek behind the scenes a little if you control the runtime.

Yeah, you may debug the result of your declarations if introspection is ok, but god has mercy if the error is at the runtime level.

Re: The unreasonable effectiveness of declarative programming

#70

Post by nevir »

Trufa wrote: post #68
cool-RR wrote: post #67

Looking at the first code sample, I wouldn't call it declarative at all. For me, the defining feature of declarative code, is that it doesn't have a list of actions to be performed one after another. That code sample is such a list of actions, which for me makes it imperative code, meaning "first do this, then do that, then do the other thing." The "list of actions" approach is what makes code complexity grow exponen…

So you would call: arr .map(x => x + 2) .filter(x => x % 3) .map(x => other(x)) Imperative?

Yes. That is imperative.

Declarative code describes the _output_ or final desired state of something.

Post reply on HN