Code complexity and poor interoperability
Addition, calculation, algorithms takes an incredibly small portion of actual code. Most code is unnecessarily there to satisfy the compiler with interoperability of methods, arranging data structures and configuration
–
Most code is not computation but a struggle to arrange code so it can be understood and be interoperable between pieces of code by the compiler. Classes, methods, types all obscure the actual algorithm or computation (such as addition) used by a piece of software.
If you were to distill most software down, there would be very little actual computation - comparisons and additions. Yet the code to produce this small amount of computation is a spider web of classes, interfaces, data structures etc.
Most code is spent arranging data structures or API calls for method calls to be right.
In fact none of this syntactic sugar is represented in the output instruction stream! It's purely imaginary concepts used by the compiler to make code organisation easier.
This job is not something humans should be doing. It's something a compiler can do.
What if I said that code didn't have to be written this way?
What if structures could be auto mapped at run time?
That is, I have a data structure and there are fields that could have slightly different names - firstName and first_name are the same thing.
Data structure nesting is another problem. Some people might pull fields into a substructure rather than in the root.
Another problem is layering of code.
If I have a simple data structure such as a btree. But I have concerns such as security, locking, caching/paging and other problems that a serious b tree needs. These concerns will mess up the reference implementation by polluting it with concerns that are not related to btrees. We need some way to layer code in a simple way.
The Ruby class extension approach feels wrong. Subclassing is over complicated and feels wrong. I think this is an example of the expression problem.
http://wiki.c2.com/?ExpressionProblem
This category is to provide solutions to the complexity of modern code bases and poor inter operability problem.
I think types are a good idea but in practice they are never used! Nobody uses the same types! People dont share types online! You're only using the same types if you use a library.
I'm saying much of the boiler plate is unnecessary.
我认为问题是缺乏共性。我同意打字是一个好方法。我正在研究一种使用类型作为功能组合基础设施的方法，一种创建重用其他类型的一致逻辑系统的方法。 可组合的类型系统之间有很多自然的共性。它们可以很容易地从一种翻译到另一种。只要结构类型可用，它们就可以以协同方式组合。所以，我相信打字是必经之路。对我来说，打字是任何项目中发生的第一件事。它创建了可重复使用的解决方案，而不是快速修复，通常是为了解决底线问题。 类型有助于封装它们所代表的快照所共有的许多功能。它们也是声明性的，使代码结构更好，可读性更强
I see problem as lack of commonality. I agree that typing is a good way to go. I'm working on the a way to use typing as the infrastructure of composition of functionalities, a way to create consistent logic systems reusing other types. There's a lot of natural commonality between composable typing systems. They can be easily translated from one to another. As long as type of structures are available, they can be composed in a synergetic way. So, I believe typing is way to go. To me, typing is the first thing that happens in any project. It creates reusable solutions, rather then a quick fix, usually to address the bottomline dollar. Types are helpful in encapsulating a lot of functionality common to the snapshots they represent. They are also declarative, making code better structured and more readable