3 ms·

I still stand by this: simplicity is a function on familiarity more than anything else. Twenty lines of procedural go code isn’t simpler than a one-liner of Cl

I still stand by this: simplicity is a function on familiarity more than anything else. Twenty lines of procedural go code isn’t simpler than a one-liner of Closure. It might be, to some people.

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.
Cthulhu_ 5y ago
It depends on how much knowledge you need to read each line. The other factor is how much work the code does. When it comes to Clojure or any kind of functional language or construct, those describe the "what"; what is the author trying to do, what should the code do. If you go for imperative code, it quickly becomes more about the "how". Loops are a great example; in functional languages and constructs, you say "filter, then map, then reduce". In an iterative language, you say "Create a variable I, then start a loop, check if it's below length of list, increment, get element I from list X", etc, you get the idea. The functional approach has a definite advantage here because - as long as you understand the language and constructs - it hides the implementation details and the exact approach to execution. A functional approach under water can transparently parallelize the request, even going as far as it becoming a distributed hadoop map/reduce job. Can't do that with a for loop. Anyway, I forgot where I was going with this. The 20 lines can be fine if the one-liner is complicated.

I still stand by this: simplicity is a function on familiarity more than anything else. Twenty lines of procedural go code isn’t simpler than a one-liner of Closure. It might be, to some people.

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.

Cthulhu_ 5y ago

It depends on how much knowledge you need to read each line. The other factor is how much work the code does. When it comes to Clojure or any kind of functional language or construct, those describe the "what"; what is the author trying to do, what should the code do. If you go for imperative code, it quickly becomes more about the "how". Loops are a great example; in functional languages and constructs, you say "filter, then map, then reduce". In an iterative language, you say "Create a variable I, then start a loop, check if it's below length of list, increment, get element I from list X", etc, you get the idea. The functional approach has a definite advantage here because - as long as you understand the language and constructs - it hides the implementation details and the exact approach to execution. A functional approach under water can transparently parallelize the request, even going as far as it becoming a distributed hadoop map/reduce job. Can't do that with a for loop. Anyway, I forgot where I was going with this. The 20 lines can be fine if the one-liner is complicated.