Despite an careful attempt in the article to define 'large' (as 'necessarily large'), this is provoking the usual dickwaving from people who think that they are

Despite an careful attempt in the article to define 'large' (as 'necessarily large'), this is provoking the usual dickwaving from people who think that they are cleverer than those poor fools that write 10K or 100K programs, when _obviously_ these 10K or 100K programs are all _clearly_ just loads of tiny little elegant programs that fit together perfectly. 1 - he's already saying that: "One of the marks of a professional programmer is knowing how to organize software so that the complexity remains manageable as the size increases". 2 - the notion that you can just glue a bunch of small elegant programs together into one large, wonderful program is on of the great half-delivered promises of computer science. Spolsky wrote a nice article about 'leaky abstractions' a while back. 3 - in my experience, there are a number of problems that are simply disgusting and don't break up into small, elegant modules, and are better solved by enormous, disgusting 5 page functions. Really. If you haven't met one, be glad, but don't kid yourself that because you've only ever found nice elegant programs that everything out there is amenable to breaking into nice elegant components. Disgusting code like this is particularly prevalent when you have to handle a lot of cases up against an interface that you don't control, especially when you have to write code that is high-performance and can't resort to some nice 'script-ish' or table-driven approach. The guts of a real, high-performance compiler (not one of a toy language, but one that has to produce good code for a huge range of bizarre coding styles on the front end) at the point that it's dealing with actual hardware is a good example. On the front-end you've got input programs (many of the properties of which the compiler designers don't control) and on the back-end you've got an hardware ISA that the compiler designers don't control either. Some elegance usually happens here and there between those two points, but sometimes you have to build a large, complex system with a lot of interactions because you have a large, complex problem with a lot of interacting concerns. NOT because you're not using "Left-Handed Object Oriented Semi-Eager Inverness Haskell". Often the difference between a successful product and a toy project is the willingness to deal with the nasty aspects of a problem that often force you to write these disgusting functions. Various PL weenies will no doubt appear and tell us how this was all solved X years ago in language Y, but they were too busy proving theorems, writing a new compiler in Y for the even more awesome language Y', and reimplementing trivial projects (Web server, anyone?) in their chosen language to build anything substantial.