The Hundred-Year Language

dtolton writes "Paul Graham has a new article called "The Hundred-Year Language" posted. The article is about the programming languages of the future and what form they may take. He makes some interesting predictions about the rate of change we might expect in programming languages over the next 100 years. He also makes some persuasive points about the possible design and construction of those languages. The article is definitely worth a read for those interested in programming languages."

Comments

Seymour Cray said it best

[grub]

I do not know what the language of the year 2000 will look like, but it will be called FORTRAN. -Attributed to many people including Seymour Cray, John Backus

I predict...

[Jack William Bell]

I predict that in 100 years someone, somewhere, will still be running COBOL applications.

And I will still be refusing to maintain them. Six years in the COBOL mines was six years too long...

Re:I predict...

[$rtbl_this]

I predict that in 100 years someone, somewhere, will still be running COBOL applications.

And I will still be refusing to maintain them.

Surely that depends on whether you're damned or not. I imagine there's a whole circle of hell devoted to maintaining COBOL apps.

Cobol is back.

[sokkelih]

I guess that programming languages are like cycles. Ah, COBOL is all coming back to me. This object orientation is way too appreciated, it is time get back to the days when VAX-admins ruled the universe of COBOL :)

No current languages will exist..

[SystematicPsycho]

When quantum computers come into the picture a new type of programming language and way we think about computers will emerge. Bit shifting will especially be different, it will be called... QBit shifting.

Re:I know!

[joeblakethesnake]

that's VisualJavaC++.Net#

Best quote from the article

[SeanTobin]

Who will design the languages of the future? One of the most exciting trends in the last ten years has been the rise of open-source languages like Perl, Python, and Ruby. Language design is being taken over by hackers. The results so far are messy, but encouraging. There are some stunningly novel ideas in Perl, for example. Many are stunningly bad, but that's always true of ambitious efforts. At its current rate of mutation, God knows what Perl might evolve into in a hundred years.

Re:Best quote from the article

[SeanTobin]

What will perl look like in 100 years?

#/usr/bin/perl
#
# Hello_world.pl
#

use uberstrict;
use all_warnings;
use diagnostics_and_repair;
use linux::registry;

use language_id qw(language);
use DBI;

my $dbinfo=new linux::registry;
my $dbh = DBI->connect(
"DBI:"
. $dbinfo->{database}->{type} . ":"
. "hello_world"
. ";host="
. $dbinfo->{database}->{host} . ";",
$dbinfo->{database}->{username},
$dbinfo->{database}->{password}
)
or die "Severe configuration error: " . DBI->errstr;

my $lang_query=qqq(SELECT `translated_text` from `hello_world` where `language`=? LIMIT 1;);
my $query=$dbh->prepare($lang_query);
$query->execut e(&language);

$output=$query->fetchrow_array();

print $output[0];

exit or die "exit failed";

Re:how long

[GnuVince]

Forth can be used a little bit like that (example taken from "Starting Forth", by Leo Brodie):

\ Word definitions : convicted-of 0 ; \ To convict someone : murder 25 + ; : arson 10 + ; : robbery 2 + ; : music-copying 40 + ; : sentenced-to . ." years of prison" ;

And to use it:

convicted-of music-copying robbery sentenced-to

Output: 42 years of prison This looks quite like english. Of course, you can do that in many languages, but it feels more natural in Forth I think.

The horror

[Chagatai]

If the children are our future, then they will be designing the future languages. This is horrible. Can you imagine the future code?

VIOD THING (OMFG!!!1 LOLOLOLOOL!!!)
INIT HAX0R N00B!!!
WHIEL STFU DO
GOTO 10
DOEN

Re:how long

[avandesande]

I hope it never is like spoken languages. I can hardly understand what my wife wants when I talk with her, why would a computer. Spoken languages are ambiguous.

Awareness...

[dmorin]

I know that's a scary word because it sounds like "self-aware". But I expect that in 100 years one of the inherent aspects of any computer language will be in detecting and working with other devices in a robust manner. In other words, being aware of what is around the programmed device. Not requiring a mandatory connection of type X. Instead I'm thinking about a device that can run just fine by itself, and then if another device of the same sort happens to come within 10 feet, then maybe they automatically attempt some sort of handshake (with encryption up the wazoo, of course) and then have the option of communicating. This would be useful for automatic transmittal of business cards, appointment schedules, and so on. Or it could be more of a client/server thing, where devices that do not have the power to get a certain job done will just naturally plug into "the grid" and request more power. The device won't have to deal with where the computing power comes from or how it is distributed.

Imagine cars that, before changing lanes, signal to the surrounding cars' navigation systems and they work out for themselves how to let the car into the lane. A computer can be told to slow down, rather than speed up, when someone wants to change lanes. Or detectors in the dotted yellow lines that sense when you changed lanes without signalling, and alert the traffic authority to bump your points (ala Fifth Element).

