Antikythera: 2100-year-old computer rebooted…

Hot off the presses…

2100-year-old computer is working again.

“The Antikythera’s user interface is deceptively simple, operated by a simple knob on the side. This conceals the intricacy within, amounting to a complex mathematical model, tracking the movements of planetary bodies and incorporating a series of submechanisms to account for the eccentricities of their rotation”.

Here is the video:

This suggests how little we know about the knowledge of the time, and how it was suppressed by the power struggles that followed (Romans, early Christianity, etc.).  There is so much more in the Antikythera mechanism than meets the eye…

An Ancient Solution to the Longitude Problem?

The Antikythera mechanism indicates that the ancients had the necessary knowledge for navigating in the open sea (or the open desert).

To determine one’s exact position (in the absence of visible landmarks), one needs to know their latitude (their distance from the equator – north, south) and their longitude (their distance from a known location across the path traveled by the sun – east, west).

Latitude is relatively easy to determine by measuring the sun’s angle relative to the equator.  (Or the difference between (a) the sun’s angle at the traveler’s home during this season, and (b) the sun’s angle at the traveler’s current location.)  We know that the ancients had instruments to measure such angles.

However, longitude is harder to calculate [1].

  • One solution requires detailed star charts and moon phases.  This solution was being explored by Halley and others in the 1700s (through measurements and studies of ancient charts).
  • Another solution requires the ability to keep perfect time while traveling (a clock set at the home port’s time), and the another adjusted every day to the local time based on the sun’s east-west position (when is noon here?).

These solutions were not available until a couple of hundred years ago.  Consider Columbus, for example, who was off by a whole hemisphere (on the east-west axis – longitude) when he landed in America.

The Antikythera mechanism indicates that the ancients (Greeks?, Phoenicians?) had detailed star charts and moon phases.  It is perhaps no coincidence that they were known as great navigators.

Also (considering how Pythagoras studied in Egypt and Babylon before he returned to Greece as an old man to teach his mathematics to a few select students), one cannot help but think of the three Persian magi, who navigated the dessert three hundred years later, guided by the appearance of a new star.

Also see the earlier post, “Antikythera Mechanism: The First Known Computer?“.


  1. Dava Sobel, “Longitude“, Walker & Company, 1995.

Anti-Spam: A Simple Algorithm for Handling Email Spam

Yesterday I had more than 200 email messages from “System Administrator” – all sent within a minute.   They came through our university anti-spam filter.  This is getting too much…

Here is a simple anti-spam algorithm:

Create an email filter (say in Python) which checks every incoming email against a list of approved email addresses. If the sender address is NOT in the list of approved email addresses, it automatically sends back (something like) this:


If you are a real human, please reply with the word “pass”.  (Simply hit Reply, type “pass” as your response, and hit Send.)

This is an automated response from Bill Manaris’s anti-spam filter.

Thank you.

This program can be placed within the .forward file on Unix systems (and eventually incorporated within email clients).  (The configuration is similar to the one used by the Unix vacation program.)

The program maintains a list approved email addresses. This list may be initialized with the user’s email contacts. This list gets updated with addresses of people who pass the test.

The program automatically places in the incoming mailbox (e.g., .mail) any messages that complete the password exchange. It strips the password exchange and leaves only the original message.

The password message is an external text file. Also, there may be an external list of passwords to pick from.

Special Cases

A special case is when a spammer uses a person’s own email address to send that person spam.  If necessary, this could be handled by expecting a special password in self-sent messages.

The above handles the majority of spam messages I have received.

Another possibility is that spammers may use emails from people already approved for a certain person.  However, since these lists are different for different people, it is highly unlikely that a general automatic technique be developed by spammers to counteract it.


The beauty of this algorithm is that it turns the table on spammers: Even if they catch on, the program can evolve its behavior (e.g., message, pass word (or pass phrase), etc.). Also different people will have different messages. So it’s hard to create an automatic anti-anti-spam mechanism.

In terms of usability, it puts some strain on email senders – but only on those who have not communicated with you before, and only once. This usability strain is similar to the image-based passwords required by services like Google.

In conclusion, this may not be 100% foolproof, but it may effectively complement existing (and sometimes ineffective) anti-spam techniques.


  1. Chris Samuel, Vacation Email Responder program, 20 Jan, 2007.

A Changing World

