My 2 cents from doing language design is that it is hard because it's hard to avoid making stupid mistakes. A successful language is a way bigger beast than you started out with. Perrone's advice about getting feedback is crucial. Point 5, understanding the theory is mandatory. If you dont, you are wasting everybody's time. However, it is very useful to do a throwaway language to develop your understanding of the theory.
Point 7, dont create new syntax for old semantics, is worth remembering, unless you have a significant simplification. In fact taking an old language and making it simpler is a very good excuse for a new language.
One thing not mentioned in the article is the importance of libraries. A new language doesnt have a lot of chance for success if users have to write everything from scratch. If you can piggyback on top of an existing infrastructure, like java, your chances are better.
The libraries point is interesting. I avoided it because it doesn't really make a lot of sense in the context of domain-specific languages or anything like that.
This article glosses over one of the key factors, perhaps the most important one: network effects. Your user-base, it's culture/community is every bit as important as the language and its implementation. Arguably, it's even more important.
One can say the following for many languages:
[X] is, in the opinion of many, not such a well designed language. But it's very useful to many people, in large part because of its community.
I think such network effects are responsible for the "worse is better" idea with regards to languages. Worse is not better. But a large active community makes better when it comes to a programming language.
So here's another reason why programming language design is hard: to be successful, you need to become popular.
I'm not sure that's an inherently "design" focused activity. In order to become popular, you have to design something that people want to use, which is captured by several of the points in the article (e.g. "talk to people"). Once "design" is done and "marketing" begins, then there's a whole different article to be written (one that would be equally interesting, but which I largely lack the expertise to write).
I'm not sure that's an inherently "design" focused activity.
The point is, that design factors other than good can come into play with regards to popularity. C syntax and "normal" operator precedence have nothing to do with a language being good. (Unless the language is C.) They have everything to do with a language being familiar.
Point 7, dont create new syntax for old semantics, is worth remembering, unless you have a significant simplification. In fact taking an old language and making it simpler is a very good excuse for a new language.
One thing not mentioned in the article is the importance of libraries. A new language doesnt have a lot of chance for success if users have to write everything from scratch. If you can piggyback on top of an existing infrastructure, like java, your chances are better.