I always liked the idea of my PDA phonebook being more of a recently-used cache of numbers instead of a local store. I just punch up a number. If it's one of my commonly used ones, it comes right up (and dials, of course). But if it's not, then my PDA connects to the phone company, gets the information (and probably pays the phone company a micropayment for the service) and now I have that number locally on my PDA until it gets scrolled off if it's not used much.

Also I expect lots of pseudo-intelligent content filtering software. You'll get 1000 emails a day and your spam filter will not only remove 99% of them, but it will also identify and prioritize the remaining ones. In order for this to be useful there needs to be languages that deal with expression of rules and logic in a meaningful way (far more than just and or not). No one 100 years from now will say "if subject ~= /*mom*/" (or however the hell you say it), they will expect to say "Give email from mom a higher priority", or sometihng very close.

Re:Awareness...

[Kallahar]

If you're going to have the cars sort themselves out, why bother with signals at all? If everything is guided by GPS, why have headlights? If it's not the human doing the driving, why have traffic laws that are there to punish human errors?

Travis

Re:Quantum Language

[NetSettler]

I def. think that a new languange based on quantum computing will be at the forefront.

If after generations and generations of computers, we are still teaching people to talk in computer terms and not yet teaching computers how to talk in people terms, we'll have gone the wrong direction.

It doesn't matter if quantum technology is used or not, for the same reason as it doesn't matter whether a brain is a parallel or single threaded machine, whether it's made of carbon-based or silicon-based technology, etc. What matters is that it can talk to you, can understand you, and can improve life.

If you want to know what computer languages should and hopefully will look like in the future, you have only to watch Star Trek. I'm not kidding. The desire to pack computer use into a short TV program has led the authors of that show and shows like it to pare out all but the absolute essentials of describing what you want the computer to do. That is what computer programming should be like, since that's what people programming is like. People don't put up with excess verbiage, and neither should computers.

History and Future

[AbdullahHaydar]

This is a really interesting paper on the history and future of programming languages. (Check out the history chart in the middle....)

Re:History and Future

[AbdullahHaydar]

I forgot to mention that it was written in 1972 and predicts a few of the occurences since then...

I wouldn't read too far into this article...

[Pollux]

I think that it would be better to call this article "Where Programming is headed" rather than "The Hundred-Year Language". He tries to justify how he can predict the language 100 years into the future...

It may seem presumptuous to think anyone can predict what any technology will look like in a hundred years...Looking forward a hundred years is a graspable idea when we consider how slowly languages have evolved in the past fifty.

