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.
Aš matau problemą kaip bendrumo trūkumą. Sutinku, kad spausdinimas yra geras būdas. Aš kuriu būdą, kaip spausdinimą naudoti kaip funkcijų sudėties infrastruktūrą, kaip sukurti nuoseklias logines sistemas, kuriose pakartotinai naudojami kiti tipai. Tarp sudėtinių spausdinimo sistemų yra daug natūralaus bendrumo. Jie gali būti lengvai išversti iš vieno į kitą. Kol yra įvairių tipų struktūros, jas galima sudaryti sinergetiniu būdu. Taigi, manau, kad spausdinimas yra puikus būdas. Man rašymas yra pirmas dalykas, kuris atsitinka bet kuriame projekte. Tai sukuria daugkartinio naudojimo sprendimus, o ne greitą sprendimą, paprastai skirtą apatiniam doleriui. Tipai padeda įterpti daugybę funkcijų, būdingų jų vaizduojamoms nuotraukoms. Jie taip pat yra deklaratyvūs, todėl kodas yra geriau struktūruotas ir lengviau skaitomas
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