In LinQ we pass anything by reference and we got closures then, and closures inside the reference objects. Doesn't that break any model of using lambdas and list comprehensions?
That's ok. Sharing is fine; references are fine. If you and I point to the same string, the fact that the string says "Hello", we don't need to have 2 copies of "Hello", we can share the same copy, so long as we don't change it. It's not sharing that's the problem, it's effects. If you share references to values that are immutable, everything is cool. If you share references to mutable values and you mutate them, everything is very uncool.
I got my ass bitten in python by this a few times, i had a few objects with a few references to them, and i assumed that all of them pointed to the right objects, but i soon discovered that some of them pointed to copies of the objects from a previous time, and that they staid the same, while the other ones changed, and i assumed they all had the same value. This took a whole day to debug, and i managed to do it by writing the program in a functional way and the functions that changed the state of the objects simply returned new objects, and i got rid of the references, i just called functions, that returned the current "state" of the objects. pretty much i minimized state, that got rid of the bug and made the game easier to understand, as Mr.Jones points out, learning a functional language(scheme in my case) does make your imperative programing better :D
LISP is worth learning for a different reason — the profound enlightenment
experience you will have when you finally get it. That experience will make
you a better programmer for the rest of your days, even if you never actually
use LISP itself a lot.
This is from "How to Become a Hacker" by Eric Raymond.
However, I think the more correct thing to say would be more on target with what you just mentioned. Functional languages teach you to minimize the mutation of state, which is a really great win in all languages, as your anecdote demonstrates.
Scheme would probably be better than Common Lisp -- the design of the language encourages functional programming more. If nothing else, naming functions that mutate state with !s (e.g. set-cdr!) seems like a good convention: it doesn't twist your arm, but it reminds you in a way that stands out.
6 comments
[ 3.8 ms ] story [ 26.1 ms ] threadThat's ok. Sharing is fine; references are fine. If you and I point to the same string, the fact that the string says "Hello", we don't need to have 2 copies of "Hello", we can share the same copy, so long as we don't change it. It's not sharing that's the problem, it's effects. If you share references to values that are immutable, everything is cool. If you share references to mutable values and you mutate them, everything is very uncool.
I got my ass bitten in python by this a few times, i had a few objects with a few references to them, and i assumed that all of them pointed to the right objects, but i soon discovered that some of them pointed to copies of the objects from a previous time, and that they staid the same, while the other ones changed, and i assumed they all had the same value. This took a whole day to debug, and i managed to do it by writing the program in a functional way and the functions that changed the state of the objects simply returned new objects, and i got rid of the references, i just called functions, that returned the current "state" of the objects. pretty much i minimized state, that got rid of the bug and made the game easier to understand, as Mr.Jones points out, learning a functional language(scheme in my case) does make your imperative programing better :D
However, I think the more correct thing to say would be more on target with what you just mentioned. Functional languages teach you to minimize the mutation of state, which is a really great win in all languages, as your anecdote demonstrates.
Edit: What am I even saying? I didn't mention LISP, it was a quote.