Clojure is imperative as opposed to declarative(lispcast.com)
lispcast.com
Clojure is imperative as opposed to declarative
http://www.lispcast.com/clojure-is-imperative
5 comments
This comment, whilst perhaps accurate in and of itself, is missing the point of his article I think...
He's saying that a small, simple, imperative core is easy to understand (and the rest of the language is built on that), whereas more declarative languages tend to involve more complex compilers and more magic, making those languages harder to learn and comprehend.
He's saying that a small, simple, imperative core is easy to understand (and the rest of the language is built on that), whereas more declarative languages tend to involve more complex compilers and more magic, making those languages harder to learn and comprehend.
> He's saying that a small, simple, imperative core is easy to understand (and the rest of the language is built on that), whereas more declarative languages tend to involve more complex compilers and more magic, making those languages harder to learn and comprehend.
Yes, for some unstated definition of "imperative" and "declarative".
Yes, for some unstated definition of "imperative" and "declarative".
This is what I gathered from the context of the article:
Clojure is imperative in the sense that the code is evaluated and executed sequentially. For example, a function cannot be referenced before it is defined.
This is in contrast with (declarative) languages such as Haskell, in which the compiler will evaluate the entire file before executing any code.
Someone please correct me if I'm mistaken.
Clojure is imperative in the sense that the code is evaluated and executed sequentially. For example, a function cannot be referenced before it is defined.
This is in contrast with (declarative) languages such as Haskell, in which the compiler will evaluate the entire file before executing any code.
Someone please correct me if I'm mistaken.
You can reference a function before it's defined, just as he did in the C example: http://clojuredocs.org/clojure_core/clojure.core/declare
That's close to what I meant.
Closer would be:
Clojure def is imperative because the semantics are defined mechanically, leaving fewer implementation details up to the implementer. http://clojure.org/special_forms#Special Forms--(def symbol init?)
Haskell toplevel function definitions are more declarative because the semantics are defined less concretely. https://www.haskell.org/ghc/docs/latest/html/users_guide/inf...
This is what I meant. I did not mean to start a flame war about the definition of declarative. It's more about different approaches to language design.
Closer would be:
Clojure def is imperative because the semantics are defined mechanically, leaving fewer implementation details up to the implementer. http://clojure.org/special_forms#Special Forms--(def symbol init?)
Haskell toplevel function definitions are more declarative because the semantics are defined less concretely. https://www.haskell.org/ghc/docs/latest/html/users_guide/inf...
This is what I meant. I did not mean to start a flame war about the definition of declarative. It's more about different approaches to language design.
Would you accept the claim though that Clojure is less declarative than Haskell, in the sense the author means? (Without necessarily a great definition of "declarative". Like how mathematicians could go far without a good definition of "function" until it got to be a problem.)
Yes, I will accept that claim. However the definitions I inferred from the article are new to me (albeit similar to other definitions I'm familiar with). I gathered the same definition as lynndylanhurley.
> It's useless to categorize things as imperative or declarative without defining those words.
Yes because his use of the terms "imperative" and "declarative" are not the way I generally use them. When talking languages, I always thought you had imperative, functional, and declarative. Clojure is functional because of it's use of concepts like "functions are first order objects", closure, higher order functions, etc. I would never consider Clojure imperative.
EDIT: Possibly with the use of core.logic you could argue that it is "declarative" if you wanted to ;)
Yes because his use of the terms "imperative" and "declarative" are not the way I generally use them. When talking languages, I always thought you had imperative, functional, and declarative. Clojure is functional because of it's use of concepts like "functions are first order objects", closure, higher order functions, etc. I would never consider Clojure imperative.
EDIT: Possibly with the use of core.logic you could argue that it is "declarative" if you wanted to ;)
> Clojure is functional because of it's use of concepts like "functions are first order objects", closure, higher order functions, etc. I would never consider Clojure imperative.
I would agree with that. Putting Clojure in the imperative camp seems a little skewed.
From the front page of clojure.org "Clojure is predominantly a functional programming language, and features a rich set of immutable, persistent data structures."
But I don't think that's his point as seancorfield pointed out.
I would agree with that. Putting Clojure in the imperative camp seems a little skewed.
From the front page of clojure.org "Clojure is predominantly a functional programming language, and features a rich set of immutable, persistent data structures."
But I don't think that's his point as seancorfield pointed out.
> I always thought you had imperative, functional, and declarative
That's not how I see it (but of course this largely depends on your definitions).
The main paradigms are imperative and declarative (think Assembler vs. Prolog if you want to go to the extremes).
'Functional' describes the language at a different level, as does 'object-oriented'.
If you go down to the core ideas, being functional is a declarative concept (mathematical functions are relations between sets), and object-oriented an imperative concept (objects are an abstraction over mutable state).
However, that's not necessarily how these concepts appear in practice (a function call is an instruction to trigger a compuation, the set of messages understood by an object declares its interface), and almost all programming languages are multi-paradigm anyway.
That's not how I see it (but of course this largely depends on your definitions).
The main paradigms are imperative and declarative (think Assembler vs. Prolog if you want to go to the extremes).
'Functional' describes the language at a different level, as does 'object-oriented'.
If you go down to the core ideas, being functional is a declarative concept (mathematical functions are relations between sets), and object-oriented an imperative concept (objects are an abstraction over mutable state).
However, that's not necessarily how these concepts appear in practice (a function call is an instruction to trigger a compuation, the set of messages understood by an object declares its interface), and almost all programming languages are multi-paradigm anyway.
>> the only thing a post like this will accomplish is starting a flame war.
And, possibly, help the author sell a few books [1].
[1] | http://www.purelyfunctional.tv/intro-to-clojure
And, possibly, help the author sell a few books [1].
[1] | http://www.purelyfunctional.tv/intro-to-clojure
[deleted]
Almost all programming languages are imperative. However, you can often program in a declarative style and some languages lend themselves better to this than others (either for technical or culture reasons).
Clojure is, at its core, imperative. Functional programming is not, IMHO, in itself declarative. To me, functional is just an approach to imperative programming.
Something like prolog is declarative: you tell it some rules and relationships (constraints on your data) and let it find the data which matches this. You declare the rules, it gives you the results. That's declarative: relationships, constraints, rules - not steps (functional, procedural or otherwise).
Clojure does lend itself quite well to declarative programming though. Partially because of its features (macros/metaprogramming, functional programming and immutability makes it easier too) and partially because of the community culture (emphasis on the data etc) and this can be seen in the libraries that have emerged in the ecosystem: core.logic is essentially embedded prolog, core.match lets you extract data declaratively, various datalog-esque libraries (eg Dataomic) to query data declaritively and others that I'm forgetting.
So in summary: I agree that Clojure isn't in itself declarative, but it is quite well suited to programming in a declarative style.
Clojure is, at its core, imperative. Functional programming is not, IMHO, in itself declarative. To me, functional is just an approach to imperative programming.
Something like prolog is declarative: you tell it some rules and relationships (constraints on your data) and let it find the data which matches this. You declare the rules, it gives you the results. That's declarative: relationships, constraints, rules - not steps (functional, procedural or otherwise).
Clojure does lend itself quite well to declarative programming though. Partially because of its features (macros/metaprogramming, functional programming and immutability makes it easier too) and partially because of the community culture (emphasis on the data etc) and this can be seen in the libraries that have emerged in the ecosystem: core.logic is essentially embedded prolog, core.match lets you extract data declaratively, various datalog-esque libraries (eg Dataomic) to query data declaritively and others that I'm forgetting.
So in summary: I agree that Clojure isn't in itself declarative, but it is quite well suited to programming in a declarative style.
I try to use function names that carry a 'declarative mindset' when I write Clojure. E.g.,
(sections x)
instead of
(get-sections x)
(refactored (styled (second-half divs)))
instead of
(refactor (apply-styles (take-second-half divs)))
About 1/4 to 1/3 of this piece is emphasized, either via italicization or bolding. Not only does that destroy the attention-getting nature that emphasized text usually had, but it made it hard to get through the text.
I've commonly heard it said (and I agree, although I used to make the mistake myself in the past) that over-reliance on visual emphasis is a sign of bad writing. Good writers use words, phrases, sentences, grammar and other linguistic constructs for emphasis so don't need to rely on visual emphasis.
This also makes it much more impactful when you do use visual emphasis because its much clearer that its important.
This also makes it much more impactful when you do use visual emphasis because its much clearer that its important.
Isn't this a side effect of how the compiler is implemented?
At this point it's mostly an "I know it when I see it" kind of thing, sometimes accompanied by a nebulous explanation about what versus how. There is a difference that programmers can feel, but we find it very hard to communicate that difference. Even at that, virtually every language has some aspects that are imperative and some that are declarative.
Without definitions (preferably rigorous ones), the only thing a post like this will accomplish is starting a flame war.