Live data from Hacker News

Imperative vs. Declarative (2013)

latentflip.com

21–30 of 43 posts

Re: Imperative vs. Declarative (2013)

#21
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?)

Re: Imperative vs. Declarative (2013)

#22
post #19

Earlier quoted context omitted.

All good points. However... 1. Declarative expressions are much easier to spot for defects (and much easier to not introduce defects). So do you want easier interaction w/ your debugger or do you want less bugs? 2. "There is no way to run" is an overstatement, I think. You have to run toward understanding the abstractions you're using. (E.g., if I have GC issues in the JVM, it's not that I have no where to run, it's…

I can really only cede point one if you qualify it with a "per line of code" or some such. I have seen plenty of "declarative" solutions that are no easier to spot errors in then the much more compact imperative version. This is the difference between closed form versus summation problems. Sure, short closed form problems are much easier to understand than infinite sums. However, sometimes the closed form is borderli…

There are concise declarative solutions in languages such as Ocaml and Haskell.

Re: Imperative vs. Declarative (2013)

#23
post #19

Earlier quoted context omitted.

I can really only cede point one if you qualify it with a "per line of code" or some such. I have seen plenty of "declarative" solutions that are no easier to spot errors in then the much more compact imperative version. This is the difference between closed form versus summation problems. Sure, short closed form problems are much easier to understand than infinite sums. However, sometimes the closed form is borderli…

There are concise declarative solutions in languages such as Ocaml and Haskell.

Depends entirely on what solutions we are talking about.

Show me a nice concise solution to the N-Queens problem in those languages.

Now add performance as a requirement. :)

Re: Imperative vs. Declarative (2013)

#24
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…

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

Re: Imperative vs. Declarative (2013)

#25
post #8

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 fi…

Exercise: are the type systems of functional languages in the vein of Haskell declarative in the sense that is associated with the disadvantages you mention?

Re: Imperative vs. Declarative (2013)

#26
post #23

Earlier quoted context omitted.

There are concise declarative solutions in languages such as Ocaml and Haskell.

Depends entirely on what solutions we are talking about. Show me a nice concise solution to the N-Queens problem in those languages. Now add performance as a requirement. :)

Here you go!

C (http://rosettacode.org/wiki/N-queens_problem#C)

Program 1 (compiled with gcc -O3 c1.c -o bin/c1)[0]

    real	0m0.003s
    user	0m0.000s
    sys	        0m0.002s
Program 2: (compiled with gcc -O3 c2.c -o bin/c2)[1]

Same as above, second code listing (faster while still readable,excluded unreadable fastest c version)

    real	0m0.001s
    user	0m0.000s
    sys	        0m0.001s
Haskell (http://rosettacode.org/wiki/N-queens_problem#Haskell)

Program 1 (modified to do 8 queens like the c versions, compiled with: ghc -O2 -threaded haskell2.hs -o bin/haskell2)[2]

    real	0m0.010s
    user	0m0.005s
    sys	        0m0.005s
Program 2 (modified to do 8 queens like the c version, compiled with: ghc -O2 -threaded haskell2.hs -o bin/haskell2)[3] (word of warning, this program is only 52% efficient according to ghc and has a lot of optimization that could be done)

    real	0m0.006s
    user	0m0.006s
    sys	        0m0.000s

Note that the fastest Haskell solution was also the shortest by quite a bit. Are you convinced yet?

EDIT: Found an ATS solution, but I'm not setup to compile it: http://www.ats-lang.org/SERVER/MYCODE/Patsoptaas_serve.php?m...

0: C, solution 1

    #include 
    #include 
 
    int count = 0;
    void solve(int n, int col, int *hist)
    {
    	if (col == n) {
    		printf("\nNo. %d\n-----\n", ++count);
    		for (int i = 0; i 
1: c solution 2

    #include 
    #include 
    #include 
     
    typedef uint32_t uint;
    uint full, *qs, count = 0, nn;
     
    void solve(uint d, uint c, uint l, uint r)
    {
    	uint b, a, *s;
    	if (!d) {
    		count++;
    #if 0
    		printf("\nNo. %d\n===========\n", count);
    		for (a = 0; a >= 1)) & full;
    	if (a != full)
    		for (*(s = qs + --d) = 0, b = 1; b 
2: Haskell solution 1 (comments stripped out for comparison)

    import           Control.Monad
    import           Data.List
    
    queens :: Int -> [[Int]]
    queens n = map fst $ foldM oneMoreQueen ([],[1..n]) [1..n]  where
      oneMoreQueen (y,d) _ = [(x:y, delete x d) | x  putStrLn [if z == x then 'Q' else '.' | z 
3: Haskell solution 2

    import           Control.Monad (foldM)
    import           Data.List     ((\\))
    
    main :: IO ()
    main = mapM_ print $ queens 8
    
    queens :: Int -> [[Int]]
    queens n = foldM f [] [1..n]
        where
          f qs _ = [q:qs | q 

Re: Imperative vs. Declarative (2013)

#28
post #23

Earlier quoted context omitted.

Depends entirely on what solutions we are talking about. Show me a nice concise solution to the N-Queens problem in those languages. Now add performance as a requirement. :)

Here you go! C ( http://rosettacode.org/wiki/N-queens_problem#C ) Program 1 (compiled with gcc -O3 c1.c -o bin/c1)[0] real 0m0.003s user 0m0.000s sys 0m0.002s Program 2: (compiled with gcc -O3 c2.c -o bin/c2)[1] Same as above, second code listing (faster while still readable,excluded unreadable fastest c version) real 0m0.001s user 0m0.000s sys 0m0.001s Haskell ( http://rosettacode.org/wiki/N-queens_problem#Haskell )…

What is the speed of this on N of 16 to 20? At 8, any implementation should suffice nowdays.

Edit: Also, apologies for the possibly ninja edit. This is ultimately somewhat silly. I am not going to lie and say that the these are easily readable. I fully cede that this could just be a training thing. I picked this particular example because I had fun with it using the DLX algorithm. Which is admittedly far above my understanding in many ways. :) Just the naive recursive solution was much easier to read, but much much slower to execute. To the point that it was laughable. (If interested, I can post my code.)

Re: Imperative vs. Declarative (2013)

#29
post #28

Earlier quoted context omitted.

Here you go! C ( http://rosettacode.org/wiki/N-queens_problem#C ) Program 1 (compiled with gcc -O3 c1.c -o bin/c1)[0] real 0m0.003s user 0m0.000s sys 0m0.002s Program 2: (compiled with gcc -O3 c2.c -o bin/c2)[1] Same as above, second code listing (faster while still readable,excluded unreadable fastest c version) real 0m0.001s user 0m0.000s sys 0m0.001s Haskell ( http://rosettacode.org/wiki/N-queens_problem#Haskell )…

What is the speed of this on N of 16 to 20? At 8, any implementation should suffice nowdays. Edit: Also, apologies for the possibly ninja edit. This is ultimately somewhat silly. I am not going to lie and say that the these are easily readable. I fully cede that this could just be a training thing. I picked this particular example because I had fun with it using the DLX algorithm. Which is admittedly far above my und…

This example is bizarre, because a fast implementation is probably going to rely on a SAT solver, at which point the "queens code" (in any language) becomes a declarative specification of the solution!

Also, I don't think that Haskell, OCaml, (or Prolog) are that much declarative: They have a very clear evaluation model, which you need to know in order to write any code. They also have debuggers as a result.

Re: Imperative vs. Declarative (2013)

#30
post #8

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 fi…

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

Oh god, this one hits way too close to home for me.
Post reply on HN