TheLibraryProgramBoundary
ThoughtStorms Wiki
BjarneStroustrup: I think people should mentally separate programming into building libraries and using them. Today you write a supporting library, and tomorrow you use it. Far too many times people try and build their systems as one big conglomerate. Even when I do individual work for only a short time, I tend to build some supporting functions and classes, and I design them to be supporting. I don't dive straight into building the whole thing that can do the whole job. So, whether you are by title a library designer or application designer, you should think about how you can separate logically the different parts of your system.
...
One way you shouldn't write libraries is by taking the view that you are the great library designer. You provide the library for me. I use it, and you go away and do something else. You have to think of a library as something you yourself are using, and something that you have to live with as a support person for a longish while. You have to talk a lot to users to get the right abstractions and the right practical details. A library has to evolve. The best libraries are by people who are also users of the libraries. You can't have a class distinction between designers and users.
PaulGraham : In LispLanguage, you don't just write your program down toward the language, you also build the language up toward your program. As you're writing a program you may think "I wish Lisp had such-and-such an operator." So you go and write it. Afterward you realize that using the new operator would simplify the design of another part of the program, and so on. Language and program evolve together. Like the border between two warring states, the boundary between language and program is drawn and redrawn, until eventually it comes to rest along the mountains and rivers, the natural frontiers of your problem. In the end your program will look as if the language had been designed for it. And when language and program fit one another well, you end up with code which is clear, small, and efficient.
I don't want to spam your wiki, but this is once again an example showing that feedback is more efficient than doing all in one sweep.
: Don't worry, you aren't spamming. :-) I'm thinking about your interactivity meme. Of course, I agree, I'm just trying to think of a more interesting response to push the conversation forward. – PhilJones
See also OnReuse, ProgrammingWithTrianglesRectanglesAndCircles