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

81–90 of 128 posts

Re: The unreasonable effectiveness of declarative programming

#81

Post by jakelazaroff »

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…

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

Animation at its core is a sequence of images. Imperative animation code would describe how those images change every frame. (For example, a for loop in which you multiply properties by i in order to change them over time).

Declarative animation code would let you define keyframes — how the images look at specific points in time — and the library would generate the images in between them. (This is called "tweening" [0]).

The sample code in this case isn't a list of actions to be performed one after another. It's a list of states (keyframes), which the library interpolates between. That sounds declarative to me!

[0] https://en.wikipedia.org/wiki/Inbetweening

Re: The unreasonable effectiveness of declarative programming

#82

Post by OliC »

ggambetta wrote: post #28
OliC wrote: post #19

Earlier quoted context omitted.

My friends and I love playing "Murder, She Wrote" on a big TV screen during downtime at LAN parties. We streamed it on Twitch for a while. We're big fans, great work!

OMG, seriously? You made my day Try the two Sherlock games if you can get them somewhere - these have a special place in my heart :)

Absolutely! I'll definitely do that!

Re: The unreasonable effectiveness of declarative programming

#83

Post by junke »

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…

> what state was created by the combination of the first 7 instructions, and does the eighth instruction depend on that state?

You would still have the same problem by using a notation that looks like function application.

The alternative is to repeat all unmodified values, so that looking at each animation step, you know what the output state is.

Re: The unreasonable effectiveness of declarative programming

#84

Post by hyperpallium »

nevir wrote: post #70
Trufa wrote: post #68

Earlier quoted context omitted.

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.

Is f(g(x)) imperative? There's an ordering... and it works in terms of mappings, not outputs...

Re: The unreasonable effectiveness of declarative programming

#85

Post by squiggleblaz »

klysm wrote: post #64
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

Even if the language is compiled, you still need a runtime.

GHC compiles to native code, but there's still a runtime for instance to handle the garbage collection, to sort out the lazy evaluation, and to translate the blocking IO API at the haskell end into a non-blocking IO api at the kernel end.

I surely wouldn't want to be debugging my haskell code on a time budget by directly looking at the machine code that is running. I know some people do that and it can be quite illuminating, but the fact that I can debug haskell in its own terms is good.

Re: The unreasonable effectiveness of declarative programming

#86

Post by hyperpallium »

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…

Can we say the difference between imperative and declarative is ordering or associativity?

Re: The unreasonable effectiveness of declarative programming

#87

Post by carapace »

bollu wrote: post #2

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 really like your website design, very clean and readable without sacrificing style.

The library is very nice too. The only thing I would add is, uh, rub some Category Theory on it. It seems like you could "go all the way" and define a formal mathematical semantics for animations, which would be nice. VPRI STEPS project made a quasi-mathematical language called Nile for compositing 2D vector graphics ( http://www.vpri.org/pdf/tr2009016_steps09.pdf ) that might be something to look at.

Re: The unreasonable effectiveness of declarative programming

#88

Post by hexane360 »

darksaints wrote: post #80
Trufa wrote: post #68

Earlier quoted context omitted.

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

I would. Because at the pure end imperative->declarative spectrum, you lose turing completeness. It is certainly less imperative than the equivalent C, that's for sure.

That's not true at all. The following is a declarative program:

    Yield an interpretation of a set of boolean variables that satisfies the following conditions:
      - A AND B
      - (NOT C) or A or B
      - A AND (NOT C)
      ...etc

Re: The unreasonable effectiveness of declarative programming

#90

Post by barrkel »

lbarrow wrote: post #74
Trufa wrote: post #68

Earlier quoted context omitted.

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

Compared with SQL it's definitely imperative. It's definitely using higher-level abstractions than a `for` loop, but it still specifies the order of operations.

Actually it doesn't unless you're assuming eager evaluation and that 'arr' is something like an array, rather than something which monadically collects functions for evaluation later.

In C#, the functions being passed could be passed as analyzable syntax trees, and the implementation could actually be in SQL.

Post reply on HN