The origin of this idea, for my first introduction I guess, was in <i>The Mythical Man Month</i>. I don&#x27;t have a copy at hand, so I can&#x27;t read what Fred Brooks wrote specifically. 10 is very precise, but really the writing was about the order of magnitude that people can manage in a day. It&#x27;s about the level of complexity involved.<p>10 lines of assembly is very clear about what exactly is happening. It&#x27;s a sequence of adds, loads, branches, stores, moves, etc. Each step is incredibly clear, but <i>what</i> are they operating on? Now it&#x27;s not so clear. What is R2 at <i>this</i> point in the program? Am I calling a subroutine? On this architecture is there some way to automatically handle this with storing the PC and everything, or am I going to use a regular branch instruction? Regular branch? Ok, now I&#x27;m storing the PC and other information away per our calling convention.<p>C: Oh, I&#x27;m calling a function. I&#x27;m calculating a formula. I have named variables, so it&#x27;s clear what I&#x27;m operating on (hopefully, this is at least <i>possible</i> here, even if not well done in practice). With typedefs, good naming conventions, structs and enums, you can maintain an order of magnitude greater complexity in the same time as an assembly programmer, in an order of magnitude lower amount of code.<p>Haskell: I have functions, I have types, I operate over these types transforming them from one to another. Collecting objects of a type here, transforming them there, zipping them with those, and back again. And I&#x27;ve written a function that would take dozens of lines of C or grosses of lines of assembly, and it took me an hour. Again, an order of magnitude more complexity can be entertained in another order of magnitude less code.<p>Don&#x27;t get stuck on the specific number, that&#x27;s incredibly pedantic and unhelpful. It&#x27;s about the degree and magnitude.