Entries Tagged 'Reviews' ↓

Some follow-ups, corrections, and expansions.  Being correct takes effort.

First, someone very knowledgeable on the internals noted that I was sloppy with the terms ‘datastore‘, ‘GBase‘, ‘GoogleBase‘, ‘GQL‘, and ‘BigTable‘.  Mea culpa.  Datastore is the most generic term and the specific one for Google App Engine is referred to as the “App Engine datastore“.  The App Engine datastore is accessed through GQL, a language reminiscent of SQL.  The App Engine datastore is built on BigTable and exposes some of BigTable’s capabilities (see Wikipedia, a formal paper,  or video documentation).    GoogleBase is an independent Google product that is also built on BigTable.  GBase is a guitar search engine and the naturally elided form of “GoogleBase” after saying it a hundred times.   Whew!  Terms.

Speaking of terms, the contract term dealing with indemnification in the Terms of Service:

13.1. You agree to hold harmless and indemnify Google, and its subsidiaries, affiliates, officers, agents, employees, advertisers, licensors, suppliers or partners, (collectively “Google and Partners”) from and against any third party claim arising from or in any way related to (a) your breach of the Terms, (b) your use of the Service, (c) your violation of applicable laws, rules or regulations in connection with the Service, or (d) your Content or your Application, including any liability or expense arising from all claims, losses, damages (actual and consequential), suits, judgments, litigation costs and attorneys’ fees, of every kind and nature. In such a case, Google will provide you with written notice of such claim, suit or action.

The annoying clause is “(b) your use of the Service”.   Given how claims are written in patents, it is entirely likely that use of the API would be an actionable breach if the Google App Engine violated patents.  Google could require indemnification by users of the API.  For most people and smaller companies, the reputation of Google and pledges to “not be evil” should be sufficient.

Speaking of evil (note the clever transistion), the lazy index evaluation that makes the database look like “read committed” is discussed here.

Finally, high availability is hard, and “9’s” go faster than you remember.

90% (1-nine) is a downtime of 36.5 days per year.
99% (2-nines) is a downtime of 3.65 days per year.
99.9% (3-nines) is a downtime of 8.65 hours per year.
99.99% (4 nines) is a downtime of 52 minutes per year.
99.999% (5 nines) is a downtime of 5.2 minutes per year, or six seconds per week.

A claim of about 2-nines reliability is reasonable.  Google App Engine was launched around four months ago in mid-April, so about a day of downtime is 2-nines.  It was down on June 17 for some unreported number of hours, and was down again on June 19 and June 25.  Add in little outages where various features broke, blocking PayPal, and other nits.  There is a list that occasionally reports downtime, but no exact statistics are available.  If there were no future outages, and you wanted to demonstrate four nines reliability, it would need to take years to overcome the existing outages.

Keep on working on it.  I hope that Google App Engine will be more fun in the future.

[I gave this talk at the BayPiggies Meeting on August 14, 2008.  The 'Newbie Nugget' talk ran about seven minutes and used only spoken words.  This is my recollection of what I said.]

I drove here today.  I got in my car, used the six speed manual transmission, steering wheel, and pedals.  I had to know how to change lanes and the rules of the road.  I needed to know traffic patterns, and directions from my house to Google.  I got here.

It was the most dangerous thing I did today.  Traffic accidents kill about 40,000 people a year in the U.S. alone.   It’s the number one cause of death for everyone from age five to about my age where heart disease and cancer start catching up.  We just take it for granted.   That’s not the car I want.

I Want My Autodriving Car!  I want to push a button on my cell phone, walk out the door a minute later, and hop into the open door of a car.  It would take me where I want to go, take the best route given current traffic, and drop me in front of the door.   It would never crash.  It would just work.  That’s what I want in a car.

Here’s what I want in an application engine.   I want to write in one language.  I want one set of tools.  One naming convention.  I want to be able to translate my thoughts into code cleanly.  I want the application to be on the Internet and scale and to share that application with everyone through a url or something like the IPhone App Store.   That’s what I want in an application server.

