Another review by me is up on Play This Thing. This time it’s Primetime Adventures, and I think it’s worth a read (but then again I’m obviously biased).

Play This Thing recently posted my article on Burning Wheel, so do yourself a favor and go read it.

Recently there was a story on Slashdot about how Java will die of old age. I have some problems with that:

The Title
Since when do languages die of old age? The article actually points out that the most successful language (C) is older then I am. (Assuming you count since inception, not since major revision. C99 anyone?) This is more of a minor nitpick, but it seems like any sufficiently popular language will never really ‘die’ (at least not in the COBOL sense of the word).

That’s Just The Way It Is
All the arguments are made based on ‘how it is’ arguments. Apparently Java will never be replaced because it’s always been more popular, because employers want it now. I don’t buy that some hip new language can’t dethrone Java (or C) because it hasn’t happened yet. On the other hand, I don’t think it’s impossible for Java and C to stay dominant until some paradigm shift in computing demands new languages. Really, I think it’s pointless to predict what language will be dominant. If you learn to code well, programming languages are just tools: you pick the right one for the right task.

Let’s take a look at the arguments, one by one:

Reason number 1: Syntax is very important because it builds on previous knowledge. Also similar syntax means similar concepts. Programmers have to make less effort to learn the new syntax, can reuse the old concepts and thus they can concentrate on understanding the new concepts.

Really, how different is syntax between any imperative, or OO/Imperative hybrid, language? Let’s take Java and Python for example. The difference is really just in the characters used to fill the same roles in the grammar: ‘: indent’ is the new ‘{’, ‘unindent’ is the new ‘}’, move the name of the superclass into some parenthesis, etc. How different, on the syntactic level, is this? Sure, the semantics of what a field is may change, and duck typing means the whole concept of a type changes, but the syntax? Not so much.

Reason number 2: Too much noise is distracting. Programmers are busy and learning 10 languages to the level where they can evaluate them and make an educated decision is too much effort. The fact that most of these languages have a different syntax and introduce different (sometimes radically different) concepts doesn’t help either.

See my argument against reason 1. Additionally, how much programming is really needed to evaluate them? Most people don’t read the first 50 pages of 10 books to evaluate them, or try a year at 10 different colleges. I know that most languages I took up I looked into first and trusted other evaluations, or was told I needed to learn for a job.

Reason number 3: Lack of pressure on the programmers to switch. The market is pretty stable, the existing languages work pretty well and the management doesn’t push programmers to learn new languages.

The ‘good enough’ argument. This is actually a little persuasive. I’m not a huge fan of Java, but it does do many things well enough. On the other hand, most of the challengers are ‘good enough’ too, so it seems reasonable to expect that over time there may be changes. If both Java and Python are ‘good enough’ but new grads (such as myself) pick up Python and prefer it (a phenomenon I see all over the NMT campus), I’d think change may happen. Certainly not quickly, but I know when I start new code for myself I tend to look at Python first. Not out of any deep analysis, but because I really enjoy the language, and unless I have very specific needs it’s a passable tool for most jobs.

Reason number 4: Challenger languages don’t seem to catch momentum in order to create an avalanche of new projects started with them. This can be again due to the fact that they spread thin when they are evaluated. They are too many.

There’s some social issues with change here. I’m not an expert on the subject, but I did read The Tipping Point (like a good portion of the American public, I presume), and change is a strange beast. Given the relative ages of the competing languages, I don’t think any conclusions can be drawn (yet).

Reason number 5: Challenger languages communities don’t do a good job at attracting programmers from established languages. Telling to somebody why she is wrong will most likely create a counter reaction not interest.

I’m not sure what communities the author is talking about. Of course it’s hard to get numbers of any sort, but I’ve been involved with the Perl and Python communities, and I really can’t imagine how they could have been nicer or more helpful. This really boils down to personal experience (on my part and the author’s).

Reason number 6: There is no great incentive to switch to one of the challenger languages since gaining this skill is not likely to translate into income in the near future.

I agree with this, but with a caveat: the incentive may be small, but so are the barriers. In general, picking up a new language to the point of proficiency is not a huge challenge, so even if the reward is relatively small, it’s worth doing. In my experience, many people do pick up new languages with relatively little incentive, but this may be more of a consequence of befriending nerds then anything else.

Reason number 7: The new languages don’t introduce an earth shattering improvement in the life of most of the programmers and projects.

I’m not sure many languages since FORTRAN have introduced earth shattering improvements, but that hasn’t stopped a somewhat steady churn of popular languages.

Reason number 9: None of these new languages has a powerful sponsor with the will and the money to push them on the market. Powerful sponsor translates in investment in the libraries - see Java. All these new languages are born in universities and research institutes or are coming from very specific niche domains.

