
Imperative vs. Declarative (2013) - actraub
http://latentflip.com/imperative-vs-declarative/
======
sytelus
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.

~~~
spiritplumber
Declarative language on top of XML... Are you talking about this one?
[http://thedailywtf.com/articles/We-Use-
BobX](http://thedailywtf.com/articles/We-Use-BobX)

~~~
kyllo
Oh god, this one hits _way_ too close to home for me.

------
Animats
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.

~~~
craigching
> "map" and "reduce" are imperative; they order something done.

So maybe it's my age showing, but I was taught that imperative was using
explicit variables to control the "looping" (e.g. for with an index a la C
style programming) whereas using "higher order functions" was not imperative.
And I tend to agree with that. So I disagree that map and reduce are
imperative because they don't _explicitly_ control how the looping is done.

Can anyone cite where map and reduce are imperative? Must be some new-fangled
text book that I'm not aware of ;)

And I get that someone could impose on me to cite references that map and
reduce are _not_ imperative. Point taken and I'm thinking that I got this from
SICP in the first place so I'm looking it up now. Will report back if I find
anything.

EDIT: First quote from SICP:

"In contrast to functional programming, programming that makes extensive use
of assignment is known as imperative programming. In addition to raising
complications about computational models, programs written in imperative style
are susceptible to bugs that cannot occur in functionalprograms."

~~~
icebraining
If I may try to answer for Animats, I think the point is that you're still
using the map in an imperative way. You set a variable to some list, then you
apply a map to that list and assign that to another variable. If you then
change the first variable, the latter doesn't change - that means the order of
execution matters for the application of the map.

That said, that's mostly a specificity of Javascript than a property of the
map operation. There's no reason you can't have a map on an FRP that truly
declares a relationship between entities.

------
taeric
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?)

------
_random_
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
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
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
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.

------
segmondy
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.

------
sanketbajoria
Good Explanation

~~~
renox
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.

