Time travel back to 1984. If you quit MacWrite, it takes ten seconds or more before the Finder appears (the Finder, of course, wasn't running; there simply wasn't enough RAM to do that) If you now double-click a document, it takes ten seconds or more before MacWrite has started and opened your document.

MacWrite, being a marvel of tight engineering, manages to handle documents of a whopping two to three pages in the 40 kB or so of RAM available to it. So, if you want to write a huge document of say four pages, you have to split it into smaller parts.

If MacWrite quit when you closed its only window, moving from part 1 to part 2 of your document would take over a minute. That is why document-based Mac applications do not quit when you close the last document.

Back in 2011, many people will expect that command-W, command-N will close the current document, then create a blank new one. If Mac OS X Lion quit applications as soon as the user closed the last window, that would no longer work. That, I guess, is the reason that the OS waits for a while before doing that.

Is that a good idea? I think quitting apps is a good idea, as long as the OS manages to completely hide it from the user. Apparently, the current behavior isn't good enough, as it annoys some people a lot. On the other hand, it may just be a matter of getting used to the change.

That's why I specifically called out OS X. In 1984, that model made a lot of sense. But sometime during the next 17 years, computers got powerful enough that the reason doesn't really make sense anymore, and we fall back to "because people are used to it".

But it's clear from Lion that Apple doesn't really care what you're used to. We've had scrolling mice for about as long as we've had OS X, yet they chose to reverse it's function in Lion because, after entering the age of touch-screen devices, they realized the old model was wrong.

I just think it's a little odd for them to implement a half-way solution like this.

I wasn't aware you knew the history. I find it odd, too, but i can think of à reasonable reason for doing this. Good apps without anything to do will not use CPU time, so the only concern is swap space. That, I think, must be the reason for implementing this: on SSD systems, swap space can be scarce (hm, there may even be hardware in the pipeline where it is even scarcer)

I do look forward to a better solution, though. The days of the "Quit" menu item are numbered. Longer term, I think we should get rid of File-Open, too, bring back Lisa-like Stationary documents, and remove File-New.

And launching MacWrite in 10 seconds was the best case imaginable. Software like MS Word or Netscape Communicator took several minutes to launch on consumer Mac hardware through the 1990s. The early versions of OS X completely exhausted lower-end G3/G4 hardware -- Everything beachballed for at least few seconds, and not even TextEdit launched instantly. There's a reason that every Mac/Windows app had those "Are you sure you want to Quit?" dialogs ... Quitting was very very expensive if you didn't mean it.

Launching small apps like TextEdit didn't really become "effortless" until the Intel era, which really didn't start that long ago.

> I've never understood the "no open windows but still running" model

Here's a very specific use case that comes up all the time (for me, but I think it's more general too) where this model is superior: I have a folder-ful of files that I need to go through one-by-one. In my case it's usually assignments my students have handed in. What I want to do is open the first one, then Cmd-W Cmd-O and look at the next one, and so on. What I have to do if I'm unlucky enough to be on a windows machine is open the first one, look at it, open the second, click or Ctrl-Tab to the first, close it, and then look at the second. This is excruciating. Alternatively, I could keep one dummy file (or perhaps just the first one) open while I sequence through the rest. This is also annoying.

This is roughly the same reason (or one of them, anyway) that I also like the screen-wide menubar: at least some actions are relevant to the program, not to the document, and there's no reason that I should need a document open to execute those actions.

If you're not editing the files, can't you just use Quicklook to basically navigate through them iteratively and intuitively? I've added plugins to support php and java. (IIRC from here: http://www.quicklookplugins.com/ )

You could have a 2nd app like a spreadsheet for "scoring"... in fact this is what I did when I'm reviewed resumes for new hires.

Historically, most applications supporting multiple files would have used MDI interface, which is perfectly happy having just a window with no documents open (the equivalent of a Mac app with no windows open). Normally, this window has nothing but a menu bar, and perhaps a toolbar.

But for single-document applications, what I do (on Windows, running Cygwin), is roughly this:

for f in *.your-file-ext; do cygstart --wait "$f"; done

That'll iterate through each of the files in sequence, opening them up in the application registered for that file type, and wait until the application is closed for each file.

If some action is required, I might stick a 'read' in to that ad-hoc script.

(Disclaimer: I contributed the --wait flag to cygstart for just this kind of task.)