I am available for freelance work - HIRE ME

Language and Metaphor: An Alternate View on Coding for the Web

posted by Matt Ward on Mar 5, 2010.

Coding websites is often thought of as being a highly technical craft, but that fact remains that the foundation of all coding is the languages that are used to do it. In this first post in a two part series, we are going to take a different view of coding for the web, by looking at various coding languages as they relate to actual, human language.

Earlier this week, I posted an article by Amber Weinberg, entitled “Should Designers Know How to Code? Thoughts From a Developer.” In that article, Amber writes about her own experiences as a front-end developer and comes to the basic conclusion that, while not all designers actually need to code their designs, they should understand the basics of what is and is not possible (or at least desirable) when it comes to web design.

Language and Metaphor: An Alternate View on Coding for the Web

Language and Metaphor: An Alternate View on Coding for the Web

She also notes that coding “is another language.” As a designer with a background in literature, this just added fuel to something that I had already been thinking about: namely the idea of how coding languages like HTML, CSS or JavaScript are related to human languages like English.

I’m no master coder, but I’ve been working on websites for well over 10 years now, and in my experience there are essentially four types of languages at work on the internet (both font-end and back-end). These include mark-up, style sheets, programming and database queries. Each type of language has a different general purpose, which is actually reflected in its general syntax and structure. In this article, which will be the first in a two part series, I want to look at these four types of coding languages, and consider their purposes through various metaphorical comparisons to human (written/spoken) language.

Some Thoughts on Language

First, though, I would like to consider the more general purpose of all languages, which is to communicate. For the purpose of this article, I have a series of ideas that I want to present to you, my readers. To do so, I carefully select strings of words and punctuation with which to form sentences. These sentences then form paragraphs. As you read, you recognize the words, then the combination of words, the sentences and so on. As you recognize, you interpret and as you interpret, you derive meaning.

If the language is used properly (and I hope that it is), the message that I want to convey is delivered from me to you.

This is the fundamental purpose of all language, and the various coding languages that we are going to look at are really no different. Each exists to communicate some message from one entity to another. The differences emerge in the form of what those entities are, and the message that is being communicated.

Mark Up – Descriptive Language

Let’s start with the granddaddy of all web language types: mark-up. The most common form of mark-up has to be HTML, in its various forms and derivatives. That’s where I started with coding for the web, and I’d say it’s a pretty safe bet to say that it’s where almost every other web developer started too. Other forms of mark up include XML, or the hybridized XHTML, which is essentially just HTML that conforms to the more rigid syntactical rules of XML.

HTML is probably the most well known form of mark-up

HTML is probably the most well known form of mark-up

Regardless of what specification we’re talking about, though, the purpose of all markup – in it’s purest form – is simply to describe content. A document is marked up with various tags, which should do nothing more than indicate the purpose of each part of the document. Consider this simple example.

<h2>Introducing <i>The Second Dive</i></h2>

<p><i>The Second Dive</i> is a completely fictional novel that I have made up to write this simple paragraph about. There may actually be a novel titled <i>The Second Dive</i>, but I have never heard of it, so I am just going to write this out for a few more words. Now it is finished</p>

What we have here is just some really basic HTML (without the proper document tags, of course). First, we define a second level heading with the <h2> tags (opening and closing). Everything that falls between these tags is considered a second level heading. Next, we define a single paragraph using the <p> tags. Again, everything between those tags is considered to be a single paragraph.

You will also notice that I’ve used the <i> tag, which indicates that its contents should be italic. I’ve done this because it is proper to set the title of any novel, film, play or other “long” work in italics. I’ve also done it because it gives me a great excuse to talk about description versus formatting.

Remember, mark-up is a descriptive language, and each tag is like a different description. We could also use the <cite> or <em> tag to make something appear in italics, but those tags have different meanings than the <i> tag. The <em> tag is basically saying that there should be emphasis placed on its content. Conversely, the <cite> tag defines its content as the citation for a quote.

Neither of these apply to our title. We don’t want the title to be emphasized, and it’s not quite a citation either. As such, the <i> tag likely provides the best description for the title of our fictional book. Since mark-up is all about describing our content, then, the <i> tag is clearly the best choice!

Styles – Sensory Language

If mark-up is basic descriptive language, style sheet languages like CSS (Cascading Style Sheets) are the sensory language that gives life to that description. As such, it is an add-on type of language, that expands the description of a given element.

I like to think of it like this. Mark up is like a noun, which literally states what something is. For instance, I can point to an object and state that it is a car. In doing so, I have described what it is, and (if you’ll allow me to extend the metaphor) “marked it up”.

CSS adds on to the structure created by HTML mark-up

CSS adds on to the structure created by HTML mark-up

Styles, however, are more like adjectives, which add extra values or properties to the noun. Now, if I point to the same object and state that it is a large, red car, the basic understanding of what the object is doesn’t change – it is still a car. However, we also have additional descriptive information that tells us that it is large and red.