As we are contemplating the future of computer science (education and curricula), this paper might provide some interesting insights into our changing world… the players are different, but the patterns remain. Change is inevitable.

Disruptive technologies are not something new or different. To the buggy whip manufacturers of the 1890s, the automobile was hugely disruptive. The same could be said for telegraph operators coping with the invention of the telephone. If there is a difference today it is only in terms of greater speed of propagation of the disruption and in the widespread publicity about the existence of the technology itself.

Harold L. Vogel (2005), “Disrpuptive Technologies and Disruptive Thinking“, Michigan Law Review – Vol 2005, No. 1.

How Hard Is It to Program?

Alan Kay, in his paper “The Early History of Smalltalk” states:

When teaching [programming] to 20 nonprogrammer adults, they were able to get through the initial material faster than children, but, just as it looked like an overwhelming success was at hand, they started to crash on problems that didn’t look to me to be much harder than the ones they had just been doing so well on. … E.g., make a little database system that would act like a card file or rolodex. They couldn’t even come close to programming it. Such a project was well below the mythical ‘two pages’ for end-users we were working with. After showing them the solution, I realized this little program contained 17(!) nonobvious ideas. And some of them were like the concept of the arch in building design: very hard to discover, if you don’t already know it.

In this context, here are two typical programs, in Java and in Python, to calculate length of the hypotenuse of a triangle given the length of the two legs.

Consider the number of new concepts/”nonobvious ideas” required to master in order to comprehend/write each of these programs.



For the Java program, a programmer needs to master the following concepts/”nonobvious ideas”:

  1. libraries (i.e., import java.util.*;)
  2. class
  3. encapsulation and information hiding (e.g., public vs. private, etc.)
  4. class name must be the same as program file name
  5. blocks (i.e., { ... })
  6. method
  7. special method main() (i.e., program entry point by Java VM)
  8. static vs. non-static methods
  9. void vs. value returning methods
  10. parameter passing
  11. arrays (i.e., String[] args)
  12. command-line parameter passing (i.e., String[] args)
  13. class instantiation (class vs. object)
  14. you may instantiate an object within its own class (i.e., chicken-and-egg paradox)
  15. statement terminator (i.e., ;)
  16. data types
  17. primitive data types vs. non-primitive data types
  18. variable
  19. assignment
  20. variable declaration
  21. input
  22. special class Scanner
  23. input streams, e.g.,
  24. class member method invocation (e.g., input.nextInt())
  25. iterators (e.g., nextInt())
  26. output (i.e., System.out.println)
  27. hierarchical composition (i.e., System constains object out)
  28. algebraic expressions
  29. Math library (i.e., sqrt())
  30. return statement



For the Python program, a programmer needs to master the following concepts/”nonobvious ideas”:

  1. module (i.e., from math import *)
  2. function
  3. blocks (i.e., indentation)
  4. statement terminator (i.e., newline)
  5. functions may or may not return a value
  6. parameter passing
  7. variable
  8. assignment
  9. input (i.e., input())
  10. output (i.e., print)
  11. algebraic expressions
  12. return statement


The above is a generic, simple (rather typical?) programming task. Given human cognitive limitations (e.g., the 7 plus-or-minus 2 rule), it is not surprising that programmers report at least a 3 times increase in productivity when they move from Java (or C/C++) to Python.

Also, the above comparison does not capture the amount of effort required to master each of the required concepts. Some concepts are easier to master than others (e.g., “statement terminator” vs. “class”). Also, a single concept may be easier to master in one language vs. another (e.g., “input” or “method/function”).

It would be interesting to generate a relative index of difficulty by, say, counting the number of lines used in a typical CS book to explain each of these concepts.

So “how hard is it to program”?

At some level, the answer depends on your language of choice. Clearly, it is harder to program in assembly than in a high-level language. But what might come as a surprise is that such distinctions exist even among high-level languages.


  1. Kay, A. “The Early History of Smalltalk“, ACM SIGPLAN Notices, Volume 28, Number 3, March 1993.
  2. Miller, G.A. (1956), “The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information“, The Psychological Review, vol. 63, pp. 81-97.
  3. McConnell, J.J. and Burhans, D.T. (2002), “The Evolution of CS1 Textbooks“, 32nd ASEE/IEEE Frontiers in Education Conference, November 6-9, 2002, Boston, MA, pp. T4G1-T4G6. “The average size for the Java books in our study is 2.25 times the average size of the Fortran books and 1.95 times the average size of the Pascal books. From the perspective of a course, the authors of three of the four Java books we examined expect that their entire book (averaging 880 pages) will be covered in one semester. This amounts to 22 pages per class or about 66 pages per week that a student is expected to prepare.”