There are two points here: libraries and sponsors. These may not be the same issue: Perl has CPAN, but no big sponsor. I’d say a sponsor isn’t as big an issue. Sure, anything Microsoft puts their weight behind is likely to make progress, but quite a few of the top languages from TIOBE have no especially moneyed backers.

Reason number 10: Most of these languages lingered around too much without stepping decisively into the big arena.

I don’t know what to say about this one. It’s hard to say if this is true to begin with, or what effect it has.

Reason number 11: “Features” that look and are dangerous for big projects. Since there are not a lot of big projects written in any of these languages it is hard to make an unbiased evaluation. But bias is in the end a real obstacle for their adoption.

If we want to talk dangerous features, let’s bring C (the most popular by all the author’s metrics) into the mix. Pointer arithmetic, arbitrary memory allocation and deallocation, inline documentation only using non-standard tools (CWEB, Doxygen). C is problems waiting to happen, yet is widely used (and for good reason).

Reason number 12: Unnatural concepts (for majority of programmers) raise the entry level. Functional languages make you write code like mathematical equations. But how many people actually love math so much to write everything in it? Object oriented languages provide a great advantage: they let programmers think about the domain they want to model, not about the language or the machine.

Well, this is all well and good for ruling out Lisp, but what about the challenger languages that provide object orientation (but don’t force it, as Java does)? Python, Perl, Ruby, they all have object models of various quality and usefulness. On the other hand, the top language (C), has support for structures (and structures with function pointer members) but no real objects.

Reason number 13: Lack of advanced tools for development and refactoring cripple the programmer and the development teams when faced with big amounts of lines of code.

This one I’m not going to comment on. I don’t have enough experience with large scale corporate development to say what works and doesn’t. I do know that many open source projects get by pretty well without fancy refactoring tools, but that may not be a valid comparison.

This entire experience is a bit pointless. It doesn’t really matter what language you code in, if you’re a good developer it will work. Trying to predict the future, especially in a field like technology, is also more then a little pointless. I’m glad to have a choice of languages, and I’d encourage anybody who writes code to be pragmatic, not dogmatic, about what language you use.

I’ve been meaning to say something about this game for some time, so now seems as good a time as any. My Life With Master by Paul Czege is probably one of the best games I’ve ever played. You could just stop reading here and go buy it.

At it’s core, My Life With Master is a game of an abusive relationship. The players take on the role of minions of some evil mastermind, and the game follows them as they develop relationships with other people and eventually rise up against their Master.

The beauty of My Life With Master is in simplicity. Characters are represented by their Weariness, Self-loathing, a More Then Human trait and a Less Then Human trait. Everything else depends on Fear and Reason, constants set up at the beginning of the game. From these basic building blocks, the game grows into a powerful story of escape from an abusive situation. This is one of the few games I’ve played that provokes thought and conveys a message.

I really can’t recommend this game enough. It’s probably not a good choice for beginning roleplayers, but if you play RPGs and you haven’t played My Life With Master yet, you’re missing out on one of the best games in the genre.

UPDATE: Apparently I can’t read, Thanks to everyone who corrected me.

I found an awesome brain-teaser project from Google Australia called Treasure Hunt, originally announced here and here. Problem is, they don’t seem to want to accept what I believe to be the right answer to a question. I’m going to post a version of the question below, to see if someone can explain the problem in my reasoning. I don’t think there’s any problem with this, but if I’m asked to take it down I will (I’ve changed constants to X and Y):

A robot is located at the top-left corner of a X x Y grid.

The robot can only move either down or right at any point in time. The robot is trying to reach the bottom-right corner of the grid (marked ‘Finish’ in the diagram below).

How many possible unique paths are there?

My reasoning: consider a 2×2 grid. The robot needs to move from (0,0) from (1,1) (this is just a restatement of the above for 2 x 2). I say the number of unique paths is infinite. Let’s take a known path to the end: (0,0) to (1,0) then (1,0) to (1,1) (call this sequence of moves Sequence A). We can also make a path that returns to the start point: (0,0) to (1,0) then (1,0) to (0,0) (call this sequence of moves Sequence B). Note that Sequence B and Sequence A both start at the same location, and Sequence B ends at that same location. We can prefix Sequence A with Sequence B and still end up at the end. In fact, we can prefix Sequence A with any number of Sequence B, and still end up at the end. Each path is still unique, since each has a different number of copies of B.

Basically, I say there are an infinite number of paths since B* A is always a valid path. However, Treasure Hunt wants an exact decimal number as an answer. What am I missing? Or are they just using a different definition of ‘unique path’ then I am?

