Jul 24, 2014

Does the world want or need a new programming language?


I recently reviewed notes going back to 2002 on the design of a programming language I've been calling Stonewolf. I have started to implement the language at least 4 times and have redesigned it at least a dozen times since then. Why do I continuously throw it away and start over? The main reason is that I have never convinced myself that my reasons for wanting it were suffieciently strong to be worth the effort of a project that could well take me the rest of my life.

My original reason for wanting a new programming language was the huge amount of pure crap you have to code to get anything done these days. The last commercial project I worked on was not that complex. The formal design document was only a dozen pages long. But, I can describe it in a paragraph. I had a bunch of original images stored as blobs in a database along with an image policy for various mobile devices. The job was to created versions of the images tailored for each mobile device. But, to do it on the fly and to cache all the new versions of the images. If originals were deleted the system was supposed to delete the cached reformatted images.

Not too complex, right? The job was done in Java using the Java imaging API and the Java database API. What took most of the time? Writing code to read and write the image files and converting to and from the format supported by the various APIs. Read the data in one format, convert it to another format, push it through the API, convert it to another format, write it out. Lots of work that had to be done because the different APIs were not compatible. Days spent writing code that just shuffled data from one structure to another structure... what a waste of time.

Most of the projects I've done lately are like that, pick the APIs, and spend all the project time writing code to duct tape them together in to something that resembles an application. What a waste of time.

Another example is some code I wrote developing a solution to the so called “nearest neighbor” problem. It is a hard problem but I came up with a pretty good solution. I developed it in C++. As I worked I realized I was spending more time working through C++'s extraordinarily complex type declarations than I spent working on the problem. The types I wanted were there, but to use them I had to write these obscenely complex type declarations. Of course, I was developing the thing as a template so I could adapt it to store multiple types of objects. That made it even worse. Testing templates is not easy. I thought I had written a complete test suite. Not so, first time I tried to use the template in a program I found that a whole section of the code had never even been compiled, and in fact, did not compile. Did not, because it could not. The code had never even been parsed.

Why does it have to be so hard? If I had never used a system that wasn't so absurdly complex I might just accept it as normal and move on. But, as a young programmer I learned LISP. Back in the early '70s I had pretty much every feature of C++ but without the complexity. By the early '80s when Standard Lisp came along you had everything C++ has now, but without the complexity.

(Lisp only has a couple of problems, first off nobody likes the parenthesis, and it is named “Lisp”. Very few managers have the balls needed to go before their management and say they are going to use “lisp” for a mission critical system. Three of the greatest languages in history, Lisp, Scheme, and Smalltalk, were all killed by their names. After all, what “Real Man, He Man, Programmer” wants to go to a party and say they Lisp, Scheme, or Smalltalk all day?)

My number one open source project for many years was SDL. A great project. But, what is it? A cross platform pile of duct tape that attempts to provide a consistent, integrated, API using many different libraries on different platforms that all do the same thing in different ways. The reason I first got involved with SDL was because I was looking for a portability platform for Stonewolf. By the way, SDL is an excellent pile of duct tape. It saves the programmer an enormous amount of time. But, it is still duct tape being used to cover over the absurd complexity that has been created in the form of languages, libraries, and operating systems.

Every time I started to work on Stonewolf I ran into questions that I could not answer. That is a good thing really. It made me do a lot of research. Just Unicode cost me months of reading and studying. Ever thought about the problem of defining “<” on strings with three cases and two ways to represent every letter that has a modifier?

So, finally I just started collecting reasons why I wanted a new programming langugue. I have quite a pile and it keeps growing. Each reason could be the subject of a very long article. Here they are, in no particular order, and certainly not finished yet.

I want a language that:
  1. Understands that Moore's law is an unstoppable force. Every 20 years Moore's law lets me buy 1024 times as much hardware for fewer dollars.
  2. Understands that my life span is more valuable than computer machine cycles. It has to get rid of all the dumb ass time wasters built into so many programming languages.
  3. Understands that multi core and 64 bits is the norm, not the exception. Every year the number of cores is going to increase.
  4. Understands that there is such a thing as a network and is happy to work with it.
  5. Does NOT try to make every I/O device look like a stream. Most things that are treated as streams are really random access devices. The rest are better thought of as message/event devices.
  6. Is more like a Swiss army knife and less like duct tape. The way to add new “libraries” is to integrate them into the language, not just provide a thin layer that exposes the API worts and all. It should be like SDL. If it has to provide duct tape, it should provide excellent duct tape.
  7. Cleans up the conflation of concepts that are built into most programming languages. For example: Variables have values. Values have types. Variables do not have types so why do we treat them like they do?
  8. Supports language extension through generic programming and an extensible set of operators without an abomination like C++ templates or the need for C++ style operator declarations. (I have some ideas... but this is a tough problem.)
  9. Is very easy to read. There can be no ambiguity about where a control structure ends, or begins for that matter. Likewise the syntax should make it easier for the language implementation to identify semantic errors. How many days of your life have been wasted looking for the place where you typed “=” instead of “==”? How much life span has been wasted looking for typos like the misplaced semicolon in “if(x < 0);”? C like syntax is full of gotchas like that one.
  10. Has a rich set of control structures. Why can't I do an SQL like select on an object container and get back a vector of objects that meet my criteria? Why aren't threads built into all programming languages? At the runtime library level?
  11. Supports more than one human language. I am not talking about locales and Unicode, I am talking about supporting multiple human languages at the source code level. Maybe the hardest problem on the list.

Oh, by the way, I also want a great IDE for the language and there should be versions for every kind of machine there is and every operating system and even for embedded systems with no OS. And, yes, I want an egg in my beer...

I'm sure to come back to this and add more “wants” to the list. But, for now this is enough to keep me busy for a very long time.

The fact is that large numbers of people have been programming since the 1950s. And yet, most of the languages we are using perpetuate mistakes that first appeared the 1950s and 1960s. Now days it is common to find people with 40+ years of programming experience. Dennis Ritchie was only 28 or 29 when he started developing C and in is early 30s when the first version was called “complete”. (If you ever programmed in K&R C you know it was no where near complete.) Brain Kernigan was a few months younger that Ritchie. As brilliant as they are they had not lived long enough to acquire the mature understanding of the practice of programming that someone with 40+ years of experience has. They most certainly did not have an understanding of 21st century computing environments. (It may seem that I am picking on C, but I use C for my examples because so many people know it and so many languages perpetuate the mistakes of C. And, it is one of my favorite languages!)

Why do we still use languages that do not reflect the environment or experience of modern programmers?

Can I solve all these problems? I doubt it, but I can try and in trying I can at least hope to get people thinking about solutions. The group is often smarter than the individual. But, is it even worth trying? Does anyone but me care about these problems?