2006...so taking that into account.<p>I am not quite sure why something like OCaml has not taken off in game development yet. Seems the promise of C speed, better programming abstractions and functional core would be something a strong game development studio would jump all over.<p>Though, being completely honest, I am not fully in tune with the game development community. Can anyone else comment?
I think one of the big issues that needs to be tackled for the next generation of languages is inherent support for concurrency and orchestration of concurrency. Typically multithreading is something you have to explicit program into your solutions and make a trade-of between performance and thread-safety. It would be neat if a langugage could be designed with concurrency supported by default, with as small hit to performance as possible for simple scenarios.<p>There are some languages that provide some inherent support already, primarily functional languages (haskell, f#). Some more tradional languages have started tacking on features to better handle parallelization/concurrency, for instance C# with async,plinq, parallel.net etc.<p>I'm a bit doubtful however that everyone is going to switch to a functional language, I think the mainstream will stay with a object-oriented language. But there should be an oppurtunity to design a new object-oriented language from the bottom up for paralllization and concurrency which tries to solve performance issues with locking/collections etc on a lower level but provider higher level of abstraction.<p>Another issue that perhaps should be addressed is better support for "huge" data. In most cases with todays programming languages you have to type your integers, meaning you have to chose between an int, long, bigint or whatnot. and if you type something as bigint for instance all instances takes up loads of memory even if the span of the integer isn't that big. Why cant a number simply adapt to how it's used. I realize the underlying problems of the cpu and precision but still, it should be possible with a more elegant solution.
I love checking in with this slide deck from time to time.<p>I'm not a language nerd by any means, but I wonder how much of the reliability issues are now "solved". It seems that Scala would do a lot of what is required, if only checked exceptions were enabled (why the Scala compiler doesn't have this as a compiler flag, I don't know). I understand why the author wants his static compilation cake, but sometimes sucking down some syntax for practicality/doing stuff now might be OK ;)
Re-reading this now, I'm struck by how similar some Tim Sweeny's lines of discussion are to Rich Hickey's, particularly about functional by default and bounded mutability.<p>A dependently typed Clojure would do well against all 3 of Tim's stated topic areas (and of course most likely would need the obligatory curly bracket syntax... for better or worse).