Re: Have we reached the asymptotic plateau of innovation in programming language design?

Rui Maciel <rui.maciel@gmail.com> writes:


> - And here's the first itchy point: there appears to be no correlation
> between the success of a programming language and its emergence in the form
> of someone's doctoral or post-doctoral work. This bothers me a lot, as an
> academic. It appears that deep thoughts, consistency, rigor and all other
> things we value as scientists aren't that important for mass adoption of
> programming languages.


As a non-academic, I agree. None of those things matter very much to me
when it comes to actually getting stuff done. They are not bad things
to have, but they are not the things that matter.




> - So one pertinent question is: given that not much seems to have emerged
> since 1979 (that's 30+ years!), is there still anything to innovate in
> programming languages? Or have we reached the asymptotic plateau of
> innovation in this area?


As others have mentioned, there may be some good ideas to come in the
area of safer and more efficient parallel programming. I like the CSP
model, but perhaps there is something better. I personally think the
model of threads, mutexes and condition variables has so far proven too
difficult to use correctly for most programmers. That goes double for
the atomic operations and barrier model. And functional and dataflow
programming languages do not appear to have gotten much adoption in
practice.


I also think there is more room for thought about programming in the
large. Many software shops these days are huge, producing programs that
are far too large for anybody to keep in their heads. As a side-effect,
many programmers spent a lot of time performing maintenance of various
sorts. What can languages do to help? Refactoring is just the most
obvious example in this space, and even there it is clear that some
languages support refactoring far better than others. Other areas
related to language are speed of development, dependency management,
ease of debugging, modularity, ease of performance analysis, no doubt
many more.


Ian

Return to the comp.compilers page.
Search the comp.compilers archives again.