Ask HN: Which people and groups are researching new approaches to programming?

Oh man, this is exactly what I've been thinking about lately (though I think it should be built on something like Scheme). The more research I do, the more it seems like a Hard Problem. In a nutshell, how do you handle inherently ambiguous composed grammars? Do you see your system being flexible enough to be able to essentially "behave like" arbitrary existing languages? It would be very easy to port things to it if this were the case.

Anyway, good luck!

This may be a strange way of looking at it, but let's backtrack 30 years before and see what made the biggest differences. As I've been in the industry for about thirty years, my impression is that nothing much has changed. That seems strange, but it's still the same job that I started with.

For me it is interesting that in my career, code base sizes grew to gigantic proportions -- there are many applications that are 10s of millions of lines of code. In the middle of my career I worked on a few. Interestingly, I'm doing web development now and a lot of my colleagues think that 5000 lines is unbearably big. I think the take-away here is that we have gotten slightly better at abstracting things out and using development libraries (and dare I say, frameworks).

OO was just becoming a big thing at the start of my career. Everybody did it incredibly badly. Then Kent Beck and Ward Cunningham came along and told people how to do it not-so-badly. I think the biggest thing that I saw in this time frame was the breaking of the myths of OO being about code re-use, and the movement away from huge brittle design structures. Good OO developers moved back to the really basic ideals of dealing with coupling and cohesion in design. We even started to have a language to be able to discuss design intelligently. Of course, quite a huge number of people were oblivious to this, but it always struck me how amazing it was that Beck and Cunningham were really 15 years ahead of most of the rest of us.

Lately, functional programming is coming into vogue. For the second time in my career I was surprised. People in the know are talking about idempotence, and immutable structures. This was the stuff that the crazy people were talking about in the 80's -- stuff that was "too slow", and "too memory intensive" to take seriously. But now it's pretty obvious this is the way to go.

I think the other big thing that blew me away in the last 30 years was testing. Probably some people will remember pre-conditions, post-conditions, and class invariants. This was unfortunately forgotten by most, but the most astonishing thing was unit testing. Especially the practice of Test Driven Development that not only allowed you to document your code with executable examples, but also forced you to decouple your objects/modules by the very behaviour that creates the documentation. Very few people do this well (just like most of the other things I've mentioned), but it is completely game changing.

As for the future, what is coming up? I suggest you look at what has gone before you for hints to that. In the last 30 years, apart from TDD (which came completely out of the blue as far as I could tell), the major advancements came from stuff we already knew about. It was the stuff that the "crazy" people advocated in the 70's and 80's, but that seemed impractical. If I were to guess, I suspect that we will see further progress on decoupling in design. Immutable data structures will not just be common, they will be how ever professional designs code. As performance moves from single processing to multi-processing, this will be important. Look at innovative ways of processing like flow based processing and other crazy ideas from bygone years.

My last piece of advice: Don't look for large revolutionary changes. I think those are unlikely. The programmer of 30 years from now will probably still be doing the same job as I am today. The changes will be much more qualitative. Also, expect that the vast majority of programmers will be as oblivious to the advancements as most programmers are today.

Actually, the graphical aspect of a visual programming language is often an "un-abstraction." Text is pure abstraction with little static context beyond names. VPLs often attempt to provide more context by (a) mixing in execution context (like in Quartz Composer) and (b) through direct mappings to the domain (e.g. a VPL for layout that has you manipulating layouts directly). Much of the usability benefits, as well as scaling problems, that arise in VPLs is due to trying to them trying to be less abstract.

Just noticed I switched up the PureData and Max MSP links. whoops!

Jordan Pollack's group is interesting (genetic algorithms, etc.): http://www.cs.brandeis.edu/~pollack/ Web page is hilariously archaic as bonus