Two done (ITS & ITB), another two more to go (UI & UGM).
1. Why Visual C++?
As Petzold said here http://www.charlespetzold.com/etc/DoesVisualStudioRotTheMind.html , drag-n-dropping stuff can rot your mind. What's there to teach if all you have to do to accomplish a task is drag a control here, and fill up this code there...
From previous workshops in some campuses, I actually hear these feedbacks from my student ambassadors and others, "The students said there was no real programming. It's just drag here and drag there, and voila a website is done."
And I intend to fix that.
So now it's clean. You build a new Visual C++ Project. Then choose Empty Project. That's right, write the code from scratch. Of course the the next labs build on codes from previous labs, so writing from scratch is only true for the first lab.
And I can't print a manual with 200+ lines of code... and also I don't want students to copy-paste from text files, since that will defeat the purpose of line-by-line learning the codes. So I put the codes as read-only PDFs :)
And now the feedback I'm getting is "...it's boring". The requirements for this workshop are "C++ knowledge, and minimum 3rd year students". Gosh, I should have added "Has taken and passed a course on Automata or Theory of Computation". Anyone who hates Automata, shouldn't take a compiler course :)
2. Why Interpreter?
Some people who hasn't seen the inside of a compiler will say, "Why Interpreter?" Since they know that interpreter is slower than compiler. I hope that's not the only thing they know about interpreter.
Check this out, an interpreter will have a front-end, back-end and some interface between them: (Click the image for a larger version)
And let's see how a compiler implementation may look like:
Gee, what changes? You saw right, only the backend changes since we can reuse the frontend from interpreter.
This is my one-year project. First, teach how to build interpreter. Second, teach how to build a debugger. Third, teach how to build a compiler. Obviously, the knowledge gained from interpreting line-by-line of code is essential to building a debugger. In the interpreter workshop, I showed them how we can inject the source code line number into the intermediate code. This is useful for debugging, for if there's an error, we know which line number caused the problem.
I can say that building an interpreter is probably harder than building a compiler. Why?
Well, what a compiler does is turn this source code:
int b = 10;
int a = b;
into this code:
.locals init (int32 b,
1: ldc.i4.s 10
In the diagram above, that means :CodeGenerator has a mapping of C# source code to IL code and :ObjectBuffer is the one that creates the .exe assembly.
How hard is that? Especially now that we have ILGenerator.Emit in the System.Reflection.Emit namespace, it's (supposedly) easier to build a .Net compiler using .Net itself...
On the other side, if you build an interpreter, this source code:
int b = 10;
int a = b;
will probably be handled like:
The keyword 'int' signals a variable declaration.
If 'b' exists in symbol table, throw up a variable redefinition error.
Else put 'b' into the symbol table.
Recognize that 10 is a constant, so put 10 into a constant table.
Set the value of 'b' to a pointer to 10 in the constant table.
If 'a' exists, throw up a variable redefinition error.
Else put 'a' into the symbol table.
Set the value of 'a' to a pointer to 'b'.
Oh wait, let's do some optimization here, since b points to a something that never changes, change value of 'a' to directly point to the constant 10.
3. Why am I doing this?
I am dreaming the next Anders Hejlsberg (Pascal), the next Rasmus Lerdorf (PHP), the next Yukihiro Matsumoto (Ruby) will be from Indonesia. Teaching this compiler stuff to Top 4 State Campuses (ITS, ITB, UI, UGM) and with 20 students each, I am reaching to 80 students. Either some of these 80 will continue their Final Project or Master's Thesis or hopefully they pass on the knowledge (and the source code) to their younger student peers.
Yes, compiler writing can be boring... but imagine the impact if you create a small easily-understood beginner's programming language: our little brothers in Sekolah Dasar and Sekolah Menengah Pertama can learn programming at very early age. Imagine them creating a simple calculator, a simple student grade application, etc...
Stay tune, I am not going to finish the workshops just like that. After my next 2 interpreter workshops, I will announce the Microsoft Mini-Language Programming Competition!