New Model Needed for Program Development

The preceding series of blogs have addressed both the physical limitations of the human brain and the limitations of programming languages when developing computer programs.

Finally, it is time to list some of the characteristics that a new model for computer program development should attempt to embrace. Future development models should address as many of the following elements as possible:

  • Not be exclusively language based
  • Not be English language based
  • Move our focus from language details to overview/conceptual level
  • Allow better reuse of the program chunks that others have developed
  • Engage the visual processing capabilities of the brain
  • Include elements of the physical/natural world to simplify and improve our ability to visualize what is happening in the program
  • Intrinsically support parallel behaviors so thinking about parallel behavior in the model automatically translates into thinking about parallel operations in the program
  • Limit human exposure to explicitly managing parallel details (locks, mutexes, etc)

Notice that none of these items address maximizing parallel program performance or any of the other performance side-tracks that we could get derailed on. Avian Computing is exclusively addressing the efficiency of the human-program development interface. The goal of this list is to reduce the time it takes to develop a high-quality parallel program.

Yes, it is always nice to reduce a 100-second job down to 10 seconds, but if it takes 3 months to develop, test, correct, and deliver that 90-seconds saving, then it’s a false savings. After all, the next generation of hardware will probably achieve that time savings. If not, throw another 100 CPU cores at the task – that should speed it up.

By the way, ConcX implements the last six items in the above list with the specific intention of providing a workspace to explore using multiple threads to achieve a parallel program solution. Its GUI design allows each thread to be pre-configured and then its progress monitored while executing, as well as its runtime behavior saved for analysis after each run. These features allow developers to experiment with different thread settings to identify bottlenecks and performance-critical processes.

Leave a Reply

Your email address will not be published. Required fields are marked *