November 26, 2014
Hot Topics:

Coming Soon: Autonomous Nano Code Generators

  • August 29, 2005
  • By Paul Kimmel
  • Send Email »
  • More Articles »

Surmounting Hurdles

At present, code generators have practical limitations. They lack the following technical requirements:
  • Positional assembly — The ability to put code where we want after it has been written and compiled
  • Massive parallelism — The ability to work together to solve bigger problems
  • Convergent assembly — Little assemblers writing little pieces of code and increasingly bigger and more complex assemblers assembling successfully more complex code

Positional Assembly

Because reflection attaches code generators into existing applications at large, granular intersections, the code is not fully integrated and may not be “integratable” after deployment. A better solution would be a trusted generator injecting code precisely where needed. Such an injection could occur at the fragment, statement, algorithm, class, namespace, or assembly level, intertwined or attached to existing code. This is the concept of positional assembly.

Suppose that over a period of time an application keeps raising an exception that is unhandled and crashing as a result. This predicament highlights the need for positional assembly. Theoretically, an autonomously generated try..catch block could be wrapped around the crashing block of code and at a minimum the exception could be written to the event log. Better yet, the problem could be diagnosed at an earlier juncture to prevent the crash-inducing bad input.

To support positional assembly, software language vendors would need to implement what I refer to as sleeves. Sleeves are wrappers that permit the positional placement of dynamically generated code. At present, code is four-dimensional. Code is comprised of lines, modules, assemblies, and execution over time. Sleeves are fifth-dimensional entities in a space wrapped around four-dimensional code, and they are permitted to interact at any of the five dimensional points, including across sleeve boundaries.
Note: An alternate way to think of code is in terms of four states: creation, execution instance, execution overtime, and rest. Think of a sleeve as a fifth dynamic state that can interact with code during any of its other states, including inter-sleeve communications.
Current implementations such as .NET support the isolation of applications by application domain in order to prevent contamination. Sleeves would act like layers around application domains and play the role of boundary entities that can interact at any point in an application domain by injecting generated code and across application domains in order to work in parallel and convergently. Obviously, this capability would be greatly dependent on trust and reliability.

Positional assembly also would rely on programming languages and generators supporting the two other concepts as well, massive parallelism and convergent assembly (which were identified by Dr. Ralph Merkle).

Massive Parallelism

Massive parallelism is many autonomous nano code generators working together, perhaps like Howard Rheingold’s Smart Mobs. Parallelism is presently supported in hardware and software, but it hasn’t been applied to code generation.

Like a colony of ants, code generators would assemble for a period of time to accomplish a common goal, with each code generator performing a very simple task.

Convergent Assembly

All of these small code generators would need to converge and work in orchestrated groups to make small bits of generated code into bigger bits. For small, algorithm-sized problems, a few dozen or maybe as many as a few hundred generators would converge and piece together a solution. As the problem increased in complexity and scale, nano generators would assemble small pieces of code, and molecular—or larger—generators would converge to convert the small fragments of code into increasingly larger chunks of the solution. In this way, fragments, algorithms, classes, components, aspects, sub-systems, and possibly whole systems could be generated autonomously.

Getting There from Here Without Stumbling

Implications, both good and bad, will need to be weighed as this technology matures. Let’s take a moment to consider some of these.

Benefits of Generators

Several benefits of code generators come to mind. An obvious one is that when metacode is correct all subsequently generated code will be correct. For example, if you write a code generator for managing threads in WinForms, then every generated use instance will work correctly. This means that even if a developer hasn’t mastered the nuances of Invoke and delegates, he or she can still use multithreaded behaviors. Further, a nano code generator could discover an optimization point and inject the threaded behavior correctly itself.

Some areas are ready to explore code generators right now. Of course, software development would benefit from the availability of more code generators because this would enhance reliability factors. We programmers could also define plug-in points that look like assemblies, permitting us to dynamically add assemblies later. This is how internationalization works. (Internationalization keys off country codes. If a country code changes, the .NET Framework looks for a specific resource assembly.)

Implications of Automated Code Generators

In the face of automated code generators, programmers might worry about their financial future. Don’t worry. For the foreseeable future, software will continue to grow in complexity, and code generators more than likely only will alleviate tedium because the easy tasks will be automatable. A bigger concern is how we cope in a world with software with diverging behaviors.

The end result may be many more support people for all of these slightly different variations, as well as developers searching for unique evolutions. Perhaps even a whole cottage industry will crop up where programmers are paid to test and distribute new evolutions. In addition, someone will have to write all of these generators, and the ratio between metacode and generated code is about 10-to-1. (That is, it takes about ten lines of code-generating code to generate one line of code.) This might mean that we will need even more developers than ever to write all of these generators.

Many problems remain to be solved, including diverging evolutions, and security and trust between code generators and applications. The technology isn’t quite there yet. But in this world, software could grow in capability, value, and complexity at geometric rates, resulting in some very valuable and interesting derivatives.

Science Fiction Becomes Fact

Like pieces of a puzzle, the technologies and pragmatic problems involved in designing autonomous nano code generators are slowly taking shape. I think it was Stephen Hawking who said, “Yesterday’s science fiction is today’s science fact.”

We already have the science fiction in Michael Crichton’s novel Prey, in which he captures an interesting and perverse scenario based on nanotechnology and intelligent nanomachines, and we have most of the science facts in refactoring, patterns, generics, reflection, code generators, and parallel computing. For science fiction to become science fact, we need the capability to generate code wherever it is needed—we need autonomous code generators. Alan Turing demonstrated that complex machines could be created through lengthy binary decision making, and I don’t see any reason why simple binary rules couldn’t be used to support autonomy.

Collectively, this means that science fact is hinging on positional assembly capabilities in languages like C# and the ingenuity of programmers like you and I.

About the Author

Paul Kimmel has written several books on object-oriented programming and .NET. Look for his upcoming books UML DeMystified from McGraw-Hill/Osborne (Spring 2005) and Expert One-on-One Visual Studio 2005 from Wiley (Fall 2005). Paul is also the founder and chief architect for Software Conceptions, Inc, founded 1990. He is available to help design and build software worldwide. You may contact him for consulting opportunities or technology questions at pkimmel@softconcepts.com.

If you are interested in joining or sponsoring a .NET Users Group, check out www.glugnet.org.

Copyright © 2005 by Paul Kimmel. All Rights Reserved.



Page 2 of 2



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Rocket Fuel