In order to have an understanding of what a programming experience is, the designer either has to look at his own experience and also observe others, possibly t

In order to have an understanding of what a programming experience is, the designer either has to look at his own experience and also observe others, possibly taking input from likeminded people. Further than that, in language design you obviously can't do A/B testing, since the cost would be too high, focus groups are in general fundamentally flawed because you can validate whatever you want and UX studies in language design would be too superficial, unless performed for a long period of time, but then you get to the same problems the scientists have to deal with in studies on nutrition. So unless you're proposing design by committee, which never worked in language design, you tend to get the best results from one language designer that outlays the foundation based on personal opinions and ideally on the prior work of others and is then helped by the community. I do understand your point on different styles of programming. However you can't please everybody. For example if you choose for your language to be IDE friendly, you end up with Java. Not sure how many people remember, but one reason for why Java EE has been a complete clusterfuck was the IDE oriented design, as in this belief that an IDE can help with the boilerplate and the wiring. The availability of IDEs is also why XML become popular. Even today Java is not usable without an IDE, because Java's libraries have been designed with IDEs in mind and they are too verbose for your brain to even remember the names of methods, let alone the happy path. Ruby's libraries on the other hand have been designed for expressiveness, for being easy to remember, also to counteract the poor IDE support. Neither approach is superior, but the choice in design was very conscious.