6 ms·

The book chapter aside, I think you might actually have it backwards. Hopefully I'm not misunderstanding you terribly! The reason why PG has to spend as much ti

The book chapter aside, I think you might actually have it backwards. Hopefully I'm not misunderstanding you terribly! The reason why PG has to spend as much time as he does warning programmers about hidden ways in which Common Lisp mangles your data structures (nconc, for example) is because Common Lisp does not come with immutable data structures out of the box. My impression is that he's telling you how to work as well as you can (strive for purely functional code) with the tools at hand. Clojure, on the other hand, was built so that you could code without having to worry about that stuff by default. Also, you say that lisps have "always had shared structure." I'm not sure what you mean by that? Clojure implements _structural sharing_, which is what allows it to have persistent, immutable data structures. Common Lisp certainly doesn't do the same. I'm not sure what you mean by "Lisp went on a journey to Java and was transformed by the experience." I think you're saying that Rich Hickey designed Clojure to be a lisp that's more Java-like? Could you explain how? My impression is that Rich Hickey thinks OO is broken (see the talk "Are we there yet?"), as is the notion of mutability as implemented by Java. Clojure's interop with Java is a great convenience, but the emphasis is still on functional programming. I don't think I understand what you're saying, or maybe it's just that we disagree? Finally, from clojure.org: "Clojure is predominantly a functional programming language, and features a rich set of immutable, persistent data structures. When mutable state is needed, Clojure offers a software transactional memory system and reactive Agent system that ensure clean, correct, multithreaded designs." Maybe it's these state management features you're concerned about? If so, then I would suggest that vars, atoms, refs, and agents are not as inspired by Java as you're saying. Or maybe we just disagree that, the majority of the time, you should be writing pure functions and using immutable data structures in Clojure?

