But using plain English to explain JS makes as much sense as using CSS to explain a piece of classical music.
Fortunately the coding language of English includes a handy framework called Metaphor™. This blog series, metaphorically speaking, is a guide to utilising Metaphor™ to describe some of the principles and use-cases of the common web development languages to both beginner programmers and people who regard computer code as impenetrable alien gobbledygook.
No Metaphor™ project is ever perfect, but they are all open source and collaborative, so hopefully you will be able to adapt my source code to your own uses, as well as make a few contributions yourself…
CSS (Cascading Style Sheets)
A standard that describes the formatting of markup language pages (HTML, XHTML, XML, etc). Enables developers to separate content and visual elements for greater page control and flexibility.
We can say:
Imagine you have hired an interior decorator to completely make-over your house. You’ve got very specific taste and want the job to be done exactly to your specification, but unfortunately you’re going on holiday the only week the decorator is available.
To make sure things go according to your plan, you create a folder containing detailed descriptions of various styles you want used throughout the house: a recurring colour motif, a certain style of picture frame, a particular lighting effect, and so on.
You give each ‘style’ a codename, aka a ‘class’, sometimes creating several variations on a style for use in different contexts. Then you go round your house and pencil the names of one or more classes onto each ‘element’ of your house (walls, floor, skirting board, etc).
This is exactly what CSS files and class names in HTML do. Of course, how closely your instructions are going to be followed depends on the quality of the decorator. Unfortunately the metaphor breaks down here because the user chooses the decorator when they pick a web browser, which is a bit like redecorating your home every time you have house guests. Fortunately browser standards and support are better now than ever, so you are far less likely to let a cowboy like Internet Explorer 8 loose in your home.
SQL (Structured Query Language)
A domain-specific language used in programming and designed for managing data held in a relational database management system (RDBMS), or for stream processing in a relational data stream management system (RDSMS).
We can say:
Imagine all of the internet is down and you desperately need to send a spreadsheet to someone on the other side of the world (perhaps because this spreadsheet will help them fix the whole world’s internet!). Fortunately the phones are still working, so you call up your colleague and begin telling them how to manually recreate the spreadsheet at their end.
You’d start by saying something like, “Yo, create a table called ‘customers’ with these column headers…”
Then, “Ok homie, now insert the following values into ‘customers’, column by column, row by row…”
Occasionally your contact might respond with an error: “Hold up dawg, you be trippin’ – you can’t insert a text value into this column! A minute ago you told my ass it should only contain numbers, fool!”
When the spreadsheet is completely transcribed, someone else in another part of the world comes on the line: “Fo’ shizzle, get me the ‘name’, ’email’ and ‘address’ column values from the ‘customers’ table where the ID is equal to X.”
This – authentic urban slang aside – is how SQL works, except it is written instead of spoken. An SQL file or script contains instructions of how to construct, amend and/or read a database and the only real difference between SQL code and an actual conversation is that you probably wouldn’t shout your CREATE, INSERT and GET commands over the phone… unless you a trill hustler, y’all!
A lightweight, interpreted, or just-in-time compiled programming language with first-class functions … a prototype-based, multi-paradigm, dynamic language, supporting object-oriented, imperative, and declarative styles.
We can say:
Imagine you are the director of a play. When you start rehearsing, you’re naturally going to need to give all your actors instructions for what they should do. But there’s a catch – this play involves lots of audience participation.
So for each actor, you need to second-guess what the audience members might say or do when they interact with the performance. For each point of interaction, you’ll ask the actors to listen for the input from the audience, then define what actions they should take, allowing for certain parameters and specifying a default behaviour where applicable.
You might also tell the actors to play off each other, so when one cast member performs a certain action, another player is going to react to it in some predetermined way, possibly setting off a sequence of events crucial to the plot.
This can range from a simple ‘curtain up’ cue like
window.onload to complex instructions such as: “If the audience member asks you to recite a speech and you know the speech, recite the speech; else ask them to choose another speech from your repertoire; if they don’t come up with any sensible suggestions, do the ‘What a piece of work is man’ bit from Hamlet and hope for the best…”
More of this blog series to come…