6 ms·

Imperative vs. Declarative (2013)

72 points by actraub 12y ago

deleted 12y ago
[deleted]
_random_ 12y ago
Still waaay too imperative, how about this: func [1,2,3,4,5] => [2,4,6,8,10] //Calculation inferred by compiler. console.log (func [6,7,8,9,10]) //=> [12,14,16,18,20]
- i_am_ralpht 12y ago
  What algorithms are there for inferring the calculation? I'm playing around with a tool for building touch gestures visually, and I have some problems that look a bit like that (want to infer a function from some examples) but I don't yet know how.
  - gajomi 12y ago
    This calculation is underdetermined, and there isn't any algorithm that would specify "it", since there are many functions that would satisfy the requirements. In general this is a hard problem of induction. In a more limited context you might think about adding regularizations that will make the function better determined. Choosing these and implementing them may not be trivial. If you are talking paths generated from touch gestures there is some research on that topic.
    - art-w 12y ago
      People working on program synthesis consider the Occam razor "the shortest/simplest code" to be a good heuristic of the intended function (given a good test case.) Their main problem is the exponential space search.
  - hcarvalhoalves 12y ago
    Sounds like a regression problem? The actual algorithm will depend on how well you need to approximate the function, the nature and amount of example data. http://en.wikipedia.org/wiki/Machine_learning#Approaches http://en.wikipedia.org/wiki/Machine_learning#Approaches
- evincarofautumn 12y ago
  One practical way to implement this would be a “...” operator which would look at the syntax of the surrounding expression and attempt to infer an inductive definition from that, based on some assumptions about e.g. the structure of lists or the values of integers. double xs => [xs[0] * 2, ..., xs[xs.length - 1] * 2] map f xs => [f(xs[0]), ..., f(xs[xs.length - 1])] sum xs => xs[0] + ... + xs[xs.length - 1] foldl f z xs => f(f(..., f(z, xs[0])), xs[xs.length - 1]) foldr f z xs => f(xs[0], f(..., f(xs[xs.length - 1], z)))
- segmondy 12y ago
  Not practical, there are infinitely many functions that could produce such result here is such psuedo code foo(x) { if (x <= 5) { x * 2 } else { x } } foo1(x) { if (x <= 6) { x * 2 } else { x+1 } } foo1(x) { if (x <= 7) { x * 2 } else { x+2 } }
Animats 12y ago
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 level and decide what to do. CAD files are declarative. Spreadsheets are mostly declarative. The usual problem with declarative forms is lack of expressive power. If you need to express something the declarative form can't handle, it's tempting to bolt on some kind of imperative gimmick. This is how we ended up with Javascript.
- aikah 12y ago
  > Yes, way too imperative. "map" and "reduce" are imperative; they order something done. Well how would you write these snippets the right way then?with the language of your choice, so it fits the declaritive way a 100% ?
  - Animats 12y ago
    I'm not saying those things should be written in a declarative form, just that what the author is calling "declarative" isn't. If you wanted to do something like that in a declarative way, though, consider a spreadsheet with an intelligent evaluator. The spreadsheet is a declaration of a dependency relationship. When a number is changed, the numbers depending upon it change. It's not always just a recalculation, either. There are spreadsheets that let you work backwards (change a total, watch the inputs change), and cloud-based spreadsheets that sync (one of YCombinator's companies, Fivetran, has one). Spreadsheets also suffer from imperative creep. People try to use Excel spreadsheets for iterative work, which gets away from the declarative design.
    - kyllo 12y ago
      Spreadsheets also suffer from imperative creep. People try to use Excel spreadsheets for iterative work, which gets away from the declarative design. ...which is how we ended up with VBA macros.