Google App Engine is not there yet.   Google App Engine is a step along that path, and lets you see where application engines are headed.  For the first time, you can see that installing and configuring MySQL on a server and then renting space in a rack for the server will someday sound the same as someone talking about pulling the engine in his car and changing out the rings in the driveway.  I guess you could do that yourself, but why?  You still need to work in the soup of languages:  HTML, CSS, JavaScript, HTTP headers, Flash, Python, and more.   You still need to coordinate your tools for each language:  editor coloring, debugger, make system, test harness, code coverage, and documentation.  It does us good to keep our eyes on the App Engine we want.

So, let’s talk about Google App Engine:  what is does, how to write for it, where you would use it and not.

Google App Engine is fundamentally a deployment engine.  After you write your application, it provides that application out on the Internet.  It’s also very early technology.  It sort of supports Django (‘jango’ for those who talk; ‘d-jango’ for those who read), but using the latest version runs up against its thousand file limit.  Fully half of the seventy posts a day on the mailing list are about deployment quotas or looking for workarounds to deployment limits.  You cannot run any long job that takes more than a few seconds.  Still, it’s free.

Writing for Google App Engine is much like writing for any other application engine.  You use the WSGI interface, which someone taught me is pronounced ‘whiskey’, that provides a mapping between the requested URLs and the classes to serve them.  You write a class that has methods to respond to HTTP messages like get and put.  Your codes spits out the HTML and whatever to respond.  Sometimes you trigger urlfetch, from urllib, of your own application like remote procedure calls to avoid hitting computation time request limits.  You store your data in the Google Base data store.

Google Base can be a problem.  The Google Base datastore is not a relational database.  It’s a great database for working data you collect from all over the web, like web pages or screen scraping, where you are working with massive amounts of data and some of it is always aging out.  It should never be used for accounting.  For example, you can’t just run a GBase query to update the total invoices for a month.  You need to walk through all the records.  If you update the date on an invoice and then retotal the invoices, you might get the wrong answer.  GBase doesn’t guarantee the invoices index is immediately updated.  It would probably work, but if you were to try running tests to see how often it fails you’d use up your quota and be locked out for a few days.

So where is Google App Engine the right choice?  First, it’s free.   It’s a good way of learning how to write for application servers.  There are some good tutorials and videos and off you go.  If your application needs a lot of bandwidth downloading from elsewhere on the internet, it’s probably a good choice.  So if you want to try out an idea that’s not for making money, go for it.

Where is Google App Engine the wrong choice?  If you are trying to make money, it’s right out.   First, the license includes clauses that require you to indemnify Google if the API infringes patents.  A Fortune 500 company won’t let you agree to that.  Second, its reliability wants to get up to five nine’s (.99999) but is hovering between one and two nines.  Third, it’s really early tech.  You can watch lots of  bugs get filed and occasionally fixed, but they are in the stage of getting it feature complete first.

In conclusion,  I want an auto-driving car and I want my great application engine.  Google App Engine is like getting a taxi.   A taxi does the driving, but I still need to know directions and road conditions, and I still get into car accidents.   With Google App Engine, I still need to know the whole stack of languages, my site still gets hacked, and it still goes down a lot.  But you can see the future in Google App Engine, and it may turn into something great.

[Clarifications and follow-ups for this article got a bit long.  I added some expansions on this blog post.]

80% of effects come from 20% of causes
— Pareto Principle by Vilfredo Frederico Damaso Pareto, 1906

90% of Everything is Crud
– Sturgeon’s Law by Theodore Sturgeon, 1956

100% of Everything is Crud
– Linear extrapolation of above, 2006.

There seems to have been a natural tendency for us to look at past as some magical time when quality mattered. Really, only the pure quality of finished work survived. We forget the uncountable steps towards quality.

In the world of desktop environments, the journey towards quality continues. KDE 4.1 makes a step, following trends, and aiming to be The One Last and True Windowing System.

Quality Steps and Missteps

I installed Kubuntu with KDE 4 on my laptop, and am using it to write this post. That it is written at all shows a minunum level of quality. That the post starts with these quotes shows a maximum level.

