Lambda the Ultimate

Peter, I would personally appreciate it if you could refrain from such postings here. This is far, far outside any reason anyone reads LtU.

[Edited.]

I wouldn't have posted but for the facts that:

1. The student asked for advice first, I didn't initiate the thread to promote my organization.
2. Ehud already posted that the original question was on topic.
3. The IEUC is a legitimate 501(c)(3) nonprofit incorporated in New York and recognized by the US Internal Revenue Service with a Board of Directors, a high caliber Advisory Board, and many other volunteer participants besides myself, who I won't list here lest I get flamed for further pomotion.
4. The IEUC strives in part to help students, like the poster, to further their study through mentoring and volunteer opportunities as I concisely described in my reply which was intended to be informational and not promotional in nature.
5. Moreover, I was giving general advice when I suggested volunteering with organizations 'like The Insititute....' so as not to suggest that The IEUC was the only such organization the student might want to approach.
6. At http://lambda-the-ultimate.org/node/1587#comment-19173 Ehud had previously opined:
   

   • announce an ongoing research project related to LtU topics and to invite interested LtU members to participate? (e.g. a tasteful one time recruiting pitch to announce the formation of working group on a language related topic to take a discussion offsite until some substantive results are in to be reported back to the community.) - A short post is fine.

   A sanctioned exception to the usual guidelines under which I felt my reply fell, when taken in the current context. This was also why I offered to host a working group on publication formats in my earlier post today.

In any case, I value this community and have truly been posting in good faith, but if it is going to cause such friction, I will leave my organization's work at the door and go back to reading quiety.

So Anton, please take this as a personal appology for ruffling your feathers and possibly running afowl of the current consenus on LtU Policy if your interpretation of my comments is the dominant view of the community.

...but the immediate question is about "PLT - Programming Language Theory" from the standpoint of an academic use of the term PLT. Now IEUC's goals are high and probably do touch on some areas that concern PLT, but as far as the question goes, I don't think it to be a satisfactory substitute for learning from the likes of Dijkstra, Harper, Reynolds, etc...

The immediate topic is not about how to get practical experience or about what research projects are worthy. In that light, I don't think it's on-topic.

I think Chris is right as regards what might be fruitful for the original poster. Peter's post was short and to the point, so while I think it wasn't a good suggestion in this context, I didn't object to it on principle.

Good points.

I tend to agree with most of what Bijan wrote. It is important not to underestimate the obstacles.

I don't know how institutions other than my own handle admission decisions, but I agree with bparsia's coursework recommendations. I can state with near-certainty that I would have been better served as an undergrad by taking abstract algebra than I was by probably any two CS courses. A good algebra background is essential for a lot of PL work (and work in many other subfields). Taking a number of courses where you learn to write good proofs will probably also help you prepare for some of the stuff you might wind up doing in PL.

The two courses that I regret not having under my belt are abstract algebra and elementary logic. For some reason my undergrad Comp Sci dept overlooked these. These are crucial for PLT research, and it has been a bit challenging for me to catch up on my own. PLT is dominated by mathematicians and logicians, so you need to learn their langauge.

However, there is an alternative path which hasn't been discussed much here, that is the software engineering path. At Microsoft for instance we have two separate divisions who work on programming languages: Developer Division and Microsoft Research. "Dev Div" is more interested in people who have practical knowledge and experience with writing and developing compilers and designing DSLs. "MSR" on the other hand is more interested in solid academic foundations and publication experience.

If you are interested in the academic path as opposed to the engineering path, then you need "research chops" as bparsia says. This is more important than what specific department you do it from. You want a supervisor who can help you learn to think and write in a scholarly manner. This can be mathematics, philosophy, or of course computer science. The subject matter of PLT I believe can be easily be picked up, once you have the proper foundations, by simply studying a few dozen papers.

It's not just that ability, and I would take "publishable" as a rough proxy for "worthwhile", but yes, that is a key ability.

A professor explained to me, once, the structure of (one aspect of) their (undergrad) math program: Calc for non-techies satisifed the math requirement. Calc 1 through Calc 3 (multivariable) were designed to get in the basics and provide enough background for the science/technical majors. These were all heavily "algorithmic", in that they primarily taught people how to compute rather than how to prove theorems. The linear algebra class was the testing ground, with a serious emphasis on "thinking like a mathematician". There was still a good bit of algorithm style work in the class, but there was enough theory to help find the people who might make good (and happy) math majors, and to start them down that path.

So, it is not unnatural to start out following algorithms (in novel circumstances), then following proofs, then generating proofs for known solved problem, then generating proofs for given unsolved problems, then selecting known unsolved problems, then figuring out new problems...this isn't a strict "progression", but it's often how people learn. Being able to generate proofs for (given) unsolved problems makes you at least a really handy research associate. Being able to sort through the more or less known unsolved problems and pick out the ones that one can likely solve (given recent advances) or would be worth solving (e.g., because they would help something else), also makes you at least a really handy research associate etc. etc.

Having all these skills to a high degree makes it very likely that you will do good, probably excellent, work over your career. If you can write things up well, that's really helpful too. Different people will have different balances of skills and traits. Getting along with other folks well is valuable because it allows you to balance your weak areas with other people's strong areas. (The specific modalities of collaboration and interaction vary enormously from field to field.)

To get a PhD (in the parts of programs I've been involved in) you have to demostrate that you can at least select an interesting area, formulate a "worthwhile" problem in that area, and solve it (or at least advance toward a better understanding).

(Of course, cracking a known, hard, sexy problem will do the trick. Deciding whether P = NP is more than enough :) But if someone came to me and said, "You know, I'll have the best thesis topic ever!!! I'm going to show that P=NP!!!! Then they'll have to graduate me!" I would have a loooong talk with them (presuming they were serious). Hard open problems can be good motivators, but one needs to have realistic goals and good contingency plans. Ideally, even if one's research doesn't solve the problem you set out to solve, it still has taught you (and the rest of us) something new and interesting.)

So, to get into a PhD problem, you have to convince the admissions committee (and typically your future advisor) that you will, eventually, do a PhD (and in reasonable time). There are other things as well (e.g., that you can publish; that you are stimulating to work with; that you won't drive everyone nuts; that you can do the coursework; etc.), but most of it can be managed a bit easier than the Big One. Failure to finish students, or to have students take forever (and I am a forever taker :(), is bad for a professor and for a department. (Often directly bad in that support from dean's and the school at large can strongly depend on graduation and placement records.)

Hmm. This isn't just an answer to your question, MTaylor. But I think the kind of considerations that goes into a throwaway line like "She's got great research chops" is actually enormously complicated and contextual. Anyhoo!