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