Live data from Hacker News

The unreasonable effectiveness of declarative programming

bollu.github.io

71–80 of 128 posts

Re: The unreasonable effectiveness of declarative programming

#71
post #68
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?

[deleted]

Re: The unreasonable effectiveness of declarative programming

#72
post #68
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?

The border is fuzzy, so there wouldn't be a yes or no answer. Here are a couple of things that make your example more declarative than OP's code:

1. While each line is a separate step that's done in order, it's done on the results of the previous step. So it's like "get me the sum of the products of the results of foo" rather than "do x, then do y, then do z".

2. Your example has less steps.

Re: The unreasonable effectiveness of declarative programming

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

Thank you for the interesting post. Can you explain why the "A complex animation" code example is declarative? 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…

"Declarative programming" at its core seems to be about separating what the code says from what it does, and trying to put more "magic" in between the saying and the doing. But that's not a binary distinction for all kinds of reasons. What a code "says" is already a bit subjective to start with, but then we get into things like, is this "declarative"?

    def SayHello():
        print("Hello!")

    SayHello()
After all, when I type "SayHello()", I'm not specifying how I want Hello to be Said, just that I want it said. Yet, of course, if this is called "declarative" than the word is stripped of all meaning, and we do clearly want it to mean something.

Personally I'd set the line as being somewhere where by definition of the system, there is a barrier set up and you are no longer allowed to "see into" the implementation because it's going to do things so crazy to your declaration that allowing you to see into it would ruin it. e.g. in SQL when you send in your query the query engine is reserving the right to rewrite it in absolutely crazy ways, and in principle, you have no right to ask about what it actually did as long as you get the "right answer". This is because I then like to segue into how that barrier is somewhat illusory because it's always going to take some concrete actions and you may have need to see into those actions. But that isn't the only place to draw the line, it's just where I find it convenient to draw the line so I can ride a pet hobbyhorse. There isn't really a bright line, even though there is clearly some real difference we are trying to talk about.

Re: The unreasonable effectiveness of declarative programming

#74
post #68
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?

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.

Re: The unreasonable effectiveness of declarative programming

#76
post #74
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.

> it still specifies the order of operations

Yes, although not necessarily all of them. Some languages will process this eagerly, some lazily.

Re: The unreasonable effectiveness of declarative programming

#77
post #74
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.

[deleted]

Re: The unreasonable effectiveness of declarative programming

#78
post #68
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 and no. It’s a functional chain of higher-order operations over a collection.

So yes—-it is imperative, but it uses functional abstraction to reduce complexity.

Re: The unreasonable effectiveness of declarative programming

#79
post #33

Earlier quoted context omitted.

C doesn't have first-class functions, because you can't define new functions in general places (only at top level).

The definition of first-class functions is the ability to treat functions as data, which C supports. Yes, they are cumbersome to work with, since they must always be defined at top level, but that is just missing syntax sugar. GCC even allows nested function definitions.

My understanding agreed with your respondent. I haven't dug deeper but per wikipedia there's a split in the CS community as to whether function literals are necessary for functions to be first class. I think we all agree on the reality of the situation, whichever way we decide that ambiguity.

Re: The unreasonable effectiveness of declarative programming

#80
post #68
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?

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.

Post reply on HN