Code Innovator is dedicated to innovating how code is written.


For quite some time I have had this nagging feeling that the way we currently write code is woefully inefficient.  I feel this sense of vision and calling that compels me to say “There is a better way”.  At the time of this writing I only have a few scattered ideas and vague concepts of what we can do better.  But, part of me just knows there is a better way.  It’s almost clairvoyant in nature.  It’s like it’s on the tip of my tongue and I’m struggling to communicate it.  I can’t describe it.  This site will document what I am able to communicate at the moment and my odyssey to further manifest this vision.

By researching and studying other programming languages I will learn new programming idioms that will change the way I program and teach me to better use the languages I already know.  When a writer expands their vocabulary they are able to express their thoughts more eloquently.  They are able to use less words to communicate the same idea and they are familiar with more concepts.  It is my hope that increasing my “vocabulary” of programming idioms will allow me to design a better language.

Unanswered Questions

Programming languages haven’t really changed in the last 30 years.  It seemed like in the beginning, when people first started writing software, there were all kinds of innovations.  What happened?  Why has it almost completely stopped?

Why is it that we can explain to a programmer exactly what we want in a few minutes and yet it will take that same programmer hours, if not days, to write it?  Sometimes it is because computers are just not capable of understanding what we want.  Other times the computer may lack the neccesary domain knowledge to solve the problem.  Frequently though, this is not the case, or at least it doesn’t need to be the case.  Often, it is because there is an insufficient level of abstraction.  Closing the gap between intention and implementation will be one of the main topics of focus.

The Plan

I intend to take a structured approach to solving this problem.

  • define the problem / pain
  • define the possible goals
  • research other languages and development methodologies to discover the general characteristics of their strengths and weaknesses
  • implement ideas
  • experiment and test the ideas with real world applications
  • report
  • refine / repeat process

I will cover this in another post.

About the Author


My name is Brennan Cheung and I have been programming for a little over 20 years.  I started programming computers at the age of 7 on the Commodore 64.  My primary interest at that time was to learn how to write video games.  I started off with Basic and them assembly on the C64.  Later I moved onto the IBM PC, C, x86 assembly, Java, and then a whole bunch of other languages after that.

I started off with video game programming, then in high school I started to gain interest in operating systems.  Right now the bulk of my programming is web based programming to one degree or another.  Improving this area is my primary intent.

I am currently employed full time as a programmer.  I enjoy spending my free time learning about compilers and different languages.  I also enjoy glamour photography and have had my work published in various magazines, web sites, and calendars.