Last week, I penned a substantial article titled “Language and Metaphor: An Alternate View on Coding for the Web“, in which I discussed the various web languages and suggested that they all fall under one of four different categories – descriptive (HTML, XML), sensory (CSS), procedural (JavaScript, PHP) and request (SQL).

That was the first of a two part series on language and coding. This article is part two.

More Thoughts on Language and Coding for the Web

The specific direction of this article is a little less focused. Though I will ultimately come to a final conclusion, I would mostly like to consider coding as it relates to human (or “natural”) languages in several areas. First, I would like to look at the evolution of language, and the way different languages can be grouped into families. Then, I will consider the importance of syntax and grammar and the linguistic base of every coding language that I know of.

This will, admittedly, be a somewhat general discussion, but I think and hope that you may find it interesting.

The Evolution of Language

Human languages do not exist in a vacuum. Nor have any of them simply sprung out of nothingness fully formed and ready to be written or spoken by the masses. Instead, languages change and evolve. Often, they even collide, creating hybrid dialects which may go on to become new languages all on their own.

Take English, for example. Though I am simplifying somewhat, English began as the language of the Anglo-Saxons who invaded the British Isles in the late 5th century. It was primarily Germanic in origin, and eventually evolved into what is known today as Old English, which very few of today’s English speaking people could read without extensive study.

Later, English would be transformed again by contact with the Norse, and through the Norman conquest, which would infuse the language with a great deal of French-influenced words. As such, the language that we have today actually has several linguistic ancestors, and is related to other languages like French and (to a lesser extent) German.

Coding languages are much the same. HTML was developed from an older language markup language called SGML, which was in turn a standardized version of an older language called GML. In turn, HTML has also been extended in multiple versions (including the new HTML 5) and into XHTML.

Similarly, while languages like PHP, Perl and JavaScript are all vary from each other and serve vastly different purposes, they also share a common programmatic ancestor in the C language.

All in the Family

In a sense then, we can think of each of the four different types of coding languages that we looked at in the previous post as language families, within which the specific languages are all related to each other in some way. There are even some relations between families. PHP is a good example of this. While, at its core, it is a procedural programing language, it is also designed to integrate with blocks of HTML code, making it an ideal for serving up dynamically generated web pages.

All of these relationships can actually be a real advantage for would be coders, because it means that when you move from one language to another, you don’t necessarily have to learn everything from scratch. PHP, Perl and JavaScript all use a basic C syntax, which means that someone who is familiar with one will have a reasonable level of comfort when transitioning to another. Similarly, if you know HTML, moving to XHTML is fundamentally a matter of learning which tags have been deprecated and how to tighten up the code to make it validate according to the stricter XML specifications.

Many human languages are more closely related than we might think

To continue with our linguistic metaphors, it’s kind of like learning a sister language to one that you already know. Both French and Spanish ultimately derived from Latin, and I have often heard that if you know one, learning the other is relatively easy. While I don’t know very much Spanish, I did take one Latin class at university, and found that my fluency in French really helped. Most of the other students in the class were Classics majors (I was in the English program), and had little training in French (other than the high school classes that all Canadian students are required to take). Because I had been speaking French since I was six years old, though, I seemed to pick up the ancient Roman language more quickly, because I could relate it back to a something that I already knew.

When the semester was over, I decided that Latin was not something that I really wanted to pursue, but still ended up with one of the highest marks in the class. If it had not been for my background in French, though, I’m not sure that I would have been quite so successful.

Regardless, the point that I am trying to make here is that learning to code in multiple languages (HTML and XML, for example, or JavaScript and PHP) is not necessarily a matter of learning each one from scratch. Much of what you learn from one language can actually help inform what you need to know for another language.

Of course, this is especially true of different languages within the same basic family. If you learn the basic concepts of programming – defining variables, defining conditional statements, writing custom functions and such – what you learn can be generally applied from one programming language to another, from C to PHP, and even to Basic-based languages like Visual Basic. The key differences are found mostly in the names of various commands and functions, and (often slight) variations in basic syntax.

Syntax and Grammar

