Lambda the Ultimate

But personally, I think a healthy dose of hardware knowledge would be a good thing in designing new languages. I think concurrency is a big issue right now, from threading to parallel processing on multi-CPU boards to clusters. I don't see how you can design good concurrency support in language without knowing something about how the hardware is designed. I'm guessing you'll get plenty of mathematics in your CS studies, but you might find that it's worthwhile to take a few extra classes and minor in it. Especially if you want to work with embedded systems, I don't see how having some engineering knowledge would hurt.

If you really want to do it, then you need all 3. If you skimp on one you'll find you need it later. However, what you want to know and what you should major in to know it are two entirely different things.

Also, your undergrad choice of major(and school) will affect your prospects for grad school. Obviously, you don't need a degree to learn something and you don't need a degree to do PLT research, but you probably will need a Ph.D. to convince someone to pay you to do it.

Personally, as a recent graduate with an MS in Mathematics and a BS in Electrical Engineering from a lesser known school, I've found that while I learned a lot, some of my choices have made further progress difficult on the Ph.D. route.

Your school may have a horrible CSC department. Your engineering program may not believe in grade inflation, so you won't have a good GPA or recommendations. Your math department may not respect the computational aspects of math you're interested in. If you have all of the above, change schools. If CSC and ECE are in different colleges, double majoring may be prohibitive in the excess number of requirements. Better to pick one, take classes in the other and ditch the double degree.

Your choice of degree should depend on which department is better able to further you down the path. If you choose based on stubborn resolve(like me), you may know a lot of what you want to know, but be unable to pursue it.

On your own, you should be reading papers, talking to their authors, asking questions about them, and generally trying to find the people who do the sort of research you want to do. Even if you don't understand the papers, read them anyway, and ASK questions.

As I said though, you need all 3, and frankly, some other areas as well(linguistics, the humanities, psychology, etc.). Language design is as much about people as anything, and so don't forget those goofy liberal arts and humanities people :).

Of course, this is MY experience, and others, including people who are in real schools doing this sort of thing will have better advice.

Learn to read, write, and speak as best as you can. I'm not joking. You'll figure out programming on your own, you can figure out math on your own, you can seek out papers on your own, you can read textbooks on your own. But no single skill will ever be as valuable in your research or professional career than to hone your ability to communicate effectively. And few aspects of our field are in more desperate need of improvement.

Choose an application domain, try writing code in existing languages for that domain, see what's wrong, move toward a domain-specific language for it. I think that's where you'll find the biggest bang for your time.

I had a double major in CoE and CS in undergrad. Fortunately, there was alot of crossover between the two. I'm finishing up my master's in CoE (specifically computer architecture) at a different school. I can see here how they make it very difficult for undergrads in EE or CoE to even take classes in the liberal/fine arts let alone major in second field.

I don't regret going the route (in undergrad) that I did. I switched between EE and CS several times. I finally settled on the path mentioned, because I was interested in the interface between hardware and software. This led me to my graduate program. I enjoyed alot of computer architecture and VLSI classes.

Why am I at this site, you may ask? Well, I decided to attend an undergraduate programming languages class (something I had avoided in my program) in which the language Haskell was taught. It intrigued me to no end (meaning it still does). And so, I was reading all I could on it when I came upon LtU. The discussions on programming language theory also interested me. I don't understand most of it; however, I'm working on it (when I'm not trying to find a job and graduate as well).

So, from my experiences, here's my general advice to you:

1. Be open to new ideas. You will be surprised by the number of things you learn in one area that also apply to another. Those areas may be completely unrelated.
2. Learn as much as you can about everything. This can be difficult, because some things interest us more than others. It's important to realize that these interests change. I was surprised, for example, when I was suddenly interested in language design even though I had avoided that class years ago. I remember stories other students told me about Scheme, and I saw no need to take it then.

Some specific comments in response to your questions are:

• For compilers and anything "embedded," you should also have a reasonable background on computer architecture.
• I'm very happy with my engineering training. Of course, my CS program was also in the College of Engineering. I would recommend this practical, applied experience to anyone. However, I don't think it helps much with proofs. You need a good algorithms background for that. I wish I had a better theory background in general.

Here's a question I've been meaning to ask the community: Would an "abstract algebra" course be useful for PLT? Any others along this line?