CS Education: C# in Mono / Java

At least three times this year, I have found myself suggesting that perhaps it would be better to teach component-based software enginereing to young undergraduates using C# (via Mono, of course) as opposed to the more-restrictive Java. I feel a little like Nixon going to China when I say this...

Having said that, it's probably better to use Java for production code. But I almost think that you need flexibility to experiment at the educational level, and Java has no flexibility (because it is so tightly crafted for security, portability, and stability). C++ has a lot of flexibility, but no one wants students learning C++ anymore (a comment on that in a bit). C# (under Mono, of course) has more flexibility than Java but less than C++. It's relevant, as it is relatively easy to move from C# development to Java develpoment (and there are plenty of companies (or at lest one gigantic one) that are looking for C# developers too). It has preprocessor directives (even though it has no preprocessor), which gives it a customizable presentation for the classroom environment. So it feels like it would be easier to start with C# and then "graduate" to Java (and go to graduate school for Lisp? I dunno. And where does Python fit in? Maybe it takes the place of Logo in 4th grade).

Regarding the note above about no one wanting students to learn C++ anymore, it is interesting that software interviewers are typically of the age and rank where most of their experience is in C or C++. I was at an interview recently where the interviewer asked questions contrasting addressing individual bytes of a 4-byte unsigned integer using pointers or bitmasks; such a question does not belong in any discussion of Java. Moreover, I heard someone in a nearby cubicle on a phone interview being asked about static variables in C and C++ programs. The graduate student was more familiar with "static" in the context of Java, and so I think he worked htings out sufficiently well, but most students have never heard of this term (likewise, they don't even think to look up "persistent" in their MATLAB documentation). So it seems unfair that undergraduates are being switched over to Java... and will be asked about pointers in some of their first technical interviews. Oh well...

Dr. Bernoulli gets a job: Mathematics of the Job Search – Faculty Version

I recently found out that the Duke Computer Science department had 404 applicants for the open position in their department. I mentioned that to a CS professor from a different university, and he didn't seem surprised by that number. Moreover, when you think about how many "faculty candidate" lectures there usually are within a CS-like department each hiring season, and you consider that those interviewees are likely a small selection of the total applicants, then 404 starts sounding reasonable.

When there are 404 applicants who each have PhD degrees, publications, and possible post-doctoral or existing faculty appointments, let's also assume that the objective function that each department is maximizing is pretty flat. If you don't like that assumption, then assume we have no prior information, and so we will maximize entropy and assume that each applicant has a 1/404 chance of being picked for the job (in reality, this probability is itself conditioned on whether the state steps in and has a hiring freeze... so the real probability might be closer to 1/1000). So that is a very low number. Can we fight low probability with high volume of applications?

Assume we apply to N schools where the probability of getting an offer is

p = 1/404

at each of them. Then the probability of not getting an offer from each of them is

1 - p = 403/404,

and so the probability of not getting an offer from all of them is

(1 - p)^N = (403/404)^N.

So finally we arrive at the probability of getting an offer from at least one of them, which is

1 - (1 - p)^N = 1 - (403/404)^N.

Hypothetically speaking, let's say you apply to N = 50 such positions. Then you have a

1 - (403/404)^N = 1 - (403/404)⁵⁰ ≈ 11.65%

probability of getting the offer. Of course, if you were paying attention, you remember that p (1/404) is very small in this example. Consequently, the (1 - (1 - p)^N) curve looks linear for a wide region around the origin. So even though you remember your fourth-grade math teacher teaching you that you cannot additively accumulate probabilities (i.e., your probability of getting a job is not (N × p)), in this small-p case, it is a pretty decent approximation. In particular, even with our ostensibly large N, it is the case that

N × p = (50)(1/404) ≈ 12.38%,

which is pretty close to our slightly more dismal 11.65%.

In December, I ran into a woman who just got finished submitting all of her faculty positions. She said she applying to just 10 of them because she was exhausted and figured she was just practicing this round. Setting N = 10 reduces your chances to 2.45%. Having said that, the distribution across the applicant pool is certainly not flat. Her home institution, research, adviser, and other factors make her a very attractive candidate who will likely do well with such a low N... In fact, she was recently interviewed at a university near me (that, again, may have to deal with hiring freezes, etc., in the near future).

Now, in my case... Maybe I should burn my CV and dust off my résumé... I hope I'm not too old and outdated.

Scripts to get Mercurial up and running on OSU CSE machines (SunOS and Linux)

UPDATE: A day after I posted this, Mercurial and Python (and Git) were added as optional subscriptions for users of these machines. So login to your desired machine and execute subscribe, then select MERCURIAL and whatever PYTHON is available (version 2.4.x or higher). Quit subscribe to save your changes, and re-login (of course, you can also do the same thing with GIT).

If you are a student, staff member, or faculty member in the Computer Science and Engineering department at The Ohio State University, you may have found yourself wanting to use a DVCS like Mercurial (hg) for SCM. Unfortunately, the version of Python that comes bundled on these enterprise systems prevents installing Mercurial, and some other issues on the SunOS system (like the lack of round() in the math library) prevent building a recent version of Python 2 that is needed for installing Mercurial. There are ways around this mess, and I have done my best to automate them within a script.

So give it a shot:

• install_hg_osu_cse_linux.sh – Linux install script (i.e., for faclogin.cse.ohio-state.edu and stdlogin.cse.ohio-state.edu)
• install_hg_osu_cse_sun.sh – SunOS install script (i.e., for facsun.cse.ohio-state.edu and stdsun.cse.ohio-state.edu)

Download the appropriate script to your desired target machine. Next, edit the script (e.g., using pico, nano, vi, or emacs) to verify that the INSTALLDIR location at the top of the script is what is desired – if you are going to run the script on both types of machines, your INSTALLDIR must be different in the two scripts. Then run the script on the machine (e.g., ./install_hg_osu_cse_sun.sh) and follow the instructions. The script is interactive, and so you will be able to manage its behavior as it runs. Be sure to follow its instructions at the end about setting your PATH and PYTHONPATH; if you ran the script on both types of machines, you will have to be clever in your script RC/profile file to set these differently based on the machine you are on – I recommend using uname to detect the different machine type.

After that, you should have a working Mercurial. In the Linux script, you may adjust the Mercurial and Python 2 versions downloaded, but in the SunOS script, you need to leave the Python 2 version alone as later versions of Python will not build on the SunOS machines (due to the problems with the old math library). On either machine, if you are adventurous, you can use the installed Mercurial to clone the stable Mercurial repository (hg-stable) and keep your installed Mercurial up-to-date with the very latest stable version.