21–30 of 87 posts
This talks about code complexity a lot. This, however, is not the chief source of complexity in many code bases. The number of tools needed to build things is the bane of the modern software developer. Also, the use of microservices where none are needed results in and enormous increase in complexity. Code complexity is relatively easy to fix compared to all of this.
Number of lines of code is a good metric for complexity. The hard part is estimating how many lines of code is reasonable for a specific feature. Some complexity is necessary. The problem is unnecessary complexity.
I don't agree with that premise. LOC are a metric for code size, not for complexity. I've found that in practice the number of statements is a more reliable indicator for code size than lines of code. (For typical imperative languages anyways.)
Number of lines of code is a good metric for complexity. The hard part is estimating how many lines of code is reasonable for a specific feature. Some complexity is necessary. The problem is unnecessary complexity.
> Number of lines of code is a good metric for complexity. I don't agree with that premise. LOC are a metric for code size, not for complexity. I've found that in practice the number of statements is a more reliable indicator for code size than lines of code. (For typical imperative languages anyways.)
### Mathematical prototype
- Its mathematical prototype is the simple, classic, vivid, and widely used in social production practice, elementary school mathematics "water input/output of the pool".
### Basic quality control
- The code must meet the following three basic quality requirements before you can talk about other things. These simple and reliable evaluation criteria are enough to eliminate most unqualified codes.
- Function evaluation: Just look at the shape of the code (pipeline structure weight), and whether the function is a pure function.
- Functional pipelined dataflow evaluation: A data flow has at most two functions with side effects and only at the beginning and the end.
- System evaluation: Just look at the circuit diagram, you can treat the function as a black box like an electronic component.
- Code Quality Visualization:
- For Lisp languages, S expression is contour graph, can be very simple transformation into contour map, or 3D mountain map.
- If the height of the mountains is not high, and the altitude value is similar, it means that the quality of the code is good.
- For non-Lisp languages, you can convert the source code into an abstract syntax tree (AST), and then into a contour map, or a 3D mountain map.
Simplicity, Unity, order, symmetry and definiteness.
---- Lin Pengcheng, Programming aesthetics
The chief forms of beauty are order and symmetry and definiteness,
which the mathematical sciences demonstrate in a special degree.
---- Aristotle, "Metaphysica"
The aesthetics of non-art subjects are often complicated and mysterious, making it difficult to understand and learn.
The pure function pipeline data flow provides a simple, clear, scientific and operable demonstration.
Simplicity and Unity are the two guiding principles of scientific research and industrial production.
- Unification of theories is the long-standing goal of the natural sciences; and modern physics offers a spectacular paradigm of its achievement. It can be found from the knowledge of various disciplines: the more universally applicable a unified theory, the simpler it is, and the more basic it is, the greater it is.
- The more simple and unified things, the more suitable for large-scale industrial production.
- Only simple can unity, only unity can be truly simple.
In the IT field, only two systems fully comply with these 5 programming aesthetics:
- Binary system
The biggest advantage is that it makes the calculations reach the ultimate simplicity and unity, so digital logic circuits are produced, and then the large-scale industrial production methods of computer hardware are produced.
### Others
- Software and hardware are factories that manufacture data, so they have the same "warehouse/workshop model" and management methods as the manufacturing industry.
- From the perspective of system architecture, it is a warehouse/workshop model fractal system. It abstracts every system architecture into a warehouse/workshop model .
- From the perspective of component, it is a pure function pipeline fractal system. It abstracts everything into a pipeline.
- It adheres strictly to 10 principles and 5 aesthetics, and it consists of 5 basic components.
- It uses the "operational research" method to schedule the workshop to complete tasks in optimal order and maximum efficiency.
### Reference
The Math-based Grand Unified Programming Theory: The Pure Function Pipeline Data Flow with Principle-based Warehouse/Workshop Model
https://github.com/linpengcheng/PurefunctionPipelineDataflow
Earlier quoted context omitted.
> Number of lines of code is a good metric for complexity. I don't agree with that premise. LOC are a metric for code size, not for complexity. I've found that in practice the number of statements is a more reliable indicator for code size than lines of code. (For typical imperative languages anyways.)
Lines of code is a very good approximation so long as each line is compiled into a similar number of bits across different systems and languages. The total size of the compiled source code in bits is literally the entropy of the system so it's the definition of complexity.
Earlier quoted context omitted.
Lines of code is a very good approximation so long as each line is compiled into a similar number of bits across different systems and languages. The total size of the compiled source code in bits is literally the entropy of the system so it's the definition of complexity.
I think you applying that definition in your way to the issue of source code complexity is outlandish.
The problem with using lines of code as a metric for developer productivity is precisely that it leads to developers introducing unnecessary complexity into the system since they try to add as many lines of code as possible for implementing any feature.
There is no drawback in keeping the source lines of code to the minimum amount necessary to get the job done.
There are a lot of things you can do to lower these sort of metrics without addressing actual complexity, sweeping the problem under the rug. Perhaps a better metric for software complexity would be the amount of work the computer has to do, or the number of instructions it has to execute.
I recall implementing some linear algebra numerical code. The problem was a bit complex, resulting in a bit of code complexity.
However I realized I had some extra information I hadn't used, and I spent half a day going over the math again. After a couple of pages of derivations I could narrow down the result to a couple of dot products.
So, I ended up with a commit where I had 100 or so lines of comments including equations to justify my two lines of code.
The implementation became super-simple, but why it worked was suddenly not so simple. I had effectively moved complexity from code-space to problem-space.
Number of unnecessary abstractions.
Earlier quoted context omitted.
I think you applying that definition in your way to the issue of source code complexity is outlandish.
Why is it outlandish? You're confusing the reliability of using source lines of code as a metric for measuring the productivity of developers with measuring the complexity of a system. It's a bad metric for measuring productivity but a good metric for measuring complexity. The problem with using lines of code as a metric for developer productivity is precisely that it leads to developers introducing unnecessary compl…
Ugh, no. I’ve worked in a codebase where CI would reject changes that had too much ‘code complexity’. You’d constantly have to find clever ways to split up your code, when doing so did not make sense, to appease the complexity checker. Oh yeah, and if you ever make a one-liner change, you might end up being forced to do a full refactor because that one line pushed the complexity threshold over the edge. The results:…