I guess the man who has found the One True Development Process has now found the One True Language as well. :-) But seriously, I think before you can say thing

I guess the man who has found the One True Development Process has now found the One True Language as well. :-) But seriously, I think before you can say things like "I don't think there are any more types" with any useful meaning, you have to have some idea of what a "type" of programming language is. For example, most current languages are at least strongly biased towards either a declarative style or an imperative style. Considering only languages that are in reasonably widespread practical use today, rather than some hypothetical ideal, we see that a declarative style can lead to very neat expressions of pure data manipulation, but is often less effective when we're dealing with side effects and a time dimension. In contrast, an imperative style puts things like timing and side effects front and centre, but tends to lack both the elegance and the safety that more declarative abstractions can bring. Both approaches have their strengths, but for a general purpose programming language, I don't believe either is ideal on its own. Is it a stretch to think that future languages will support both better ways of describing real-world processes (things with a time dimension and effects that might interact) and better ways to describe pure data manipulations without specifying irrelevant details? Would a language that made a sharp distinction between these two goals, instead of trying to bend both aspects into a single programming style, be counted as a new "type" of language? One could imagine a similar "middle ground" debate between other extremes as well. Again, most mainstream languages today are basically either statically typed or dynamically typed, though we do see a few common overlaps, such as polymorphic OO function call dispatch and "variant" types in otherwise statically typed languages. Would a language that was statically typed by default but natively supported dynamic typing within the system look like anything we see today? What about a language that was basically dynamically typed but supported type annotations for checking some properties at run-time, or in advance? How does that compare to the kind of type inference we see in some of the more expressive static type systems today? Again, there are already a few languages that are experimenting with some of these ideas, but I suspect they are a long way from becoming the norm yet, if indeed they ever do. I think we'll see plenty of innovation in programming language design for a long time to come, but at the lower-level end of the language spectrum it will mostly be in cleaner ways to blend between extremes that each have both strengths and weaknesses. I also expect we'll get much better at supporting things on a larger scale, where I think so far we're barely scratching the surface of how to build interacting, independent systems involving concurrency, distributed execution, fault tolerance, high performance, etc.