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

Re:The Language of the future ...

[Anonymous Coward]

The quote is from Dowd and Severance (see http://home.gwu.edu/~robinson/math181/lecture7.htm l)

Re:History and Future

[AbdullahHaydar]

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

Not long...

[MosesJones]

In fact never. Because while its okay human languages have a few problems

1) Redundancy, far to many ways to say or do one thing

2) Ambiguity, "1 may be equal to x" "Sometimes allow the user to do this if they aren't doing something else that might conflict"

So what you might get is a restricted language with restricted terms that could help. But even these tend to fall down, the first UML spec was written using such a language but this was abandoned for the more formal UML language as the inherent ambiguities of languages couldn't be overcome.

So basically you might have some mechanism of translating from formal into informal but the real work will be done in a formal manner, as now, as ever because at the end of the day....

Who wants to rely on a system that implements "sometimes" ?

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:I wouldn't read too far into this article...

[eMilkshake]

From http://www.legacyj.com/cobol/cobol_history.html:
In 1952, Grace Murray Hopper began a journey that would eventually lead to the language we know as COBOL.

Fortran dates to 1954.

So, there are 50 years of computer language.

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

[Black Parrot]

> And he considers something like Object-Oriented Programming a slow evolution?

When you consider that it is just a metaphor for refinements of pre-existing ideas such as data hiding, which in turn are refinements of pre-existing ideas such as structured programming, which in turn are refinements of pre-existing ideas such as "high level" programming languages, ...yes, it has been a slow evolution.

See past the hype.

English and Grammar...

[MosesJones]

English actually doesn't really have a written Grammar BTW, English was the language of the poor people not of the gentry therefore it evolved as a loosely ruled language rather than as a language with definate constructs like proscribed Latin or modern German.

Basically English is the language of plebs, the rich and diplomats spoke French. The idea of a grammar was retro-fitted by the Victorians who applied Latin rules to English which just don't fit.

Lets put it this way, in English you can screw with the language as much as you want and it continues to change every year. This is fine as it makes it a rich communication tool.

What other languages can use one word to make an entire sentence ?

F*ck's F*ckers F*cking F*cked

Re:Best quote from the article

[lostboy2]

What will perl look like in 100 years?

Ha. I always thought it would look more like:

#!/CowboyNeal/bin
use CowboyNeal;

my $CowboyNeal;

foreach $CowboyNeal (@ARGV) {
$CowboyNeal || die "You insensitive clod!";
$CowboyNeal =~ s/[^CowboyNeal]/CowboyNeal/gi;
push @_, $CowboyNeal;
}
print @_;

Re:Lisp...

[hding]

Well, for starters I'd look here (make sure to look at the links in the navigation bar on the left) and here.

Yep, dead end

[Anonymous Brave Guy]

dead-end? Java has already spawned javascript and C#.

...Neither of which has done anything to advance the state of the art in programming languages, even if your claim were true.

The one thing I have confidence in about programming in the future is that sooner or later, the tools and techniques with genuine advantages will beat the "useful hacks". Java, C++, VB and their ilk are widely used today because they can get a job done, and there's not much better around that gets the same job done as easily.

Sure, there are languages that are technically superior, but they're so cumbersome to use that no-one really notices them, and when they do, you don't have the powerful development tools, the established code base of useful libraries, the established user base of developers to hire, etc. When we get to the point that languages with more solid underlying models catch up on ease of use, then we'll relegate the useful hacks to their place in history as just that. Until then, we'll keep using the useful hacks because we have jobs to do, but don't expect the tools of the future to be built on them.

Re:Somebody mod this back up

[__past__]

It's no surprise that he feels future languages 'will be list-based' and 'arrays will be obsolete'.

You do realize that Lisp has arrays just as it has lists, structures, objects etc?

He wrote another article in 2001 which declared Java a 'bad technology,' and not because he knew Java or had ever used it, but because his 'Hacker's radar' detected it.

No he did not. He wrote an essay about why Java has no appeal to (a certain kind of) hackers. He wrote about the Java culture, not the Java[TM] Programming Language, explicitly saying so.

Believe it or not, but there is a reason why Lisp users are more often also Lisp lovers than Java users are Java lovers: Lisp has very few primitives, and very many high-level tools built upon it. While you have a productive toolset from the beginning, you are always able ot change everything if it doesn't happen to fit your problem exactly, using the more basic tools.

For example, Lisp object systems are implemented in Lisp itself. Take that together with Lisps ability to redefine programs at runtime, you get something way more powerful that Java's object system. If you don't like an object system, change it until you do, or write your own. Everything in the language not only makes this approach of programming by language-tweaking possible, but encourages it - don't like the default way multiple inheritance is done in CLOS, the standard Lisp object system? Use the meta-object protocol to implement a metaclass that implements your weirdo inheritance rules.

Conventional languages like Java don't allow you to do this, instead they force you to think the way it's invetors wanted you to (which is not neccessarily the way they like to think themselves, as in the case of COBOL or Java). Lisp is not a single language - it is a toolkit to easily build a language that is perfect for your task.

Re:Interactivity

[ichimunki]

We do already have some primitive forms of this conversation idea via versioning systems like CVS. The problem is writing a program that recognizes patterns in the changes and learns to do that stuff on its own.

Also, think about languages like Ruby or Lisp where the interpreter can alter a program while it's running. As an example I wrote a small text editor in Ruby/Tk in which you could modify the source code to the editor in a buffer, then choose "eval buffer in application", and that code would run in the context of the application. Once you have the core of such a program, with proper error handling, you need never turn the program off again (as long as you don't redefine the core engine with a bug). I was able to add menus, menu items, rewrite existing routines, etc, all while executing the original code. Of course, emacs has been doing this same thing for years...

Using both CVS and live eval you get much closer to code being a conversation between the programmer and the system.

Check your facts, please

[voodoo1man]

Please check your facts. Development on Lisp started long before the 1960 paper.

We do not know which translation rules McCarthy used in the end of 1958 ... When McCarthy was working on this function S. Russel saw it and suggested translating it by hand - as he had done so often - and adding it to the program system . McCarthy recalls (22): "... this EVAL was written and published in the paper [I think this is referring to AI memo number 4, where apply first appeared] and Steve Russell said, look, why don't I program this EVAL and you remember the interpreter, and I said to him, ho, ho, you're confusing theory with practice, this EVAL is intended for reading not for computing. But he went ahead and did it. That is, he compiled the EVAL in my paper into 704 machine code fixing bugs and then advertised this as a LISP interpreter which it certainly was, so at that point LISP had essentially the form that it has today, the S-expression form ..."

PS -

Anyone who's done more than a little programming knows that strings need to be "first class" objects. The lack of genuine strings is one of the worst problems in the C language, and the source of most of the published vulnerabilities at CERT.

You do know that Lisp (unlike C) includes higher order procedures that make data representation irrelevant, or are you just speaking out of ignorance?