I find immediate problems when installing. The very first action, the “Read Me” during the LiveCD boot, comes up in a clipped and illegible font. During partitioning the disks, the progress bar hangs at 0% for ten minutes. The task bar lacks resizing and basic functionality. The quick launcher, Katapult, disappeared. A new program launcher experiment falls flat with some buttons activating by click and other by hovering the mouse.  Konquer still crashes.   I discover new bugs a few times per hour.  These are the the nits and bugs of a new system.

The subtle problems are the problems repeated from previous years: the LILO boot system that unhelpfully refers to Vista as “longhorn” and Kubuntu as “generic Ubuntu core”; the cobbleware of screen layout that has fonts too big for buttons, text too wide for dialogs, and odd alignments; the usual flakiness with power and wireless management. These problems persist for ages from expectation, difficulty, or blindness.

So quality is a step downward while the easy bugs are fixed. Some nice features, like FileLight are a definite step up that I expect every other distribution to copy soon. KDE did buck the trend in releasing a quality downgrade.

Trends in Window Managers

KDE 4 follows the collective wisdom of other software competitors including GNOME, Sugar, Microsoft’s Windows line, and Apple’s OS X line. It tries to be different just like everyone else.  It adds new functionality in pieces and parts.  The hodgepodge of bundling, or smush, that make up windowing systems includes GUI and interface candy, applications, and APIs.

Smush is not pejorative. Open source swaps in and out competing components and the windowing system selects components under its seal of approval and delinates APIs outside its control. Quality for each component is involved at several layers. When the power management on my laptop fails to hibernate before powering off, I could file a bug with KDE, Ubuntu (link to shuttleworth), Debian, the Linux ACPI mailing list, hardware discovery, or just fix it myself. When searching for a workaround, it could exist anywhere.

KDE is following the trend towards aggressively  cross platform deployment. By using Qt 4 as it’s underlying graphics engine, KDE hopes to deploy on desktops (Linux, MS Windows, and OS/X), cellular phones, and some embedded devices. It is currently hampered by Qt 4 having no LGPL or BSD license, requiring a special licensing cycle to deploy any commercial application. The previous Qt 4 copyright holder, TrollTech needed this revenue to continue operations. The new holder, Nokia, may free the code in order to encourage wider adoption and easier developer migration to its cellular phones.

KDE also follows the practice of wrapping more and more functionality into API layer plug-ins. Rather than commit to a scripting language, Kross wraps or interfaces to Python, Ruby and JavaScript. Rather than commit to a multimedia engine, Phonon creates one more layer of indirection for a common interface to GStreamer, QuickTime, DirectShow, and others. The new release switches many of the wrappers so now it is Phonon (multimedia), Solid (device integration), Plasma (a new desktop), Kross (scripting), DXS (application data updates), Decibel (human communications), and D-BUS replacing DCOP (application messaging). It is unclear if “one more layer of indirection” will be the correct solution in the long run.

In the long run, of course, KDE hopes to birth “The One Last and True Windowing System.”

The One Last and True Windowing System

Results 1 – 10 of about 1,040
– Google search for “One API to Rule Them All”

Windowing systems race towards the goals of full functionality, sweet abstractions, and wide deployment with the winner creating a work that will last decades. Each release brings new experiments and implements growing standards. Implementations trump ideas. Differing implementations get abstracted and merged. Engineers have always raced towards sweet solutions.

Software does get finished. We still use the C programming language after more than a third of a century. The syntax, style, and assumptions are passed to new languages such as C++, Python and Ruby. Other contenders failed. Hardware architectures now handle pointer indirections, sequential arrays, and null terminated strings. C goes through occasional updates and forks, but it endures. Also enduring are the most of the Internet stack including TCP/IP, DNS/Bind, and packet switching; HTTP protocols, SQL, and many more. These become the common parts upon which we solve new problems. Many hope to finish writing the desktop software.

FreeDesktop.org gently pushes towards standardization by facilitating discussion. It speeds the process of making compatible, then integrating, then merging competitng development that has become similar. It’s influence on KDE is unmistakable.

