January 5th: http://buytaert.net/drupal-7-to-be-released-on-january-5th-with-one-ginormous-party Before Duke Nukem. (Actually *all* Drupal releases ever have been released during Duke's development...)

the calculators listed below are of precision quality

To how many significant digits? We need to know what level of precision we're working with.

If you're into strategy and don't mind losing all of your free time and some of your work time, there's FreeCiv. Think Civilization recast as a full-on client/server multi-player setup. I've not played it recently (no time to game at all lately, too much code to write!) but the graphics requirements should be fairly modest.

The best advise I ever saw in terms of meeting people (it wasn't direct at me, but it was on a mailing list that I was on) was "if you want to meet and/or date people who are interested in X, you've got to put yourself where people interested in X are." That's true for any given definition of X.

Figure out what your interests are, geek or otherwise. Don't take a cooking class just to meet chicks if you don't want to know how to cook for your own sake. If you are interested in it, though, get out there and do it. Meet people. If you're looking for geeky relationships (friendly or romantic), find your local LUG, or an open source project you're into may have a local users group. If you're into Star Trek or role playing, look for a local fan club or D&D group or LARP. If you're a somewhat religious person, get involved with your church/synagogue/mosque/whatever. (Note: Do NOT do that if you are not genuinely at least somewhat religious.) Personally I'd recommend taking a massage class. Not only is it a very good skill to have, it's a skill that many people appreciate in a person (friendly or romantic) and my understanding is those classes tend to be mostly women, too. :-)

The geekier groups are likely going to be mostly male, but that's OK. You're trying to meet *people*, not *women*. The women come later, because they're people too. :-) (And acting like they're not is a great way to stay single.) Half the time you'll meet someone through someone else that you really like, that you wouldn't have met if you hadn't met the first person first. Friend-of-a-friend is a great way to meet people as well, if you bootstrap yourself first.

If you already have a few friends, see about tagging along with them to things they do. Odds are if they're your friends you have interests in common, which means you probably have *other* interests in common, too. If they're real friends, they'll be supportive of your endeavors.

I'll also add that when people ask me how I learned to dance, my answer is always the same: By being a bad dancer for a long time and not caring, until I got good at it. Socializing is a learned skill. It will take time to learn. Just remember that it's a much "softer" skill than programming, but that doesn't mean it's not as complex or challenging.

As others have said, expose students to all three methodologies (procedural, OOP, and functional) as early as possible. A language that supports all of the above can be good for that, or else pick languages with reasonably similar syntaxes (eg, they all use curly braces for code blocks) to reduce the mental overhead.

That said, I would do procedural first. It's the closest to what the computer actually does: Execute one instruction after another in order. It is also, therefore, the one with the least mental overhead. It's easier to explain a conditional or a loop in a procedural structure than a functional structure, I'd argue. (And in that case OOP is a superset of procedural, as the code within methods is still behaving procedurally.) So the 101 course should be in a procedural language, or using procedural style in a procedural/OO language.

I did OO next, but in hindsight I'd probably suggest functional second. It's the most "mathematically pure", and the one that forces you to think about what you're doing at a conceptual level the most. It's also the one they're least likely to use in practice out in industry, but what students learn about good design in a functional language (atomic functions, no side effects, logical thinking, etc.) will serve them in very good stead later on in their careers. I only had about a quarter of one class in which we covered functional languages and I just didn't get it at the time. Years later I finally figured out what functional programming was all about and even though I don't write functional code I've found my coding style drifting to be more functional-ish, and as a result much less bug-prone and, for me at least, easier to read.

Then put it together with good OOP. You then have the procedural stuff down pat, and the good practice of how to treat functions as discrete behaviors. An object, then, is just a larger chunk of discrete behavior bundled together. It introduces the complications of state, but the idea of each method as an atomic little bundle of behavior within that larger bundle should be a smooth transition from functions as an atomic little bundle of behavior.

All three are equally expressive, but knowing all three will give students a better understanding of *how to think about the problem at hand*, which is what school is all about. Even if you're not coding in one of those paradigms, you can still implement many of the same concepts in another paradigm where appropriate. (No-side-effects from functional, polymorphism and delegation from OO, and "how does the computer think" from procedural are all applicable in all paradigms, if you're coding properly.)

I argued much the same thing in much less space 2 years ago. :-) Most "MVC" web frameworks are anything but, and it is disingenous to claim that they are. It's a marketing gimmick for people that don't actually know what they're talking about.

I have long argued that MVC doesn't even make sense on the web to begin with. MVC is a great architectural model for live interactive systems, but a web site or web app is not a live interactive system. It's an asynchronous challenge/response system.

I blame Sun for completely abusing the term in their Java stacks (I think they called it "model 2"?), and Ruby on Rails for popularizing the wrong impression. MVC by definition requires a direct observer connection from View to Model. All web-MVC frameworks I've seen start with the initial statement that the Controller, not the View, is responsible for handling user interaction and communicating with the Model. Sorry, that's not MVC. It's not a bad model for the web, but it's not MVC. If anything it's closer to PAC.

See the link above for a lengthier analysis and links to Wikipedia. :-)

Really, the whole point of design patterns is to have a common vocabulary. How is that useful if you're going to bastardize your terminology due to stubborn ignorance?

It's not a natural right, but considered by many people to be a societal right, granted by societal agreements. And taxes aren't theft. That's a false dichotomy.

People who want "Lifestyle phones" are in a specific demographic. Maybe it's a large demographic, or maybe it's one of the largest demographics, but that still stands. Just because you want this for your phone does not mean everyone does!

Regardless of what you want to do with your phone, the point of a lifestyle device is that it looks good and very quickly and effortlessly performs it's functions without hassle (it does not cause stress or aggravation to your life, it just works). I agree with you only in one class of exceptions: Science and Engineering - people who desire to use a smartphone as a power tool would probably not find a lifestyle phone very attractive. But outside of that very slim demographic (that probably wants quick keypad shortcuts for everything and can tolerate or even desire complex interfaces), I think that everyone benefits from a lifestyle approach, regardless of their usage profiles.

This is why companies like Nokia, Sony Ericsson, etc have a wide range of offerings to suit different needs. If you don't want a phone that works like a computer than for god's sake don't buy it!

Actually, I disagree. I believe this "shotgun approach" is rooted in something much simpler than attempting to reach different market segments. It is simply the lack of any essential insight into how such devices should be designed to cator to all usage profiles seemlessly. The companies are clueless on how to achieve this and therefore have to resort to verticle market strategies to attempt to get coverage and compete in the different artificial smartphone categories. Even claiming that PDA Phone is a market category that makes sense makes my head spin. Perhaps stylus enabled phones are in a seperate class, but PDA Phones? Come on.

My main point is that the "lifestyle phone" segment is covered by every manufacturer, as is the "PDA phone" segment, as is the "low end" segment, as is the "Music phone" segment, etc, ad infinitum.

And my point is that "lifestyle" should not be a segment at all, but a firm basic requirement of any phone. I can see the need to specialize in certain respects (e.g. power tool phones for developers, engineers, scientists, high end camera phones for photographers, high end media phones with huge batteries for travelers, stylus phones for MBA PHB types, etc...) - however, all of them should resonate style, simplicity and resonance with stress-free living (e.g. lifestyle). Currently, I don't really think anyone has this right. I am holding out some hope that Apple will give us all a clue as to how next generation handheld devices should integrate with our lives. [ crosses fingers ]