As a working PL researcher, I agree with plsceptic: we, the field of PL research, have a measurement problem. We don't have empirically validated and methodolog

As a working PL researcher, I agree with plsceptic: we, the field of PL research, have a measurement problem. We don't have empirically validated and methodologically sound studies that quantify the "dividends" of one PL or PL feature "over another, such as reductions in deficits, program size, or development time". To be sure, all this can be measured in principle, and measurement is one of the hallmarks of being a science. Alas, things are not so simple: 1. Like with cosmology or string theory, experiements that would readily decide scientific questions (like Java is a better programming language than ML) are prohibitively expensive. We could take 10 million programmers, split them in two groups and let them use the same problem but with one group using language L and the other language L'. Let this exeriment run for 10 years. Naturally, during that experiment, both groups must not, in any form or shape, communicate with each other. Due to the sheer expense of such an experiment, it's never going to happen. 2. Like the social sciences, reflective humans are integral part of any relevant experiement, leading to all manner of problems. For example the participants could actively sabotage the experiment. Of course PL research isn't the only field that lacks easy empirics. And like those, PL shouldn't let the perfect be the enemy of the good. It's quite clear that PL features do have positive productivity consequences, with garbage collection being the most clear-cut example. The interesting question is what do we do the absence of good empirical methods. One answer, and one that has been supremely successful is mathematical proof, although there is a real danger of loosing touch with what's needed on the proverbial 'ground'. Another answer, and one that is clearly being taken, is to let a form of social evolution play out: flood the world with programming languages, and see what happens. The poster complains about this flood and I understand why this can be seen as a problem, but I see this flood of new PLs as a sign of PL research's triumph: making new programming languages (for sequential computation) is now so easy that it's a frequent topic of undergraduate dissertations. Note the qualifier: while PL development is essentially played out for sequential computation (except at the margins) and not a research topic any more, languages for parallel and distributed computation is a wide open field. Note that there are virtually no typing disciplines or verification methodologies comparable to dependent types for non-sequential computing. I would also like to correct the misconception that PL research is (soley) about developing new languages. Clearly what's a good language depends in parts of the application domain. PL researchers are few and application domains are many. Consequently, a core component of PL research involves the following activities. a. Finding repeated patterns in software, and the software construction and evolution processes. b. Analysing these pattern mathematically, to find common abstractions. E.g. monads as generalised sequential composition, pattern matching, or various forms of interaction as a common form of computation. c. Automatising repetitive activities, e.g. compilers, or testing-tools.