>Refactoring lisp gets harder the more complex the program gets. Approachs that are clever and reasonable for a 1000 line program can become hell in a 100,000 l

>Refactoring lisp gets harder the more complex the program gets. Approachs that are clever and reasonable for a 1000 line program can become hell in a 100,000 line program. Can you substantiate this claim? One of the reasons Lisp was used in the past was because it was particularly suited to complex, big projects... Like autopilot for spaceship, wind tunnel simulation, CAD/CAM systems, etc. Lisp (as 'Common Lisp', the traditional dialect) has this concept of "packages" and "systems". You can divide your code in "packages", each package contains separate namespaces for classes, function names, variable names, symbol names, keyword names and others. Thus each package doesn't collide with another package and names don't collide at all. Many packages are combined into a "system" (by defining, for example, the required order for compilation, etc). Thus you cleanly separate your code in packages and systems. The 100,000 line program becomes a combination of many shorter programs. Of course this is nothing new, this is just standard practice for keeping big programs manageable. >Breaking up programs into more powerful little pieces is never a clean separation Care to explain? Well, i'll continue with my post. And we'll assume that what you say is true, so i'll list other advantages to keep complex systems at check. Now, here is a big plus for complex systems: In such a Lisp, the system is hot-patchable. You can redefine functions while your program is running. Without stopping the program. We're talking about doing this even on a production environment, if necessary. You can also redefine classes while your program is running. Without stopping the program. Another big plus is the condition-restart system, which very few languages implement. Lisp has not only the notion of "catching exceptions", but also after catching the exception, provide alternate ways of recovering of this exception, including being able to resume operation at the point where the problem was found. This is another big plus for building reliable systems -- and complex systems benefit from being composed of reliable parts. I could go on with other big pluses as well. For example, multi-paradigm. Some parts are more readable (and thus easier to understand, maintenable) if written in the functional style. Others map better to the OOP style. Others would map better to the imperative/procedural style. Other would better be expressed as logic programming (think Prolog.) Lisp allows you to use all these paradigms. So the code stays clear. I say this is very good for complex systems.