I did a control system for a covered skid that contained three natural gas compressors. They had to pump it up to 3600 psi (245 atmospheres). It was for fueling vehicles. The pressure had to be that high so that the tank would equalize to a reasonable pressure / gas content in under 10 minutes.

It was 40 degrees F in the winter and 95 degrees F in the summer. Took about 6 months so I got to feel both. It also reeked of natural gas, was greasy, oily, etc. There were metal shavings and fumes from all of the machining and welding.

I also worked a similar gig off and on for about two years involving a circuit-board drilling operation. Imagine walking through a factory floor with acid baths and various machinery to work on scoring machines and massive computer-controlled drills. The drills were pretty serious (60krpm) and they each had a 1.5 ton block of granite just to dampen vibration. To this day, it's the only computerized machine I've worked on that required a pneumatic hook-up.

Here's a photo of the drills from the internet: http://www.cerambus.com/equip/images/4-MK%205%20DR.JPG

As of Python 2.6, look at the multiprocessing module.

The shared memory feature is nice.

As of Python 2.6, look at the multiprocessing module.

Look at the multiprocessing module.

Not only does it implement processes in a way that is quite similar to the existing threading implementation, but it provides a ton of synchronization / locking primitives that work seamlessly across processes. This includes the ability to utilize shared memory. It's crazy that this module doesn't get more press, because there's nothing quite as easy in most other languages.

Actually, cartesian products and joins aren't gone. It turns out that they just end up being done client side.

It's the tragedy of "join-less" databases. Joins do something that you need. The lack of joins forces people to correctly normalize, which ironically they should have been doing anyway. It doesn't take away any genuine need to join though. :(

In the end, the problem is that people just want a "default tool". They don't want to think about their requirements for data consistency. The really scary bit is that while RDBMses are the "default tool" of yesterday and slacker DBs are the "default tool" of tomorrow, neither of them are really the "problem".

The "default tool" attitude IS the problem. Unless you carefully weigh your data consistency requirements, you shouldn't be making that call at all.

I welcome the slackers and all of their new options along the spectrum of speed versus consistency. It's just that most of the people developing applications scare the shit out of me. They're so cavalier (or should I say, "agile", or maybe "pragmatic") about requirements that it's truly disturbing.

That said, if you're really interested in all of the options, I also recommend checking out memcachedb, memcacheq, and redis.

Maybe it's a declarative language?