Summary
I've blogged here before about how I'm a Java convert, never going back. Some recent comments by Frank Sommer about developing idioms in prgramming solutions sparked some other thoughts that I've had about this whole "Let's write a new programming language" party scene.

Frank Sommers wrote:
> I agree with Ward that a lot of what we consider great
> design is often a product of evolution, rather than
> someone sitting down and figuring everything out up-front.
...
> In lieu of a grand design, what I often find useful,
> though, are idioms.

This is exactly what I use. I have particular patterns of overall system architecture that I utilize in particular situations.

I often cast these patterns into classes at some point and provide enough augmentation via abstract interfaces to make them a general solution to a particular class or problem.

I did this with JDBC access and AWT layout very early in my use of java. Now, I always use those two classes when I write programs using those parts of Java.

This type of programming creates an application oriented language for how I architect a solution in programming constructs. It is extremely powerful. Patterns have been pressed hard over the years. What makes them difficult in practice is that everyone gets to recreate them in different languages.

As I've stated before, I've stopped switching languages. I adopted the Application Oriented Language paradigm of programming because I tired of not having the same tools everywhere. If the Java language APIs don't work the way I need, I recast them into something that is more familiar. If I am used to using the bourne shell to script a particular class of problem, and I have to do it in Java, I'll create some programming API tools to do that project and then I have them in my tool kit.

I strongly believe that this kind of programming is what will allow us to move on to faster solutions to larger or at least really different programming problems. In the end, computers can calculate numbers. We've managed to make everything look like a number, and then wrap all of our language based programming proceses around processing these numbers (but calling them somthing else). When we have finally solved all problems that need to be solved with numbers, then it will be time to invent a new base programming language.

Think about it... Every new language that is written today is written in another programming language that came before it. So, we have only recast the programming model.

Java finally closed the gap on memory management in a way that is powerful and effective (but not completely efficient, it needs a counting collector). What is left?

Many people say that they need lots of different languages, because the features of one language make them more productive in a particular environment. What I am thinking about is the whole tool verses canvas issue. If you have a nail, and your canvas is paper, you can use the nail to do but a few things to the paper. If you have a piece of thread as your tool and your canvas is a fire, what can you do with that thread?

What I have been doing with Java over the years, is picking my canvases, instead of finding a canvas and then picking a tool. What I see happening is that more canvases that are JVMs are popping up in more places. I can now use java 'anywhere'. There are litterly millions of smart cards that use the smartcard jvm. There are small processors like the aJile AJ-100, the systronix.com use of that chip in 'stamp' like packages. There are JVMs for many PDAs. There are JVMs for desktop and server class computers.

So, I can be a Java software Artisan in just about any place I go for just about any type of application domain.

There are of course FPGAs, DSPs and other specialized processors that still have their own programming languages and platforms and tools. I suspect that they will linger for some time to come. But, I also know that we've learned a lot about many of these application domains, and there are many solutions that don't need programability anymore. The solution spaces are known, and are being recast into hardware or libraries.

This is how application software developers need to think. Using domain centric patterns and casting them to code once will greatly improve where software evolves to. What we have to get over is creating a new programming language that invalidates all the tools we've already built for so many domains.

I consider the move from C to Java to be a worthwhile move. In Java, we have an interface from Java back to C/C++ if we need to tie some old tools together. We can script with Python, TCL and who knows what else using libraries that people have built for Java.

If you find that Java feels like Marble, then perhaps you are using the wrong canvas! Use a programming environment that allows you to mold your Java software more readily. I try my hardest to include delayed/late/runtime binding into software whereever that doesn't impact the application. This allows the software to be molded more readily and allows me to change how interfaces work. I can get the benefits of more dynamic programming languages just by changing how I architect my software.

When you write software, write it using an Application Oriented Language API that lets you say what you want done, not how to do it. Then, implement the how to do it part for your specific application. Later, you can change the how to part if you need to, and you'll feel a lot more like you are working with clay rather than Marble.

Talk Back!

Have an opinion? Readers have already posted 16 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Gregg Wonderly adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Gregg Wonderly graduated from Oklahoma State University in 1988 with an MS in COMSCI. His areas of concentration include Operating Systems and Languages. His first job was at the AT&T Bell Labs facilities in Naperville IL working on software retrofit for the 5ESS switch. He designed a procedure control language in the era of the development of Java with similar motivations that the Oak and then Java language development was driven by. Language design is still at the top of his list, but his focus tends to be on application languges layered on top of programming languages such as Java. Some just consider this API design, but there really is more to it! Gregg now works for Cyte Technologies Inc., where he does software engineering and design related to distributed systems in highly available environments.