Call for a Programming Language

Written By John Sonmez

Why do we need yet another programming language?

One thing I have noticed lately is the increase in the number of frameworks that have sprung up in the .NET and Java ecosystems.  I often tell people I spend the first hour of my day every day just reading blogs and development news to catch up and stay up-to-date on what is going on, and even then I am still falling behind.  It seems like everyone I know is creating their own dependency injection framework.

As a community, I think in general most good C# and Java developers have embraced dependency injection as a whole.  So why do we need so many implementations of the concept?  It is very confusing to say the least.

Why not have dependency injection built into the programming language? Let's make it a first class citizen, just like object orientation is in Java and C#.

While we are at it, let's look at some of the other major failings of modern statically typed languages.

  • Logging: Do we really need to import logging into a framework and put logging code all over our nice clean code, making it harder to read?  There must be a better solution.  (I know about Aspect Oriented Programming, but that is kind of complex, and doesn't always give you what you need.)
  • Exception Handling: try… catch is crap.  It is complete crap.  There has to be a better way.  Try catch blocks pollute your code, make it hard to read, and break the rules of separation of concerns.
  • Concrete Inheritance:  This is bad, it leads to bad design and it needs to be done away with.  Do we really need public, private, protected?  Can't we get away with visible or hidden?  Isn't that really what we are trying to say from a true OO perspective?
  • Threading:  This is a complete mess right now in C# and Java, there is no really good way to write parallelized algorithms and to take advantage of multi-core systems.  Concurrency is a nightmare.  Can't we build a language smart enough to deal with this?

Now I know some of these things are being tackled by new languages designed to tackle these problems individually, and others of these problem are solved by annotations or aspect injection, but I'm not interested in that.  I am interested in solving these problems all together in one simple language.  I think the craft of software engineering has evolved enough where we need a new statically typed language that advances us up to one more higher level of abstraction.

A very rough crack at it

Here is the kind of thing I am thinking of:

I'll call this language Tea#

Here are some of the notable things in Tea#

  1. Classes provide an interface using the provide keyword.  Methods for that interface provide using the provide keyword, a method could use the same method to provide more than one interface implementation.  Potentially you could remap the names of methods, like an adapter pattern, if they share the signature.
  2. Classes use interfaces which are automatically resolved to the default implementation of that class and there is no need for declaring instance variables.  You can use the uses keyword to give a class access to providers.
  3. Instead of public, private, protected there is just hidden and visible.  Here I am making the data hiding explicit.  You are either hiding it or not.  It can apply to methods and state.
  4. Logging is built in through the logX keywords.
  5. Instead of try catch blocks, any method can have an on error ____ attached to the end to give instructions of what to do on an error (or exception).
  6. If statements are not allowed to have blocks, there must exactly be one statement after the if condition.  If you have to have multiple statements, you encapsulate that logic in a method.  (I am not 100% sure this works for all situations yet.)  The basic idea here is that it enforces cohesion in the class by forcing methods to do only one thing and enforces smaller classes, since there will be a need for sharing state variables.

Disclaimer: I don't have all the answers, I don't pretend to.  Tea# is just an example of some syntax and ways that the kind of things I am suggesting could work.

With that said, I think the benefits of a language like Tea# are numerous.  We have reached the point in software development where many of the best practices that most software developers are practicing is done outside of the language.  I can see a parallel here to trying to doing object oriented development in C.  Because the language is not built to support it, it requires outside knowledge, techniques and framework to make it work.  It is a huge learning curve.  Folding these best practices into a language where they are actually enforced is similar to the creation of object oriented languages to enforce OO concepts.