So, will KDE give birth to the “One Last and True Windowing System” that lasts for decades?

Conclusions

KDE took a significant risk. It’s adoption of Qt 4, dropping of DCOP, and making so many changes significantly hurt its quality. On the other hand, it might provide a new level of functionality to catapult into the top three windowing systems. Time will tell. For people just wanting a desktop to work, stay away for six months. Continue reading →

Probably the worst hardware/software system I have had the misfortune to own.

It seems like a good idea:  1/2 Terabyte of backup, expandable upwards, software RAID, clean looking hardware, pretty box, a friend’s recommendation.  Yes, it’s a bit pricy, but OK, quality is worth it in archives.

I’m not too picky am I?

1.  The default user name and password is “admin”, “netgear1″.  Not “admin”, “infrant1″ as stated in the printed and online manuals, online website, etc.  Oddly, the default guest name and password is “guest”, “infrant1″.

2.  The NAS box cannot just connect directly to a computer as it states in the manual.  Put it on a network with a DHCP server.

3.  The adapter into Windows Explorer isn’t bright.  It doesn’t refresh when the drive contents change.  This means you rename a directory and wonder why it doesn’t change.  Hit ‘Refresh’ to work around it.

4.  Administer the system from a web based interface that comes up in Internet Explorer regardless of your default browser.  Unfortunately, it seems to assume a physical size not found on laptops or any standard PC shipping before 2012.  Important information will run of the visible pane and there are no scroll bars.

5.  Starting the administration applet immediately dumps any other active connections, such as back-ups in progress.   Delete and start over.

6.  By immediately dumping, I mean without releasing locks.  You cannot just start over.  Reboot the NAS.

7.  Wait about 4 minutes for it to come up.  It’s idea of a ‘quiet fan’ is not a mortal’s view of a ‘quiet fan’.  Fight off the headache.

8.   No problem, log onto the web site and contact tech support.  Actually, you cannot.  There are some JavaScript errors that do not allow you to contact tech support.  Odd links will take you around in circles until you figure this out.

9.  Download the Linux Driver from the website.  Try to run it.  Get “arith: syntax error: ‘i+1′”.   Start debugging their install scripts.

…

I could go on, but why?   We are stuck with this equipment now.  I don’t want to go dealing with a 30% restocking charge.  I hope it doesn’t cause cancer.

Ron Eglash makes a strong case for fractals being the dominant art form of Africa in this Ted Talk.

He explores villages showing a fractal nature far beyond the accidental. Art and religion drive village architectures that repeat into small objects at the heart of the village. His discussions with tribal leaders show the deep meanings of these choices, and a continuance of these themes into African life.

Fractals are explained, and the theme is shown in the Mancala games, fence construction, tapestry, and aspects of religion. Binary patterning, as part of mysticism, produce a good random number generator. Finally, some efforts are shown as incorporating this heritage into an educational system.

This is a fascinating 15 minute video. Also, he provides software for exploring fractals.

Google Test Automation Conference Lightning Talks

Good and excellent short talks from the 2006 conference covering many testing topics. Slides are available.

01:20 Dan North from Thoughtworks on Getting Lean

• Automated Testing has the secondary effect of enabling two of the Lean Principles: Lean Product Design (maximize discovery by faster releases) and Lean Manufacturing (low variance repeatable testing).
• Sort of supply chain management because design is just before coding is just before release.
• Automated Testing allows for frequent shipping of high quality product.

06:00 Steve Freeman JMock I Done By Five Minutes

• JMock is a library for using mock objects in the test-driven development of Java code.
• JMock’s types allows IDE to expose just right spots. Good error reporting.

10:50 Nat Pryce, The JMock II update

• Update is Java 5, JMock library is framework independent
• Cleaner testing code, better IDE autocomplete
• New refactoring support

15:01 Christine Newman from Progressive Insurance, Getting More Funding for Automated Testing

• Quantify the value of automated testing with numbers like “Production Problems Prevented; Risks Mitigated (by severity); or Hours Saved”

