"I 100% understand the aspiration; I just don't think it works as well as this in commercial software development, where there are competing concerns, not just

"I 100% understand the aspiration; I just don't think it works as well as this in commercial software development, where there are competing concerns, not just idealized software construction. Leaving some of the less-commonly used (domain) abstractions out, and instead building them out of more commonly used (non-domain-specific) abstractions, is what I assert is actually desirable, but Lisp doesn't help you much here, as it's almost too easy to create new abstractions. (I'll go further: I think the principal cause of Lisp's relative lack of success is the ease with which it lets you build your own private language, and the concomitant difficulty in teaching other people that language, when you need to bring new people in.)" I think we agree on everything except for what is desirable. Macros certainly allow you to do some interesting things with control constructs, but I have to disagree that they are really that big of a help in constructing your own private language. I can imagine doing bottom up programming in the style of lisp in a language like C quite easily. The only difference is you wouldn't get to write your own control structures. "Your new hires have a natural language they talk about the domain in - a programming language, like Java or C#. They are usually not subject matter experts when they arrive, and certainly they won't be 100% up to date on the particular dialect chosen for your architecture. That's why it's important to choose the right abstractions, and not to move too close to the problem domain." I guess it depends on your business model. If you are a small shop and you expect to have a high retention rate of a few experts that you pay well, I don't see 'new hire' turnover as a big deal. In addition to that, it doesn't seem to me that anyone really knows how to 'program' once they get out of college, unless they were doing it before college. Your CS student from college is going to need mentoring, just as your mechanical or civil engineer will need mentoring at the beginning of his or her career. If you create the language in a reasonable way (using a functional approach rather than creating piles of macros). It seems it should be possible to read the program just as any other. As you learn about the problem domain and become an expert in it, the program should become easier to understand. "In commercial development, everything is underspecified and underdocumented. This won't change." The specification should be in a constant flux of improvement. The initial specification is bad. The finished product specification should be strong. Iterate and get a lot of feedback and clarify that feedback, and the specification has to improve. If it isn't specified as being the wrong thing to have happen, how can it be a bug? If I want computer programming to be closer to engineering and further from voodoo, the only thing to do is to have better specifications and reasons for doing things. "This, frankly, is nonsense, and is the reason I've reacted so much to your comment; it makes me inclined to think you don't have much commercial experience. The best way of understanding a program is by fixing bugs in it, and that will involve modifications to areas of it, well in advance of understanding all or most of it." I think I communicated badly. I agree completely that fixing bugs is the best way to learn a program. I intended to imply that you HAVE to understand what the code that directly interacts with the bug does, in order to actually fix it. If you don't do that, you have possibly created new bugs.