We can think of styles in much the same way. They hook into HTML and add in various bits of information (predominantly for visual rendering) that exist independently of the mark-up itself. For example, this following rule would add extra information to the second level heading from the our HTML sample:

  color: red;
  font-size: 1.3em;
  font-weight: bold;

In a nutshell, this styling indicates that all <h2> tags are also to be coloured red, rendered at 1.3 times the basic font size and to be bolded. To translate into relative English, whenever a browser sees and <h2> tag, it understands and renders the content as a large, red and bolded second-level heading. The style adds to the mark-up to make it richer.

A One Sided Relationship

It also helps to understand the relationship between mark-up language and styling language as being entirely one sided. Styles cannot function without mark-up, but the reverse is not exactly true. Let’s look at another literary example. Currently, I am reading the novel The Awakened Mage by Karen Miller. Allow me to quote the opening passage.

With one callused hand shading his eyes, Asher stood on the Tower’s sandstone steps and watched the touring carriage with its royal cargo and Master Magician Durm bowl down the driveway, sweep around the bend in the road and disappear from sight. Then he heaved a rib-creaking sigh, turned on his heel and marched back inside.

Now, let’s look at the same passage with all of the adjectives (or adjective-like phrases) removed.

With one hand shading his eyes, Asher stood on the Tower’s steps and watched the carriage with its cargo and Master Magician Durm bowl down the driveway, sweep around the bend in the road and disappear from sight. Then he heaved a sigh, turned on his heel and marched back inside.

It’s not much different, and still completely readable and understandable. It’s just missing some of the finer details that help contribute extra meaning to the passage. Now, let’s look at it with the nouns (and pronouns) removed.

With one callused shading his, stood on the and watched the touring with its royal and bowl down the, sweep around the in the and disappear from. Then heaved a rib-creaking, turned on his and marched back inside.

Without the nouns, the paragraph becomes completely non-nonsensical and looses all meaning, and the adjectives have absolutely nothing to work on. The same concept applies to HTML and CSS. While HTML can exist without CSS and still make sense, CSS without HTML is like throwing a bunch of adjectives onto a page without a single noun to give them context.

Which, of course, serves to emphasize the importance of the mark-up over the styling in design. Good, clean and well-structured HTML should always proceed the creation of equally good, clean and well-structured CSS.

Scripting – Directive Language

With that little aside out of the way, let’s get back to the matter at hand and look at the next type of language: scripting, which could also be called programming. This one probably has the largest series of specific languages that fall beneath it, including JavaScript, PHP, Perl, ActionScript and so forth. Each of these languages are unique in their own right, have varying syntax, functions, methods and core functionality.

JavaScript is a popular form of scripting

JavaScript is a popular form of scripting

However, like all programming languages, they share the common bond of being procedural, or as the title to this section suggests, directive. The purpose of any script is to provide a series of directions which, when followed, will yield a desired result.

This differs dramatically from mark-up and styling languages, which describe what something is and what it is like. Directive or procedural language is more like the instructions that came with your last IKEA purchase (though hopefully vastly more helpful). For example, here is the code for a simple JavaScript function.