sytelus 12y ago
I'd been enough in to these battles so my 2 cents. I'm not saying that declarative mode is bad, in fact I love it, but the problem is that people tend to over do it in undesirable way. I've seen "architects" designing declarative language on top XML and asking programmers to code in it. There are also examples in likes of WPF which is perhaps the ugliest fattiest hairiest thing out there that lot of people have to fight with to get their job done. 1. Declarative languages or constructs are much harder to debug when things are not working as expected. There are no breakpoints to put or no debug statements to write or no watch to put. It was supposed to do that and you just can't tell why it's doing this. 2. Performance issues are much harder to resolve with declarative constructs. When you get in hotspot, there is no way to run. You would be fortunate if your language/platform allows you to fall back to imperative mode but there are platforms/languages out there which insist in 100% declarative styles. 3. There is lot of bad declarative syntax that is not designed to be composable. Lot of time, it's just is not extensible or allows to take advantage of modern programming language constructs such as inheritance, functional patterns, etc.
- tagrun 12y ago
  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 PC and make-believe that it's a PC game. Analogy #2: if I want to write a novel in Spanish, it will not be possible to achieve the quality of a text written in Spanish from the beginning, by say, writing it in Japanese and using a translator (no matter how much you may like Japanese). Some idioms and culture-dependent things will be lost in translation. (Italian or Portuguese might be better, however)
  - taeric 12y ago
    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 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.
segmondy 12y ago
Awwww, all that an no mention of Prolog or Mecury? Prolog is a declarative language that is being used in the real world and being used often to solve interesting problems too. There is always a joke about how folks tend to reinvent lisp while trying to extend their language. Same can be said for any program that has rules, there is always a half ass prolog engine poorly implemented.
taeric 12y ago
Hasn't it been fairly well established that imperative and declarative are not necessarily duals? That is, !imperative is not the same as declarative. And vice versa. That is, the base generalization here is invalid. Further, there are plenty of things where imperative just makes sense. It is why we have plenty of imperatives in every day usage. I mean, sure, you could tell your kids "I want a clean room." Likely, they will look at you and wonder, if that is what you want, why don't you clean it. :) So, sure, if there is a nice clean concise declarative way to specify something, do so. However, I think it is a fool's errand to think that can be the universal case. Even in an ideal sense. It is why you don't hear people trying to drop imperatives from daily life. (Or... do you?)
sanketbajoria 12y ago
Good Explanation
- renox 12y ago
  I disagree, it could be improved: imperative|declarative is not a binary state but a continuous line. For example, you could use foreach instead of for in the imperative solution and the loop would become closer to the declarative one.

72 points by actraub 12y ago

deleted 12y ago

[deleted]

Still waaay too imperative, how about this: func [1,2,3,4,5] => [2,4,6,8,10] //Calculation inferred by compiler. console.log (func [6,7,8,9,10]) //=> [12,14,16,18,20]

i_am_ralpht 12y ago
What algorithms are there for inferring the calculation? I'm playing around with a tool for building touch gestures visually, and I have some problems that look a bit like that (want to infer a function from some examples) but I don't yet know how.
- gajomi 12y ago
  This calculation is underdetermined, and there isn't any algorithm that would specify "it", since there are many functions that would satisfy the requirements. In general this is a hard problem of induction. In a more limited context you might think about adding regularizations that will make the function better determined. Choosing these and implementing them may not be trivial. If you are talking paths generated from touch gestures there is some research on that topic.
  - art-w 12y ago
    People working on program synthesis consider the Occam razor "the shortest/simplest code" to be a good heuristic of the intended function (given a good test case.) Their main problem is the exponential space search.
- hcarvalhoalves 12y ago
  Sounds like a regression problem? The actual algorithm will depend on how well you need to approximate the function, the nature and amount of example data. http://en.wikipedia.org/wiki/Machine_learning#Approaches http://en.wikipedia.org/wiki/Machine_learning#Approaches
evincarofautumn 12y ago
One practical way to implement this would be a “...” operator which would look at the syntax of the surrounding expression and attempt to infer an inductive definition from that, based on some assumptions about e.g. the structure of lists or the values of integers. double xs => [xs[0] * 2, ..., xs[xs.length - 1] * 2] map f xs => [f(xs[0]), ..., f(xs[xs.length - 1])] sum xs => xs[0] + ... + xs[xs.length - 1] foldl f z xs => f(f(..., f(z, xs[0])), xs[xs.length - 1]) foldr f z xs => f(xs[0], f(..., f(xs[xs.length - 1], z)))
segmondy 12y ago
Not practical, there are infinitely many functions that could produce such result here is such psuedo code foo(x) { if (x <= 5) { x * 2 } else { x } } foo1(x) { if (x <= 6) { x * 2 } else { x+1 } } foo1(x) { if (x <= 7) { x * 2 } else { x+2 } }