18:20 Andrin von Rechenberg, Google Intern, Improving WURFL data

• Database mobile phone capabilities are hard to test for 8500 user agents.
• Check your logs to see how they navigate, e.g., to find HTTPS capability

23:30 Ade Oshineye from ThoughtWorks, Five Heresies in Five Minutes

• Convert your logs of real people into test cases
• Mutation Testing works (change code, if test passes then test is bad) for high risk, about to be refactored, or bug-prone sections.
• Run actual tests on production hardware with production systems for new release or when making a dummy is hard.
• Test your vendor’s code lest their upgrades break you or you are afraid to upgrade.
• Static analysis works now. Use FindBugs or PyChecker or IntelliJ’s stack analysis server to find bugs people won’t find or broken language idioms.

29:00 Timur Hairullin for Vandex (Russian Search Engine)

• Had unexplained performance problems on an update.
• Measure performance from time between first byte of request to something happening inside browser of older computers; not just to server sending last byte of response.

32:00 James Richardson on Automated Testing: Why Bother?

• How do I quantify Automated Testing? I missed Christine Neuman’s lecture.

34:00 James Lyndsay for Workroom Productions, Automated Tricks for Manual Testors

• Some tests must be manual and observed by good testers; they look for surprisers and emergent behaviors.
• Use snippets of code (your manual testers should code and use Unix)
• Use virtual machine images to hand over bugs.

38:26 Jordon Dea-Mattson, some radiation treatment machine firm

• Working on client/server in life-critical, highly regulated systems.
• Most testing strategies have single points of failure; try thinking of testing defense in depth.
• Collect more data in the (wild) field instead than just crashes.
• Think of software ERP, integrating the whole requirement to delivery chain.
• Strong recommendaton for TestQuest; UI testing tool.

42:10 Curtis “Ovid” Poe with the Perl Foundation, TAP

• TAP (Test Anything Protocol) is a human and machine readable protocol for test output.
• TAP is simple, line oriented, and implemented in C/Perl/Python/Ruby/JavaScript/PostgresSQL
• Driven by PerlQA team and a new language agnostic list is forming.

Overall, a great video.

“A New Way to Look at Networking” by Van Jacobson

This is great video on the history of voice and TCP/IP networking. Van Jacobson shows the telephone network solved the problems of its day and framed out thinking. He then shows how TCP/IP packet switching solved more problems and framed our thinking again. He then suggests we should be thinking about a data centric view of networking, and that our problems warrant another generation of networking. Then the talk falls down.

[00:00]

Van Jacobson’s resume is impressive: he solved many of the Internet congestion problems, worked on the MBONE, wrote early whiteboard software, and generally knows his packets.

[07:00] History of Telecommunications, the Phone System

The telephone system, Ma Bell, emphasized wires and connecting wires to each other. A telephone number is just a program for which wires to connect to build a path, committing each segment before the next segment is parsed. Reliability was enforced by a centralized architecture with extremely reliable components. The pipes were smart because the end points were dumb. This view of the world really did work for phone conversations and got wires pulled everywhere.

[17:20] History of Telecommunications, the Packet Generation

In about 1964, Paul Baran and Don Davies publiched a paper on breaking data into small packets and passing them from link to link in a communications system that could be less than fully interconnected. The paper was denounced by all, and the ARPANet was built anyway. At first, this looked like an inefficient way to use the wires already in place courtesy of the telephone generation. With practice, it proved useful.

[24:53] CateNet and TCP/IP (1971 paper, 1977 demo) improve the Packet Generation

ARPANet worked, and by the early 1970’s there were a dozen incompatible packet switched networks. Vint Cerf and Bob ? from Stanford took the viewpoint that only the endpoints mattered, not the topology of the networks. A common encapsulation and addressing scheme suffice to concatenate networks using the encapsulation and addressing only at thenetwork edges. They demonstrated moving bits from packet radio, through satelites, telephone lines, and other networks. Bits were bits, and reliability *increases* exponentially with system size. No path set-ups, no scheduling issues; just an address.

