Slashdot Mirror


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."

7 of 725 comments (clear)

  1. Re:History and Future by AbdullahHaydar · · Score: 4, Informative

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

    --


    Suicide Booth: You are now dead! Thank you for using Stop and Drop, America's favorite since 2008.
  2. Not long... by MosesJones · · Score: 3, Informative


    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" ?

    --
    An Eye for an Eye will make the whole world blind - Gandhi
  3. Re:dead-end? by Billly+Gates · · Score: 4, Informative

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

  4. English and Grammar... by MosesJones · · Score: 3, Informative


    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

    --
    An Eye for an Eye will make the whole world blind - Gandhi
  5. Re:Best quote from the article by lostboy2 · · Score: 3, Informative
    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 @_;
  6. Yep, dead end by Anonymous+Brave+Guy · · Score: 3, Informative
    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.

    --
    If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
  7. Re:Interactivity by ichimunki · · Score: 3, Informative

    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.

    --
    I do not have a signature