I understand about avoiding unclear terms, but I think "scripting language" actually does serve a useful purpose as an umbrella term for all those kinds of languages. It's not technically precise, but if you describe a language as "a scripting language", it does clear away a large part of the design space (not Haskell, C, Forth, or J) and tells you that this is meant to be user-friendly as opposed to performant, terse, high-assurance, etc. That's worth something. Of course if someone is still interested, then you want to get more precise pretty quickly. I think Wren does well enough at that on its landing page.
> user-friendly as opposed to performant, terse, high-assurance, etc.
Strange, I really don't see that as an axis worth recognizing with that, or any, terminology (but whenever I bring this up I get voted down, so I guess more people agree with you.)
I think the core of my disagreement is that, just because a language is user-friendly, that does not mean that it is not a "professional" or "high-assurance" language. I'm not saying that you are using it in this fashion, but I believe that with the terminological strategy you are suggesting, the term becomes a pejorative, wielded by those who use (C/C++/Rust/Java/Haskell/etc) as a subtle put-down to people who are using more user-friendly languages.
Related, I think it's a rather confusing axis that doesn't fit the space of programming languages well:
Go is user-friendly (I gather) and verbose, but performant and high-assurance.
Python is user-friendly and terse, but non-performant and low-assurance (I'm a python programmer, but the run-time bugs put it in that category if we're comparing to statically typed languages). A lot of website HTTP handlers are written in Python, so "scripting" language seems like a very poor description for what it's doing there.
IMO reasonable axes that are worth recognizing with terminology include interpreted vs compiled, statically vs dynamically typed, weakly vs strongly typed, but do not include {user-friendly} vs {performant, terse, high-assurance}.
It might make more sense if you think of "scripting language" as being a statement of intent than a technical classification. I have seen it used as a perjorative, which I agree is stupid.
More generally, performance, ease of programming, correctness, etc are goals, whereas typing systems and compilation strategies are techniques that can be used to reach those goals. "Axes" is probably overthinking it, as none of these criteria or properties are linear, but terms for all of them can be worthwhile if used to answer the right questions.
Since goals have a strong influence on technical properties, it's not completely crazy to summarize a language's technical features in terms of its goals. "Scripting language" makes sense as a description for languages that emphasize ease of programming (with overtones of interacting with a larger system) over other features. You also have a clue about a language called "high performance": probably not interpreted or dynamically typed (although exceptions include kdb, arguably Java and Julia).
Finally, not every term needs a rigorous definition in terms of more primitive terms. Sometimes you just need a name for a category that everyone kind of knows is there. This is probably the more realistic origin of the term, though I do think the underlying reason for that category existing is mostly the goal-driven one described in my previous paragraph.
Note: In the bit you quoted, I certainly didn't mean to say that "user friendly" was necessarily opposed to all those other goal properties. I was just trying to give examples of other things you might want to prioritize in a design.
