CodeGuru content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The term nano means very small. For example, a nanometer is one billionth of a meter and a nanosecond is a billionth of a second. The term reasonably applies to code because code runs digitally—almost ephemeral appearances of electrons, which themselves are each at least as small as a nanometer. In fact, we soon should have autonomous, nano code generators: code generators that automatically write additional code based on patterns of use, operator behavior, changing environmental dynamics, or really, any reason their programmers desire. A nano code generator is a very small bit of code that generates a fragment, the smallest useful bit of code.
Code generation already is in wide use today. A code generator simply is metacode that generates executable code. You can write code generators quickly and easily because of research in refactoring and patterns, and languages such as C# and VB.NET that support parametric template classes, reflection, and CodeDOM code generators. Millions of programmers use this technology every day. For example, if you have ever used Microsoft .NET’s XML Schema Designer, you have used a code generator. In fact, simple code generators have existed for a couple of decades.
So why no autonomous nano code generators yet? Despite the many tools for generating code, a few unmet technical requirements prevent these generators from working autonomously. This article describes where nano code generators are today, discusses some of their likely benefits and hurdles, and explains how such an evolution may impact the day-to-day lives of computer users and programmers.
How Would Autonomous Nano Code Generators Work?
A nano code generator generates a small fragment of code. For example, you might have a single generator that simply generates a conditional test. An autonomous, nano code generator would contain both the metacode for generating the desired output and the logic for deciding whether the code should be generated. Nano code generators could write small, whole fragments based on simple logical conditions: If A then B, where the predicate condition A must exist before the code B is emitted.
Then, in successively larger and more complex aggregate relationships, molecular assemblers could be designed. These assemblers could collaborate as temporal, cohesive smart mobs to solve algorithmic problems or be composited further to solve problems of increasing complexity and scale. For this to work, generators would have to be created from generatively larger and more complex rules of collaboration and orchestration.
Understanding Generative Code
Software can be grown organically and generatively. Generatively grown code is code that increases in capability and scope as programmers add to it over time. For a practical line programmer, this might be as simple as building critical sub-systems first and then adding additional sub-systems over time.
In this concept, patterns and refactoring technologies are used to ensure that code reaching an arbitrary complexity of n is continually capable of growing in scope and complexity. Patterns are sound solutions that have been demonstrated to resolve classes of problems, and refactoring is a predictable means of changing and improving code.
A few additional technologies help greatly in generative code too:
- Parametric templates (or Generics in .NET)
- Code generators
- Components
- Aspects (most recently)
Parametric Templates
Generics are whole algorithmic solutions that are known to work. Simply fill in the data type and the code works every time, reliably.
Code Generators
Code generators write code automatically but at present are initiated manually. If the generator is correct, the generated code is always correct.
Components
Components are sub-systems big and small, which have been around for a couple of decades. The biggest obstacle to components is that too many companies suffer from the not-invented-here (NIH) syndrome. These companies are easily identifiable because their developers and managers march around saying, “We don’t use third-party code.”
Almost every aspect of modern life is invented by a third party, yet many developers would prefer to roll their own. This is an understandable byproduct of a keen intellect and is understandable from the programmer’s point of view, but it is definitely not in the self-interest of companies.
Aspects
Aspect-oriented programming (AOP) has to do with the separation of responsibilities in distinct, non-overlapping entities. AOP addresses modularization and the encapsulation of cross-cutting concerns; dividing and orchestrating solutions is critical to managing generationally grown code.
Code Generators Are the Tools
Generative code is not generated code, but code generators are its tools because they can generate code reliably and quickly every time. As most manufacturers know, time to market and reliability are huge factors for any successful endeavor, and they are hugely missing in our industry.
At this time in history, we are just beginning to depend on code generators. Most code is generated at design time. However, it is already possible to invoke code generators dynamically at runtime and load and execute them post-deployment. A functional example is the beta tool CodeDominator that my firm offers. While the tool is imperfect, it contains a huge library of atomic-, molecular-, and component-level generators, and it is capable of creating working—albeit generic—applications.
