3 ms·
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
by mattiask 16y ago
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.
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.
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.
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.