If you were taking my CS 111 final right now, you’d have these questions (among others) to look forward to:

Is everything in the set P in the set NP?

Is everything in the set NP in the set P? (There are always a few students who apparently think they’ll be getting one million dollars)

What is the Church-Turing thesis and why is it important to computer science?

What is the difference between a compiled and an interpreted language?

Extra Credit: Circle the cutest kitten:

Extra Credit: Write a haiku about some topic in computer science.

Extra Credit: How would you sort a list of a million 32 bit integers? Why?

(Each student can answer only two extra credit problems, I just offer more since they’re fun to write.)

Things that I’m currently greatly enjoying:

• TextMate
• Tex/Latex
• Python

These days, it seems like Marvel and DC come up with some new crisis to be dealt with every year or two. However, it seems DC was planning the run up to Infinite Crisis long before anybody ever cared about an OMAC:

From Justice League of America #35, Feb. 1990, words by Giffen and DeMatteis, pictures by Hughes, Nichols, Rubinstein, and Marzan

Too bad Beetle didn’t listen to Booster. On the other hand, I like the idea of Kooey Kooey Kooey being a reason for Infinite Crisis.

Sure, that was over 15 years before Infinite Crisis started, but Giffen and DeMatteis were up to their old tricks again a few years later. Tell me Ralph doesn’t know he’s going to get walked all over in Identity Crisis in this panel:

From Formerly Known As The Justice League, April 2004, words by Giffen and DeMatteis, pictures by Kevin Maguire

Come to think of it, Infinite Crisis was not a good time for the 80’s-90’s Justice League. Just off the top of my head, I know by the end of the whole Infinite Crisis shindig (including 52) Elastic Man, Blue Beetle and Rocket Red were knocked off. No wonder Giffen and DeMatteis had characters complaining about it years before it even happened.

Seriously though, if you haven’t read the Giffen/DeMatteis Justice League (Justice League of America, Justice League International, and Justice League Europe) or the follow ups they did a few years later (Formerly Known As The Justice League and I Can’t Believe It’s Not The Justive League), read them. They;re some of the most humorous comics ever written, with some good super-heroing thrown in to complete the mix.  There’s one volume of JLA collected, plus Formerly Known As… and I Can’t Believe It’s Not…, for the rest you’ll have to find single issues. Trust me, it’s well worth it.

It struck me while showing my students in CS 111 some pictures of the internet backbone over geographic locations that the structure of the internet backbone is strikingly similar to the Ticket To Ride board (at least for America).

In the next few days I’ll probably get around to doing a big summary post of what I’ve learned from interviewing all over the place. For now, here’s a rundown of my most recent two interviews.

Microsoft
My Microsoft interview didn’t get the best start. My flight to Denver was delayed, so I ended up not making it to Seattle until around 10 p.m., making for a pretty late night. After finally making it to my hotel, I ironed my clothes and tried to get some sleep.

Microsoft starts their interviews early. 8 a.m. early. I’m not too much of a morning person, but I managed to get awake and put together with plenty of time. Microsoft has a lobby just for interview candidates, including a Micorsoft Surface demo unit and a 360 with Rock Band. The Surface demo was certainly interesting, but playing Rock Band didn’t really strike me as the right thing to do just before an interview. Don’t get me wrong, Rock Band’s awesome, but I think I liked the calmer atmosphere of the Google waiting room a little more. The Microsoft lobby was pretty cool, and a lot of people were playing Rock Band, it just wasn’t my thing at that particular time.

After a quick briefing with my recruiter, I headed off to building 43 for interviews. Microsoft has campus shuttles (Toyota Pruis cars) going all day, making getting around easy. All of my interviews were in 43, so I didn’t need to take many rides.

I was interviewing for a SDET position. I wasn’t too sure how well it suited me going in, but then again it was a better fit then the SRE position at Google, so I was willing to go with it. Turns out I kind of like the idea of being a SDET. Microsoft has you interview with two teams, with each interviewer communicating with the next one to make sure they adjust your schedule and topics to fit what they need from you. I was interviewing with CLR (Cross-Language Runtime) and UIFX (Silverlight).

My first interviewer had me do some coding, I don’t remember the exact question. After the coding, I had to figure out how to test a real-world system. Oddly enough, I had been reading the section of Knuth’s The Art of Computer Programming that dealt with this same system just the night before, so I went into it with quite a bit of confidence.

After each interviewer at Microsoft I was taken to one lobby or another to wait for the next one. This was sort of nice since it meant I had some time to recover (and watch heated ping pong matches), but given my lack of sleep it also lead to me feeling more tired after each interview, instead of just keeping momentum. Overall a nice way to do things, and sitting in the lobbies and watching people go by gave me some ideas how people at Microsoft actually acted.

