Imperative vs. Declarative (2013)
latentflip.com
Imperative vs. Declarative (2013)
1–10 of 43 posts
Re: Imperative vs. Declarative (2013)
#2[deleted]
Re: Imperative vs. Declarative (2013)
#3Still 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]
Re: Imperative vs. Declarative (2013)
#4Yes, 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.
Re: Imperative vs. Declarative (2013)
#5Still 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]
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.
Re: Imperative vs. Declarative (2013)
#6Still 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]
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.
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.
Re: Imperative vs. Declarative (2013)
#7Yes, 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…
> 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% ?
Re: Imperative vs. Declarative (2013)
#8I'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.
Re: Imperative vs. Declarative (2013)
#9Still 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]
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)))Re: Imperative vs. Declarative (2013)
#10Yes, 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…
"map" and "reduce" are imperative; they order something done.
Well, in JS, sure, but what about if you could do:
a = 13
b = map(function(x){ return x; }, [1, 2, 8, a])
print b
> [1, 2, 8, 13]
a = 26
print b
> [1, 2, 8, 26]
What I'm trying to say is that the concept of map is not necessarily imperative, just JS's version.