I’ve just finished reading Stevey’s latest. His quite long essay (that was apparently written in under an hour) is about the features he believes we will see in the next language that is going to take over the world. What he describes sounds like magic. A language with Lisp’s expressiveness, C’s speed and Python’s cleanliness. Well, not exactly, but more or less in that spirit. Here’s a summary of the attributes he expects to see in the Next Big Language (NBL):
Rule #1: C-like syntax
This is because programmers are lame, but hey, it’s your target audience. Give the people what they want.
Rule #2: Dynamic typing with optional static types.
Adding in optional static types is the ideal solution. It helps with performance, it helps with code reliability and (possibly) readability, it helps IDEs navigate your code, and most importantly, it helps combat the incredible FUD that dynamic languages inspire in people who come from static backgrounds.
Rule #3: Performance
Generally speaking, NBL will have to have a much greater focus on performance than so-called “scripting languages” have had in the past. I mean, if it’s really the Next Big Thing, it’ll have to run on mobile devices, game platforms, and all sorts of other hardware-constrained devices.
Rule #4: Tools
I can’t tell you how many times I’ve heard people say they wouldn’t use Ruby because it lacks automated refactoring tools. Ruby doesn’t actually need them in the way Java does; it’s like refusing to switch to an electric car because there’s no place to put the gasoline. But programmers are a stubborn bunch, and to win them over you have to give them what they think they want.
Rule #5: Kitchen Sink
Here’s a short list of programming-language features that have become ad-hoc standards that everyone expects:
- Object-literal syntax for arrays and hashes
- Array slicing and other intelligent collection operators
- Perl 5 compatible regular expression literals
- Destructuring bind (e.g. x, y = returnTwoValues())
- Function literals and first-class, non-broken closures
- Standard OOP with classes, instances, interfaces, polymorphism, etc.
- Visibility quantifiers (public/private/protected)
- Iterators and generators
- List comprehensions
- Namespaces and packages
- Cross-platform GUI
- Operator overloading
- Keyword and rest parameters
- First-class parser and AST support
- Static typing and duck typing
- Type expressions and statically checkable semantics
- Solid string and collection libraries
- Strings and streams act like collections
The most disturbing thing about his post is the insinuation that he has some inside information that leads him to believe he knows what that future language might be. I tried to guess what he was talking about while I was reading and couldn’t come to any conclusion. None of the languages I’ve worked with (C++, Java, C#, VB.NET and Python) seem to fit the bill. They are all either too restrictive or too slow to actually become the next best thing. As much as I love Python, it was designed to be “glue” between components written in C and C++ and most of its speed-critical libraries are still written in those languages and that doesn’t seem likely to change in any near future (even with PyPy). And for a language to become truly popular it isn’t enough for it to be merely good, fun or fast. It needs to be endorsed by somebody big. As much power as we think the open source movement might have, the really big endeavors need money to succeed and that can only be provided by large businesses. And no, I don’t see a major bank’s IT department developing a Zope- or Rails- based information management system any time soon. They need someone to blame and to buy consulting from if (or more likely, when) things go wrong, so they’ll probably go with Java or .NET (or Fortran :) ).
But that’s not all. It seems (and I’m probably very late to find out about it), that Adobe’s Apollo project is supposed to be everything Java Applets and .NET’s Zero Deployment should have been – a secure sandboxed environment for running applications downloaded from the web to be run on the local computer with no more hazard or installation pain than visiting a web site. I’ve previously written that desktop applications could fight back the current wave of moving everything to the web. I wrote that post under the assumption that the tools for creating web applications will develop in a linear fashion through slow evolution of what we have today. And what we have today isn’t much – creating a responsive AJAX application that works across platforms and browsers is still too hard, much harder than creating a desktop application with, say, wxPython, that does the same thing. If Apollo does deliver an out-of-the-browser platform that will actually work, and you’ll be able to code to it using a language that doesn’t feel like bootcamp all over again, desktop applications will probably disappear.
And if Adobe does pull that off, they, along with their technology will become the next big thing.