Ask HN: When was the last really transformational idea in programming languages?
This question came up in another thread (http://news.ycombinator.com/item?id=470838) and got me thinking. Smalltalk dates from the early 70s; Lisp, APL, and Forth are all earlier. When was the last innovation that can truly be called fundamental?
We're not talking language features here. Obviously a great deal of refinement and elaboration has taken place since 1971. To qualify, an idea has to be deeper than that. It needs to have the paradigmatic quality that the above do. (Edit: I'm not looking for historical arguments so much as asking what ideas people feel have this quality.)
The only other candidate I can think of off the top of my head is Backus' 1977 work on FP, which certainly struck me as fundamental when I read it, though now I'm not so sure.
Others?
52 comments
[ 4.6 ms ] story [ 106 ms ] threadFor a truly transformational step we need a new machine.
http://en.wikipedia.org/wiki/Connections_(TV_series)
Not that the long-form version isn't entertaining as well.
Naturally you've got my vote.
Let me add a bit of history to reduce the 'me too' content: There was an interesting hardware development at the same time which was specifically tailored to these channels, the 'transputer' by INMOS.
The whole upshot of this idea was that processors and a bit of support structure would live on a small dimm like package that you could stick into a base platform to create a mini cluster on a card.
I think this idea was well ahead of its time and that eventually we'll see something very much like it as our future hardware architecture. After all the current trend towards clustering and miniaturization all point in that direction.
XMOS looks interesting.
- Type-safe generic programming
- Introspection
http://en.wikipedia.org/wiki/Generic_programming#Generics_in...
I was hacking together an Arc interpreter in Haskell the other day, and after refactoring some of the hairier monadic code, I was horrified to see that the type signature for a particular function was twice as long as the function body. And that's with the compiler figuring it out for me... I don't know what I'd have done if it was C++ instead.
C++ STL code can be similarly (un)fun.
There're a lot of really interesting ideas going on in the programming language research community right now. Subtext, Epigram, associated types, Goo(ze) (which unfortunately seems to have been abandoned), JoCaml, STM, etc. Unfortunately, it probably won't be possible to judge the worth of these ideas for another 20 years.
Category theory is another perhaps - it's from the 40's but it's application to programming is new - 80's perhaps?
Of course there may be pre-ML work predating even that.
According to the wikipedia page (http://en.wikipedia.org/wiki/Type_inference#Hindley.E2.80.93...), it dates back to 1978
It seems like that might be the next transformational idea, since it hasn't transformed mainstream language yet.
The idea of the DOM?
Both mid 90's
The DOM (as in Document Object Model defined by W3C) has nothing to do with Javascript - it's just an API originally designed for accessing the various parts of HTML. It was set up so that it could be implemented for almost any language. In fact, had it actually used some of the more advanced (Self-inspired) features of Javascript within the definition of the DOM, the DOM may not have been such a pain in the ass. :)
What Javascript did manage to do that was very important is that it ended up becoming not only the most installed programming language of all time, but unlike BASIC, it's actually a pretty damn good language under the covers. So if anything, the fundamental innovation of Javascript within every browser has basically yielded another BASIC-like inspiration to a whole new generation of programmers. Except this time, their intro language was much more abstractly powerful.
I believe it is a large factor of why Python has/is gaining mindshare in technical but non-programmer fields, education, science. If true and continues seems transformational to me.
http://vpri.org/
One of their projects is to see if they can build a complete software stack -- from the OS through the GUI and networking/graphics libraries to end-user software -- all in 20,000 lines of code total.
They have already made some major progress in the past few years. I highly recommend reading (or skimming) their progress report from last year. In addition to being quite impressive, it also has several cool ideas that I had not seen directly before:
http://www.vpri.org/pdf/tr2007008_steps.pdf
And focusing on code size is possibly misleading, as code size does not exactly equal orthogonality.
focusing on code size is possibly misleading
It's not the best metric, but it's close enough in this case. The whole problem is that large commercial (and some open-source) systems are in the millions of lines of code. What is all that code doing?
code size does not exactly equal orthogonality
One implies the other, at least in the way they've phrased the problem. Their goal is to build everything using only 20,000 lines of code. This means they have a strict overall budget and therefore cannot afford any duplication anywhere.
They weren't required to change the stack
You can't go from millions of lines to 20,000 by making incremental changes. The whole system from the ground-up has to be rebuilt with the code budget in mind.
they should have waited until they hit beautiful enough technology that would require such a change
They would be waiting forever. At some point, you have to dive in. Nothing good ever gets built without several iterations. Combine this with the fact that frameworks and languages are best built simultaneously with the applications that will use them (so that the levels of abstraction are correctly tuned), and I think their approach is perfect. By being forced to consider all levels of the stack, they achieve all of these goals.
Incidentally, they're not hoping to get the system built in one go. They're "building [at least] one to throw away", as Brooks said. They are building a rough version of the system (over-budget on lines) to see where the problems are. Then, they will use this first system to build the real thing.
At its heart, this project seems like an ideal way to do research into computing systems. Take on a daring project which will require many innovative ideas -- some small, some large -- while making sure that you're always tied to reality by having concrete goals and need to have some sort of a working system at all times.
What I was trying to say was: to be brave, That it wouldn't be about waiting forever. Jumping in is important but keep a wide perspective and be able to throw it all out, over and over again. What they're looking for isn't going to come incrementally from code size. They've been given a golden chance here and I think they should consider being brave enough to lose site of shore -- to go for broke. I think the Alan of the 1970's would have done that.
http://stackoverflow.com/questions/432922/significant-new-in...
I like how he refuted most of the responses usually stating that a given invention was already invented at Xerox PARC in the 70s.
KRC, SASL, Miranda. Simon Peyton-Jones was a key driver of some of this work, and obviously he's still a major force behind Haskell.
We're only at the very early stages of the parallelisation of hardware, but as that trend intensifies, I can't imagine compiling efficient code without explicit compiler knowledge of what code might side effect.
Though there was also a fair bit of Self optimization work going on at the same time--don't know if Alan's and Peter's work was the very first of its kind.