I have some news on the undergraduate research situation that I briefly mentioned at the beginning of the semester. However before I get to that, let me expand on the bullet point in the linked post. (I apologize for the length. As usual, this one aspect of my life expanded to epic proportions.)
I want to go on to graduate school after I complete my four years here at Purdue. I am 99% sure that will result in a master's degree, but I am still split 50-50 on whether to continue to a PhD from there. The 1% in the former case is reserved for some amazing job offer that would warrant postponing grad school. The latter case is far more complex and worthy of a post unto itself. Luckily I still have a year and a half to think about it.
In preparation for whatever I decide, my counselor advised me to do undergraduate research. Grad schools appreciate research experience when considering admissions, and it is good to start as early as possible. I did not start looking for a research sponsor early enough last semester and projects consumed all my time once I did. Despite that I had two tenuous leads.
The first professor specialized in GUIs and GUI optimization. and I spoke to him about one of his projects involving program auralization. Think "visualization" but with MIDI. By running source code through the application and compiling the output, the resulting program would play "music" when it executed. Somewhat nifty. It goes along with programmers' love of bizarre data representations. However the application was almost finished and had few uses beyond a toy or hard-to-use addition to a debugger. Our research would involve "finding its killer app". We could expect minimal programming; certainly nothing involving MIDI or language parsing, the two parts of the project that interested Lee and me.
I decided not to pursue that research opportunity. Was I being picky? Perhaps, but if I am going to work on a semester-long independent study project, I want it to be with something I enjoy and that would look good to recruiters. I didn't feel that a nearly complete "music box" satisfied either criterion.
I learned about the second professor— let's call him Professor J.— through a classmate named . Professor J. specialized in programming languages and was interested in discussing some of the ideas Chris and I had brought up in last semester's "preparation for undergraduate research" seminar course. It seemed like a good fit except that he was out of the country. I had not heard from him by the end of the semester, so I feared I would have to postpone my undergrad research for next year.
Professor J. responded just as the new semester began (here we arrive at the bullet point). He, Chris, and I quickly scheduled a meeting to brainstorm on research options. We touched on visual programming languages, typography, program visualization, and functional languages, among other things. We didn't reach a conclusive project idea, but it gave Chris and me a place to start thinking.
Chris and I planned to get together a few days later to bang out a project idea. I proposed that we include Lee in the meeting and project group. After all, I worked with him in our compilers course and had planned to do research with him and the first professor. Chris was open to the idea, so the three of us met.
The following is a snippet of the email I sent to Professor J. explaining the project idea we came up with at that meeting.
[snip]
Chris and I have made progress on starting the undergraduate research we spoke to you about last week. We met on Friday to brainstorm ideas based on the topics we discussed in your office. I invited a fellow CS honors student named Lee Ballard to join us. We had a productive three-way discussion and now feel we have a good basic idea for a semester project. Can we meet with you sometime this week to get your input and direction as well as discuss the possibility of Lee joining the group? Chris and I both feel that a three-person team would yield a very impressive project.
The idea we came up with drew from our talk about typesetting and visually augmented languages. We batted around ideas for visual debuggers, improved typesetting languages, and niche visual languages based on functional languages; all things brought up in last week's meeting. From typesetting and functional languages we progressed to more generalized vector languages such as Postscript, SVG, and others. It seems these languages lack-- and you will be able to help us verify this-- some kind of built-in programmatic functionality. For example, to plot some mathematical curve, a scientist must write a program or use a pre-made package that plots points and exports a final picture in the vector language. We asked ourselves, "Would it be possible to make a vector language that includes this functionality natively? That is, could a vector image language contain control flow and functional structure similar to a multipurpose language? If so, how would one design such a language, how would it function, and what would be a good use for it?" These questions are all good foci for research.
One can also look at this question from the point of view of a general-purpose language. Most languages with a graphical component tack it on as a secondary library. (i.e. Java's various Swing graphics classes) On the other hand, some vector languages allow for programmatic control via a programming language tacked on to the vector data. (i.e. SVG and Javascript) A programmatic vector language such as the one we were discussing would blend the drawing and control flow into a unified environment.
We feel this path (if it hasn't already been tread; again, you can help us determine that) offers a great deal of research promise. We look forward to discussing it or possible alternatives whenever you are available to meet.
[/snip]
The four of us met today to talk about where to go next. The meeting was terrible (I do not want to go into why), but we left with three goals for the near future:
- Define the abstract scope of the project. We need to figure out what the program will do while avoiding the trap of defining exactly how the application will work. Questions about the languages, libraries, interfaces, and output need to wait.
- Think about the basic questions. Why pursue this project? What problems will it solve? What needs will it satisfy? What can we or the world learn from it?
- Figure out if it has already been done before and modify numbers one and two as necessary. This is the important one. It is disturbingly likely that someone has thought of something similar before. As undergraduates without research experience or research knowledge, we have no clue what work people have done already. We hope that our idea fits in a niche between graphics libraries and declarative vector languages. If not, we need to think harder or expand on what has already been done. "To Google!" is our mantra.
All three of us have built personal programs for our own enjoyment and class projects for the grade, but this will be our first big independent project in academia. I plan to record our progress throughout the semester. Unlike a job, I can write about a research project as much as I want.