(When I quote people here, I won't use names in case people prefer to remain anonymous. If you want me to credit you for a quote, drop me a line, and I'll do so.)
Comments I wanted to respond to:
- ~"test cases are irritating" => Hopefully, you'll come to believe that putting in some test cases saves you TONS of work down the road (assuming you write them first). This will probably only be true if you practice writing "parsimonious" test cases. Don't write a HUGE list of test cases to test EVERYTHING that could ever happen. Think about the functionality that matters and how it breaks down into pieces. Write one or two good test cases to push on each aspect of that functionality up front. Then, use those test cases (both the ideas behind them and the actual automated testing) to craft your implementation.
- ~"test cases are especially irritating on helper functions" => The point here was that helper functions' purpose might evolve as you go. It might help to not write your helper function right away. Just write a brief purpose so you remember what you were doing, then assume the thing works and go back to the main function. You might even write a "stub", like the functions that just evaluate to false or whatever argument is passed in that we've been writing in class.
- ~"Oh, for System.out.println!" => I know the debugger has been crashing for many people. To print output, try using the display or printf functions. (As usual, you can find documentation in the Racket docs.) These aren't designed to evaluate to interesting values; so, how do you use them? With begin:
(begin
(printf "Here's the lhs: ~a~n" lhs)
(binop + (parse lhs) (parse rhs)))
Use these sparingly!
- "recursion makes me laugh" => :^)
- "I finally figured out what an s-exp IS (an intermediate representation returned by (read ...) and what lispers mean by "Code is data"." => Just had to include this comment!
- Judge/understand languages by analyzing and more deeply understanding their design elements. I was happy to see this thread come up often, since it's a core goal of the course. Many people put it like "determine how well-suited a language is to a task". Our emphasis will be on studying some of these design elements in depth, but we'll also talk some about the choices that various languages make around the elements.
- Craft new languages or understand the innards of existing ones. These are closely related ideas. We'll be repeatedly building new languages via interpreters, and that will likely help you with these goals. One caution: our goal in this course is not to study the practical issues involved in tuning/optimizing industrial languages. We will often take a clean, simple approach to implementing our semantics, where a more complex (but semantically equivalent) approach is needed to achieve scalable efficiency. CPSC 411 might be a better place to study practical aspects of compilation.
- Become a better or more flexible programmer. I strongly believe that this course suits this goal. From a personal perspective, every time I learn new language design features, I find that I can import the positive aspects of the programming style it enables into my work in many languages that don't specifically support or aren't built around that language. My earlier post about continuations in C++ is a rather grand example of the same idea.
- Learn a new language (Racket, Scheme, Lisp, other). You certainly will! :^)
- Quickly pick up languages. I was surprised at how rarely this was mentioned. I find that three aspects of a course like this help me with new languages: (1) understanding design choices "under the hood", (2) brushing up against a new syntactic paradigm, and (3) getting practice with new ways to find support resources. On (2): yes, we belittle syntax a bit in this course, but getting a bit of experience with some of the popular syntaxes out there (C-like languages, LISP-like languages, sh-like languages, etc.) can help you pick up a new syntax that much faster.
- New ways to think. Yes! I hope that as you learn about closures, continuations, typing, laziness, etc., you'll start thinking "why haven't I solved these sorts of problems this way before?!"
- Credits. A worthy goal :^)
- Shift my focus from language syntax to language semantics. One person mentioned this. I hope this course will help with this!
- Standardization process for languages. This isn't something we'll talk about a lot, although it might come up in my blog posts. (I have one brewing about a JavaScript blog I read that's got some juicy comments on standardization.)
Steve
Very neat to read, thanks!
ReplyDelete