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