Hardware Reference
In-Depth Information
Markup languages describe the structure of the document
and how it's to be presented, but they don't tell you
anything about what's in the document. They are to text
documents what MIDI is to music: it describes the param-
eters of how to play a note without telling you anything
about the actual timbre of the note.
that the element be played on loading. There aren't HTML
commands to make anything happen once the page is
loaded. Markup languages usually rely on an outside actor,
like the user, to prompt action.
In contrast, programming languages initiate action based
on their own internal logic. Programming languages are
sets of commands that make things happen. Your job as
a programmer is to structure a set of commands to make
things happen they way you want them to.
You may have noticed that none of the transfer protocols
you saw used the characters
<
and
>
. That is one reason
why HTML uses these for tag markup. In parsing an HTTP
response, you can know that you've reached the main text
when you hit the first < character. Similarly, wiki markup
typically uses square brackets,
[
and
],
to enclose tags.
This helps distinguish it from HTML or XML markup.
That way, the same document can contain both types of
markup without causing conflict.
Programming languages have variables and arrays to
manage simple data, but they generally don't dictate how
you format complex data. The assumption is that you'll
come up with a data format or protocol, and then use
the programming language to read it byte-by-byte and
interpret it, or to assemble it byte-by-byte. Useful pro-
gramming languages come with libraries that can read and
write common data formats, which you've seen through-
out this topic. Most of the libraries you used were designed
to read or write a given data format. HTML5 represents a
good combination of a markup language (HTML and CSS)
and a programming language (JavaScript) that allows
designers and developers to create full applications in a
browser.
The bytes that form a web page can pass through a lot of
programs before they reach the end, each using a different
protocol. When each protocol is designed to take the
others into account—as you can see with HTTP, HTML,
and wiki markup languages—it's easy for each program to
parse the bytes that matter to it and leave the rest alone.
Most of the time, you don't need all the information you're
given in a typical information transfer. Knowing the proto-
col's structure and syntax not only helps you understand
what's said, it also helps you determine what to ignore.
Having to evaluate every chunk of data you receive can tax
your system (and your patience) quite a bit. But when you
know what you can ignore, you win. For example, consider
the HTTP POST request that Twilio sends in Chapter 10.
There's a huge amount of data there, more than 500
bytes. The only part you cared about, though, was the
Digits property, so your sketch just scanned through the
incoming stream of text, not saving anything until it saw
the string "Digits". That kind of scanning and ignoring is
central to good data parsing.
By now you've noticed that programming languages can
be somewhat unforgiving when you leave out a comma
or a semicolon, or get the capitalization of a word wrong.
This is because the text of the programming language
you write is actually a sort of markup language for the
compiler. The compiler reads your text and translates it into
machine language, so the text you write has to be machine-
readable, just as markup languages and data formats do.
The challenge to designing a good programming language
is similar to designing a good data protocol: you want it to
be efficient for the machine to read and interpret, yet still
readable by humans.
The key to interpreting any data protocol—from the most
simple comma-separated list to the most complex pro-
gramming or markup language—is to start by asking what
it's designed to do, and then look closely at its structure
to see how it's organized. As you can see, many different
protocols and languages share similar elements of punc-
tuation or structure, so knowing one helps you to learn
others.
X
Markup vs. Programming
Languages
Markup languages are primarily descriptive languages, not
always active ones. They are interpreted by the program
that displays them. For example, consider HTML, or
HyperText Markup Language. HTML describes what a
page should look like, but it doesn't have verbs to tell the
browser to initiate action. It might describe an element
to be displayed, such as a movie or audio file, and specify