brudgers 12y ago
PG isn't warning any experienced Common Lisp programmer about `nconc`. The [n] at the front means it's destructive...there's also `nsubst` and `nreverse` and `nstring-capitalize`. They all exist in Common Lisp to allow a programmer to avoid consing and the subsequent garbage collection. In other words, they exist to allow a programmer to optimize their code. They exist as exceptions to idiomatic Common Lisp practice of returning values in lieu of mutating locations. Sure it is not as idiomatic in Common Lisp as in Clojure in part because Common Lisp is largely a product of its time and that time was largely single threaded. Avoiding mutation in Common Lisp is even less idiomatic than it is in Scheme - where there are not destructive versions of various functions by default and idiomatic practice is mutation is signaled with a bang [!]. But again, the preferred approach is persistence and writing side-effect free functions. Indeed at the front edge of Scheme, Racket implements immutable data structures by default. Idiomatic functional style and defaulting to immutable data structures are not what makes Clojure unique as a Lisp - it's knob twiddling, not a new paradigm. It has some great built in syntax that allows for the best part of Lisp-2 programming - i.e. symbols representing a collection acting as functions over the collection and the association of a meta-data map with a symbol like a plist. But it's evolutionary as a Lisp. On the other hand, though not unique, idiomatic functional style and defaulting to immutable data structures are unusual in relation to the Java platform. Its relationship to the Java platform is what makes Clojure unique. STM is not a product of it's Lisp heritage. Neither is it's implementation of objects with via interop [largely eschewing objects despite availability is also idiomatic Lisp]. Understand, I'm writing to think. What you've written is just a starting point I can use as an excuse for saying what I was primed to say anyway. Like I said in my original comment, I was already drinking from the Clojure firehose. So what's the upshot? Well what did your article say that hasn't already been said before about functional programming? Why not point people to Chapter 3 of Graham? It's more convincing for those who need convincing and more in depth for those who don't. Why not point people to The Value of Values, it's again more convincing for tire-kickers; a comfortable sermon for the newly converted, and a reference point for those already in the cult. What really makes Clojure unique?
- nonrecursive 12y ago
  I don't think I read On Lisp the same way. From 3.1: "If a function is advertised as destructive, that doesn't mean that it's meant to be called for side-effects. The danger is, some destructive functions give the impression that they are. For example,(nconc x y) almost always has the same effect as (setq x (nconc x y))". Calling it dangerous sounds like a warning to me. I definitely agree, though, that he makes the case that the preferred approach is writing side-effect free functions. I'm not sure what you mean by "persistence" though, because Common Lisp doesn't have persistent data structures. I don't know if its emphasis on functional programming and values makes Clojure unique, but that's definitely one of its core design concerns. The "article" is a chapter from a book on Clojure, and learning to write in a purely functional style is essential to learning Clojure. The point of the chapter isn't to get to the heart of what makes the language unique, it's to offer instruction on how to use it.
  - brudgers 12y ago
    Here's the recycled cons at the car of ANSI Common Lisp section 12.4: Common Lisp includes several functions that are allowed to modify list structure. These functions are destructive for reasons of efficiency. Though they may receive conses passed to them as arguments, they are not meant to called for their side-effects. For example, delete is a destructive version of remove. While it is allowed to trash the list passed to it as an argument, it doesn't promise to do anything. This is what happens in most implementations: > (setf lst '(a r a b i a)) (A R A B I A) > (delete 'a lst) (R B I) > lst (A R B I) As with remove, if you want side-effects, you should use setf with the return value: (setf lst (delete 'a lst)) Because garbage collection and homoiconicity can sometimes feel like magic, it can be hard to think of Common Lisp running closer to the metal than a language like C. But it does. Cons cells are locations in memory, and symbols are pointers and there's nothing in between. A programmer doesn't even get `free(array)`. Memory locations can be shared willy-nilly because just as in Clojure, two distinct lists/sequences can share a tail. From ANSI Common Lisp section 12.8, "Constant Structure": > (defun arith-op (x) (member x '(+ - * /))) <function:arith-op> > (setf lst '(as it were) (AS IT WERE) > (nconc (arith-op '*) lst) (* / AS IT WERE) > (arith-op '-) (- AS IT WERE) ;; bad > (arith-op 'as) (AS IT WERE) ;; even worse "Oh Shit!" moments like this are why Lispers like Graham developed a functional programming style. It's a lot of what motivated the design of Scheme. It's not really what motivated Clojure because Java already solves this problem. Clojure is designed to solve the problems Java doesn't more easily. That fundamental goal is why what makes Clojure unique matters when explaining Clojure. It's also what makes Clojure a less than ideal vehicle for teaching functional programming style - it's designed for programmers who are solving problems on the JVM [or CLR or V8], and not really so much as a general purpose language. It's designed around interop. As weavejester says in his linked talk, Clojure is a Java library. There are better languages for teaching functional programming - Scheme/Racket. What makes them objectively better is that helping people learn to program in a functional style is one of the problems they are trying to solve, and they have almost four decades of development toward that goal. Education is entirely orthogonal to Clojure, even more so than Java with its two decades of introductory text development and promotion via vocational arguments in CS departments. And, Racket/Scheme isn't trying to solve JVM problems. Teaching functional programming style is hard, but a largely solved problem because the internet allows pointers to excellent materials. http://learncodethehardway.org/blog/AUG_19_2012.html http://learncodethehardway.org/blog/AUG_19_2012.html

brudgers 12y ago

PG isn't warning any experienced Common Lisp programmer about `nconc`. The [n] at the front means it's destructive...there's also `nsubst` and `nreverse` and `nstring-capitalize`. They all exist in Common Lisp to allow a programmer to avoid consing and the subsequent garbage collection. In other words, they exist to allow a programmer to optimize their code. They exist as exceptions to idiomatic Common Lisp practice of returning values in lieu of mutating locations. Sure it is not as idiomatic in Common Lisp as in Clojure in part because Common Lisp is largely a product of its time and that time was largely single threaded. Avoiding mutation in Common Lisp is even less idiomatic than it is in Scheme - where there are not destructive versions of various functions by default and idiomatic practice is mutation is signaled with a bang [!]. But again, the preferred approach is persistence and writing side-effect free functions. Indeed at the front edge of Scheme, Racket implements immutable data structures by default. Idiomatic functional style and defaulting to immutable data structures are not what makes Clojure unique as a Lisp - it's knob twiddling, not a new paradigm. It has some great built in syntax that allows for the best part of Lisp-2 programming - i.e. symbols representing a collection acting as functions over the collection and the association of a meta-data map with a symbol like a plist. But it's evolutionary as a Lisp. On the other hand, though not unique, idiomatic functional style and defaulting to immutable data structures are unusual in relation to the Java platform. Its relationship to the Java platform is what makes Clojure unique. STM is not a product of it's Lisp heritage. Neither is it's implementation of objects with via interop [largely eschewing objects despite availability is also idiomatic Lisp]. Understand, I'm writing to think. What you've written is just a starting point I can use as an excuse for saying what I was primed to say anyway. Like I said in my original comment, I was already drinking from the Clojure firehose. So what's the upshot? Well what did your article say that hasn't already been said before about functional programming? Why not point people to Chapter 3 of Graham? It's more convincing for those who need convincing and more in depth for those who don't. Why not point people to The Value of Values, it's again more convincing for tire-kickers; a comfortable sermon for the newly converted, and a reference point for those already in the cult. What really makes Clojure unique?