[31:10] The Success Catastrophe of TCP/IP Packet Generation.

The TCP/IP data model works for conversations between computers and has made a world rich in devices, connections, and information. The challenges of firewalls, VPNs, ad-hoc synchronization, and NATs are symptoms of the success and of changing problems. The Internet is binary; you are connected with a global address that lasts in the minutes or hours or you are not. We now face problems with many machines per devices, and those devices are moving between networks quickly.

[38:25] The Data Generation; a coming generation based on finding and replicating data.

Almost all requests today are for named blocks of data. Downstream switches are often processing many copies of the same video stream. Radio based networks target individual receivers by broadcasting the same data to all and having most ignore it. The TCP/IP protocols are based on one-to-one conversations between computers; we should research fetching and caching data.

New data chunks would include validation hashes, providence hashes, sequence information, and a degree of permanance. Every cachable device would be a vehicle for data.

[44:53] The descent into unorganized ideas.

That said, the talk descends into unorganized ideas. There is a short thought demonstration of fetching the NYTimes headline with validation and providence hashes. There are complaints about lack of multicasting; good things to say about BitTorrent and SnakeBite; ideas of moving QoS to the endpoints and progating back to the core; requests for fast set up times and for alternatives to DSL; wishes to have cached repositories in the local area; instant PKI and webs of trust beating certificate authorities; and a host of complaints about our current infrastructure.

Most of these ideas about data centric networking are not well thought out, which may the point of the talk.

Lightning Talk on my Google Summer of Code by Rok Zendler

Rok Zendler describes his summer internship project:  creating automated unit tests of Drupal. Drupal is a PHP based, LAMP architecture, content manager used by non-profits and various other websites. Rok created a web interface for submitting a patch set to some Drupal project. His system then creates a new Drupal site, applies the submitted patches, runs unit tests, and provides a report. This provides a sanity check to submitted patches.

Rok could be a better speaker, could use fonts that are readable and large, and be a more ambitious.

 Advanced Python (or Understanding Python) by Thomas Wouters

Thomas Wouters speaks with a great signal to noise ratio. He guides by groking both Python and which bits of Python confuse learners. An advanced programmer will love his short code snippets. An intermediate Python programmer will appreciate the clarity in which he covers topics. A beginner will also appreciate the ‘Understanding Python’ section.

You may want to use this video more as reference than a single experience.

‘Understanding Python’ explains the cohesive and consistent rules covering all the scoping rules, modules, definitions, and object rules. Much of the rest of lecture covers a variety of topics, mostly related to special classes. I find this a good reference lecture to get the two minute overview of a particular topic.

“Get you program, can’t tell your decorator from your generator without a program.”
0:00; ‘Understanding Python’
0:17; Details about object lifecycle and implementation.
0:27, Iterators and Generators.
0:33, Decorators
0:40 Special Class Hooks, including New-style 2.2 classes (0:38); Descriptors (0:40), Properties (0:41), Classmethods, staticmethod (0:43), __slots__ (0:47), __new__ actual constructor (0:48).
0:51 Metaclasses
1:01 Multiple Inheritance
1:05 Unicode

Keep this link in your reference folder.
Have an excellent day! — Charles Merriam

Practical Common Lisp by Peter Seibel

Date: May 10, 2006

Overview

• Good material with mediocre presentation. Seibel seems to hint obliquely at his three major points:
  1. Lisp gives a higher level view of an implementation than Java et al.
  2. Lisp constructs can be made to work in other languages, but verbosely.
  3. The key tool is Macros, which allows programmers to define new syntax to better express the problem.

Details

These are my mostly raw notes from watching the hour long video.

Peter Seibel

• Pronounced “Sigh-bull”
• Practical Common Lisp
  • 500 pages long
  • Winner of Jolt Award
  • Aimed at an expert non-LISP programmer
• Worked at Kenamea, BEA, Organic Online
• Second generation LISP programmer

Ideas from Peter Naur’s “Programming as Theory Building”

• View that ‘theory’ is the essence of a program
• Can only get theory from code without work equivalent to writing it
• Programming languages allow us to write more concisely

