3 ms·

I agree that literate programming chunks can be very leaky abstractions, and it's a good point that LP systems provide no guarantees whatsoever about interfaces

I agree that literate programming chunks can be very leaky abstractions, and it's a good point that LP systems provide no guarantees whatsoever about interfaces. But for precisely that reason, LP chunking sometimes is useful in situations where procedural abstraction is limited: In algorithms where the various sections are connected with very wide interfaces. If all you have are procedures, you either pass around a big struct, or an enormous number of procedure arguments. In object oriented programming, the big struct is implicit in the self/this pointer. LP gives another alternative.

svat 8y ago
Right, I agree; that was exactly my point too. :-) Maybe I worded it poorly initially: The original post was about the cost of "heavy" abstractions (functions), instead of something lightweight like comments and naming. (In searching for "the cost of abstraction", I just now found another post by the author: http://250bpm.com/blog:86 http://250bpm.com/blog:86) I agreed with this, and gave literate programming and the programs of DEK as an example (an alternative to “formal” abstraction): a prominent programmer finding ways to achieve things with only chunking/“lightweight abstraction”. (BTW, the programs I mentioned also eschew other sorts of abstractions like abstract data types, e.g. all memory is laid out in huge arrays and manually managed — it seems to work for him. But that may have been a constraint of the language for all I know.)