Subject: Re: A lisp challenge. From: Erik Naggum <firstname.lastname@example.org> Date: Thu, 21 Mar 2002 22:13:00 GMT Newsgroups: comp.lang.lisp Message-ID: <email@example.com> * firstname.lastname@example.org (Damond Walker) | Agree with the C++ reference. I'd figure that 60% to 90% of a C++ | coders experience with a problem "worth solving" would be spent | slinging infrastructure. Odds are if the problem definition changes | then much of that infrastructure, if tied to closely to the original | problem, would be thrown out. Precisely, and the personal attachment that mere mortals feel towards what they have written is such a strong barrier to throwing things out that it is even a stronger motivator to keep going than all the waste of time that went into what is thrown away. However, anyone who has ever successfully been published (even in academia), will know that in order to get an idea across, you need to be able to phrase it as least half a dozen different ways and be able to expand on each of them. Successful writing is much harder than chess or go in terms of thinking ahead and setting up for future moves. Writing good software is even harder, and that is why setting up the proper abstractions is so amazingly hard and why both library and language design requires so much forethought and experience. The problem with C++ is basically that it was not thrown out in time, that Bjarne accepted almost every suggestion he received. The more experience you have writing, the less attached you become to what you have written. This does not appear to be true for programmers, maybe because the function the copy-editor and editor has in a publishing company is performed by the compiler, so everything that passes the compiler is effectively "published". | As an aside: A correct solution is not always the optimal one. Would you | consider sub-optimal solutions to still be in the class of problems | "worth solving?" I'd say yes though I'd qualify it with a "it depends." Whether a problem has been solved sufficiently or not is usually an engineering decision, not an academic exercise in perfection, but if there is a satisfaactory general solution, the engineering decisions change dramatically in nature. /// -- In a fight against something, the fight has value, victory has none. In a fight for something, the fight is a loss, victory merely relief.