Views from Patterns

• Software patterns for people writing software
• Building patterns make some rooms more usable
• Alexander looked for a generative language
• Patterns generate forces; a good language could make closure
• Software patterns are for a particular language sets; others do it automatically.

What’s Natural

• Language wars are often fought based on what’s natural
• What’s natural is often confused with what was learned
• Infix notation is hard to learn, but is ‘natural’ because we learned

Sapir-Whorf hypothesis

• By Edward Sapir and Benjamin Whorf in 1920’s
• Suggests the thoughts we think are largely determined by the language we speak
• Sometimes called Linguistic Determinism
• Strong Linguistic Determinism is that you can’t think what you can’t say
• Weak Linguistic Determinism is that what you can say influences what you think
• Strong LingDet undermined by fact we can translate human languages
• Weak LingDet supported by colors being easier to remember when named
• Turning Completeness destroys Strong LingDet for programming languages

Paul Grahm

• “Beating the Averages” by Paul Grahm
• The ‘Blub’ paradox of the intermediate powerful programming language
• Looking at less powerful languages shows what they lack from Blub
• Looking at more powerful languages looks like Blub plus unknowable gunk
• If you could think in most powerful language possible, could work in any.

Quotes

• “Beware of the Turning Tarpit” by Alan Perlis
• “LISP isn’t a language, its a building material” by Alan Kay
• “LISP has assisted … in thinking previously impossible thoughts” by Dykstra

Vistor Pattern (Double Dispatch)

• Often used when traversing a tree of heterogeneous objects
• Traversal is not the point of the pattern
• Double-dispatch is point of the pattern.
• Example: use for pretty printing or compiling a tree of syntax tree
• Trying to dispatch to a particular function based on two object hierarchies.

Java Vistor Pattern Example

• Polymorphing is like “Object o; o.display()”
• Non-polymorphing, or overloading, is like “Object o; ((Book) o).display()”
• Could write hand-coded dispatching but maintenance nightmare
• Java cannot direct dispatch correctly a something like DisplayPtr.display(MediaPtr)
• The DisplayPtr subtype cannot be resolved at compile time, so is Non-polymorphing overloading
• Pattern concentrates the grunt code in one place and makes it more maintainable.
• Lisp does this without writing grunt code

Language rants

• Simula and LISP mixed well made SmallTalk by Alan Kay (Good)
• SmallTalk (did he mean Simula) and C mixed make C++ (Bad)
• SmallTalk added message dispatch, now back in CommonLisp
• Methods no longer are member of classes, so organize them well.

Multiple Dispatch

• Explained much better in Wikipedia
• Shows using a pattern in Java that accomplishes the same thing as in Lisp.
• Key aspect is that same pattern can be implemented, but with easy syntax in Lisp.

Error Handling in General

• Pre and post condition testing is not sufficient
• There are ‘actual’ pre/post conditions that cannot be derived from code
• Formal pre/post conditions are what we can derive from code
• Actual pre/post conditions are real corner cases, like file gets deleted during run
• Can open up our expectations and passing error handling upward to a degree.

Error Handling in C, Java, etc

• C uses a ‘return value’ which is often ignored
• Java, Python, etc. propagates exceptions so routine must “handle it or fail”
• Some exceptions need to have decision about how to handle it far up the stack.
• Making that decision in a Java exception system unwinds the stack too early.

CommonLisp Exceptions

• Example is pretty badly described. Think “Top level decides if parse problem is fatal or not.”
• Allows signal of error to be passed up stack independently of unwinding the stack.
• Can use an ‘restart’ method to keep the original stack
• Key aspect is that this is a pattern easier in CLOS, but implementable in other languages

* 55 minutes into video
Macros are the most important feature of CLOS

• The language parser parses into a generic abstract syntax tree
• You can hook your own code generator into the compiler at any scale or level
• These macro hooks expand into lots of Lisp code.
• This allows one to create new syntax and language concepts
• New, compile-time syntax is often best way to express a problem
• Making the pattern explicit in a macro avoids making it implicit in code