Prev: Anybody mind to translate this Felleisen quote from German to English
Next: Macros and anonymous functions
From: Zach Beane on 25 Feb 2010 09:31 ccc31807 <cartercc(a)gmail.com> writes: > This morning, with a fresh slate, I opened the file, compiled it, and > it ran perfectly. I don't know what I was doing wrong, and certainly > didn't do anything to fix it, so the only explanation I can give is > the remission of programming sins by the programming gods. Blaming gods is a great way to absolve yourself of responsibility and avoid learning from your actions. You accumulated state in your system that interfered with its normal operation, and you fixed it by restarting from a clean state. This is a drastic but sometimes effective problem-solving technique, and can be the easiest thing to do when you don't yet know how to inspect and manipulate the system's accumulated state to get it back in order. No gods were involved in the making or solving of this problem. When I first started using Linux, I accidentally unpacked a nethack tarball in /dev. As I saw the file list flying by as they were deposited all over that directory, I knew I could never find them all and clean up the mess. So I erased my system and reinstalled it from floppies. Problem solved; I didn't have any especially valuable state worth preserving, anyway. Now that I know better, I feel fine about building up important state on my Linux systems and have confidence in my ability to recover from accidents without starting completely from scratch. Zach
From: ccc31807 on 25 Feb 2010 09:56 On Feb 25, 9:31 am, Zach Beane <x...(a)xach.com> wrote: > Blaming gods is a great way to absolve yourself of responsibility and > avoid learning from your actions. Are you serious? Or are you saying this with tongue firmly planted in cheek? (I was attempting levity, which probably wasn't evident.) > You accumulated state in your system that interfered with its normal > operation, and you fixed it by restarting from a clean state. This is a > drastic but sometimes effective problem-solving technique, and can be > the easiest thing to do when you don't yet know how to inspect and > manipulate the system's accumulated state to get it back in order. Yeah, it took me about three microseconds to figure this out. That's not the answer, and it's certainly not the question, but at least I learned that this is a problem you can have, which isn't a problem in my normal working environments. > No gods were involved in the making or solving of this problem. They were either the programming gods, or the programming fairies, or the programming elves. There is simply no explanation other than supernatural beings who interact with humans in an arbitrary and capricious manner, making logic, reason, and science totally illogical, unreasonable, and unscientific. ;-) > worth preserving, anyway. Now that I know better, I feel fine about > building up important state on my Linux systems and have confidence in > my ability to recover from accidents without starting completely from > scratch. In my experience, a lesson really isn't driven home (as opposed to just learning it) until it has been validated in the school of practical experience. This has happened to me in the past, it will happen in the future, and now I can began to explain it and develop strategies to deal with it. It's all part of learning to use a new language. CC
From: Tim Bradshaw on 25 Feb 2010 10:06 On 2010-02-25 14:31:18 +0000, Zach Beane said: > No gods were involved in the making or solving of this problem. True, most of the Lisp gods are now dead or withdrawn
From: Zach Beane on 25 Feb 2010 10:14 ccc31807 <cartercc(a)gmail.com> writes: > On Feb 25, 9:31 am, Zach Beane <x...(a)xach.com> wrote: >> Blaming gods is a great way to absolve yourself of responsibility and >> avoid learning from your actions. > > Are you serious? Or are you saying this with tongue firmly planted in > cheek? (I was attempting levity, which probably wasn't evident.) I meant what I wrote. >> You accumulated state in your system that interfered with its normal >> operation, and you fixed it by restarting from a clean state. This is a >> drastic but sometimes effective problem-solving technique, and can be >> the easiest thing to do when you don't yet know how to inspect and >> manipulate the system's accumulated state to get it back in order. > > Yeah, it took me about three microseconds to figure this out. That's > not the answer... [snip] It is exactly the answer. > I learned that this is a problem you can have, which isn't a problem > in my normal working environments. Problematic state can happen in many systems. Resetting a system is a usually not necessary if you have the tools and skills needed to inspect and manage the system's state. You have the tools but not the skills when it comes to Lisp, but practice should give you the skills. Good for you if you have both the tools and skills in your normal environments. Zach
From: Norbert_Paul on 25 Feb 2010 11:01
I could produce state even you cannot fix without resetting if I only knew your G�del number. Norbert Zach Beane wrote: > Problematic state can happen in many systems. Resetting a system is a > usually not necessary if you have the tools and skills needed to inspect > and manage the system's state. You have the tools but not the skills > when it comes to Lisp, but practice should give you the skills. Good for > you if you have both the tools and skills in your normal environments. > > Zach |