Hmm...funny, fifty years ago, if I remember my history (since I wasn't alive back then), those relay computers needed rolls and rolls of ticker-taped punch holes to compute math. The language was so-low-level...even x86 Assembly would have been a godsend to them. And he considers something like Object-Oriented Programming a slow evolution?

All he's doing in the article is predicting what languages will be dead in the future, and which languages won't be. For example, he says Java will be dead...

Cobol, for all its sometime popularity, does not seem to have any intellectual descendants. It is an evolutionary dead-end-- a Neanderthal language...I predict a similar fate for Java.

I'll not go there, because predicting the demise of Java is opening another can of worms. But let's just say that he really doesn't support his argument with anything other than anecdotal opinion.

I say read his article in jest, but don't look too deep into it.

Re:I wouldn't read too far into this article...

[Anonymous Coward]

no, you don't remeber your hist very well at all.

using round numbers, he is talking about the fifties, although really he probably wants to include the sixties.

So what did we have? Among others: Fortran, which is still around and has influenced many designs. Algol, which begat c, java, c++, c#. Lisp, which introduced FP and most (certainly not all) of the interesting ideas that somewhat mainstream languages like python, ruby, perl are starting to pick up on 30+ years later.

I know you weren't paying attention, but OO came in the 60's, and was developed *far* beyond anything seen today in mainstream production languages by the early 80's. (smalltalk, New Flavours, CLOS)

Most of what mainstream programmers think of as the history of language ideas is complete drek, because they make the mistake of thinking that the first time they see a company hyping an idea has any relationship to when the idea was arrived at.

If you had actually read the quoted sentenc fo comprehension, you would understand that he didn't say that Java would be dead, he said that it was an evolutionary dead end.

Not the same thing. Java is a fairly direct evolutionary descendant of Algol. Cobol, a contemporary of Algol, has no evolutionary descendants.

What he said is that the languages of 100 years from now will not *descend* from Java, any more than the languages of today descend from Cobol. I wouldn't be surprised if there were Java programs around in 100 years, but that is the nature of legacy systems, not an interesting insight.

On natural language...

[dmorin]

I think that the question of whether natural language is the "way to go" misses out an important distinction. There will always be users of technology, and creators of new technology, and they must speak different languages. I do not need the same skills to drive a car as I do to build an engine. Being able to type does not make me a novelist. There are two different cultures at work.

Having said that, I expect that the user language should certainly be natural language -- the "computers should understand people talk, not the other way around" argument. People know what they want out of their machines, for the most part. Whether it is "change my background to blue and put up a new picture of the baby" or "Find me a combination of variables that will result in the company not failing with a probability of greater than 90%", people want to do lots of things. They just need a way to say it. Pretty much every Star Trek reference you'll ever see that involves somebody talking to the computer is an input/output problem, NOT the creation of a new technology.

It's when you build something entirely new that you need a new, efficient way to say it. Anybody remember APL? Fascinating language, particularly in that it used symbols rather than words to get its ideas across (those ideas primarily being focused on matrix manipulation, if I recall). Very hard for people to communicate about APL because you can't speak it. But the fact is that for what it did, it was a very good language. And I think that will always hold true. In order to make a computer work at its best, speak to it in a language it understands. When you are building a new device, very frequently you should go ahead and create a new language.

Re:dead-end?

[Billly Gates]

javascript was orignally called livescript. Sun licensed java to Netscape for free under the condition that they change the name livescript to javascript.

Re:dead-end?

[shemnon]

Sorry, Wrong and Wrong.

Comparing JavaScript and Java is like comparing a Shark to a Dolphin, quite different actually even though both animals live in the sea, and both languages use the letters J A and V. Both have cariovascular systems and both use variables and control structures. But that is basically where the similarities end.

JavaScript actually started life inside of Netscape as LiveScript, and durring the Netscape 2.0 time frame was re-named to JavaScript to ride the Java bandwagon, but thre is no realtionship at all beyond that. Compile-time type saftey? Java yes JavaScript no. Prototypes? JavaScript yes Java no. eval() of new programming code? One but not the other. Interface inheritance? Again. First Class Methods? yep, not both. Bones? Sharks no Dolphins yes (teeth don't count).

Now C# and Java, they are at best siblings but java did not beget C#. The namespace structure is straight from Ansi C++, and the primative types include Cisims like signed and unsigned varieties. You don't shed a tail and then grow it back further down the trail. The comparison here is alligators and crocidiles. Very similar but one did not beget the other, it was a closer common parent than the sharks and dolphins.

Reductionism, you kidding?

[Jagasian]

I think it's important not just that the axioms be well chosen, but that there be few of them. Mathematicians have always felt this way about axioms-- the fewer, the better-- and I think they're onto something.

To anyone that has studied theoretical computer science and/or programming languages knows that such reductionism is a fallacy. "...the fewer, the better..."

It turns out that its better to strike a balance, where you make the formal mathematical system (what a programming language is after all) as simple as possible, until you get to the point where making it more simple makes it more complicated. Or in other words, making it more simple would cloud the mathematical structures that you are describing.

Here are some examples of reductionism gone too far: Sheffer stroke, X = \z.zKSK, one instruction assembler, etc...

The only logical connective you need is the sheffer stroke... but thats of no use to us as it is easier to more connectives such as conjunction, disjunction, implication, and negation.

The only combinator you need is X, and you can compute anything... but making use of other combinators... or better yet the lambda-calculus is more useful.

Point is that we need more powerful tools that we can actually use, and there is no simple description of what makes one tool better than another. Applying reductionism can result in nothing special.

The true places to look for what the future brings with regards to programming languages are the following:

1. Mobile-Calculi: pi-calculus, etc...
2. Substructural Logics: linear-logic, etc...
3. Category Theory: It is big on structure, which is useful to computer scientists.

Re:how long

[grumpygrodyguy]

Spoken language is far too full of grammatical bodges and fixes to become a structure logical enough for a programming language

This is a false and limited conception of the original poster's intent. Imagine having an A.I. on a PDA-type device that you carry with you from the age of 4. The PDA has a 100Terabye HD, and records/monitors your spoken words, actions, etc. After 20 or 30 years of this, your PDA probably knows you better than anyone. So if you tell your PDA "make a cool program that looks like this, and does this" there's a very good chance it understands what you mean.

Think about police sketch artists. They take vague, half remembered information...and turn it into a very accurate rendering of the original image. You have a vague idea in your mind of what you are describing, and you can't see what he/she is drawing. So you describe the person...and 5 minutes later the artist shows you a rather remarkable portrait of what you described. Which in many cases later turns out to very closely resemble the suspect. The missing link here is context. The context of shared culture and language.

If you can sit at a table and describe the basic functionality of a program, and describe its interface using words. Then your magic PDA will do the rest. It will even give you demos and visual feedback on the fly as you describe the program. It would serve as a layer between the absolutely massive context of your personal history, and the "structured" programming language required to build said program.

Please don't limit the future, it's bigger than you are.

Re:how long

[Simonetta]

I believe that programs should read like novels; there should be long paragraphs of text that describe what and how the code is working followed by short bursts of actual 'dialog' that is the actual source instruction to the computer.
The actual source code (i.e. the instructions to the processor) should be surrounded by quote marks or other delimiters, and the comments (i.e. the extended code description and documention) should be the part of the source surrounded by white space characters (space, tab, cr/lf).
I never cease to be amazed at how little programming has changed since the 1960's. It really seems that the only innovation in compilier user-interface design has been that (some) compiliers will actually allow you to put your keywords and comments in color! (duh!)
If we are ever going to increase the productivity of programmers to even remotely match the vast increases in price/performance of the the hardware then we must be willing to spend large amounts of time energy and money to develop new and better approaches to writing software code.
We must abandon our kilobyte mentality to gigabyte technology!
As an example of a different approach, has anyone considered using Chinese characters arranged in a three-dimensional grid as a method of doing syncronous parallel programming? Have each character represent a complete function and have their placement in the 3-D grid space represent the point in the algorymthic process that the function should be complete. The compilier would either create the machine language or suggest other arrangements of the parallel process by rearranging the Chinese characters in the 3-D user interface.
(The fact that it sounds weird is not important. What is important is that any new idea that can help improve the productivity of programmers should be considered, regardless of how strange it may sound at the present time)

Thank you,

Re:Notation

[rabidcow]

I think the uathor expects Lisp to remain a vital evolutionary branch because of its mathemtical roots.

I think he expects it to remain a vital branch because recent languages have been more and more like lisp. If lisp doesn't directly beget new, highly popular languages, lisp's features will be (and have been) absorbed into whatever does become popular.

my grade

[bob dobalina]

The signal to noise ratio in this piece is high. There's lots of metaphors and similes to explain his otherwise very facile points.

He also seems to be contradicting himself. " Semantically, strings are more or less a subset of lists in which the elements are characters. So why do you need a separate data type? You don't, really. Strings only exist for efficiency. ", he says at one point, then a few paragraphs later says "What's gross is a language that makes programmers do needless work. Wasting programmer time is the true inefficiency, not wasting machine time.". The efficiency in implementing strings in programming languages is for the programmer, who doesn't have to use said "compiler advice" and carefully separate his strings from his other, non-string list instances and keep the two distinct in his programming model. Apparently it's "lame" to simplify text manipulation for programmers, but at the same time the efforts of programming language design should be towards making the programmer's life easier. Which is it? I know strings and string libraries have made my life a whole lot easier.

Nevertheless, I'm willing to accept the notion that eliminating strings and other complex, native datatypes and structures serves to make a programmer's use of time more efficient. But how does it do it? Graham doesn't say, he just waxes nostalgic about lisp and simpler times and languages.

I don't think the slashdot crowd needs it explained why data manipulation by computer needn't be simplified; it already is, as machine code is binary in the common paradigm. What ought to be simplified is data manipulation by humans, and on this point Graham nominally agrees (I think). This has been the thrust of the evolution of programming from machine code to assembler to high level language. Simplifying high level languages into more and more basic, statements -- getting closer to the "axioms" that Graham calls tokens and grammars -- simply reverses that evolution. It makes it easier and more elegant to compile programs, but it does absolutely zero to make the programmer's life more efficient, or easy. The whole reason high level languages were developed was precisely to get away from this enormously simple, yet completely tedious way of programming.

The overarching fallacy in this article is Graham's reliance on what is known about computation theory now to determine what programming languages would (and should) look like then. And while it's interesting to prognosticate on what the future would be like 100 years from now based on what we have today, it's not a reliable guide. Like Metropolis, A Trip to the Moon, and other sci-fi stories from the distant past, they're entertaining and no doubt prescient to the people of the time, but when we reach the date in question, the predictions are largely off the mark. It's somewhat laughable to think that despite our flying cars and soaring skyscrapers, we use steam engines to power our cities and make robots with eyes and mouths. Likewise, I don't think an honest, intelligent prediction or forecast of (high level) programming languages 100 years hence can occur without a firm basis, or even idea, of what assembly code would look like then. This, in turn, relies on a firm idea of what computer architecture will look like. Who knows if five (or fifty) years from now a coprocessor is designed that makes string functionality as easy to implement as arithmetic. Such an advance would completely invalidate Graham's point about strings and advanced datatypes, and in fact possibly stand modern lexical analysis on its head. Or if an entirely new model of computation comes to the fore. Even Graham himself admits that foresight is foreshortened: " Languages today assume infrastructure that didn't exist in 1960.", but he doesn't let that stop him from making pronouncements on the future of computing.

Graham seems to be spending too much time optimizing his lisp code and not enough on his writing. This piece of code could have been optimized had he used a simile-reductor and strict idea explanations. But it's definitely a thesis worth considering, if for no other reason than mild entertainment. C-