In Z Beginning...
As we saw, the beginning of the industrial age brought with it the kind of complexity that would reduce human calculators to tears. We're just not made to do complex counting and equations, you know? Well, that's just what Konrad Zuse of Germany thought: Why should we have to do equations that machines can do? So he went and built the Z1, a first-generation computer featuring mechanical memory, arithmetic units and a binary based language system (in both input , processing and output).
Basically, the Z series machines processed input via punched tape. As long as the user submitted valid arithmetic in binary form, the computer could handle it. As such, these machines are considered the first freely programmable computer based on binary floating point numbers and a binary switching system.
This "first generation" method of interacting with machines is called coding in a "machine level" language, since the input format exactly matches the computer's processing format.
A Bit of Theory
If your going to write a masters thesis, try to make it as groundbreaking as Claude Elwood Shannon's A Symbolic Analysis of Relay and Switching Circuits, (MIT, 1937). This paper made Shannon pretty much the father of electronic digital computation. In the first part, Shannon uses concepts from boolean algebra and binary arithmetic to demonstrate how to simplify the arrangement of electromechanical relays used in telephone routing switches. Then he proceeds to show the real value of the relationship between binary math and these electromagnetic structures: look! since we can represent boolean algebra functions with the layout of electronic circuits, then we can use the arrangements of electronic relays to solve complex math problems!
Connecting the Dots
So far, both Zuse and Shannon represent hardware innovators, and as such, their machines only work when you speak in "their" language: the language of 1's and 0's (or left's and right's, or on's and off's, etc.). This language is effective and fast--but it is also hard to write and debug. Good thing there's been some software innovations to match and complement these hardware based achievements; otherwise I'd be writing and you'd be reading only 1's and 0's!
Resources
Zuse's son documents his father's career
Wikipedia on Shannon
Wikipedia on the History of Computers
Tuesday, April 22, 2008
Monday, April 21, 2008
History of Computer Programming, Part 1
Humans have been using machines to get things done for a long time. However, they haven't been able to program those buggers to do those things automatically until relatively recently.
Though I haven't done a tremendous amount of reading on the subject, it appears most computer historians agree the first legit programmed machine was Joseph Marie Jacquard's textile loom, which would weave according to templates defined by a series of punched cards.
Somewhat later, Herman Hollerith struck upon the real value of punched cards for basic computing in order to solve a major national problem. See, by 1980 the United States was growing at such a rate that the constitutional mandate to record and process a national census every ten years was approaching the line of impossibility. Since the results had to be counted and processed by hand, the interval between census and result was exceeding the ten year limit! Quite the problem.
Well one day, Hollerith is sitting on the train, watching the conductors issue tickets. He sees how they are recording basic information about each traveler by hole-punching the ticket. Then, all of the sudden, "punch!" went the conductor's machine and "ding!" went Hollerith's brain: ah ha!
Hollerith realized that, given the proper material and the right electronic apparatus, the information recorded on a punch card could be "read" and processed by a machine. This would work well with counting operations especially. Hmmm, what major national crisis needed some quick counting?
So Hollerith constructed a machine for counting people and their basic attributes. A insulated card would be placed over a series of mercury pools corresponding to all the possible punch holes. Then a series of spring loaded wires (placed similarly) would be brought down over the card. Add some electricity, and bam!, holes = electrical circuits which power a specific counter to advance.
So began Hollerith's corporate counting endeavors, which formed into Computing Tabulating Recording Corporation (CTR), and which, in 1924 became IBM (International Business Machine Corporation).
What does Hollerith's counting machine have to do with computer languages? Well, as we'll see in the next article, Hollerith built a machine that counted according to a very very basic assembly language, one that "spoke in" the exact literal language of the machine's processes themselves.
Though I haven't done a tremendous amount of reading on the subject, it appears most computer historians agree the first legit programmed machine was Joseph Marie Jacquard's textile loom, which would weave according to templates defined by a series of punched cards.
Somewhat later, Herman Hollerith struck upon the real value of punched cards for basic computing in order to solve a major national problem. See, by 1980 the United States was growing at such a rate that the constitutional mandate to record and process a national census every ten years was approaching the line of impossibility. Since the results had to be counted and processed by hand, the interval between census and result was exceeding the ten year limit! Quite the problem.
Well one day, Hollerith is sitting on the train, watching the conductors issue tickets. He sees how they are recording basic information about each traveler by hole-punching the ticket. Then, all of the sudden, "punch!" went the conductor's machine and "ding!" went Hollerith's brain: ah ha!
Hollerith realized that, given the proper material and the right electronic apparatus, the information recorded on a punch card could be "read" and processed by a machine. This would work well with counting operations especially. Hmmm, what major national crisis needed some quick counting?So Hollerith constructed a machine for counting people and their basic attributes. A insulated card would be placed over a series of mercury pools corresponding to all the possible punch holes. Then a series of spring loaded wires (placed similarly) would be brought down over the card. Add some electricity, and bam!, holes = electrical circuits which power a specific counter to advance.
So began Hollerith's corporate counting endeavors, which formed into Computing Tabulating Recording Corporation (CTR), and which, in 1924 became IBM (International Business Machine Corporation).
What does Hollerith's counting machine have to do with computer languages? Well, as we'll see in the next article, Hollerith built a machine that counted according to a very very basic assembly language, one that "spoke in" the exact literal language of the machine's processes themselves.
Programming Track Beginnings
Web development requires more than a simple knowledge of networking facts and protocols--it calls for a knowledge of software development. That's why I'm kicking off a branch of research into understanding the origin and development of computer programming!
Here are some initial questions to get this going:
1) What do I need to understand about computer hardware in order to have the concept of software and software development cease to be a black box?
2) Why did software development emerge when and where it did?
3) How do we begin to make sense of the generation and development of programming languages?
4) What are the different kinds of programming languages?
5) How do we understand the relationship between programming languages and the web?
6) What are other good questions to ask?
Here are some initial resources to get this going:
Here are some initial questions to get this going:
1) What do I need to understand about computer hardware in order to have the concept of software and software development cease to be a black box?
2) Why did software development emerge when and where it did?
3) How do we begin to make sense of the generation and development of programming languages?
4) What are the different kinds of programming languages?
5) How do we understand the relationship between programming languages and the web?
6) What are other good questions to ask?
Here are some initial resources to get this going:
- A visual time-line representing the history of programming languages to the end of 2007
- A companion link-list to descriptions of all the languages in the time-line
Wednesday, April 16, 2008
A Few Gaps Filled
So far the we've just been watching the train wiz by--trying to take as much in as possible. Time to review the tape just a bit.
Transport Layers
TCP isn't the only transport layer, that honor is shared with UDP (User Datagram Protocol). Both contain information concerning sending and destination ports, they differ in how they handle packet sequencing. Where TCP insures packets are processed in the order sent, UDP just sends them on to the application in the order received--no insurance, just pure raw speed. UDP works well when you're sending/receiving a single packet or when you're streaming audio or video for recreational use.
Ports
Remember the mail analogy? Well, if the IP address is like the address to your building, a port number is your name. All incoming mail has your name on it because all the mail you sent out has your name on the top left, so those catalog companies know whom to send stuff to.
The concept of port is borrowed from the physical ports on your machine--those interfaces that allow you to connect machine to machine with various wires and such. But port numbers are simply that, numbers that are used to identify the sending and receiving nodes of internet applications.
Port numbers range from 65,535 to 0 since they are represented by 16 bits. Numbers 0-1023 are restricted for common internet application use (HTTP, FTP, ETC).
Servers generally receive HTTP requests on port number 80 (standard just to say port 80). Client applications, on the other hand, define a new and unique port for each data element coming in. Think of it as an insanely fast moving deli line at your local grocery store, every part of the request gets its own number.
The Data Link Layer
What's under IP? Good question: it's the data link layer. Let's not get into it much here, just know that every physical device on your network is assigned a Media Access Control (MAC) address to identify itself on a network. The MAC address is usually burned into the machine during manufacturing, like a fingerprint or something. OK, there it is, now you know.
Sockets
A "socket" is a class of software that is used to "bind" a connection between two applications into a persistent connection. For example, it is the deal that is sealed after TCPs three way handshake: client reaches out to shake the hand of server, server reaches back to shake the hand of client, client and server shake the shake and establish a socket connection that enables their a working and productive relationship. How nice.
Resources
From java.sun.com
RandomGuy James again
Socket stuff from java.sun.com
About.com on Sockets
Transport Layers
TCP isn't the only transport layer, that honor is shared with UDP (User Datagram Protocol). Both contain information concerning sending and destination ports, they differ in how they handle packet sequencing. Where TCP insures packets are processed in the order sent, UDP just sends them on to the application in the order received--no insurance, just pure raw speed. UDP works well when you're sending/receiving a single packet or when you're streaming audio or video for recreational use.
Ports
Remember the mail analogy? Well, if the IP address is like the address to your building, a port number is your name. All incoming mail has your name on it because all the mail you sent out has your name on the top left, so those catalog companies know whom to send stuff to.
The concept of port is borrowed from the physical ports on your machine--those interfaces that allow you to connect machine to machine with various wires and such. But port numbers are simply that, numbers that are used to identify the sending and receiving nodes of internet applications.
Port numbers range from 65,535 to 0 since they are represented by 16 bits. Numbers 0-1023 are restricted for common internet application use (HTTP, FTP, ETC).
Servers generally receive HTTP requests on port number 80 (standard just to say port 80). Client applications, on the other hand, define a new and unique port for each data element coming in. Think of it as an insanely fast moving deli line at your local grocery store, every part of the request gets its own number.
The Data Link Layer
What's under IP? Good question: it's the data link layer. Let's not get into it much here, just know that every physical device on your network is assigned a Media Access Control (MAC) address to identify itself on a network. The MAC address is usually burned into the machine during manufacturing, like a fingerprint or something. OK, there it is, now you know.
Sockets
A "socket" is a class of software that is used to "bind" a connection between two applications into a persistent connection. For example, it is the deal that is sealed after TCPs three way handshake: client reaches out to shake the hand of server, server reaches back to shake the hand of client, client and server shake the shake and establish a socket connection that enables their a working and productive relationship. How nice.
Resources
From java.sun.com
RandomGuy James again
Socket stuff from java.sun.com
About.com on Sockets
Monday, April 14, 2008
HTTP!
HTTP is the protocol which enables your web applications to interact with resources located anywhere on the internet. On the most basic level, the protocol takes the form of request/response. Here, a client program establishes a connection with a server and begins making requests. Likewise the server, once a connection has been established makes a series of responses.
Upon closer inspection, we see that this response/request interaction is defined by one of seven core request methods available to the client. These methods are as follows:
Each of these tokes defines the action the client wants the server to make on the resource specified in the URI (Universal Resource Identifier, which is the combination of URLs (Locators) and URNs (Names)--ok, they're also known as WWW addresses).
Think of the request protocol like a grumpy caveman: He points at a given resource (via URI) and makes his demand: "GET!" then "PUT!" then "DELETE!" You get the picture.
The first four methods in the list might be seen as "active use" methods, since they define active interaction with a given resource. The last three options are mostly reserved for "test use" and are used mostly to test the attributes of a given server or communication state. We're not going to worry about the test use methods for now.
The Four Active Methods (Careful, I made up the phrase "active method")
GET is the most common of the HTTP methods, and it pretty much works as advertised: it requests that the server fetch and send over a given entity (head+body) specified in the URI. Every server is required to respond to GET. GET is designed to be a "safe" operation since it does not change the resource and it does not perform any legally binding operations (such as seal an agreement)--it merely supposes retrieval of information.
POST asks that an enclosed entity be worked into the structure of the identified resource. This action enables network-based annotations, online posts, form submissions and mediated database updates. As you may imagine, it is considered an "unsafe" operation and servers are not required to support POST requests.
PUT asks that a given resource be stored under the requested URI. This could be an altogether new resource or it could replace the existing resource. Whereas the POST method uses a URI to specify a handling resource which contains the processing logic to work the new resource into the existing body, the PUT uses the URI to refer to the resource it is supplying. (unsafe/not required)
DELETE asks that a server delete the resource identified in a URI. (unsafe/not required)
Resources:
Upon closer inspection, we see that this response/request interaction is defined by one of seven core request methods available to the client. These methods are as follows:
- GET
- POST
- PUT
- DELETE
- HEAD
- OPTIONS
- TRACE
Each of these tokes defines the action the client wants the server to make on the resource specified in the URI (Universal Resource Identifier, which is the combination of URLs (Locators) and URNs (Names)--ok, they're also known as WWW addresses).
Think of the request protocol like a grumpy caveman: He points at a given resource (via URI) and makes his demand: "GET!" then "PUT!" then "DELETE!" You get the picture.
The first four methods in the list might be seen as "active use" methods, since they define active interaction with a given resource. The last three options are mostly reserved for "test use" and are used mostly to test the attributes of a given server or communication state. We're not going to worry about the test use methods for now.
The Four Active Methods (Careful, I made up the phrase "active method")
GET is the most common of the HTTP methods, and it pretty much works as advertised: it requests that the server fetch and send over a given entity (head+body) specified in the URI. Every server is required to respond to GET. GET is designed to be a "safe" operation since it does not change the resource and it does not perform any legally binding operations (such as seal an agreement)--it merely supposes retrieval of information.
POST asks that an enclosed entity be worked into the structure of the identified resource. This action enables network-based annotations, online posts, form submissions and mediated database updates. As you may imagine, it is considered an "unsafe" operation and servers are not required to support POST requests.
PUT asks that a given resource be stored under the requested URI. This could be an altogether new resource or it could replace the existing resource. Whereas the POST method uses a URI to specify a handling resource which contains the processing logic to work the new resource into the existing body, the PUT uses the URI to refer to the resource it is supplying. (unsafe/not required)
DELETE asks that a server delete the resource identified in a URI. (unsafe/not required)
Resources:
Hypertext Transfer Protocol -- HTTP/1.1 RFC 2068
WC3 Article on Methods, URIs and Safe/Unsafe Interactions
Subscribe to:
Comments (Atom)