[aminit]

I exaggerated a little with this randomness.

Let me explain:

Given the same input Prolog program and imperative (Pascal?) one will give the same results. Because Prolog is imperative.

Non-imparative languages give estimated results (actually I don't know any of these). Why? Because for example data is too large to do simple things like counting all elements. Thats non-imperative. Result is no longer based on what is in the data space, but based on its characteristics. For example, you may calculate a number of helium atoms in a cubic inch, but you will never do such thing like counting them one by one (imperative way).

[debacle]

aminit I am not sure if you know what imperative means.

Imperative programs have a state or virtual machine that is manipulated by the program. All programs, at heart, are imperative, but higher level constructs allow for procedural or declarative programming which abstracts away the lower-level imperative bits.

    // Imperative 
    if(foo == 'Tuesday') {
        print 'Taco Tuesday';
    }
    
    // Procedural
    if(isTacoTuesday(foo)) {
        writeTacoTuesday();
    }
   
    // Functional (but not monadic)
    (if (eq foo 'Tuesday') (print 'Taco Tuesday'))

    // Declarative
    taco_tuesday : foo == 'Tuesday'
    run : ( taco_tuesday -> write('Taco Tuesday') ; true )
    run;

No I have not had lunch yet.

[kyllo]

Nice.

I like this more for a functional idiom:

    case foo of 
        TUESDAY => "Taco Tuesday"
        | _ => "Not Taco Tuesday"

Or this:

    (cond (= foo TUESDAY)
        ("Taco Tuesday")
        ("Not Taco Tuesday"))

All programs, at heart, are imperative

Yes, but only because the underlying machine architecture is imperative, right? If you had a chip that could evaluate pure functions with no mutable state (like a Lisp Machine that used a purely functional dialect of Lisp) then you could have programs with no underlying imperativeness.

But in a perhaps more relevant sense, in languages like Haskell or Prolog it is possible to write a program with no imperative state manipulation happening at the programmer's working level of abstraction.

Still, this really has nothing to do with determinism.

Also, I like SQL as an example of declarative programming.

    SELECT * FROM USERS
    WHERE JOIN_DATE = "20150106"

That is a declarative program; the SQL engine it's run on decides the underlying imperative implementation of the solution at runtime. It is also deterministic in that when it's run on the same database containing the same data multiple times it will return the same result.

From what I know about Prolog, I understand it's similar in this regard.

[qbrass]

Look at your case statement. In most languages, if you swapped the order of TUESDAY and _, you'd get different results.

An actual declarative language would choose TUESDAY over _ because it's the most specific match, and not because it matched it first.

[kyllo]

Yes, good point, but this was not meant to be an example of declarative paradigm, just functional paradigm. It's SML, which is not a particularly declarative language. Haskell is a little bit more declarative but AFAIK its pattern matching works the same way as SML.

[aminit]

Your examples are a little misleading.

// Imperative: (essence of it) x = 0; x = x + 1; y = x;

// Procedural: x = 0; inc(x); return x;

// Functional: return inc(x);

// Declarative: select x + 1;

--- My argument is that all of these above are imperative. Down below sits imperative CPU which will give exactly the same result. Every time.

Wiki definition of imperative programming in my opinion is too broad: "Imperative programming is focused on describing how a program operates"

This applies to every program in every language. Because you as a programmer are always focused on describing how program operates. Prolog is only another higher abstraction layer.

Wiki: "... imperative programming is a programming paradigm that describes computation in terms of statements that change a program state."

Lets reverse the logic here. Non-imperative programming will not describe computation in terms of statements that change program state. So, non-imperative program will not use statements.

[kyllo]

Down below sits imperative CPU which will give exactly the same result. Every time.

If you're authoring programs for an abstract virtual machine in a declarative and/or functional style, it doesn't necessarily matter to you that that the underlying CPU architecture is imperative in nature. That's the point of an abstraction layer.

When we say a language is declarative vs. imperative, we're talking about the language level itself, not the full stack all the way down to the metal. A programming language and an implementation are different things.

[aminit]

Your examples are a little misleading.

// Imperative: (essence of it) x = 0; x = x + 1; return x;

// Procedural x = 0; inc(x); return x;

// Functional return inc(x);

// declarative select x + 1;

--- My argument is that all of these above are imperative. Down below sits imperative CPU which will give exactly the same result. Every time.

Wiki definition of imperative programming is wrong: "Imperative programming is focused on describing how a program operates"

This applies to every program in every language. Because you as a programmer are always focused on describing how program operates. Prolog is only another higher abstraction layer.

[aminit]

Your examples are a little misleading.

// Imperative: (essence of it) x = 0; x = x + 1; return x;

// Procedural x = 0; inc(x); return x;

// Functional return inc(x);

// declarative select x + 1;

--- My argument is that all of these above are imperative. Down below sits imperative CPU which will give exactly the same result. Every time.

Wiki definition of imperative programming is wrong: "Imperative programming is focused on describing how a program operates"

This applies to every program in every language. Because you as a programmer are always focused on describing how program operates. Prolog is only another higher abstraction layer.