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

On 3/7/2012 7:52 AM, Rui Maciel wrote:
> - And herebs the first itchy point: there appears to be no correlation
> between the success of a programming language and its emergence in the form
> of someonebs 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 arenbt that important for mass adoption of
> programming languages.


I think what is need for mass adoption is the following:
1. Robust implementations that are comparable in speed and power to what
exists.
2. Intuitive syntax to programmers. This probably explains why APL never
caught on :-)
3. Ability to interface with existing code.
4. Proof that the code can solve real problems. If you can give people a
fully-featured web browser in language X, you're probably going to be
able to build more adoption than if the largest program is a calculator.


> - And, finally, all of these new languages, even when created over a week as
> someone's pet project, sit on the shoulders of all things that existed
> before. This leads me to the second itch: one striking commonality in all
> modern programming languages, especially the popular ones, is how little
> innovation there is in them!


I've also noticed that, with the exception of the languages which are
effectively pioneers (FORTRAN, LISP), none of the modern major languages
are the first to develop the techniques they used. This may be because
people are predisposed to not trust research-quality software.


> - 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?


If you can view it as a PL concern, the modern memory model of C11,
C++11 and Java 5 is new.


The biggest thing that I think needs innovation is parallel programming:
we're still waiting for the innovation like OOP that makes large
commercial parallel programs (leaving aside HPC as wanting something
different) much easier to program. After that, I think more expressive
type systems could be another fruitful field of research, although it
requires care to make sure that the errors they produce are easily
understood by the lay programmer (think of how confusing most people
find C++'s template error messages).


Another thing--this really isn't innovation, though--that people
proposing new languages need to pay attention to both the features and
misfeatures in the programming languages people use. I think PHP is
evidence that trying to under-the-hood sanitize input to prevent
unintentional exploits is prone to backfiring spectacularly. On the
other hand, coercing string types to be UTF-8 or UTF-16 is probably a
bare necessity for any new programming language.


A final thought I had was the idea of source-to-source translation tools
to help migrate code written in $OLD_LANGUAGE to $NEW_LANGUAGE. Again,
not strictly PL, nor is it truly new, but I think it's a place that
could use some more work.


--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth
[Source translators are very old. I used one in about 1969 that translated
Fortran 66 to PL/I on IBM mainframes. It worked, but the code was very ugly
due to minor semantic differences between similar constructs like format
statements. With the improvements in program analysis in the past 30 years,
I suppose it's possible that a translator could identify situations where
the differences don't matter and emit simpler code. -John]

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