The Pythagorean Theorem code was written by my students, Brian Smith and Jeff Shumard.

Antikythera Mechanism: The First Known Computer?

In today’s article “In search of lost time“, Nature 444, 534-538, Jo Marchant presents remarkable new findings on the Antikythera Mechanism. The Antikythera Mechanism is a mechanical computer (similar to Charles Babbage’s Analytical and Difference engines) designed to calculate astronomical positions, which was discovered in an ancient ship wreck (150-100 BC) off the Greek island of Antikythera. What’s really intriguing about this “computer” is that was developed about 2000 years before Babbage’s model.

Here is a summary of the article and a few thoughts to provide context for photos taken while visiting the National Archaeological Museum in Athens, this summer.

101_15081.JPG 101_1515.JPG

Images 1-2. Front view of the Antikythera Mechanism fragments and
official caption, as exhibited at the National Archaeological Museum in Athens, Greece (click to enlarge).

First, about the Discovery…

According to Wikipedia,

Sometime before Easter 1900, Elias Stadiatos, a Greek sponge diver, discovered the wreck of an ancient cargo ship off Antikythera island at a depth of 42 m. Sponge divers retrieved several statues and other artifacts from the site.


101_1501.JPG 101_1498.JPG 101_1502.JPG 101_1503.JPG 101_1504.JPG

Images 3-7. One of the bronze statues found at the Antikythera wreck
as exhibited at the National Archaeological Museum in Athens, Greece.


p6070150.JPG p6070149.JPG p6070151.JPG

Images 8-10. Another of the bronze statues found at the Antikythera wreck.


The mechanism itself was discovered on May 17, 1902, when archaeologist Valerios Stais[1] noticed that a piece of rock recovered from the site had a gear wheel embedded in it. Examination revealed that the “rock” was in fact a heavily encrusted and corroded mechanism that had survived the shipwreck in three main parts and dozens of smaller fragments. The device itself was surprisingly thin, about 33 cm (13in) high, 17 cm (6.75in) wide and 9 cm (3.5in) thick, made of bronze and originally mounted in a wooden frame. It was inscribed with a text of over 2,000 characters, about 95% of which have been deciphered. The full text of the inscription has not yet been published.

Now, about its Functionality…

According to Nature’s article, the mechanism fragments

contain at least 30 interlocking gear-wheels, along with copious astronomical inscriptions. Before its sojourn on the sea bed, it computed and displayed the movement of the Sun, the Moon and possibly the planets around Earth, and predicted the dates of future eclipses. It’s one of the most stunning artefacts we have from classical antiquity.

No earlier geared mechanism of any sort has ever been found. Nothing close to its technological sophistication appears again for well over a millennium, when astronomical clocks appear in medieval Europe. It stands as a strange exception, stripped of context, of ancestry, of descendants.

Here are some more of the photos from the visit to the museum.

101_1507.JPG 101_15081.JPG 101_1505.JPG
101_1516.JPG 101_1517.JPG 101_1518.JPG

Images 11-17. Various views of the mechanism fragments and X-rays.

The mechanism is an implementation of Hipparchus’s model of planetary motion.

The researchers realized that the ratios of the gear-wheels involved produce a motion that closely mimics the varying motion of the Moon around Earth, as described by Hipparchus. When the Moon is close to us it seems to move faster. And the closest part of the Moon’s orbit itself makes a full rotation around the Earth about every nine years. Hipparchus was the first to describe this motion mathematically, working on the idea that the Moon’s orbit, although circular, was centred on a point offset from the centre of Earth that described a nine-year circle. In the Antikythera Mechanism, this theory is beautifully translated into mechanical form. “It’s an unbelievably sophisticated idea,” says Tony Freeth, a mathematician who worked out most of the mechanics for Edmunds’ team. “I don’t know how they thought of it.”

Here are photos of a reconstruction of the mechanism by Prof. Derek de Solla Price, Yale University:

101_1512.JPG 101_1513.JPG 101_1514.JPG 101_1515.JPG

Images 18-21. Various views of the mechanism’s reconstruction, as exhibited at the National Archaeological Museum in Athens, Greece.

