Whenever I do imperative programming I'm always conscious of time. Each statement may change state and I'm aware of how that can affect the system. I'm very aware of "time".

When I do functional programming (like Scala) I feel like I'm writing mathematical statements that aren't causing actions but just stating truths. It feels like time doesn't exist.

I know it's just a feeling and under the hood there's still a Von Neumann engine chugging away, but it's a feeling I can't seem to shake.

The original analogy involved a principal (a fairly complex process) who instructs a group of students (a collection of complex processes) to go to various classrooms (a fairly expensive / time consuming task). The pseudo-code he has breaks most of these assumptions and results in a simple single threaded task calling move-to-classroom routine that is so trivial that the implementation is not even shown. His straw man analogy is thus not correct.

It could easily be the case where the analogy is correct. e.g.

1. This is distributed system run on a server farm so the principal and each student could easily be run as separate processes and thus giving responsibility via messaging would be more efficient.
2. Assigning a student to a classroom is an expensive operation. Perhaps many transactions have to be made, email needs to be sent, humans need to approve, etc.

In this case, implementing this system (especially with a technology such as actors) would very closely parallel the analogy and the anthropomorphism would aid in communicating the design. The straw man argument that the author dredges up is a very simple example not worthy of most tasks a software developer faces in the 21st century.

Any analogy can be incorrect. Don't use them if they're incorrect.

This is a pretty healthy conversation but I can still add my $0.02

I hosted my own email server (webserver etc.) from 1995 to 2005. It was very enlightening but eventually grew to be a big pain in the ass. The last straw was a power surge that fried the motherboard. (raid and backups can't help with that) and looking at the the time and effort of getting a new hardware (and getting more redundant hardware) I decided to go with a hosting service. Eventually I pointed my domains to gmail.

Every geek friend I know has at one time hosted his own email. I'd be hard pressed to find a techno-nerd worth his cred who hasn't tried this. I also don't know anyone who has continued to host their email after a number of years of feeding and caring for the server beast.

I think the big issue is figuring out where to separate you hobby from your job. If you have a classic car in your garage that you like to tinker with is fine. If you decide to do you daily 20 mile commute in your classic car you're signing yourself up for some headaches as there will be days that you will need to bumb a ride, take a bus or taxi, etc. Hosting your own email is like commuting to work in a car that only you are able to fix in an environment where there are no buses, taxis or other cars. You have to be prepared to drop everything at a moments notice to fix your email server.

You can have someone else host your hardware but then ask yourself, why not have someone else configure and maintain the software as well?

DIY is great but realize what your signing up for if you want to DIY a critical system.

I agree with you that this sort of publication of charges instead of convictions sucks.

However, your characterization of drunk drivers is just wrong. They ARE incredibly dangerous. They ARE reckless, and while they may not intentionally be seeking out people to mow down, they are showing a tremendous disregard for those same people.

Buying Chocolate when you wanted Strawberry is a bad decision. Getting behind the wheel while drunk shows a fundamental contempt for human life.

Attempting to trivialize it in the way you have is honestly quite disturbing.

Royalties for a text-book, yes. However writing a text book is not an expected part of a university professors job.

Creating lesson plans, however, is a very different animal. It's an expected and required part of your job. We (the taxpayers) pay teachers to create these plans. For a teacher to claim ownership of these plans doesn't make a lick of sense to me. Just because you 'do it at home' doesn't change it. If I write software for a company at home, I'm still being paid for that work and have no right to claim it as my own. There is no difference here.

I will absolutely not pay unless I can freely stream my Hulu content to my TV.

Denver is currently piloting a meter that is really nice. It looks like a traditional meter, but it accepts credit cards instead of just coins. Convenient, easy, and apparently not very difficult to retrofit.

How does this generate extra revenue for the city over the traditional system? The real problem these systems solve (and they are very widespread) is making it easier to support credit cards for payment. That's a huge convenience for most folks who don't generally carry change. I get that cynicism is ultra-cool these days, but it's hardly warranted in this case. This is an attempt to alleviate a real problem for folks (like me) who rarely have change. I've used the system in Portland, Denver, and several other cities both here and abroad and I see no issues with it.
 

That article had no statistics, just a guy who has had articles buried. It was all based on 'talking to his buddies' who have also had articles buried.

It may very well be happening, but that article/blog-entry thing provides no insight into what is going on at all.

Simply not true. Nokia S60 has a veritable ton of apps available. Palm has roughly a billion.

It's not quantity, it's quality of experience. Neither Nokia nor Palm have really made the process of locating and buying apps very easy. The iPhone has.

Google has built a promising system for Android, and as they get more phones to market you'll see more and more applications built for it. I think this battle is going to be fought on balancing 'open' versus 'reliable'. Is apple right? Can developers not be trusted to build high quality applications if the phone is largely open?

Time will tell.

The point is you don't have to do even that. The routine would look something like:

- User initiates action with the floppy drive
- Run the auto-detection routine to see what answer you get
- Spin up the drive and check to see if something is in the drive
- Compare that with the pre-spun result to see what answer you get.

Something along those lines. There are several variations on this that would work and never require you to interact with the user at all.