nonrecursive 12y ago
I don't think I read On Lisp the same way. From 3.1: "If a function is advertised as destructive, that doesn't mean that it's meant to be called for side-effects. The danger is, some destructive functions give the impression that they are. For example,(nconc x y) almost always has the same effect as (setq x (nconc x y))". Calling it dangerous sounds like a warning to me. I definitely agree, though, that he makes the case that the preferred approach is writing side-effect free functions. I'm not sure what you mean by "persistence" though, because Common Lisp doesn't have persistent data structures. I don't know if its emphasis on functional programming and values makes Clojure unique, but that's definitely one of its core design concerns. The "article" is a chapter from a book on Clojure, and learning to write in a purely functional style is essential to learning Clojure. The point of the chapter isn't to get to the heart of what makes the language unique, it's to offer instruction on how to use it.
- brudgers 12y ago
  Here's the recycled cons at the car of ANSI Common Lisp section 12.4: Common Lisp includes several functions that are allowed to modify list structure. These functions are destructive for reasons of efficiency. Though they may receive conses passed to them as arguments, they are not meant to called for their side-effects. For example, delete is a destructive version of remove. While it is allowed to trash the list passed to it as an argument, it doesn't promise to do anything. This is what happens in most implementations: > (setf lst '(a r a b i a)) (A R A B I A) > (delete 'a lst) (R B I) > lst (A R B I) As with remove, if you want side-effects, you should use setf with the return value: (setf lst (delete 'a lst)) Because garbage collection and homoiconicity can sometimes feel like magic, it can be hard to think of Common Lisp running closer to the metal than a language like C. But it does. Cons cells are locations in memory, and symbols are pointers and there's nothing in between. A programmer doesn't even get `free(array)`. Memory locations can be shared willy-nilly because just as in Clojure, two distinct lists/sequences can share a tail. From ANSI Common Lisp section 12.8, "Constant Structure": > (defun arith-op (x) (member x '(+ - * /))) <function:arith-op> > (setf lst '(as it were) (AS IT WERE) > (nconc (arith-op '*) lst) (* / AS IT WERE) > (arith-op '-) (- AS IT WERE) ;; bad > (arith-op 'as) (AS IT WERE) ;; even worse "Oh Shit!" moments like this are why Lispers like Graham developed a functional programming style. It's a lot of what motivated the design of Scheme. It's not really what motivated Clojure because Java already solves this problem. Clojure is designed to solve the problems Java doesn't more easily. That fundamental goal is why what makes Clojure unique matters when explaining Clojure. It's also what makes Clojure a less than ideal vehicle for teaching functional programming style - it's designed for programmers who are solving problems on the JVM [or CLR or V8], and not really so much as a general purpose language. It's designed around interop. As weavejester says in his linked talk, Clojure is a Java library. There are better languages for teaching functional programming - Scheme/Racket. What makes them objectively better is that helping people learn to program in a functional style is one of the problems they are trying to solve, and they have almost four decades of development toward that goal. Education is entirely orthogonal to Clojure, even more so than Java with its two decades of introductory text development and promotion via vocational arguments in CS departments. And, Racket/Scheme isn't trying to solve JVM problems. Teaching functional programming style is hard, but a largely solved problem because the internet allows pointers to excellent materials. http://learncodethehardway.org/blog/AUG_19_2012.html http://learncodethehardway.org/blog/AUG_19_2012.html