CS PhD jobs

I'm meeting with the career counselor for computer science students today at the U. We are going to look over my resume. I think this comic sums up things nicely:

Embedded languages

Some time ago I read Stephen A. Edwards' article called Design Languages for Embedded Systems. Although it is now over four years old, it did and still mostly does provide a nice survey of a embedded programmer's language options. I wanted to review four that he mentions and one that he does not:

• C - This is pretty much the current lingua franca for embedded systems, and it will probably stay this way for many years (fears of my previous post aside). Often classified like a big gun, one can do whatever they want with C. That include writing really really really BAD programs.
  
• Java - Object-oriented, automatic garbage collection, and lots of other goodness. real-time java attempts to provide embedded developers necessary tools, but it has not completely caught on yet.
  
• VHDL - This is a hardware description and modeling language. Reminds me of the good ol' days in CS 224. I must admit I did not actually use much VHDL then, but one or two people in the class did. So I am actually not really familiar with it.
  
• Esterel - I am not really familiar with this either. However, at LCTES '06 I heard a number of talks from researchers using and/or improving it. Edwards was one of them (showcasing SHIM) and in his paper he classifies Esterel as a hybrid language.
  
• OCaml - This is the language I am currently using the most, so I have to mention it. Unfortunately, I am not using it to do embedded programming but to analyze embedded programs instead. OCaml does not seem to be suited for really tiny MCUs, but it might work with other embedded programming
  

C in the future

During the last meeting of the Compiler's Reading Group (CRG) here at the University of Utah, the discussion moved to our future vision for users of the C language. The question put forth by Jay (if I remember correctly) was whether C (and C++) is going the way of Fortran, or if people will continue to use it as it is, or if people will use some "safe" variant of it. My advisor, John Regehr, asserted that both the first and third options will occur. Specifically, that C will become (it already has, to some degree) a niche and/or legacy language and that the version of it to be used will be made safe.

I think this answer will probably be correct eventually. It is supported by by Kathryn McKinley's talk from a few months ago. One poor student decided to take her on and say he did not believe that java garbage collection could do a better job than his own memory management. After some back and forth, she eventually said "you're wrong!" When it was her credibility vs. his, she wins. The point of that is programs have become so complex that a compiler usually beats the programmer. That makes languages which rely more on the compiler, like Java, seem a little more appealing and languages which give total control to the programmer, like C, seem a little more out-dated.

You may or may agree with this. My impulse is to fight long and hard against this. A lot of us like the "freedom" C gives us and hate having hands tied in any way. However, maybe the time has come to face the music and switch to another language...

Social networking

I decided that it was time to update my social networking and web 2.0 sites on the web. I thought it would take a few minutes and then all would be well. I also figured that while I was at it I would sign up for facebook. Well, a day and a half later I am done. Of course, part of that delay was time taken to watch my newborn and 19 month old, but it still took longer than I thought. I think in the future I might let some of these die off (again), but I hope to keep some of them up to date (more or less):

• 
  
• 
  
  
• TMM Alumni Profile
  
• LDS Linkup Profile
  
• Friendster Profile
  
• del.icio.us bookmarks
  

Research tools

Talking with other PhDs, there seems to be a universal paradox with doing thesis work. More often than not, our small projects become big projects. This means that the big projects need documentation, maintainability, usability, and all those other -ities for significant pieces of software. However, for small projects we just want to hack them up and get it out the door so we can move on to something important. Those two do not mix, so the question is how to balance and transition between them.

My thoughts on this now (in retrospect) is that every small project should be treated like a big project unless there are significant time constraints or it is a perl/python script. Anything else should be expected to be used/extended by someone, possibly not yourself. If the project stays small, the documentation will be insignificant. Plus, if you are in academics you are going to write a paper about it anyway.