Programming language innovation - Is it dying?

constraint programming (mozart/oz)

actor model (erlang,mozart/oz)

More generally, see peter norvig's talks on youtube where he talks about data being more agile than programming. The new frontier in computing is using data to get things done. Programming language researchers, bless their hearts, are nice people, but won't add to much computing in the future.

Very few languages are truly groundbreaking. Most are simply refinements of existing ideas (doesn't necessarily mean that they're not a step forward). If you're interested in something earth-shatteringly different, you're going to need to look into programming language research to find it (One great reference that could probably answer this question better is http://lambda-the-ultimate.org/).

For examples of a recent-ish language that was developed by a professor at UIUC, see http://maude.cs.uiuc.edu/, which is based on rewriting logic and is currently still being developed/refined. But even that has strong ties to a previous language OBJ by the same creator.

If you're interested in learning something really different but a bit easier/more fun, I would strongly recommend Prolog. Schapiro has a great book (http://www.amazon.com/Art-Prolog-Second-Programming-Techniqu...).

Flow! http://www.flowlang.net/

I think to the contrary, programming language design as an area is flourishing now more than it has in a couple of decades. The availability of the JVM and JS as targets are freeing people up to experiment with lot's of different languages. Sure a lot of the things in these languages have been seen in some form before, but because there is so much cross-interaction between language features, putting things together in tasteful and elegant ways can be very innovative in the PL context.

It's easy to forget that Lisp, Haskell, Python, etc, didn't just spring forth fully formed. I read a great history of Lisp recently: http://www.dreamsongs.com/NewFiles/Hopl2.pdf. A lot of the features in Common Lisp we take for granted today were the product of various dialects and splinters of Lisp over the years.

As an Interaction Designer, I'd love to see a language that was built using UX methods and patterns (e.g. user research, usability testing, designing for visual perception). It probably won't produce linguistic innovations, but it could be a way to advance productivity and developer experience.

I think the problem is more about visibility, adoption and becoming industry usable language (community, framework, library, learning curve, etc.) then being groundbreaking. Language being too innovative and too different from mindset of developers in my opinion would create barriers for adoption. Take a look at functional reactive languages and value they offer for web or even to regular UI scenarios (http://lambda-the-ultimate.org/node/2057). There are a lot of research and real world languages done, but adoption rate is really low. On another hand if you do hit a sweet spot by simplifying existing scenarios and piggybacking on some popular concepts (example of node.js library using JS and simplifying web developers workflow) you instantly get adoption and visibility.

Most of it's been covered here, but another point is that for every mainstream language that doesn't seem to be so revolutionary, there are lots of little languages that never made it. In order for there to be lots of innovation, we also need lots of iterative steps in languages. This helps the less than genius programmer, the ones that get that templates in C++ are good, but would never bother learning lisp, get the new ideas in incremental steps.

Also, something you see quite a lot is innovative concepts built onto existing languages via libraries that then get integrated into new languages.

For a PL theorist/purist, there may not be much new under the sun. However, for "real" programmers (I kid) there is a lot more to programming languages than the theory.

A programming language is not just a means to formulate instructions for a computer to execute. It is also a way for programmers to communicate with each other and, taken further, a way for customer desires to translate into computer actions. I would agree that, viewed as instructions for a computer, not much new has come about in the last 10-15 years.

What has developed more recently are all the new ways that programmers are discovering or creating to communicate via code. TDD/BDD/RDD, literate programming, module systems baked into the language, optional typing, parameterized types, etc. are all features that, while not necessarily entirely new from a theory standpoint, are creating new ways for programmers to signal intent.

A good example of this at work is the recent resurgence in functional languages. These have, literally, been around since the very first programming languages were created, but they have never really "caught on" (for some value of "caught on"). I would suspect that part of the problem is that it has traditionally been more than a little difficult for someone not used to functional programming to approach the code. So, I would argue that the most important recent advances in the FP space have less to do with type inference, lazy evaluation, or correctness provability, and more to do with clearly communicating intent.

The recent trend in languages like Go is not bad. The intention is to make you productive. It's a new direction that programming languages should explore more. Instead of CS theory emphasize psychological theory, since it's still humans that program.

And note the human reaction to yet another language like Dart. Many of the programming languages they've tried promised the moon, but turned out didn't have huge effects on general productivity. Libs, frameworks, idioms, testing approaches etc, have a bigger impact.

I can say that, with Gosu, our goal is not to be innovative with syntax or semantics. Rather, our goal is to make common patterns today easier to deal with.

As an example: the open type system allows developers to mix various resources (xml files, wsdl files, json/jschema files, etc.) along side the gosu code, and access it all in a type-safe, easy-to-tool manner. This isn't particularly innovative from an academic perspective: there are no theories at work here, just some practitioners trying to make our lives easier. On the other hand, it is a very nice advancement for day-to-day coding.

As a broad generalization, I think that the technology community over-prioritizes innovation: I believe it would be more productive for most people to take the best ideas of the past and get on with the laborious task of sanding down and perfecting the implementations.