So where do you actually disagree with the author? You don't think the gains from these were substantial enough?
Also the author makes a clear argument for why functional programming is, from a complexity perspective, something entirely different from mere "linguistic features". And a "silver bullet" according to Brooks is something that might take a decade to show full impact.
They are not.
> So where do you actually disagree with the author? You don't think the gains from these were substantial enough?
I think that 1. the collective gains might have been substantial but not 10x, and 2. the very ideas proposed by the author as being a silver bullet are not even among those in the first group.
> Also the author makes a clear argument for why functional programming is, from a complexity perspective, something entirely different from mere "linguistic features". And a "silver bullet" according to Brooks is something that might take a decade to show full impact.
When I was in university, Haskell was all the rage. People were saying how in some years we'll all be programming in it or in a similar language. That was in 1998 or 1999. Functional programming in general has been well known, and taught for many decades. I'm not saying it's particularly bad, and maybe it could even have a small positive effect, but saying it's a 10x silver bullet at this point sounds delusional. If Brooks was wrong and there is a silver bullet, I very much doubt it's something we've known about, and tried again and again, in various forms, for decades.
None of "open-source libraries and online forums, automated testing, and garbage collection" have led to a documented 10X improvement in productivity by themselves, so they are not silver bullets.
It has been popular in some class of languages that directly influence one another, and less popular in others. If you look at the software world in, say, 1995, I think a larger precentage of programming was done in typed languages than today. The question of "to type or not to type" wasn't on anyone's mind because virtually all languages used for serious stuff were typed. In any event, even if there is an MLification in important corners of the industry, it's still nowhere near a silver-bullet level of adoption. There is, I agree, a return to the popularity of typed languages, but it hasn't yet reached the level it was before 2000.
before 2000.
So 1990s types were a worst-case scenario: not expressive enough for many practical cases (you had to cast a lot anyway), hence the safety you get from typing was not much, syntactically heavyweight, bad error messages. Pointless trivial type annotations like
A a = new A(...);
Are you sure there was a big rise in dynamic languages at any particular point? I’m not so sure there really was (but I’m interested in documentary evidence if you know of any).
I always figured dynamic languages became more popular as computers got bigger and faster, so efficiency became less important in most scenarios. But that’s not the only trend -- plenty of people programmed in BASIC in the 80s, on tiny 8-bit computers! It was slow as hell, but P-code can be very memory efficient, so even on a tiny slow computer dynamic languages can make sense.
(I count BASIC as dynamic even though it lacks useful abstraction mechanisms because most dialects manage memory for you automatically.)
Edit to add: maybe Forth is a better example (and a much better language!) although I don’t think it was ever as popular as BASIC.
If anything, I see ML as the (spectacularly) successful attempt at typing Lisp for increasing reliability. Remember Milner was at Stanford in the 1960s, surely he will have conversed with McCarty. Milner's early theorem provers were in Lisp. He invented ML to reduce the pain of using Lisp (remember, ML stands for "meta language"), and to make theorem proving less error prone. More precisely to reduce the TBC (= trusted computing base) in theorem provers through types (viz the famous Thm abstraction).
ML was essentially finished in the late 1980s [1]. Every responsible programming language designer could have taken on board ML's lessons sincen, and it's an interesting historical question why this did not happen.
[1] R. Milner, M. Tofte, R. Harper, The Definition of Standard ML. http://www.lfcs.inf.ed.ac.uk/reports/88/ECS-LFCS-88-62/
I started with Haskell, where the main influence besides ML was Miranda. (If I remember correctly, Haskell was only created because Miranda was proprietary; similar to BitKeeper and Git.) I guess Miranda’s main innovation was lazy evaluation. That has certainly been influential but outside Haskell I don’t think it’s ever had widespread adoption in the same way as ML-style typing and type inference.
* Every responsible programming language designer could have taken on board ML's lessons sincen, and it's an interesting historical question why this did not happen.*
Agreed! But maybe it is happening, it’s just that it’s taken 30 years instead of the 5 or 10 one might have expected?
Lazy evaluation was invented multiple times. First in theoretical studies of the lambda calculus by Wadsworth in 1971. Later, Friedman & Wise, and independently Henderson & Morris proposd a lazy Lisp, Turner (who later did Miranda) gave SASL a lazy semantics (SASL was eager initially). All three were from 1976, so it was clearly an idea in-the-air. SASL later evolved in to Miranda. Another of Miranda's innovations was to use combinators for graph reduction to implement the Miranda run-time.
Widget *pw = new Widget(); // heap
Memory is no longer highly constrained
Javascript, Python and Ruby are the big dynamic languages today. But you can go back as far as you like, to when languages like Perl, TCL, Lisp and BASIC were big. There have always been dynamic languages.
Static languages have gotten more robustly type-safe over time (even today’s C is much safer than K&R C). But apart from that shift, it seems to me that the static vs dynamic landscape has been much the same for decades.
Some versions are a little bit richer in that you can have both ints AND doubles (woot, woot!).
Well, who said his prediction turned out to be true? Who actually measured the "impact to productivity" in any quantifiable terms? And who re-did that measurement after "No Silver Bullet, Refired" (which was 25+ years ago)?
The very first piece of software I optimized, I started with “One Mississippi”, moved to a stopwatch app on my PDA, before I ever bothered with instrumentation. Because any idiot can tell 2 seconds from 3, that a boat won’t fit in the garage, or that more than double is way less than ten.
Ironically, if Brooks had said 3x instead of 10x, he might still be right and we’d have invested more in measuring things.
Also, the claim that X has not had a large positive effect requires no evidence. It must be assumed true until proven otherwise; that's just the scientific method. The larger the claimed effect and the longer until it is detected -- especially in a selective environment -- the less likely it is real. However, the claim that something has had a big positive bottom-line effect and yet that effect is not detected in a selective environment that is known to have selected beneficial techniques all the time is false with a very high likelihood to the point of being self-contradictory.
Even if you aren’t on-board with the ones this article mentions, there are a bunch more in this list.. and it could probably do with a refresh soon
In addition, I agree with the author that the biggest contributions to productivity we have seen were, in this order, the availability of open-source libraries and online forums, automated testing, and garbage collection -- all of which have been adopted at rates we'd expect from adaptive traits in an environment with selective pressure. What is conspicuously missing is linguistic features, also in line with Brooks's observation. And yet the author still claims that linguistic features are the silver bullet. At this point this qualifies as an extraordinary claim that requires extraordinary evidence, but I would settle for ordinary evidence, which is also lacking -- strange, considering that a silver bullet, i.e. something with an extreme bottom-line impact, should be easily observable.