Chunks of code

The first thing anybody learns to program is the ubiquitous hello world application. This simple application prints some variation of "hello world" to the screen. Depending on who you ask, the phrase hello world dates back to the early 1970s where it is used to demonstrate the B programming language, or even to 1967 where it appears in a BCL programming guide. In such a simple application, there is no need to worry about the structure of code. Indeed in many programming languages, hello world needs no structure at all, as shown in the following two languages:

• In Ruby:

  #!/usr/bin/ruby
  puts "hello world"

• In JavaScript (via Node.js):

  #!/usr/local/bin/node
  console.log("Hello world")

Programming modern computers was originally done using brutally simplistic techniques. Many of the first computers had the problems they were attempting to solve hardwired into them. They were not general purpose computing machines the likes of which we have today. Instead, they were built to solve just one problem of decoding encrypted text. Stored program computers were first developed in the late 1940s.

The languages used to program these computers were complicated at first, usually very closely tied to binary. Eventually, higher and higher-level abstractions were created to make programming more accessible. As these languages started to take shape through the '50s and '60s, it quickly became apparent that there needed to be some way to divide up large blocks of code.

In part, this was simply to maintain the sanity of programmers who could not keep an entire large program in their heads at any one time. However, creating reusable modules also allowed for code to be shared within the application and even between applications. The initial solution was to make use of statements, which jumped the flow control of the program from one place to another. For a number of years, these GOTO statements were heavily relied upon. To a modern programmer who has been fed a continual stream of warnings about the use of GOTO statements, this seems like insanity. However, it was not until some years after the first programming languages emerged that structured programming grew to replace the GOTO syntax.

Structured programming is based on the B?hm-Jacopini theorem, which states that there is a rather large class of problems, the answer to which can be computed using three very simple constructs:

• Sequential execution of subprograms
• Conditional execution of two subprograms
• Repeated execution of a subprogram until a condition is true

Astute readers will recognize these constructs as being the normal flow of execution, a branch or if statement and a loop.

Fortran was one of the earliest languages and was initially built without support for structured programming. However, structured programming was soon adopted as it helped avoid spaghetti code.

Code in Fortran was organized into modules. Modules were loosely coupled collections of procedures. For those coming from a modern object-oriented language, the closest concept might be that a module was like a class that contains only static methods.

Modules were useful for dividing code into logical groupings. However, it didn't provide for any sort of structure for the actual applications. The structure for object-oriented languages, that is classes and subclasses, can be traced to a 1967 paper written by Ole-Johan Dahl and Kristen Nygaard. This paper would go on to form the basis of Simula-67, the first language with the support of object-oriented programming.

While Simula-67 was the first language to have classes, the language most talked about in relation to early object-oriented programming is Smalltalk. This language was developed (behind closed doors) at the famous Xerox Palo Alto Research Center (PARC) during the 1970s. It was released to the public in 1980 as Smalltalk-80 (it seems like all historically relevant programming languages were suffixed with the year of release as a version number). What Smalltalk brought was that everything in the language was an object, even literal numbers such as 3, could have operations performed on them.

Almost every modern programming language has some concept of classes to organize code. Often these classes will fall into a higher-level structure commonly called a namespace or modules. Through the use of these structures, even very large programs can be divided into manageable and understandable chunks.

Despite the rich history and obvious utility of classes and modules, JavaScript does not support them as first class constructs. To understand why, one has to simply look back at the history of JavaScript from Chapter 1, Designing for Fun and Profit, and realize that for its original purpose, having such constructs would have been overkill. Classes were a part of the ill-fated ECMAScript 4 standard and they are a part of the upcoming ECMAScript 6, but for the moment they don't exist.

In this chapter, we'll explore some of the ways to recreate the well-worn class structure of other modern programming languages in JavaScript.