A few moments ago I posted some thoughts on Ian Bogost's concept of procedural rhetoric, and whether it might be applied to programming languages. In this post, I'm going to dive right in to some examples.
User Distribution Types
My argument, generally speaking, is that some types of code are more open - or want to be more open - than other types of code, and the determining factor is when and how the code is exposed and read. All modern programming languages have human readable source code, but the form an application takes when it is distributed to a user is not always human readable:
* Programs written in languages like C/C++, Pascal, Java, and their predecessors are compiled into binary code prior to distribution to users, i.e. they output machine-readable user distributions.
* Other languages - particularly scripting languages like Perl, PHP and Javascript, and markup languages like HTML and XML - output human-readable user distributions; the code necessarily remains in ASCII through the distribution phase and, in some cases, through the consumption phase.
When software is distributed only in machine-readable forms, then the source code is closed by default, and requires a conscious decision to make it open source - namely, to offer the human-readable source code alongside the application, along with a copyleft license.
When software can only be distributed in human-readable forms, on the other hand, it takes on open source properties by default, and requires a deliberate effort to enclose it; legally, of course, it is automatically enclosed by copyright, but the fact that the source code is part of the distribution makes it nearly impossible to prevent copying and modification of the code, without substantial legal effort.
Hello Case Study
Consider the following table, which shows how the source code of a simple application, using a simple code library, progresses from its origin to the user, in three different languages.
| |
C++ |
PHP (server-side script) |
Javascript (client-side script) |
| Library Source Code |
string get_hello() { return "Hello World"; } |
function get_hello() { return "Hello World"; } |
function get_hello() { return "Hello World"; } |
| Library Distribution |
Only function headers are readable: string get_hello(); Code is compiled into binary. |
All source code |
All source code |
| Application code |
cout get_hello(); |
print get_hello(); |
print get_hello(); |
| Application distribution |
all code compiled |
print get_hello(); |
print get_hello(); |
| User Agent (browser) |
N/A |
"Hello World" |
print get_hello(); |
| End User |
"Hello World" |
"Hello World" |
"Hello World" |
Each of these three "applications" does the exact same thing (except for the browser step, which I've omitted for C++ for simplification). The application calls the get_hello function from the library and prints the result to the user. The user, in the end, sees "Hello World" in all three cases.
The status of the source code, however, varies dramatically between the languages. C++ code is compiled before distribution, so the library source code is hidden from the application developer, and the application code is hidden from the user, as well as any intermediaries between the developer and the user. The application and the library are distributed in unreadable, binary form.
PHP, on the other hand, is a server-side scripting language, so the source code is not compiled until it is executed by the server. This means that anyone developing an application on top of a PHP library has access to ALL of the source code in the library, and anyone installing a PHP application on a server has access to all of the source code in the application (including the library). The code is only compiled at the moment of execution, on the server, and then the output is sent to the user -- there is never a binary version of the application, anywhere, and the source code is visible to everyone but the end user.
Javascript takes things a bit further - it is a client-side scripting language, so the source code is actually sent from the server to the client (browser), and compiled and executed by the browser. While the end user typically does not see the source code, it is not because it is unavailable, but simply because they don't need to see it; the source code is, however, only a few clicks away on any popular web browser.
Historical Factors
It's tempting to dismiss these distinctions as matters of circumstance with little rhetorical significance. Certainly, the very topic of politics in programming languages is flirting with the esoteric and pedantic. However, a quick glance at the history of these languages provides a hint of why there might be more to it...
C++ appeared in 1979 and was a direct descendant of the earlier languages C (1972) and B (1969). While ARPANET and other early networks were already in place by 1979, and personal computers were beginning to appear in homes, it would be another decade before the World Wide Web would be invented. Computing power was limited, so code had to be compiled before distribution, for the sake of execution speed.
PHP and Javascript, on the other hand, were both created in 1995, just as the Dot Com Bubble was beginning to inflate. Moore's law, in the form of the Pentium processor, had delivered sufficient computing power for run-time execution of scripting languages (both client and server side), while a new bottleneck (modem bandwidth) diminished the importance of execution speed, and the sudden importance of websites brought programming out of the science lab and onto the personal computer.
There's certainly more to be mined from the history, but there is no doubt that the technological landscape in 1995 impacted the types of programming languages that were being created, and the development processes they would foster. So, let's look at some of these processes.
Processes
First, some anecdotal thoughts...
When I learned to write C and C++, I learned it from a textbook in a programming course. The first actual C++ code that I wrote was probably a simple "Hello World" application like the one above, followed by a program that printed the numbers from 1 to 100, followed by a program that checked whether a string of letters was a palindrome. In other words, I wrote code from scratch and completed assignments oriented around learning, not production. When I had troubles, I was likely to turn to classmates and reference books.
When I learned to write PHP, I learned from code. I downloaded some open source application (osCommerce, perhaps?) and, when it didn't quite do what I wanted, I started editing code. I didn't read a book, and I didn't write from scratch - I was focused on production, not learning. When I struggle with PHP, I always turn to Google.
What I think this suggests, at least anecdotally, is that there is a relationship between (1) whether programs in a particular language are distributed in human readable code form, (2) how programmers learn, develop, and collaborate when working with that language, and (3) whether the resulting programs are distributed under open-source licenses.
Determining the validity of this relationship is likely to be a significant part of my research over the next few months.