Coming Soon Logo



The 21st century is upon us and we have largely failed at creating a complete methodology whereby collaborative software development efforts achieve the types of productivity that a lone effort, or a very small team effort can achieve. This is not to say that all teams have failed to achieve productivity, but that assembling a team that will be productive is hit-or-miss. The reason is that productivity is not implicitly designed into the development platform. What I mean by this is that we have inherent problems both in infrastructure and in language (some more so than others).

On the infrastructure side, the success of HTTP and other stateless protocols, combined with server-side processing has severely damaged productivity. The success of this combination has created a huge divide between business applications and traditional client-side applications. Below is just a small enumeration of the problems encountered using the stateless/server-side combination;

  1. Putting things in the "session" is equivalent to having everything in global variables. We are essentially back to procedural programming (if not worse, because we don't have compilers to catch our mistakes). Thus the time-to-develop the application is substantially longer than that of a traditional client-based application. Developers often under estimate the loss of productivity due to this hindrance and are stuck scrambling to complete projects on time.
  2. The resultant code, while somewhat better using technologies such as ASP.Net, is essentially throw-away code. Its code that is difficult to debug, maintain, and enhance.
  3. The final application has a feature-poor user interface. As yourself, "why it is that computers are far more powerful today than they were ten years ago, yet the interfaces we use are inferior to those that we used in 1994?"
  4. We have separate modes of development and delivery; one for browser-based application and one for traditional applications. This divide is going to continue to grow until we solve the glaring problem. If we don't do it, a private company will. We will not be satisfied with the cost and/or portability of that solution (.Net, Flash, etc).
  5. Use of HTTP for non-sensitive information and HTTPS for sensitive information allows identity thieves to readily discern which messages contain sensitive information (Those that are using HTTPS). All communication, regardless of it sensitivity, should be transmitted encoded.

You may be asking, why not X<add technology here>? There are many different flavors of XML based architectures from groups such as Mozilla and Microsoft. The problem with XML based architectures is that the languages which derive from it are not optimally human readable in all circumstances. XML's flexibility allows it to be used to represent just about ANY type of information. But this does not mean that it is the most productive format to use in every situation. I would argue that there are far more productive, human readable formats for creating user interfaces.

Another reason why our collaborations often fail to achieve productivity is the languages themselves. There are a number of bottlenecks in modern languages that serve to confuse the readers of that code. Languages which are easy to write but difficult to read, such as Perl, are the antithesis of collaborative productivity. Languages such as Java and C# come a long way in bringing readability to source code, but fall short in a number of ways;

  1. The basic structure of C-language derivatives is not conducive to legibility. For example; the multiple indention standards, the difficulty of passing back multiple and dissimilar values in a concise manor, the forced separation of code and comment (javadoc and xmldoc are a step in the right direction, but fail to achieve their goal by requiring additional work to make them useful), the squiggly bracket notation ( { } ) thats supposed to save time compared to typing out keywords such as END. What we've failed to consider in the squiggly bracket paradigm is the effort it takes to make sure our code is properly indented and aligned. Even then it does very little to help readability once the code has exceeded one page's height.
  2. As we've moved up the structural-chain from the simple constructs of C, to the large-scale constructs of object oriented languages, we've neglected to maintain contextual information beyond the initial declarations. What I mean is that C constructs are small and do not require additional contextual information. But object oriented constructs are weaved into the architecture of an application. This leaves the reader of a given method wondering the context of a particular object, such as; Is this a method variable, or a class variable? The reader must search the method, then the class to find out. Is this class variable public, protected, or private? Again, we need to go looking in the code or else the class browser. Is it a static or instance variable or method? Having the context of a property or method readily available will make code much more legible.

I would like to continue with my thoughts on why our language has become a hinderance, but its clear to me after writing these two points, that I cannot make it fully clear what the solutions and the benefits of these solutions are without having a concrete example. We're all coders here, so its all just pie-in-the-sky until I start spitting out some real example's of the "old" way and the proposed way. I have it all in my head right now, so my intent is to begin implementing this new language and thinking through the potential pitfalls. When I get to the point of showing code, I will have a feasible, cross-platform basis for solving all of the aforementioned problems and many more.

We in the Computer Science industry have a real problem. If we don't solve it, someone will. We may not like who solves it or how they solve it. We need to work it out now while it's still in our hands. Your thoughts and comments are welcome.

Oh yeah, and what does SCRAPIE stand for? Source Code Reuse, Abstraction, Polymorphism, Inheritance, and Encapsulation. We have reuse at the class and/or method level, but not at the source code level. This is the language issue I want to solve, and will serve as the basis for a growing architecture that ultimately solves the infrastructure problems listed above.