Now, let's think for a moment, what would that language look like. We cannot just Star Trek ourselves a few years forward, but we can try making an educated guess about it, and getting at least some things right. So my guesses are:
- It's going to be have support for all the common things people are programming, at language or stdandard library level. That means direct support for: HTTP, TCP/IP, XML, Unicode, i18n. I wouldn't be surprised if it even had AJAX. Some languages are already trying to explore this kind of integration. See for example CDuce. Oh yeah, and GUIs are probably not in this category - they are common, but nobody knows how to make a decent portable GUI library (see recent Java GUI issues).
- It's going to be simple. C was much simpler than Ada and it won. Java was much simpler than C++ and it won. Ruby is much simpler than Perl and it's winning. Ruby on Rails is much simpler than PHP and J2EE and it's winning. If the language can still surprise you after a few months of using it, has ugly corner cases, and many things that "kinda work, but not always", it means huge loss of productivity.
- It will cooperate with the outside world. You know what was great about Perl ? You never had to care about dealing with the outside, you could support even the weirdest interfaces with just a few lines of code and get back to coding the real thing. If the outside world changed completely, you needed a few minutes to make your program work again.
- It will give a damn about security. Most programs run on insecure networks. Take a look at some existing programming languages - C is just great for crackers - it makes writing stack smashing friendly code so easy. And PHP is so SQL injection friendly. I wouldn't be very surprised if the authors of C and PHP were member of CIA or some other GNAA trying to make people write insecure code so they can exploit it. But people are smarter now, and I think the language of 2010 will make it easy and natural to write secure code.
- It won't give a damn about performance. Designing for performance is root of all evil. All languages designed for performance suck. You can get most of the performance later. For God's sake, even Java is faster than C++ these days. The language's only ahead-of-time compiler will probably be JIT compiler running in a hacked mode.
- It will be dynamically typed and completely object oriented, kinda like Ruby. It will also have high-order functions and metaprogramming, kinda like Ruby.
- It will use reasonably familiar syntax and be based on principle of least surprise. You can change syntax a little - after all syntax of Perl, Python and Ruby is not strictly C-based, but reasonably readable for people with C-syntax background. But if you go too far, people will reject your language. Every programmer's brain has a part that is responsible for parsing. If they used Java-style or Ruby/Python-style syntax all their lives, they will have trouble programming in Lisp or ML style languages. It would take years for them to switch their brains enough for the different syntax to feel natural. The same with semantics - if you changed traditional variables into Prolog style variables, or traditional control structures into monads people would probably reject your language, even if the new semantics was technically superior. That means it can take many iterations before the good idea gets accepted. Like, people went from C to C++ to Java to Ruby to start real object-oriented programming even though Smalltalk was available back then. It was probably too weird back then.
- It will be implementation-defined and will evolve. Standards are a great way to kill a language, we just need a single good Open Source implementation. All the recent winners were implementation-defined: Perl, Java, Ruby. Compare with standards-based languages like C/C++ which are simply dying now and being replaced by Java and others instead of evolving. And portability of programs written in standard-based C/C++ is so horrible that everybody is using (implementation-defined) stuff like autoconf. So what was the point of standards again ? Oh design by committee can lead to horrible results - like while a few things about Scheme suck (Scheme has a small standard covering just the basics), it would be more accurate to say that a few things about (the paragon of design by committee) Common Lisp do not suck. Should I even mention that most of the "standards" are not available online for legal reason ?
- It will be easy to code interactively and IDE-friendly. Java folks are recently doing some really great things with IDEs that the rest of the world doesn't even know about yet. And we need a way to code everything interactively or many things will be really painful to debug. A common problem with many of the today's systems is that you cannot interactively run client-server programs and you need to debug by ugly hacks. This has to be fixed.
- It will probably have macro support and something callcc-like. Macros are the most obvious way we can extend power of the languages nowadays, so I guess the language will support those. callcc is used only occasionally in the end programs, but it makes extending infrastructure much easier.
See also: Paul Graham's idea about language design.