4 ms·

To name a few: 1. Macros. And you don't get to weasel, because any non-trivial spreadsheet application contains at least a few. 2. relative references, which

by lliwta 12y ago

To name a few: 1. Macros. And you don't get to weasel, because any non-trivial spreadsheet application contains at least a few. 2. relative references, which are basically heap pointers. 3. simulating for loops/iteration is a fairly common thing in spread-sheet programming. But also see my edit to the original comment. As an aside, it's absolutely astounding to me that my original reply is down-voted. edit: most obvious -> a few edit2: Could someone please explain what's so offensive about these posts? Is there that much love for spreadsheet programming (last I checked everyone understood the downsides of at-scale spreadsheets and how these problems arise from subtle non-declarative features)? Am I being unintentionally abrasive? Should I post example files and links to empirical studies demonstrating how people commonly program spreadsheets in non-declarative ways?

roel_v 12y ago
I think the problem is (at least that's my problem with your posts, although I didn't downvote you) that you're, and from the look of it for your disdain for spreadsheets, arguing spreadsheet != declarative programming because <i>tenuous definition of declarative programming</>, and the whole argument just smells like cognitive dissonance - declarative programming good, Excel bad, hence Excel not declarative programming. Not trying to be an asshole, but since you were asking, I'm just saying what I suspect to be a possible reason...
- lliwta 12y ago
  > tenuous definition of declarative programming > declarative programming good, Excel bad, hence Excel not declarative programming. I didn't choose the definition of declarative programming. I'm taking the article's definition as given.
tlarkworthy 12y ago
Spreadsheets are a great example of a declarative ethos. You're nitpicking on details which equally applies to prolog too. The underlying theme of spreadsheets is definitely declarative. Spreadsheets are older than excel.
- lliwta 12y ago
  > Spreadsheets are a great example of a declarative ethos. I kind-of agree. The primitives do have many nice properties. > You're nitpicking on details which equally applies to prolog too. I strongly disagree. When escape hatches exist, I think you have to look at how a language/system is commonly used in order to assess whether it has some of these properties or not. Otherwise everything in which a pure function is definable becomes declarative and the phrase becomes rather useless. Prolog and spreadsheets differ in a rather fundamental, albeit empirical, way: spreadsheet users tend to make pervasive use of the these imperative features. So there are two alternatives -- spreadsheet programmers are all completely inexperienced and have no idea what's good for them, or there are fundamental limits to the declarative features of the spreadsheet model, beyond which they become imperative. I think the answer is a bit of both. Spreadsheet users tend to not be trained software engineers, but they aren't idiots and basic programming is not rocket science. None-the-less, lots of spreadsheets end up with pervasive use of imperative features (which causes real problems in terms of maintainability) So assuming a huge population of users are at least kind-of competent/intelligent, there appear to be fundamental limitations to the basic model, beyond which it can't be used to solve common problems effectively in a declarative way. Which of course should be interpreted by those who really like spreadsheet programming as a call to arms (education and/or refinements to the model) rather than a categorical criticism...
- dragonwriter 12y ago
  The "underlying theme" of spreadsheets may be declarative, but declarative has very little relation to how real non-trivial spreadsheet-based apps are constructed. Spreadsheets are a tool in which one motivated in that direction can do fairly pure, fairly complex, dataflow oriented programming -- but that's not generally what they are used for.
klibertp 12y ago
There is nothing wrong with your posts. It's just that recently the understanding of what downvotes mean changed drastically in the community. I've no idea why and when it happened, but downvotes now seem to mean "I disagree, but am too lazy to write a comment", instead of "your comment is not fit for this site and/or it damages the quality of current discussion" as it was understood before.
ww520 12y ago
Macro is not part of the spreadsheet computation model. It's like saying a FFI library written in C for Haskell somehow makes Haskell a stateful language. Relative reference declares a dependence relationship. That's part of what declarative programming is.
- lliwta 12y ago
  Macros are used pervasively. To use your analogy, it's like writing a lambda calculus interpreter with an FFI, doing everything via the FFI, and calling it declarative. But macros are only part of the problem. > That's part of what declarative programming is. Sorry, I was constraining myself to the definition from the article.
