I never designed an actual programming language, but I imagine these would be some of the things to consider when doing so:
1. How much functionality do I want to (a) hardcode in the programming language itself, (b) provide as a “standard library”, or (c) leave for the programmer to implement?
If the programming language provides something, some users will be happy that they can use it immediately, and other users will be unhappy because they would prefer to do it differently. If I wait until the “free market” delivers a good solution, there is a chance that someone much smarter than me will develop something better than I ever could, and it won’t even cost me a minute of my time. There is also a chance that this doesn’t happen (why would the supergenius decide to use my new language?) and users will keep complaining about my language missing important functionality. Also, there is a risk that the market will provide dozen different solutions in parallel, each great at some aspect and frustrating at another.
Sometimes having more options is better. Sometimes it means you spend 5 years learning framework X, which then goes out of fashion, and you have to learn framework Y, which is not even significantly better, only different.
It seems like a good solution would be to provide the language, and the set of officially recommended libraries, so that users have a solution ready, but they are free to invent a better alternative. However, some things are difficult to do this way. For example, the type system: either your core libraries have one, or they don’t.
2. Who is the target audience: noobs or hackers?
Before giving a high-status answer, please consider that there are several orders of magnitude more noobs than hackers; and that most companies prefer to hire noobs (or perhaps someone in the middle) because they are cheaper and easier to replace. Therefore, a noob-oriented language may become popular among developers, used in jobs, taught at universities, and develop an ecosystem of thousands of libraries and frameworks… while a hacker-oriented language may be the preferred toy or an object of worship of a few dozen people, but will be generally unknown, and as a consequence it will be almost impossible to find a library you need, or get an answer on Stack Exchange.
Hackers prefer elegance and abstraction; programming languages that feel like mathematics. Noobs prefer whatever their simple minds perceive as “simple”, which is usually some horrible irregular hack; tons of syntactic sugar for completely trivial things (the only things the noob cares about), optional syntax that introduces ambiguity into parsing but hey it saves you a keystroke now and then (mostly-optional semicolons, end of line as an end of statement except when not), etc.
Hacker-oriented languages do not prevent you from shooting your own foot, because they assume that you either are not going to, or that you are doing it for a good reason such as an improvised foot surgery. Noob-oriented languages often come with lots of training wheels (such as declaring your classes and variables “private”, because just asking your colleagues nicely to avoid using undocumented features would have zero effect), and then sometimes with power tools designed to remove those training wheels (like when you find out that there actually may be a legitimate reason to access the “private” variables e.g. for the purpose of externalization).
Unfortunately, this distinction cannot be communicated openly, because when you say “this is only meant for hackers to use”, every other noob will raise their hands and say “yep, that means me”. You won’t have companies admit that their business model is to hire cheap and replaceable noobs, because most of their energy will be wasted through mismanagement and lack of analysis anyway. But when designing a language, you need to consider all the usual horrible things the average developer is going to do with it… and either add a training wheel, or decide that you don’t care.
3. It may depend on the type of project. But I fear that 9 out of 10 cases someone uses this argument, it is actually a matter of premature optimization.
I think your h4ck3r-versus-n00b dichotomy may need a little adjustment.
It’s true that some hackers prefer mathematics-y languages like, say, Haskell or Scheme, with elegantly minimal syntax and a modest selection of powerful features that add up to something tremendous.
But _plenty_ of highly skilled and experienced software-makers program in, for instance, C++, which really doesn’t score too highly on the elegance-and-abstraction front. Plenty more like to program in C, which does better on elegance and worse on abstraction and is certainly a long way from mathematical elegance. Plenty more like to program in Python, which was originally designed to be (inter alia) a noob-friendly language, and is in fact a pretty good choice for a first language to teach to a learner. And, on the other side of things, Scheme—which seems like it has a bunch of the characteristics you’re saying are typical of “expert-focused” languages—has always had a great deal of educational use, by (among others) the very people who were and are designing it.
If you’re designing a programming language, you certainly need to figure out whether to focus on newcomers or experts, but I don’t think that choice alone nails down very much about the language, and I don’t think it aligns with elegance-versus-let’s-politely-call-it-richness.
I never designed an actual programming language, but I imagine these would be some of the things to consider when doing so:
1. How much functionality do I want to (a) hardcode in the programming language itself, (b) provide as a “standard library”, or (c) leave for the programmer to implement?
If the programming language provides something, some users will be happy that they can use it immediately, and other users will be unhappy because they would prefer to do it differently. If I wait until the “free market” delivers a good solution, there is a chance that someone much smarter than me will develop something better than I ever could, and it won’t even cost me a minute of my time. There is also a chance that this doesn’t happen (why would the supergenius decide to use my new language?) and users will keep complaining about my language missing important functionality. Also, there is a risk that the market will provide dozen different solutions in parallel, each great at some aspect and frustrating at another.
Sometimes having more options is better. Sometimes it means you spend 5 years learning framework X, which then goes out of fashion, and you have to learn framework Y, which is not even significantly better, only different.
It seems like a good solution would be to provide the language, and the set of officially recommended libraries, so that users have a solution ready, but they are free to invent a better alternative. However, some things are difficult to do this way. For example, the type system: either your core libraries have one, or they don’t.
2. Who is the target audience: noobs or hackers?
Before giving a high-status answer, please consider that there are several orders of magnitude more noobs than hackers; and that most companies prefer to hire noobs (or perhaps someone in the middle) because they are cheaper and easier to replace. Therefore, a noob-oriented language may become popular among developers, used in jobs, taught at universities, and develop an ecosystem of thousands of libraries and frameworks… while a hacker-oriented language may be the preferred toy or an object of worship of a few dozen people, but will be generally unknown, and as a consequence it will be almost impossible to find a library you need, or get an answer on Stack Exchange.
Hackers prefer elegance and abstraction; programming languages that feel like mathematics. Noobs prefer whatever their simple minds perceive as “simple”, which is usually some horrible irregular hack; tons of syntactic sugar for completely trivial things (the only things the noob cares about), optional syntax that introduces ambiguity into parsing but hey it saves you a keystroke now and then (mostly-optional semicolons, end of line as an end of statement except when not), etc.
Hacker-oriented languages do not prevent you from shooting your own foot, because they assume that you either are not going to, or that you are doing it for a good reason such as an improvised foot surgery. Noob-oriented languages often come with lots of training wheels (such as declaring your classes and variables “private”, because just asking your colleagues nicely to avoid using undocumented features would have zero effect), and then sometimes with power tools designed to remove those training wheels (like when you find out that there actually may be a legitimate reason to access the “private” variables e.g. for the purpose of externalization).
Unfortunately, this distinction cannot be communicated openly, because when you say “this is only meant for hackers to use”, every other noob will raise their hands and say “yep, that means me”. You won’t have companies admit that their business model is to hire cheap and replaceable noobs, because most of their energy will be wasted through mismanagement and lack of analysis anyway. But when designing a language, you need to consider all the usual horrible things the average developer is going to do with it… and either add a training wheel, or decide that you don’t care.
3. It may depend on the type of project. But I fear that 9 out of 10 cases someone uses this argument, it is actually a matter of premature optimization.
I think your h4ck3r-versus-n00b dichotomy may need a little adjustment.
It’s true that some hackers prefer mathematics-y languages like, say, Haskell or Scheme, with elegantly minimal syntax and a modest selection of powerful features that add up to something tremendous.
But _plenty_ of highly skilled and experienced software-makers program in, for instance, C++, which really doesn’t score too highly on the elegance-and-abstraction front. Plenty more like to program in C, which does better on elegance and worse on abstraction and is certainly a long way from mathematical elegance. Plenty more like to program in Python, which was originally designed to be (inter alia) a noob-friendly language, and is in fact a pretty good choice for a first language to teach to a learner. And, on the other side of things, Scheme—which seems like it has a bunch of the characteristics you’re saying are typical of “expert-focused” languages—has always had a great deal of educational use, by (among others) the very people who were and are designing it.
If you’re designing a programming language, you certainly need to figure out whether to focus on newcomers or experts, but I don’t think that choice alone nails down very much about the language, and I don’t think it aligns with elegance-versus-let’s-politely-call-it-richness.