To produce any kind of taxonomy, you'd need to first ask yourself some questions:
- Are objects I'm going to put into whatever relationships defined properly?
- If so, do they actually exist?
- Am I limiting myself to only a specific kind of relationships between objects, or is there a set requirement for the system to use only legitimate relations?
Typically, when one hears a question like the one you asked, the expected answer makes several assumptions. For instance, it is natural to assume that since all of these are languages they must form a hierarchy under a more general concept of language, or that they partition the space of all languages, or that they are subsets of each other.
#Programming languages
Programming languages
Unfortunately, none of the above seems to be true. Perhaps only the programming languages have a definition most agree on. Programming languages are languages which encode programs. Encoding means that a word in the language can be interpreted as a program (a sequence of actions). Computer programming languages are a subset of these. Examples of non-computer programming languages: a grocery list, interpreted as directions for a buyer in a supermarket, DNA interpreted by transcribing peptides, an analogue musical record serving as a program for a tape recorder.
Computer programming languages are thusly the ones which program computers.
#Scripting languages
Scripting languages
Aren't well-defined. It is open to interpretation what this term means. Historically, it would seem that programming languages which did not have a compiler to produce machine code had been called this way. By today's standards this would put every popular programming language sans Assemblers into this category. Even the so-called low-level languages like C require a runtime with pre-existing procedures, thus the binaries obtained by compiling a C program aren't entirely machine code, but also call to the runtime every now and then.
#Markup languages
Markup languages
Aren't well-defined. Whenever the term is used, the intention seems to be to describe a programming language with very limited lexicon, primarily used to generate visual or audio image. It may be difficult to see XML as programming something, but if you look at Man or TexInfo markup, you'll see that the "special" characters are actually instructions of the interpreter.
It is also possible to give a "programming" interpretation for XML language, something that could go like this:
< := put interpreter in the reading node mode ! := if reading node, start CData/Comment mode else if not in read text mode, signal error -- := if in start CData/Comment mode, start comment else if in comment, put in end comment mode else if in end comment mode, signal error ... Bottom line: this division as of today, doesn't seem very meaningful, it can only give you some intuition as to what kind of language you are faced with, but it will not provide you with rigorous definition.