Syntax is important too, and the concept comes directly from the field of linguistics itself, where syntax is used to describe the formation of sentences – either written or spoken. At its most basic level, then, syntax is about word order, punctuation and the other rules of grammar, and varies from language to language.

A simple example is the difference between the use of adjectives in English and French. In English, adjectives almost always precede nouns, as in the example:

The large, red tree…

In French, however, it is common to see adjectives come after the noun as in

Le grand arbre rouge…

If we were to try to use the exact same French syntax in English, the sentence would read:

The large tree red…

And that’s a sentence that even Yoda wouldn’t use. So, as you can see, syntax is important for conveying meaning in language.

It is doubly so with coding. Computers are very powerful when it comes to processing raw data, but they’re really not all that smart. While bad grammar can make something difficult to read, in most cases the human mind is smart enough to be able to fill in the gaps and actually figure out what is being said. Again, Yoda is a prime example. The Jedi master might say something like:

Changes nothing this does.

This is not a proper sentence in English, but most people who hear (or read) it will be able to translate the sentence and understand that it is actually saying:

This changes nothing.

Computers don’t usually work this way, which means that you need to be much more exact with your syntax. For example, in JavaScript you would declare a variable like this:

var myName = “Matt”;

This command will be understood and executed by the interpreter. However, something like this will throw an error:

Variable myName is Matt.

As humans, we are able to recognize that these two commands are saying pretty much the same thing, but when it comes to coding “pretty much” might as well be “completely wrong”. The computer is expecting very specific commands that follow very specific rules. Any deviation from those rules will inevitably cause problems.

Fortunately, the syntax for coding languages tends to be far simpler than the grammar for a spoken language like English. There are typically a few simple rules for structuring your code, most of which are usually fairly simple to learn. There are few (if any) exceptions to these rules, too, unlike English which has at least a dozen ways of breaking any given grammatical rule.

I would suggest that if you can read and write, you can also code

This makes learning a coding language much simpler than learning another spoken language. In fact, I would like to suggest that anyone who can read and write can (with some commitment) also learn to code!

Seriously.

In truth, all “coding” is simply writing a series of instructions or schematics to be interpreted by the computer. If you can write basic instructions in English, or describe the various elements of a given object, I am confident that you would also be able to write code. All you need to do is learn the language and its syntax.

Based on English

Despite the fact that looking at a few lines of JavaScript can be as inaccessible to a non-coder as a few lines of Old English, the fact remains that every single major programming that I know of is actually based on English, which can make it a lot easier for English speaking people to pick up these coding languages.

If you understand the meaning of words like if, else, loop, for and while, then you will already have a solid grasp on many of the commands used to control loops and conditional statements in most languages. Similarly, functions like JavaScript’s alert(), prompt() and confirm() are all relatively self-explanatory, based simply on their names.

The same is also true of HTML, with tags like <title>, <blockquote> and <cite>, or for CSS properties like background-position, line-height or font-weight, which literally describe the properties that they control

The Masters… and the Rest of Us

Of course, while I do believe anyone who can write can also code, I don’t necessarily believe that everyone can really master the art. The vast majority of people in Western countries can read and write. In my opinion, far fewer can actually write well, and only a very rare few are what I would call masters of the language – those individuals who can weave their words with such poise and beauty as to be able to truly affect the hearts of their readers.

I think the same thing is true of coding. While I believe that any designer can develop into a competent coder, I don’t necessarily think that all of these people will necessarily be good coders. Moreover, only a very few will ever become the type of truly great coder who is capable the pure creativity and innovation that truly moves the internet forward.

Those coders are the Shakespeares, Hemingways and Hardys of this great digital playground we call the World Wide Web. Many of us designers and developers look up to them, perhaps with the hope of one day achieving a similar status. Until then, the rest of us can just keep learning and pushing forward, and getting a little better with every single day.

What are your thoughts? How do you relate the concepts of language and coding for the web? I’d love to hear your thoughts on this, so please feel free to leave a comment!

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd

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

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

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

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:


h2{
  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

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
  alert(newValue)
}


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

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.

Conclusion

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?

Exclusive Content

To thank you for subscribing to my feed, I am including exclusive, feed-only content for you at the bottom of each post!

Current Freebie Code - 7ev165dd