There may not have appeared to have been any personal accountability, but make no mistake if anything had gone wrong with the On-Board Software the EXACT same accountability process would have been initiated to ensure that the same human error did not occur for a second time.
Very unlikely, unless that had been imposed on the group by an external, blame-oriented entity.
Left to its own devices, the group would most certainly have operated as it did every time it found fault in its output: find out how The Process had allowed for a fault to be introduced and reach output, find out how to make The Process prevent the introduction and/or release of such faults, fix The Process.
So no, the "exact same accountability process" would most definitely not have been initiated within the group, a very different one would have taken place.
It's also worth noting that GUIDs in this case have nothing to do with persistence but rather with associating urls with behaviour in much the same way as the fnids you'll see on various urls (like flag) on hacker news.
Agreed, the costs of living in London (especially Zones 1 and 2) puts London in the top 20 of most expensive cities to live in the world. However, If you're going to pay a youngster £30k they will not (and should not) be expecting to live in Zones 1 and 2.
Which is my argument suggesting London isn't suitable for a youthful startup culture as many younger people will be put off from moving into the suburbs because of the costs involved.
Not answering for everyone, of course, but I find the mac model breaks down when I only want to pull a single window of an app to the foreground.
Envisage, if you will, this scenario. I have multiple terminal windows open in the background connected to various services and my current focus is on my fullscreen IDE of choice. Now my IDE has various pieces of information on it and, given that my short term memory isn't what it once was, I would like to always be able refer to it. So I switch to Terminal and ALL the Terminal windows are pulled above the IDE window, often obscuring the piece of information I wanted to reference.
It's not that the 98-esque model is necessarily superior, it's rather that it's surprising when windows you haven't requested to see are pulled into the foreground. Now this may be due to me having used `window-centric` switching for many years but after 3 years of owning a mac I still find this behaviour frustrating.
If you don't mind using the mouse, you can bring a single window to the foreground by right-clicking the corresponding application's Dock icon and selecting it from the list.
Another more visual option (that you can manage with keyboard only) is to use Exposé. In Snow Leopard, press the Exposé key on the keyboard (or set your own shortcut), start typing the name of the window you want, and press return to bring only that window to the foreground.
I've found these to be pretty good built-in solutions to the single-window problem.
You might want to check out Visor - http://visor.binaryage.com/ makes your terminal a roll-down fps-like console, and can handle all the tabs as well. I've found it very useful to solve the exact problem you're having.
I just realized the other day that you can drag a tab off of visor and use it as a regular terminal window in case you need to look at two terminals at once.
CMD-` switches between application windows. That might help a bit, I use it constantly; so constantly in fact, that I remapped buffer switching in emacs to that command.
I'm a hater of the App -> Windows paradigm. I just brought up two finder windows, minimized one, CMD-TAB'd to Chrome, then back to Finder, and finally no amount of CMD-` would make the minimised Finder visible. Plus, just how many mouse actions does it take to tile two windows? Two in Win7, a whole lot more in OSX.
CMD-` doesn't solve the problem, if you are in an application and you want to bring up a window from another application you still have to use CMD-TAB. But this brings up all the windows from the other application.
Yeah, the best solution here is definitely exposé. Invoke, select just the window you want via arrow keys or beginning to type the window's title, hit return, and only that window comes forward.
Unfortunately, the traditional way to solve this problem on a mac is to arrange the windows, and remove what wasn't needed. Full-screen apps weren't supposed to be used.
Exactly. And now Lion is going to apparently emphasize full-screening apps. This is a complete 180 by Steve Jobs who has hated full-screen apps as long as I can remember.
No offense but I don't think you get the concept of batteries included. Python has batteries included, Clojure has batteries available.
Even the clojure contrib jar is not included by default and has to be downloaded separately and then clojure needs to be launched with extra command line arguments to setup the classpath properly (or you need to fiddle with the classpath from within clojure), the same goes for any Java library that you want to use.
Except for the classes in the JDK. That gives you networking, file I/O, string processing, regex, Swing GUIs, JDBC, ZIP compression, some XML processing, among other things.
Even by itself, that is better than most Lisps out there, if not enough to make a Pythonista happy. The problem with this stuff is usually the painful verbosity of Java necessary to use it, but you can wrap away that pain very quickly with Clojure.
I do take the point about needing to fiddle with the classpath for any other Java code you want to use. But for me the Java classpath system holds up better than most other software deployment mechanisms. Usually, you just download a jar file, drop it on your classpath, and it just works. I think jar files are an unappreciated success story of the Java ecosystem. Clojure has functions to easily add jars to the classpath at runtime, which is even better, but I find it does not always work seamlessly for me.
Those numbers do look a little funny, 22 seconds seems way to high for Ruby 1.8, on my macbook 2.6Ghz it's around 3.2 secs.
Out of curiosity, what were you doing that made your SBCL numbers so high? I've got 1.8.6 (running natively on OSX) clocked at 1.3 seconds and SBCL (linux on VMWare) at 78 ms.
(These times are with the random number generation removed, with them the SBCL time jumps to 90ms and 1.8.6 jumps to 4 seconds).
I picked up the language after running sawfish as a window manager. This took me to emacs and from there to Common Lisp. I can highly reommend 'A Gentle Introduction To Symbolic Computation' if you are new to programming and 'Practical Common Lisp' if you aren't new to this field.
If you follow that up with 'On Lisp' and (optionally)
'Lisp In Small Pieces' you cant go wrong.
