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