Live data from Hacker News

Imperative vs. Declarative (2013)

latentflip.com

41–43 of 43 posts

Re: Imperative vs. Declarative (2013)

#41
post #4

Yes, way too imperative. "map" and "reduce" are imperative; they order something done. With true declarative forms, you can treat them as data and do something other than execute them. It's hard to do much with an imperative form other than execute it. A scene graph or a game level file is a declarative form; you can view it from different angles and positions. The programs that plan actions for NPCs look at a game l…

I think (perhaps unknowingly) you're just playing a semantic game. By your definition everything is imperative, even if it is also totally declarative. All programs are imperative in your sense. Even if you could tell the computer "Do what I want" and expect it to be psychic, that would still be imperative by your definition.

But the difference between imperative programming and declarative programming is not drawn by "ordering something done" (even if the article didn't define things precisely enough to prevent confusion on this point). It's basically a level-of-abstraction/level-of-detail thing. Saying "double each number in this list" is significantly different than saying "follow this step-by-step algorithm to double each number in the list".

The boundaries can get fuzzy; arguments can be made about where to draw the lines. But your approach lumps everything on one side of the line, and therefore becomes incapable of saying anything very useful.

Re: Imperative vs. Declarative (2013)

#42
post #20
post #12

Earlier quoted context omitted.

Can't say it's surprising. The von-Neumann architecture computers and their assembly languages are imperative. Functional programming language structs are just unnatural. Being computationally universal, one can simulate one using the other. But to me, it feels like an unwanted abstraction layer. Analogy #1: if I were going to write a game for PC, I would directly write a game for PC, not a GBA ROM + GBA emulator for…

The von-Neumann level nature of the machine really doesn't enter into it, though. I mean, ultimately, yes, somehow your solution has to be run in an imperative way. At the high level "looking at the declarative solution," though, it is irrelevant. So, to your analogy #1. If such an emulator already existed and was in wide use, you would not be doing any harm to your system to target it. To extend your analogy to the…

> The von-Neumann level nature of the machine really doesn't enter into it, though.

It does enter when you try to execute the code; which is a translation from declarative to imperative (assembly).

> To extend your analogy to the absurd, it doesn't make sense to write your program out symbolically in a programming language, because at the end of the day it is electrical values in a processor.

Care to tell me one single example of a declarative computer?

I'm more of a hardware engineer than a programmer, and I can't think of any universal logical circuit with memory that is not imperative. Even at the transistor layer, everything is imperative. This includes gate-model quantum computers and biological computers. There are some analog models that work for specific problems, but there certainly are nowhere near being declarative.

And the point was, at the high level, declarative -> imperative translation (which is done by a compiler) will typically be worse that an imperative -> imperative translation.

This is why a very written compute kernels in C outperforms its, say, Haskell equivalent, typically by orders. It's also the reason why scientific computation, signal processing, transcoding software etc. (when raw CPU performance outweighs everything) is typically written in Fortran/C/C++ with a mixture of assembly.

The reason is simple; they map to the underlying hardware well. It is also the reason why assembly languages are imperative.

Re: Imperative vs. Declarative (2013)

#43
post #42
post #20

Earlier quoted context omitted.

The von-Neumann level nature of the machine really doesn't enter into it, though. I mean, ultimately, yes, somehow your solution has to be run in an imperative way. At the high level "looking at the declarative solution," though, it is irrelevant. So, to your analogy #1. If such an emulator already existed and was in wide use, you would not be doing any harm to your system to target it. To extend your analogy to the…

> The von-Neumann level nature of the machine really doesn't enter into it, though. It does enter when you try to execute the code; which is a translation from declarative to imperative (assembly). > To extend your analogy to the absurd, it doesn't make sense to write your program out symbolically in a programming language, because at the end of the day it is electrical values in a processor. Care to tell me one sing…

Apologies, I'm not sure what it is you are trying to say. :(

The fact that the underlying system is von-Neumann seems just completely non sequitor. That is my only point. Every point you make afterwards is just as true of the "Harvard architecture" as it is of the von-Neumann one.

In the rest of what you are saying, it honestly sounds like we agree.

Post reply on HN