It's finals week across the country, and thousands of computer science students are finishing up a programming language course. At least a handful of these have been infected with the fascination of the subject, and I hope to meet them someday. From the enthusiast to the couldn't-care-less, here are my thoughts about where you can go from here with one programming language course under your belt.
Going Pro
Take more classes, participate in an open source language project, go to grad school, and get a job with a company that makes a compiler or interpreter (IBM, Microsoft, Wind River). Remember that there are lots of languages with a smaller reach that still need people to work on them. Embedded systems have lots of chips (purpose-built CPUs and microcontrollers) that need compilers and development environments.Programming Tools Development
Similar to Going Pro. Not every parser is feeding a code generator. Join a team making an IDE, an IDE plugin, a code formatter, or a code checker (a la LINT). Eclipse puts this category within reach of anyone (so did EMACS). In order to develop at this level you probably want to take at least one more course or do a semester long project to have a fighting chance of getting enough experience.In-House Tools Development
The need to make sweeping changes or do some kind of transformation on a code base comes up all the time on large projects. I should probably say the "opportunity" rather than the need, because some problems that could be solved by a transformational tool will be worked around. But here's where a little initiative and paying attention during those parsing lectures will pay off.Better Programming and Debugging
Even if you don't directly use your programming languages course, even if you hated it, if you took the right kind of course you will have your mind trained in ways that make you a better programmer. It's not a substitute for reading good code and learning from experienced practitioners, but it is similar to learning how to disassemble, clean, and reassemble a car engine blindfolded. It's analytical training for a language, you see what parts compose the tokens and phrases of the language, and see how they're combined into your program. It helps dispel myths about how your program is likely to work under the hood. This of course is especially true if the language you implement is similar to the language you write in, but if you can't go too far wrong working with a language more "interesting" than you're likely to work in.Even the time you spend studying language design is not wasted. At some point, programming on a large team involves discussions and development of a coding standard for the group. These discussions are in a sense exercises in language design, because a coding standard effectively limits the expressive power of a language into a subset of the language that everybody is comfortably working with.
Recommended Reading
| | "Essentials of Programming Language" by Friedman, Wand and Haynes. Build up your knowledge of interpreters and compilers, starting with a simple lambda calculus, then to Scheme, building up to the powerful and high-performance techniques of continuation-passing style and tail recursion. Sometimes used as a text in PL courses. Maybe you like my arch-geek friend Tony will use your newfound knowledge to spend your Christmas break writing a Scheme compiler for your HP scientific calculator. |
| | "A Retargetable C Compiler" by Hanson and Fraser. A funny book, it uses literate programming to document and explain the implementation of lcc, a C compiler used to compile Quake III. From memory management (arenas with constant time deallocation) and string hashing, the authors show and explain their C code from the bottom up. The ANSI C style is a little odd, but for the modern student, C will perhaps seem odd anyway. |
4 comments:
I didn't get a lot out of the programming language course I took. I ended up writing a 4 page diatribe on the uselessness of the class and handing it in with the end of semester rating sheets. That professor left the next semester. Coincidence?
What's sad is that I think understanding language design is critical for being anything more than a hack. I encountered a lot of putative programmers who thought some language designers off hand thought on implementation was The Way It Must Be. Gah.
susan's husband: You're right, this is all assuming a useful course including basics on lexing, parsing, and visiting the parse tree for some productive purpose.
For people who took a Language of the Month Club type of class, well maybe you'd see a lot of syntax: "here's my collection of shell script interpreters" (oblique ref to today's PhD).
I thought I was a word stud until you made me look up putative.
I was thinking higher level than that. For instance, Lisp vs. C/C++. Stack vs. heap allocation. Argument passing styles (value, reference, name, etc.). The key thing, IMHO, is not so much to know a lot of specific techniques, but to be aware that there's a lot more choice in language design than is apparent. Like your posts on ML - C/Java/C++ programmers think declaring types is just The Way It Is. But it's certainly not required.
P.S. Have you heard that C++ is trying to revive the "auto" keyword by making it useful? It would declare a variable's type automatically, e.g.
auto var = expr;
would make "var" have the same type as "expr". This would be incredibly useful for operating on templates, where the type can be very complex.
susan's husband said:
"P.S. Have you heard that C++ is trying to revive the "auto" keyword by making it useful? It would declare a variable's type automatically,..."
Why, yes I have. That's one of the many inspirations behind the Type Inference Lecture, though I'm not familiar with the details of the C++ proposals enough to know what exactly the type checker will be doing.
Post a Comment