7 ms·

With the deepest reverence to John McCarthy, I regret to say that Lisp is our cosmological constant. It creates a static universe that is otherwise expanding;

With the deepest reverence to John McCarthy, I regret to say that Lisp is our cosmological constant. It creates a static universe that is otherwise expanding; it reduces the problem to a solvable one and then declares victory. The truth is, it's all state. All of it. Remember that movie "Boy in the Plastic Bubble," about a boy with an immune system deficiency who lives instead a hermetically-sealed, sterile bubble? That's not the answer. We instead need to create immune systems (read: robust systems) rather than simply avoiding them. [I know I'm simplifying things, and this is not meant to be a slight.]

gnosis 14y ago
Lisp is a multi-paradigm language that's perfectly capable of representing state. Perhaps you're confusing it with some purely functional language like Haskell.
- david927 14y ago
  I'm not saying it can't represent state; I'm saying that it promotes avoidance of state as a virtue.
  - gnosis 14y ago
    One of the reasons avoiding state is promoted is to make it easier to write robust software. State is too often the enemy of robustness.
    - larholm 14y ago
      And robustness is often the static plastic bubble that hides in itself, never accomplishing much in the real world. State is too often the real world. Mind you, I like robustness. It's like the cinder blocks I use to build my house, each robust and contained in itself. I just can't disregard state when stacking my cinder blocks on top of each other; the flexing and distribution of load is an emergent state that I have to consider when building each cinder block.
      - nightski 14y ago
        So to be clear here I assume you are talking about mutable state. Even if that is the case, it is not about avoiding state at all. It is about managing it explicitly.
      - jerf 14y ago
        I translate your first paragraph to "I have never used Haskell" in my head. The idea that Haskell is somehow about not doing anything because it can't do state is just silly. It doesn't pass the smell test. People do not write web frameworks or compilers or anything in a language that "can't do anything" because it can't do state. Haskell is not about "not touching state". That's just objectively wrong. It may not work exactly like you are used to, you may not like the tradeoffs, but Haskell can do things. I know, because I can make it do things.
  - kristiandupont 14y ago
    I would say that it is. Mutable state in software is like moving parts in hardware. It's often necessary, but it makes everything a bit more fragile.
  - jeffdavis 14y ago
    Avoidance of state in general is a pretty ridiculous claim to make. Even when writing pure functions, the state consists of all of the arguments to all of the functions up the stack.
- dons 14y ago
  ... of course Haskell is perfectly capable of representing state too ...
augustl 14y ago
I attended TechMesh 2012 in London. The creators of Haskell were there, and there was a number of other Haskell talks. They were almost all about how to model state, I/O, etc. One of the Haskell creators also created Quickcheck, a generative testing tool where tests are written in Haskell. He talked about how he found state related bugs in Riak. Rich Hickey, author of Clojure, was there, he keynoted about state. I'd argue that the whole point of Clojure is to manage state. Specifically, have a model for how to work with the passing of time. In other words: functional programming and Lisp does not translate to ignoring state.
- dschiptsov 14y ago
  How to model a state is a meaningless question without asking state of what. Same is true for I/O. You must start from a protocol. Most of people probably underestimate how many brilliant people contribute to what we could call a modern Lisp. With all respect, Clojure is nowhere near in terms of sanity, consistency and uniformity. I don't event want to argue about Haskell. Seems like words "monad" is the same as words "chakra" or "dharma" in a popular culture.))
  - irahul 14y ago
    > With all respect, Closure is nowhere near in terms of sanity, consistency and uniformity. It's Clojure http://clojure.org/ http://clojure.org/ Closure is Google's js library and tools https://developers.google.com/closure/ https://developers.google.com/closure/
    - dschiptsov 14y ago
      Yeah, thank you. It was a typo..
  - PuercoPop 14y ago
    Ir you are talking about syntax uniformity, lisp is not very regular also http://xahlee.info/UnixResource_dir/writ/lisp_problems.html http://xahlee.info/UnixResource_dir/writ/lisp_problems.html Although I agree that clojure has is warts. For example clojurescript uses the numerical stack of JavaScript. So you get different and unexpected results than when running on the JVM
nickik 14y ago
So because there is state you want to have a messy pile of it. Many lisps have more advanced system for states then most other languages. Common Lisp has a better object system then any other in the world. Clojure has a time and state managment system.
- draegtun 14y ago
  I rate Moose (http://moose.perl.org http://moose.perl.org) up there with CLOS when it comes to power, extensibility and features. However saying these are the best OOP systems in the world is still very subjective because I do have a fondness for the simplicity and elegance of Prototype based OO especially as implemented in languages like in Io, Rebol & Self.
dasil003 14y ago
I'm sorry but what you're saying is immediately obvious. No one in the functional programming world is laboring under the impression that state doesn't exist. The real issue is whether you think it's worth separating out code that can be reasoned about in a mathematical fashion from stateful code that has to deal with mutating concerns. Functional programming is where research on improving abstractions to better allow this separation of concerns, which is pretty much the opposite of a clumsy hermetically-sealed bubble rolling around and knocking lamps over, etc.
- david927 14y ago
  I'm not sure what I said is obvious because you seem to have missed my point. I didn't say that "state exists". I said, "It's all state." I'm saying the notion of "separating out code that can be reasoned about in a mathematical fashion," while a successful strategy in the past, is inherently crippled by that division.
  - gajomi 14y ago
    For the record, I also did not think whatever you were saying was obvious, but if your point is that understanding programs by "separating out code that can be reasoned about in a mathematical fashion" is no longer a viable strategy, I must take issue with your statement. Can you provide an example of a side effect free function that can't be reasoned about mathematically? I'm sure they exist, but they seem to me to be a kind of exotic beast. Or maybe I am just not familiar with your domain of expertise?
  - efuquen 14y ago
    How it exactly is it a "crippled vision"? There are tons and tons of code that I write every day that I'm able to separate out like this. Honestly there is way more code that you can reason about in this way then not reason about in this way. This isn't some academic exercise, people right functional code that operate in this way and do a lot of useful things everyday.
- MaysonL 14y ago
  What makes you think that stateful code can't be reasoned about in a mathematical fashion?
slurry 14y ago
Funny you should say that: just yesterday Reddit informed me that Lisp is 100% imperative because it has a loop keyword and allows destructive assignment.
- chc 14y ago
  Well, "Lisp" is a language family rather than a specific language. Although it's culturally drawn toward functional programming, Common Lisp is more or less an imperative language with first-class functions, much like Python is. Its designers chose this approach because they wanted it to be a "big tent" language that imposes few opinions on the programmer. Other Lisps like Clojure and Racket went in a different direction.
martinced 14y ago
"The truth is, it's all state. All of it." The problem is not state. The problem is being able to recreate the state: both for testing and for business purposes. The bigger problem is that most programmers, like you, are knee-jerking before the issue of "recreating the state" and declaring that "It cannot be done, because it's all state". And hence we have both languages who are build by considering mutability to be a virtue and back-end databases (your typical CRUD SQL DB) build upon the same false premises. I'll give you one example: monday morning the service desk calls because one user of your app, at 3:07pm on friday, experienced a bug. Can you "recreate the state" your application was in at that time as to be able to figure out what triggered the bug? You probably can't. Because your DB has changed meanwhile: you're SOL because the 'U' and the 'D' in CRUD are destructive. It's mutability. It's the ennemy of determinism. So now you're stuck calling your DB admin asking for a dump of the prod DB on last thursday evening and a dump of the log of the transactions that happened on friday... And you're spending hours and hours trying to recreate the state the environment was in when the sht hit the fan. And you may or may not be able to do it. It's just one hypotethical scenario but things like that is the daily lot of many* programmers. But software development, in many cases, shouldn't be that painful. If you were to use a CRA DB (Create Read Append) and languages favoring immutability and a more functional approach overall, you'd have a much much easier time recreating the state. If you think of it, it's all a gigantic determistic machine. So why can't we accept that the notion of time is an important one? Why can't you realize that the battle the likes of Rich Hickey are fighting are worth it? It is possible to use programming languages and DBs (or wrappers like Datomic in front of SQL DBs) that do definitely make it easier to reason about programs and that make it just so much easier to recreate the state and to query the past (which has a lot of business value). Why do you react like this: "The truth is, it's all state". Saying that as if nothing could be done and as if every single programmer's life should be Java/C# + ORM + XML + SQL hell? There are people trying to make our life as devs easier. Why not try to listen to what their saying? Is Rich Hickey "seeing things" with Clojure + Datomic? To me the combination of a functional language (or at least a language that can be used in a mostly functional way) and a CRA DB (Create Read Append) which incorporates the notion of time from the start is a godsend to our industry. Why do you close your eyes?
- Lapsa 14y ago
chc 14y ago
You're making an extremely vague but bombastic claim here. I don't think you're intentionally trolling, but it operates on a very similar level. What does this mean in practical terms? What are you specifically criticizing? It's obvious that you're taking some kind of dig at functional programming, but what is the actual critique or logical argument you're attempting to make here? It is very unclear.
derleth 14y ago
> The truth is, it's all state. All of it. Lisp represents mutable state the same way Python and C++ do.

gnosis 14y ago

Lisp is a multi-paradigm language that's perfectly capable of representing state. Perhaps you're confusing it with some purely functional language like Haskell.

david927 14y ago
I'm not saying it can't represent state; I'm saying that it promotes avoidance of state as a virtue.
- gnosis 14y ago
  One of the reasons avoiding state is promoted is to make it easier to write robust software. State is too often the enemy of robustness.
  - larholm 14y ago
    And robustness is often the static plastic bubble that hides in itself, never accomplishing much in the real world. State is too often the real world. Mind you, I like robustness. It's like the cinder blocks I use to build my house, each robust and contained in itself. I just can't disregard state when stacking my cinder blocks on top of each other; the flexing and distribution of load is an emergent state that I have to consider when building each cinder block.
    - nightski 14y ago
      So to be clear here I assume you are talking about mutable state. Even if that is the case, it is not about avoiding state at all. It is about managing it explicitly.
    - jerf 14y ago
      I translate your first paragraph to "I have never used Haskell" in my head. The idea that Haskell is somehow about not doing anything because it can't do state is just silly. It doesn't pass the smell test. People do not write web frameworks or compilers or anything in a language that "can't do anything" because it can't do state. Haskell is not about "not touching state". That's just objectively wrong. It may not work exactly like you are used to, you may not like the tradeoffs, but Haskell can do things. I know, because I can make it do things.
- kristiandupont 14y ago
  I would say that it is. Mutable state in software is like moving parts in hardware. It's often necessary, but it makes everything a bit more fragile.
- jeffdavis 14y ago
  Avoidance of state in general is a pretty ridiculous claim to make. Even when writing pure functions, the state consists of all of the arguments to all of the functions up the stack.
dons 14y ago
... of course Haskell is perfectly capable of representing state too ...

augustl 14y ago

I attended TechMesh 2012 in London. The creators of Haskell were there, and there was a number of other Haskell talks. They were almost all about how to model state, I/O, etc. One of the Haskell creators also created Quickcheck, a generative testing tool where tests are written in Haskell. He talked about how he found state related bugs in Riak. Rich Hickey, author of Clojure, was there, he keynoted about state. I'd argue that the whole point of Clojure is to manage state. Specifically, have a model for how to work with the passing of time. In other words: functional programming and Lisp does not translate to ignoring state.

dschiptsov 14y ago
How to model a state is a meaningless question without asking state of what. Same is true for I/O. You must start from a protocol. Most of people probably underestimate how many brilliant people contribute to what we could call a modern Lisp. With all respect, Clojure is nowhere near in terms of sanity, consistency and uniformity. I don't event want to argue about Haskell. Seems like words "monad" is the same as words "chakra" or "dharma" in a popular culture.))
- irahul 14y ago
  > With all respect, Closure is nowhere near in terms of sanity, consistency and uniformity. It's Clojure http://clojure.org/ http://clojure.org/ Closure is Google's js library and tools https://developers.google.com/closure/ https://developers.google.com/closure/
  - dschiptsov 14y ago
    Yeah, thank you. It was a typo..
- PuercoPop 14y ago
  Ir you are talking about syntax uniformity, lisp is not very regular also http://xahlee.info/UnixResource_dir/writ/lisp_problems.html http://xahlee.info/UnixResource_dir/writ/lisp_problems.html Although I agree that clojure has is warts. For example clojurescript uses the numerical stack of JavaScript. So you get different and unexpected results than when running on the JVM

nickik 14y ago

So because there is state you want to have a messy pile of it. Many lisps have more advanced system for states then most other languages. Common Lisp has a better object system then any other in the world. Clojure has a time and state managment system.

draegtun 14y ago
I rate Moose (http://moose.perl.org http://moose.perl.org) up there with CLOS when it comes to power, extensibility and features. However saying these are the best OOP systems in the world is still very subjective because I do have a fondness for the simplicity and elegance of Prototype based OO especially as implemented in languages like in Io, Rebol & Self.

dasil003 14y ago

I'm sorry but what you're saying is immediately obvious. No one in the functional programming world is laboring under the impression that state doesn't exist. The real issue is whether you think it's worth separating out code that can be reasoned about in a mathematical fashion from stateful code that has to deal with mutating concerns. Functional programming is where research on improving abstractions to better allow this separation of concerns, which is pretty much the opposite of a clumsy hermetically-sealed bubble rolling around and knocking lamps over, etc.

david927 14y ago
I'm not sure what I said is obvious because you seem to have missed my point. I didn't say that "state exists". I said, "It's all state." I'm saying the notion of "separating out code that can be reasoned about in a mathematical fashion," while a successful strategy in the past, is inherently crippled by that division.
- gajomi 14y ago
  For the record, I also did not think whatever you were saying was obvious, but if your point is that understanding programs by "separating out code that can be reasoned about in a mathematical fashion" is no longer a viable strategy, I must take issue with your statement. Can you provide an example of a side effect free function that can't be reasoned about mathematically? I'm sure they exist, but they seem to me to be a kind of exotic beast. Or maybe I am just not familiar with your domain of expertise?
- efuquen 14y ago
  How it exactly is it a "crippled vision"? There are tons and tons of code that I write every day that I'm able to separate out like this. Honestly there is way more code that you can reason about in this way then not reason about in this way. This isn't some academic exercise, people right functional code that operate in this way and do a lot of useful things everyday.
MaysonL 14y ago
What makes you think that stateful code can't be reasoned about in a mathematical fashion?

slurry 14y ago

Funny you should say that: just yesterday Reddit informed me that Lisp is 100% imperative because it has a loop keyword and allows destructive assignment.

chc 14y ago
Well, "Lisp" is a language family rather than a specific language. Although it's culturally drawn toward functional programming, Common Lisp is more or less an imperative language with first-class functions, much like Python is. Its designers chose this approach because they wanted it to be a "big tent" language that imposes few opinions on the programmer. Other Lisps like Clojure and Racket went in a different direction.

martinced 14y ago

"The truth is, it's all state. All of it." The problem is not state. The problem is being able to recreate the state: both for testing and for business purposes. The bigger problem is that most programmers, like you, are knee-jerking before the issue of "recreating the state" and declaring that "It cannot be done, because it's all state". And hence we have both languages who are build by considering mutability to be a virtue and back-end databases (your typical CRUD SQL DB) build upon the same false premises. I'll give you one example: monday morning the service desk calls because one user of your app, at 3:07pm on friday, experienced a bug. Can you "recreate the state" your application was in at that time as to be able to figure out what triggered the bug? You probably can't. Because your DB has changed meanwhile: you're SOL because the 'U' and the 'D' in CRUD are destructive. It's mutability. It's the ennemy of determinism. So now you're stuck calling your DB admin asking for a dump of the prod DB on last thursday evening and a dump of the log of the transactions that happened on friday... And you're spending hours and hours trying to recreate the state the environment was in when the sht hit the fan. And you may or may not be able to do it. It's just one hypotethical scenario but things like that is the daily lot of many* programmers. But software development, in many cases, shouldn't be that painful. If you were to use a CRA DB (Create Read Append) and languages favoring immutability and a more functional approach overall, you'd have a much much easier time recreating the state. If you think of it, it's all a gigantic determistic machine. So why can't we accept that the notion of time is an important one? Why can't you realize that the battle the likes of Rich Hickey are fighting are worth it? It is possible to use programming languages and DBs (or wrappers like Datomic in front of SQL DBs) that do definitely make it easier to reason about programs and that make it just so much easier to recreate the state and to query the past (which has a lot of business value). Why do you react like this: "The truth is, it's all state". Saying that as if nothing could be done and as if every single programmer's life should be Java/C# + ORM + XML + SQL hell? There are people trying to make our life as devs easier. Why not try to listen to what their saying? Is Rich Hickey "seeing things" with Clojure + Datomic? To me the combination of a functional language (or at least a language that can be used in a mostly functional way) and a CRA DB (Create Read Append) which incorporates the notion of time from the start is a godsend to our industry. Why do you close your eyes?

Lapsa 14y ago

chc 14y ago

You're making an extremely vague but bombastic claim here. I don't think you're intentionally trolling, but it operates on a very similar level. What does this mean in practical terms? What are you specifically criticizing? It's obvious that you're taking some kind of dig at functional programming, but what is the actual critique or logical argument you're attempting to make here? It is very unclear.

derleth 14y ago

> The truth is, it's all state. All of it. Lisp represents mutable state the same way Python and C++ do.