Where are the others?

Given its sophistication, clearly this mechanism could not have been just a prototype. If so, why haven’t we found more ancient devices like it?

Again, according to Nature’s article,

Cicero wrote of a similar mechanism that was said to have been built by Archimedes. That one was purportedly stolen in 212 BC by the Roman general Marcellus when Archimedes was killed in the sacking of the Sicilian city of Syracuse. The device was kept as an heirloom in Marcellus’ family: as a friend of the family, Cicero may indeed have seen it.

How could this knowledge die away? Actually, it probably didn’t. There is evidence that similar systems existed in the eastern Mediterranean in later years in the Byzantium, Persia, and Arabia. And then, in the 14th century mechanical clocks emerge in Europe. Interestingly, these clocks were mainly used to drive astronomical displays — the time-telling functionality seemed somewhat secondary.

It is possible that medieval craftsmen re-invented the wheel, so to speak. But it is equally likely that the technique survived away from the critical eyes of the early Christian church, and possibly reached the west right after Baghdad was conquered by the Mongols in the 13th century. Soon afterwards, clocks started being constructed in the West without much information about their origins. If a medieval European craftsman had re-invented the technique, his name should have been recorded, and the technique would have probably remained proprietary for some period of time. Thus, one can safely argue that the “invention” of clocks in 14th-century Europe was not a revolutionary step (as it commonly believed), but rather an evolutionary one.

But if the Greeks had access to such powerful calculating technology, why don’t we see other useful artifacts of technical sophistication? Well, we do have the massive, architecturally intricate buildings they left behind (many still standing). But what about other technological gizmos, like the Antikythera one?

So where are the other examples? A model of the workings of the heavens might have had value to a cultivated mind. Bronze had value for everyone. Most bronze artefacts were eventually melted down: the Athens museum has just ten major bronze statues from ancient Greece, of which nine are from shipwrecks. So in terms of the mechanism, “we’re lucky we have one”, points out Wright. “We only have this because it was out of reach of the scrap-metal man.”

Bronze was a preferred medium for weapon making because of its strength and ease of casting. Romans also used bronze for casting statues of their gods. Why preserve a conquered, disgraced nation’s statues of philosophers and of strange delicate artifacts with no apparent practical use? The bronze used in these artifacts was far more valuable to the conqueror.

Also, Greeks did not necessarily have the same needs/concerns that drive technological innovation in our modern, fast-paced, bottom-line society. They were less concerned with accurate time keeping (similarly to most Mediterranean cultures) and more concerned with knowledge, philosophy, and a deeper understanding of life and the universe. As anyone who has visited Greece can attest, that’s still rooted in the Greek psyche (especially the time keeping part… ;-).


  1. Jo Marchant, “In search of lost time“, Nature 444, 534-538, Nov. 30, 2006.
  2. Derek J. de Solla Price, “An Ancient Greek Computer“, Scientific American, pp. 60-67, Jun. 1959.
  3. Alun Salt, “The Antikythera Mechanism“, Archaeoastronomy blog, Nov. 29, 2006.
  4. The Antikythera Mechanism Research Project,
  5. Philip Coppens, “The wheels of Greek astronomical science“, accessed Nov. 30, 2006.
  6. Derek J. de Solla Price, Wikipedia entry, accessed Nov. 30, 2006.

Usability of Programming Languages

Wanna know which language really is the best???

Programming languages, when viewed as user interfaces, may be evaluated formally through usability techniques.

For example, see this usability study from the NASA JPL site (35 mins).

In it, you will see the evaluator pick certain tasks, try to perform them with different programming frameworks, and in the end reporting quantitative results. Powerful!

If you are new to usability, see Jakob Nielsen’s Usability 101. As you are read about websites and users, perhaps think about programming languages and students.

Clearly, the choice of tasks is essential. You pick the wrong tasks and your results are misleading.

So, the other day, I selected a small task and wrote code both in language X and language Y.


With language X, I had to look up two things in the API, had 9 compiler errors, one semantic error, and one “headache” error. (What is a “headache” error? View the video.)

With language Y, I had only one syntax error.

The number-of-lines ratio was 3 to 1 (X to Y). Same task.

Before you ask me which languages I used and what the task was, I challenge you to do the same with your X and Y, and your task of choice. Try a task from CS1, for example. Just make sure it is not tied to syntax (e.g., inheritance vs. interfaces).