6cxs2hd6 12y ago
I think your point is broader. It applies to spreadsheets, Prolog, SQL. A declarative system needs to be "contaminated" by non-declarative pragmas for real-world use. (I think OP made this point.) To do something faster, or to do it at all. SQL is a good example. You can get the desired output from a variety of queries... some of which might complete an order of magnitude slower than others. At some point you will need to peel back the "what" abstraction and consider the "how" -- what execution plan will the engine make for a given query. Regardless, it's still a win. Even if it is no longer purely declarative, you still have leverage. i.e. You're expressing the solution concisely and with satisfactory performance, both.

by lliwta 12y ago

roel_v 12y ago

I think the problem is (at least that's my problem with your posts, although I didn't downvote you) that you're, and from the look of it for your disdain for spreadsheets, arguing spreadsheet != declarative programming because <i>tenuous definition of declarative programming</>, and the whole argument just smells like cognitive dissonance - declarative programming good, Excel bad, hence Excel not declarative programming. Not trying to be an asshole, but since you were asking, I'm just saying what I suspect to be a possible reason...

lliwta 12y ago
> tenuous definition of declarative programming > declarative programming good, Excel bad, hence Excel not declarative programming. I didn't choose the definition of declarative programming. I'm taking the article's definition as given.

tlarkworthy 12y ago

Spreadsheets are a great example of a declarative ethos. You're nitpicking on details which equally applies to prolog too. The underlying theme of spreadsheets is definitely declarative. Spreadsheets are older than excel.

lliwta 12y ago
> Spreadsheets are a great example of a declarative ethos. I kind-of agree. The primitives do have many nice properties. > You're nitpicking on details which equally applies to prolog too. I strongly disagree. When escape hatches exist, I think you have to look at how a language/system is commonly used in order to assess whether it has some of these properties or not. Otherwise everything in which a pure function is definable becomes declarative and the phrase becomes rather useless. Prolog and spreadsheets differ in a rather fundamental, albeit empirical, way: spreadsheet users tend to make pervasive use of the these imperative features. So there are two alternatives -- spreadsheet programmers are all completely inexperienced and have no idea what's good for them, or there are fundamental limits to the declarative features of the spreadsheet model, beyond which they become imperative. I think the answer is a bit of both. Spreadsheet users tend to not be trained software engineers, but they aren't idiots and basic programming is not rocket science. None-the-less, lots of spreadsheets end up with pervasive use of imperative features (which causes real problems in terms of maintainability) So assuming a huge population of users are at least kind-of competent/intelligent, there appear to be fundamental limitations to the basic model, beyond which it can't be used to solve common problems effectively in a declarative way. Which of course should be interpreted by those who really like spreadsheet programming as a call to arms (education and/or refinements to the model) rather than a categorical criticism...
dragonwriter 12y ago
The "underlying theme" of spreadsheets may be declarative, but declarative has very little relation to how real non-trivial spreadsheet-based apps are constructed. Spreadsheets are a tool in which one motivated in that direction can do fairly pure, fairly complex, dataflow oriented programming -- but that's not generally what they are used for.

klibertp 12y ago

There is nothing wrong with your posts. It's just that recently the understanding of what downvotes mean changed drastically in the community. I've no idea why and when it happened, but downvotes now seem to mean "I disagree, but am too lazy to write a comment", instead of "your comment is not fit for this site and/or it damages the quality of current discussion" as it was understood before.

ww520 12y ago

Macro is not part of the spreadsheet computation model. It's like saying a FFI library written in C for Haskell somehow makes Haskell a stateful language. Relative reference declares a dependence relationship. That's part of what declarative programming is.

lliwta 12y ago
Macros are used pervasively. To use your analogy, it's like writing a lambda calculus interpreter with an FFI, doing everything via the FFI, and calling it declarative. But macros are only part of the problem. > That's part of what declarative programming is. Sorry, I was constraining myself to the definition from the article.

6cxs2hd6 12y ago

I think your point is broader. It applies to spreadsheets, Prolog, SQL. A declarative system needs to be "contaminated" by non-declarative pragmas for real-world use. (I think OP made this point.) To do something faster, or to do it at all. SQL is a good example. You can get the desired output from a variety of queries... some of which might complete an order of magnitude slower than others. At some point you will need to peel back the "what" abstraction and consider the "how" -- what execution plan will the engine make for a given query. Regardless, it's still a win. Even if it is no longer purely declarative, you still have leverage. i.e. You're expressing the solution concisely and with satisfactory performance, both.