6 ms·
We can define the number of concepts a program uses, "Program | Concepts", and likewise, TokenSimplicity(Program | LanguageConcepts, ProblemConcepts) As
by mjburgess 5y ago
We can define the number of concepts a program uses, "Program | Concepts", and likewise,
TokenSimplicity(Program | LanguageConcepts, ProblemConcepts)
As the number of tokens an ideal programmer perfectly knowing LP-Concepts would write to produce Program for an audience also perfectly knowing LP-Concepts, employing no other concepts than those stated.
Needless complexity arises as a distance from TokenSimplicity, relative to some choice of concepts. That can arise because the programmer uses concepts outside their audiences competence, or fails to use the minimum number of tokens.
NeedlessComplexity = abs(TokenCount(Program) - TokenSimplicity(Program | Concepts, ...))
This article distinguishes (1) using surprising L-Concepts to minimize TokenSimplicity and (2) using surprising P-Concepts.
(1) is cleverness; (2) is insightfulness. And "surprising" is all about the audience having an familiarity which differs from the programmer,
Suprise(ProgrammerConcepts, AudienceConcepts) = len(Audience - Programmer)
So the objective of programming is to `min TokenSimplicity st. min Suprise`.
Where concepts are surprising, they can only rarely be used in programming, and hence drive up the number of tokens/lines written. However, where the code is getting excessive, the programmer is encouraged to surprise the audience.
The weighting of these objectives is of course team/problem/person specific. Typical webdev/bizapps perhaps extremely weights `min Suprise`, (perhaps routinely at the expense of properly understanding problem concepts).
In algorithmic R&D areas (occasionally, eg., data science) we expect the audience to have nearly full relevant ProblemConcepts.