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.
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.
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”.
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:
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
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.
newValue = myValue+5;
newValue *= 2
newValue /= 3
- 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.
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`
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: