In a nutshell, I think the Next Big Thing might be a return to parallelism, at the language level.
First, some observations:
o Hardware has been naturally parallel for many decades now.
o We are getting closer to the limits of serial processing in silicon, we will reach the limit in less than 20 (say) years. [OK, a lot of people have said this before, but it will happen eventually.]
o Software has been a von Neuman bottleneck for some time now. We are not exploiting the natural parallelism of hardware, we are not even close.
o Hardware is becoming even more parallel, with Intel hyperthreading, and increasing numbers of execution units on chips.
o There is a convergence of Model Driven Architecture, for automation of design-to-code, and modelling of executable Business Processes with specifications such as BPEL4WS, the convergence point is Activity Diagrams. Both are fashionable but embryonic. We are at beginning to learn how to design and code software which does more than one thing at a time, in a standard way.
o The BPEL4WS specification shows how interfaces to Business Processes, and their implementation, can be defined in XML.
o XML syntax is lousy for programming languages, it is way too clunky.
o Service Oriented Architecture is growing in popularity, and has asynchronous messaging at its core.
o The technology for vectorising loops has been well known for at least 25 years, and proven in practice many times ouver. Some of this can be done automatically by compilers, however it may require additional input from the developer. It is not fashionable at the moment.
o We know how to design platform-independent languages, which map onto platform-independent byte code, which can be mapped efficiently to hardware using JIT and hotspot dynamic compilation techniques.
o We know how to do continuous integration of UML and Java code for class diagrams and sequence diagrams with tools like TogetherJ. But not activity diagrams. Closer coupling of design and code is the future.
o The long-running and cross-system nature of business processes requires a non-stack based, non-platform specific approach to managing process state. We know how represent this state with XML.
o Agent echnology, which allows running code to be moved from one machine to another, has not really caught on yet, and is not in fashion. It does, however, have something in common with Business Processes it requires the execution state to be convertible to a platform-independent format between execution steps. Again, we know how to do this with XML.
So now for my predictions:
o The Next Big Thing will be a language which supports fine-grained parallelism naturally for invocations, loops, array/collection/relationship/resultset processing, IO etc.
o It will be strongly-typed, with exceptions.
o It will not be stack-based, it cant be.
o It will run on current stack-based hardware.
o There will be a parallel extension of Java Kava? [I see from Google that there already is a Kava - whatever.]
o The byte code for Kava will be a superset of Java byte code.
o There will be a parallel extension of C# - C|| ?
o The Microsoft machine-independent language for C|| will be a superset of that for C# and CLR, namely MSIL.
o Stack-based optimisation and mapping to hardware will be performed at runtime from byte code to machine code using hotspot-type techniques.
o Service Oriented Architecture will be driven down to a very fine grained level, with something like individual classes made available as services.
o Activity diagrams will have many swim lanes, each of which may be very small, supporting many small interacting processes.
o There will be tools like TogetherJ which allow continuous integration of design including Activity Diagrams/BPEL etc with Kava/C|| code. Both Activity Diagrams and BPEL will have to evolve.
o There will be further blurring of the boundaries between design and development.
o The ever-increasing natural parallelism of hardware will be better exploited, but still not fully.
o The new languages will naturally support Agent technology. This will allow mobile code to move to where the data is for much more efficient processing. We still dont know how to secure this, but we arent far off with Java sandpit and other security technology built into the JVM.
o The code will run on many different kinds of devices including phones, cards, ubiquitous devices. Well we can do most of that already with Java it is just a question of getting the cost down.
o The code will support efficient processing of images, graphics, video, speech etc. using the high-level languages, using the inherent parallelism, on small devices. [Though I don't know to what extent we will still use specialised code for these applications, some commodity code will still be implemented in C etc.]