You need to have an understanding of other programming experiences. Part of the problem of designing programming languages is that there is little agreement an

You need to have an understanding of other programming experiences. Part of the problem of designing programming languages is that there is little agreement and extreme heterogeneity in the opinions of what is and what isn't a good idea in programming language design. Ideally, PL design statements like "language X is better than Y" should be accompanied by rigorous empiricism. Clearly, the field of PL design has a measurement problem. PL design doesn't have empirically validated and methodologically sound studies that quantify the "dividends" of one PL or PL feature "over another, such as reductions in defects, program size, or development time. Of course PL development isn't the only field that lacks easy empirics. And PL development 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. There are several valid answers to this question. One of them is to be strongly guided by mathematical beauty and elegance. This is the family of languages that started with Lisp and is today represented most purely by Haskell, Scala, Clojure, Ocaml and F#. The key ideas from this family: garbage collection, higher-order functions, rich types, have been accepted by the programming mainstream. One wonders if these ideas would have been discovered if John McCarthy had studied the programming experience of working Fortran / Cobol programmers, rather than Church's purely theoretical lambda-calculus.