Friday, April 15, 2005

A musing about the Ultimate Language

I just wrote a comment at http://alarmingdevelopment.org/index.php?p=6#more-6 which I may as well repost here since it got pretty long.

----

For the past few years I've been thinking on-and-off about how the "ultimate" programming language and IDE should look, but I've seen so many cool paradigns and techniques that it seems practically impossible to make an "ultimate" language that could support all the useful ideas that I've seen. Aspect oriented programming, compile-time programming, intentional programming, languages with extensible syntax, smart editors that help you refactor and understand your code inside and out, and do duplicate code management, graphical programming (e.g. executable diagrams), languages that make various things implicit/automatic to save typing (such as type declarations), functional programming, example-oriented programming which I read about here today, and so forth.

It's clear to me that most all of the ideas I've heard are useful and have their place. But any given computer language of today supports only a subset, often just a small subset, of the useful methodologies that have been invented. The most popular languages of today, Java and C++ (and C# too) seem horribly limited to me. Similarly, our toolchains, such as our IDEs, seem very limited to me.

I've been wondering lately just how many people agree with me about this--is my frustration with today's programming world common, or is my point-of-view obscure in the world-at-large? And I wonder whether there is a community of people hidden somewhere on the web discussing all of this and planning a solution without me. Is there? I've seen several disjoint projects to make new computer languages, new GUIs, and even to "reinvent computing", but these projects don't seem to know about each other.

OOPSLA looks like a great event to discuss these things, but I'm sure there are many like me that don't have the time or money to attend. There really oughtta be a place on the Web for all of this.

----

Imperative vs Declarative vs All other styles of programming: which style should be the most "fundamental" in the ultimate language? John Edwards said "Control flow...notation...should be considered harmful to humans" and I said...

I’m not sure what you’re getting at... Are you saying the conventional “imperative” mode of programming is bad?

If so... I agree that it isn't always the best way to go about programming, but other times, in fact, it is. A lot of problems have a solution of the form "do this, then this, then this, and if 'this' is the case then do 'that', otherwise do 'this'..." If you're suggesting that the language of the future would be declarative rather than imperative, that it would look somthing like prolog, I must disagree. Both styles are useful, one usually more than the other, depending on the circumstances. For that reason I believe the "ultimate" language would be, at its very core, an imperative, sequential language. It would be this way, not because imperative style is necessarily the "best", but because it reflects the natural way in which the computer operates. Of course, you could USE other styles in this ultimate language, but you would rely on libraries (of code, syntax, etc.) to do so, and those libraries would implement declarative code in terms of the imperative equivalents.

In terms of its most fundamental features, the ultimate language should reflect the operation of the computer, because any other design would create a lot of inefficiency. Imagine an extensible language whose core only supported unlimited-precision floating-point, for example. Certainly it could do everything that a fixed-size-integer-supporting language could do, and you could certainly extend the language with an "int32" type that behaves in every respect like a C++ int, but it would be silly to do things this way because it would be horribly slow at integer calculations and probably require a grotesque amount of memory for an array of "ints".

Similarly, you could no doubt simulate step-by-step imperative semantics in an extensible language which at its core only supported Prolog-like declarative logical inferrence.... but the overhead might be unacceptable.

Conclusion: the "ultimate" language must support all (or almost all) the features that can be expected in the underlying machine, or else it would totally suck for code that relies on those features. The ultimate language would support the slow-but-safe semantics of Java or the fast-but-deadly semantics of C++, whichever the programmer requires.