function doSomething(myValue){
  newValue = myValue+5;
  newValue *= 2
  newValue /= 3

If you don’t understand JavaScript, this function is basically a series of instructions, that go something like this:

  • accept a value
  • add 5 to that value
  • multiply the resulting value by 2
  • divide the resulting value by 3
  • display the resulting value through an alert box

That’s it – just a simple set of procedures acting upon a given value. And that’s really the basic premise of all the programming or scripting that I have ever done. It’s just a matter of writing a series of steps that explain to the computer how to accept, transform and return various bits of information.

Obviously, I’m simplifying a little bit, but probably not as much as some people might think. If you can write a basic set of directions about how to get from your house to your favorite pizza joint, you’ve already written a basic non-computer-based program. To move to programming on the computer – and specifically on the front or back-end of a website – is just a matter of learning how write appropriate commands in the right language!

Query – Request Language

Last of all, we have query languages, or what I am calling request languages. Chances are that many of you will never even need to work with this kind of thing, but I think that it’s at least important to know that exists. Basically, a query language, like SQL, is a way for a program or application to communicate with a database, appending, extracting or modifying information within specific tables.

The popular phpMyAdmin system uses SQL to manage databases

The popular phpMyAdmin system uses SQL to manage databases

I like to think of it kind of like a grocery list. Let’s suppose you want milk, bread, peanut butter and some eggs from the grocery store. You write this all down on a list, give the list to your significant other and send them off to the store. Your significant other (being so kind), enters the store, checks the list, retrieves the appropriate items and finally returns to you with everything you asked for.

That’s pretty much exactly what a query language does, except that instead of a store, it’s a database, and instead of groceries, it’s retrieving data. Here is an example of an SQL command for extracting data from a standard WordPress database

SELECT `post_author` , `post_content`
FROM `wp_posts`
LIMIT 0 , 30

Basically, this list is saying that we want the information from the post_author and post_content fields in the wp_posts table. It also imposes a limit to only retrieve the information from the first 30 records. Just like a grocery list.

Admittedly, though, the grocery list metaphor is not perfect, since query languages like SQL can do so much more than just retrieve data. They can also add, remove, move and update data across multiple tables. Still, the basic concept is the same. The query has a single directive (select, add, drop etc), a listing of various bits of data and optional conditions to dictate and/or restrict what data is to be handled.

In one basic sense, a query can be similar to a script in that it dictates a command, and can actually contain some basic functions to manipulate the data. However, they key difference lies in the fact that a query only ever has a single command (though that command can be extremely complex), whereas a script or program generally contains multiple commands, which form the bulk of the procedure.


So there you have part 1 of this series. I hope to have accomplished something here for both coders and non-coders alike. For designers who don’t know how to code their own designers, I hope that this article has shed some light on the different types of coding languages that exist on the internet, and perhaps provided you a context through which to understand their various and different functionality within a website.

For coders, I hope to have provided a similar context, and allowed you to look at what you do from a different, language-based perspective. At the very least, I hope that I may have provided you with some helpful metaphors to help explain what you do to family in friends!

Of course, as I’ve already mentioned, this is only part 1 of a two part series. The second article will follow early next week, and will draw further parallels between scripting languages and the written language, including the roles of logic, syntax and grammar, and why they are all important.

In the meantime, though, I’d love to hear your thoughts on this one. Which types of coding are you the most familiar and/or comfortable with? Is there another type of language that I missed (I hope not), or a different metaphor that you think better explains one of the four types outlined above?

Post A Comment

Also from Echo Enduring Media:

An Unfolding Tale

About the Author

Matt Ward is a digital artist who lances freely under the moniker of Echo Enduring Media, and specializes in graphics design, illustration and writing. He is also the Creative Director for Highland Marketing, a creative direct marketing company based out of Waterloo, Ontario. You can follow Matt on Twitter

Like this post? Help Promote it!


Mar 5, 2010

Michal Kozak says:

Great job, Matt.

What’s great about this article? Everyone can understand it.

I like how you came up with these metaphors so even non-coders/programmers can understand the sense/concept.

As for me, I’m most familiar with what you call “descriptive”, “sensory” and “scripting” languages.

Metaphor I’m using when I’m explaining HTML and CSS:

– When you’re build a house, first thing you’re doing is building some foundations, the skeleton. So you have a building, you have some wholes where the doors and windows will go and so on. That is what HTML stands for.

Then you decide about many things – you decide about the color of the house, the colors of the rooms inside the house, the shape and size of the windows and doors, the style of door handle, color of the roof tles, etc. That is what CSS stands for.

Mar 8, 2010

ximi says:

I really, really enjoyed this article. You found some great parallels between coding and actual language.
I’m looking forward two part 2.

Mar 12, 2010

Michael Østergaard says:

Incredible article you wrote here. I find it interesting the way you make these parallels between languages.

I like your descriptive and creative articles. Keep up the good work ;)

Mar 12, 2010

Seba says:

Very descriptive and useful for non programmers!

Mar 12, 2010

sickdesigner says:

Great post Matt,

This kind of bridging the world of code and actual language is something that, not only makes sense, it creates more easily maintainable work.
I think you already read this, but some of the other people reading this might find useful my post on Super Semantic Tags: http://sickdesigner.com/index.php/2010/html-css/truly-semantic-tags-and-html5/
It’s basically a way to add even more meaning to an otherwise less than natural language.

Mar 13, 2010

Hornergraphic says:

Hey Matt, great post, highly informative and wonderfully accessible!

One statement from a developer that really helped me get my head around how do think about the language of code was to think of binary as the most tangible language, and English as the most abstract.

So, any development problem can be approached as the task of taking a statement in plain English first (a functional specification), the languages/directives can be defined second (a technical specification), and then the language can be written (the actual code).

Mar 15, 2010

Taylor Frassinelli says:

Were you using Espresso for your code demos?

Mar 16, 2010

Bert says:

Great post, I’m sure I will remember this when explaining my daily work to my grandparents the next time.

A query language example that i like is:

SELECT eggs, ham, coffee
FROM canteen
WHERE eat_by_date > curdate()

Mar 27, 2010

Amadou M. Sall says:

Awesome post, Matt. As a linguist who likes to dabble in coding (HTML and CSS – I always used to build my own sites, but now I’m all WordPress CMS!), I really enjoyed it.

Jul 11, 2010

Web Designer says:

Thanks for the article, Matt.

As a web developer who lives mostly at the coding end of site development, it is often difficult to communicate with clients who tend to think of a website simply as a flashy colourful and perhaps animated thing, rather than giving sufficient thought to the underlying form and function of a site design. Let alone give thought to repercussions of how underlying form will affect their business, their online presence and website accessibility.

Mar 10, 2011

Flash Forum says:

Nice perspective!

Leave a Comment

Copyright © Echo Enduring Media 2009-2015