My next interview had some coding questions about palindromes. In fact, many of my coding questions had to do with strings, and since C is my go-to language, I was always able to easily break my own code with non-null-terminated character arrays.

Next was my lunch interview. We headed to the Microsoft cafeteria and picked up some food. The questions while we were actually eating were mostly light stuff, interests, experiences, and so on. After lunch we headed to the interviewer’s office for some coding questions. Actually doing a real interview over lunch was a new experience to me, and a little bit of a challenge, I tend to like to enjoy my food and make small talk.

My next interview was with somebody a little hight up the management structure. My coding question was a pretty classical problem with linked lists, which I had also encountered the night before in The Art of Computer Programming. I hadn’t read the answer in Knuth’s book, but I had worked out a O(n), constant memory solution, which beat out the easier solution with is still O(n) but also O(n) memory. I got the sense that my interviewer didn’t do much C programming, so we discussed what pointers really meant for a bit. This interviewer also gave me some logic problems, which weren’t too hard to reason through.

My final interview was when I realized things were going well. We talked about general stuff for a bit before moving to technical questions. When he started deciding what question to ask he told me he was already pretty sure of my coding ability based on the interviews I’d already had (an upside to having the interviewers talking to each other all day), so he gave me my most fun question of the day. I definitely don’t want to spoil anything, since it was a great question, but it involved arithmetic in a base that you’re not going to see anywhere else, but with some interesting properties.

After this I headed back to the interview lobby. Once I got there my recruiter came down to talk with me and let me know that one team was already interested in making me an offer, and the other one might be too. I waited in the lobby for a bit, waiting for the other team to make a decision, and eventually they asked to make me an offer too. Microsoft only allows one team to make you an offer, so I had to decide. I ended up going back to building 43 to talk to the leaders of both teams, and eventually settled on the UIFX team for a few reasons, including the opportunity to work cross-platform. Haven’t accepted anything yet though.

The guys from the UIFX team actually took me out to dinner the next night to celebrate, but that’s a story for another time.

Amazon
I was a little surprised by Amazon. But before I get to that, a bit of advice that I’ve seen other places, but I can’t stress enough: make sure you get to the right part of the right street in downtown Seattle, it makes all the difference.

Anyway, Amazon put me up in a real nice place downtown, probably the nicest I’ve stayed in for an interview. Unfortunately since my Microsoft interview went so late I had a hard time finding the type of food I wanted by the time I made it to my hotel. I really just wanted some semi-nice take out, which is not easy to find in the downtown area, and by the time I realized this it was too late to have many other options.

Anyway, the actual interview was interesting. I did most of my code in Java, since the team I was interviewing with was big on OO design. I’m pretty good with Java, but I realized I tend to go towards very simplistic answers since I’m used to using Java to teach CS. In the future, I may use C++ for interviews like that (if I have more), since it doesn’t have the same cognitive baggage.

I didn’t spend much time in the Amazon lobby, due to getting there just on time. The one thing that stood out to me the most was that Amazon provided a schedule for my entire day at the start, along with the names of the people I was interviewing with, which was very convenient.

My first interview involved making a file format for a certain type of data with code to read it in and out. It went fairly well, with a few revisions to my file format as I went to make my life easier. After that was a very open ended OO design question, which was fun since it lead to a lot of discussion and refinement of my ideas.

After this was my lunch interview, where my potential boss took my to lunch. It was not an interview per se, more of a discussion of the team and the position. We went to a little Mexican place near the Amazon offices I was at which had surprisingly passable Mexican food. It lacked any real punch, but also didn’t offend my taste buds, which is probably saying something for Mexican food in the Pacific North West.

After lunch I had another technical interview, but nothing really stuck out about it. It’s a little funny: some time ago, when I first started doing this whole technical interview thing with Google, I would recall every little bit, since it was so novel and fun. After many many more, it’s still fun, but less sticks out as memorable.

My next interview was with a couple of manager-type people, but still focusing on coding questions and design. The coding question was probably one of my weaker problems, since I felt a little over-confident and stumbled some, but eventually arrived at a good bit of code. The design was also a little tougher, by the end I felt like I hadn’t quite met what the interviewer was expecting.

My final interview, the infamous ‘bar raiser’ was another fun problem. I actually coded my solution out in Python, and while it was O(n!) it was also as fast as possible. One of the more fun questions I got, partially because O(n!) is something you never want to accept as “good enough” so I was constantly trying to cut down the run time.

Amazon also made me an offer, and continued to impress me by beating out Microsoft’s offer in a few ways.

Not really sure what I’m doing now. Taking a hard look at the offers I have, and trying to figure out which company I can actually see myself at.