Animats 12y ago

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 level and decide what to do. CAD files are declarative. Spreadsheets are mostly declarative. The usual problem with declarative forms is lack of expressive power. If you need to express something the declarative form can't handle, it's tempting to bolt on some kind of imperative gimmick. This is how we ended up with Javascript.

aikah 12y ago
> Yes, way too imperative. "map" and "reduce" are imperative; they order something done. Well how would you write these snippets the right way then?with the language of your choice, so it fits the declaritive way a 100% ?
- Animats 12y ago
  I'm not saying those things should be written in a declarative form, just that what the author is calling "declarative" isn't. If you wanted to do something like that in a declarative way, though, consider a spreadsheet with an intelligent evaluator. The spreadsheet is a declaration of a dependency relationship. When a number is changed, the numbers depending upon it change. It's not always just a recalculation, either. There are spreadsheets that let you work backwards (change a total, watch the inputs change), and cloud-based spreadsheets that sync (one of YCombinator's companies, Fivetran, has one). Spreadsheets also suffer from imperative creep. People try to use Excel spreadsheets for iterative work, which gets away from the declarative design.
  - kyllo 12y ago
    Spreadsheets also suffer from imperative creep. People try to use Excel spreadsheets for iterative work, which gets away from the declarative design. ...which is how we ended up with VBA macros.

sytelus 12y ago

I'd been enough in to these battles so my 2 cents. I'm not saying that declarative mode is bad, in fact I love it, but the problem is that people tend to over do it in undesirable way. I've seen "architects" designing declarative language on top XML and asking programmers to code in it. There are also examples in likes of WPF which is perhaps the ugliest fattiest hairiest thing out there that lot of people have to fight with to get their job done. 1. Declarative languages or constructs are much harder to debug when things are not working as expected. There are no breakpoints to put or no debug statements to write or no watch to put. It was supposed to do that and you just can't tell why it's doing this. 2. Performance issues are much harder to resolve with declarative constructs. When you get in hotspot, there is no way to run. You would be fortunate if your language/platform allows you to fall back to imperative mode but there are platforms/languages out there which insist in 100% declarative styles. 3. There is lot of bad declarative syntax that is not designed to be composable. Lot of time, it's just is not extensible or allows to take advantage of modern programming language constructs such as inheritance, functional patterns, etc.

tagrun 12y ago
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 PC and make-believe that it's a PC game. Analogy #2: if I want to write a novel in Spanish, it will not be possible to achieve the quality of a text written in Spanish from the beginning, by say, writing it in Japanese and using a translator (no matter how much you may like Japanese). Some idioms and culture-dependent things will be lost in translation. (Italian or Portuguese might be better, however)
- taeric 12y ago
  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 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.

segmondy 12y ago

Awwww, all that an no mention of Prolog or Mecury? Prolog is a declarative language that is being used in the real world and being used often to solve interesting problems too. There is always a joke about how folks tend to reinvent lisp while trying to extend their language. Same can be said for any program that has rules, there is always a half ass prolog engine poorly implemented.

taeric 12y ago

Hasn't it been fairly well established that imperative and declarative are not necessarily duals? That is, !imperative is not the same as declarative. And vice versa. That is, the base generalization here is invalid. Further, there are plenty of things where imperative just makes sense. It is why we have plenty of imperatives in every day usage. I mean, sure, you could tell your kids "I want a clean room." Likely, they will look at you and wonder, if that is what you want, why don't you clean it. :) So, sure, if there is a nice clean concise declarative way to specify something, do so. However, I think it is a fool's errand to think that can be the universal case. Even in an ideal sense. It is why you don't hear people trying to drop imperatives from daily life. (Or... do you?)

sanketbajoria 12y ago

Good Explanation

renox 12y ago
I disagree, it could be improved: imperative|declarative is not a binary state but a continuous line. For example, you could use foreach instead of for in the imperative solution and the loop would become closer to the declarative one.