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

101–110 of 128 posts

Re: The unreasonable effectiveness of declarative programming

#101

Post by kerkeslager »

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.

My impression of declarative programming is that it looks good in the "Hello, world" and other basic examples because you don't have to dip into the escape hatches. But when presented with real-world problems, you end up spending more time trying to get their framework to do what you want through the escape hatches than if you had just written your own program using a normal programming language and a well-designed library.

Re: The unreasonable effectiveness of declarative programming

#102

Post by BiteCode_dev »

kerkeslager wrote: post #101
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.

My impression of declarative programming is that it looks good in the "Hello, world" and other basic examples because you don't have to dip into the escape hatches. But when presented with real-world problems, you end up spending more time trying to get their framework to do what you want through the escape hatches than if you had just written your own program using a normal programming language and a well-designed l…

You can use a normal language to well design a declarative library. That's the point.

Re: The unreasonable effectiveness of declarative programming

#103

Post by vanderZwan »

gherkinnn wrote: post #6

Interesting 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?

The website uses SVGs for animation instead of the canvas2d API, I'm fairly certain that's the cause.

(honestly I love SVGs for static images or at most one or two animations when used on a web-page, but if you're not using canvas2d or even webgl with a thin shim for anything more complex than that, mobile users will suffer)

Re: The unreasonable effectiveness of declarative programming

#104

Post by 6510 »

tonetheman wrote: post #97
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…

I am literally too dumb to know what you typed... and then all of the following comments. It is like you are speaking in Martian or something. Haskell is effectively impenetrable to me.

I dunno, I prefer to call it too practical. Lets just do terrestrial programming.

Something like this?

  @keyframes ball{
    0%{  left:50px; top:100px;width:0px;  height:0px  }
    10%{ left:50px; top:90px; width:20px; height:20px }
    20%{ left:50px; top:90px; width:20px; height:20px }
    30%{ left:300px;top:50px; width:100px;height:100px}
    50%{ left:300px;top:50px; width:100px;height:100px}
    60%{ left:200px;top:50px; width:100px;height:100px}
    90%{ left:250px;top:100px;width:0px;  height:0px  }
    100%{left:50px; top:100px;width:0px;  height:0px  }
  }
https://jsfiddle.net/gaby_de_wilde/eoj875qr/

Re: The unreasonable effectiveness of declarative programming

#105

Post by mD5pPxMcS6fVWKE »

chmod775 wrote: post #61
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'…

You confuse declarative and functional. Declarative is when the sequence of execution is not related to the order of operators in the program text, but is derived at run time. The animation, where sequence of events is known exactly, is the poorest example for declarative programming.

Re: The unreasonable effectiveness of declarative programming

#106

Post by sriram_malhar »

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…

Sequencing is a fundamental computing construct, not the exclusive preserve of imperative programming. The 'do' notation in Haskell, function composition operators, shell pipes, data flow graphs are all expressions of explicit sequencing.

Imperative programming is about each statement altering a program's state, not the act of sequencing.

Re: The unreasonable effectiveness of declarative programming

#107

Post by Jtsummers »

6gvONxR4sf7o wrote: post #95
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…

Imperative and declarative seem to me to be a matter of degree and sometimes even syntax. Point(x=1,y=2,z=3) is pretty declarative, but "point, with x set to 1, with y set to 2, with z set to 3" is getting more imperative even though it's really the exact same thing. But the syntax makes our mental model a little different, so yay. From there, it's not to hard to go to "scope, with x set to scope(a), with y set to x+…

It's not really about syntax. It's about the execution model. Your second example might almost feel normal to someone with a preference for SQL, which is a declarative language.

Declarative languages don't specify (or minimize the specification of) the execution, imperative languages specify the execution. You can look at the verbs used in describing or verbalizing the language. In declarative languages you don't talk about "assigning" as much as you talk about relationships: "x is y", "x is related to y by f(x,y)", "if x is predicate(x) then y is z else y is z'". In imperative languages you do things: "x is assigned y", "for x in y do ...", "if x is predicate(x) then do y is assigned z else do y is assigned z'".

Additionally, statements/expressions in declarative languages can be reordered more freely (the "purer" the declarative language the more true this is), given that it tends towards the relational version. In a constraint based system, for example, you could do these in either order:

   x in 1..10
   x % 3 == 2
   ;; => x \in {2, 5, 8}
x collects these constraints and so the order is irrelevant (though practically many declarative languages aren't this pure so the order may matter for various reasons).

Re: The unreasonable effectiveness of declarative programming

#108

Post by FearNotDaniel »

> As an example, a staggered animation is a nice way to make the entry of multiple objects feel less monotonous.

Hopefully readers considering this sort of thing for UI transitions will bear in mind: this is nice if the goal of your application is entertainment, deeply irritating if the goal of your application is productivity.

Re: The unreasonable effectiveness of declarative programming

#109

Post by kerkeslager »

BiteCode_dev wrote: post #102
kerkeslager wrote: post #101

Earlier quoted context omitted.

My impression of declarative programming is that it looks good in the "Hello, world" and other basic examples because you don't have to dip into the escape hatches. But when presented with real-world problems, you end up spending more time trying to get their framework to do what you want through the escape hatches than if you had just written your own program using a normal programming language and a well-designed l…

You can use a normal language to well design a declarative library. That's the point.

You're just throwing terms around here.

Something like Django or Rails, is no longer just a "declarative library" it's a framework. You're using their patterns, and you're limited to their escape hatches.

Re: The unreasonable effectiveness of declarative programming

#110

Post by sriram_malhar »

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.

nope. Sequencing and imperative have an overlap, but they are not the same thing.

Sequencing is a fundamental computing construct. Data flow graphs allow you to specify sequences, just as shell pipelines do. SQL has sequentiality built-in with nested queries. None of these are imperative environments.

Post reply on HN