The Language of 2016? Part 2: Easy Datastructures and Rapid System Access
One of the the things that made Perl gain popularity in the late 80's and 90's was how easy it was to take a string and fiddle with the middle of it without overwriting any memory. Now, C++ has real strings as opposed to C's arrays of characters, but when using many of the system calls that are critical to doing common tasks, they are incompatible. There is, of course, a c_str method, but thsere's not really a quick way to go the other direction.
What Perl did was make treating a string like it was an array as easy as indexing into it. You could insert, remove, push, pop, whatever. And many of the things you could do on an array, you could do on a hash, making playing with your data quick and flexible. Combine this with the ease and simplicity of system access and the fact that those system calls tended to return things inside of data structures, and you had a lot of utility for low cost to the Programmer. This is all possible in C and C++ of course, but there's a cost barrier. It hurts a little, not much, but it hurts. And the type incompatibility between C++ STL objects and C calls is just annoying.
Java fixed a lot of this, and good on them for it, but there is still a thick layer of crap associated with data structures and file operations. Interfaces were a clever way of handling the incompatibility of types on which common operations could be performed, but the question always remained: Why can't I just create an instance of this high level type and then YOU choose the underlying implementation for me? Plus, there's always the problem of casting to the required type to pass to an API, very annoying.
Quite often, performance reasons are cited as to why these things don't exist in the current popular languages. I'll grant that performance is an important topic... but only when I don't have the performance I need. As long as there's an algorithmic upgrade path, it makes a lot of sense to choose the simplest suitable impelementation at construction time.
The Languages of 2016 will build on the idea of easy, readily available datastructures and unfettered access to the system. The former because data manipulations are so critical to most of the work that we do as Programmers and the latter because dealing with hardware is a noxious, unloving task. I predict that in 2016, it will be common to see a language with at least basic Graph and Tree types in the standard namespace with common searches over those structures as well as manipulation and meta-data operations available. I also predict that the system access will be further simplified and generalized, probablly to treat many different distrubted storage mediums as they would the local disk (but I'm getting a little bit ahead of myself there). It would also be nice to have better ways to interface with system buses like USB (and Wireless USB), but no one's ever seemed to care about that and devices are mostly proprietary so I think that's a little unlikely.
This is an article in my series of entries entitled "The Language of 2016?"
