I would define "capable" in terms of developer productivity--the time it takes to deliver quality software. For example, if you decided to write a DNS server from scratch would choosing Haskell or Scala (both fine languages) really enable a massive (order of magnitude) improvement over choosing Smalltalk, C, Ada, or Common Lisp? I doubt it. What we do benefit from is the availability of libraries, IDE's, and various frameworks. These, I would argue, rather than innate abilities of the modern languages are what enable us to be more productive (assuming that we are).
> For example, if you decided to write a DNS server from scratch would choosing Haskell or Scala (both fine languages) really enable a massive (order of magnitude) improvement over choosing Smalltalk, C, Ada, or Common Lisp?
Well, for a sufficiently low defect rate, I suspect it would take an order of magnitude longer (for normal developers) to achieve it in C, Smalltalk, or most Lisps. Ada perhaps not, but then maybe it would've taken the order of magnitude longer to implement, particularly if you factor in making enough money to buy the development tools first. Then as now, the future is not evenly distributed.
I mean, you're undeniably right on one level: for a small, standalone executable whose main task is bit-banging, where a high defect rate is acceptable, it was possible to bash that out 20 years ago at a similar speed to what you can do in today's languages. But I think that's actually a much smaller niche than it first appears, and not where the focus of our efforts has been because that's not actually what businesses most need.
> What we do benefit from is the availability of libraries, IDE's, and various frameworks. These, I would argue, rather than innate abilities of the modern languages are what enable us to be more productive (assuming that we are).
I think the ability to write long-term-maintainable, general-purpose libraries or frameworks is actually very tightly tied to the languages we use.
