I'd add a driver for a non trivial binary protocol - I ended up implementing a JVM driver for Cassandra a few years ago, and it was a blast.
My Most Important Project Was a Bytecode Interpreter
11–20 of 154 posts
Re: My Most Important Project Was a Bytecode Interpreter
#12Also: a software rasterizer. Most people refuse to write one because it's so easy not to. Why bother? It will make you a better coder for the rest of your life. Let's make a list of "power projects" like this. A bytecode interpreter, a software rasterizer... What else?
I've messed around with a DNS client and DNS server for the same reasons, but I don't think they quite meet the bar for a "power" project.
Re: My Most Important Project Was a Bytecode Interpreter
#13One of the moments where I really started to feel like I was starting to 'see the matrix' was when I was working on a regex engine to try to make my compiler faster (it didn't, but that's another story). The asymptotically fast way to approach regex processing actually involves writing a parser to process the regex, so in order to write a fast compiler, you need to write another fast compiler to process the regexes that will process the actual programs that you write. But, if your regexes get complex, you should really write a parser to parse the regexes that will parse the actual program. This is where you realize that it's parsers all the way down.
When you think more about regexes this way, you realize that a regex is just a tiny description of a virtual machine (or emulator) that can process the simplest of instructions (check for 'a', accept '0-9', etc.). Each step in the regex is just a piece of bytecode that can execute, and if you turn a regex on its side you can visualize it as just a simple assembly program.
Re: My Most Important Project Was a Bytecode Interpreter
#14I'd add a driver for a non trivial binary protocol - I ended up implementing a JVM driver for Cassandra a few years ago, and it was a blast.
Working with data as binary is a good test of a high level language skills. When I was playing around with DNS, I wrote terrible code like https://github.com/voltagex/junkcode/blob/master/CSharp/DNS/.... A better way to do it is https://github.com/kapetan/dns/blob/master/DNS/Protocol/Head... - structs, of course.
I'd add reading and implementing a protocol from RFC - it's a great way to start thinking about design, especially if you read the original RFCs and work forward through the revisions and see what was kept vs deprecated.
Re: My Most Important Project Was a Bytecode Interpreter
#15In this same vein, I recommend coding an emulator! It can be an excellent experience.
http://www.multigesture.net/articles/how-to-write-an-emulato...
Re: My Most Important Project Was a Bytecode Interpreter
#16Also: a software rasterizer. Most people refuse to write one because it's so easy not to. Why bother? It will make you a better coder for the rest of your life. Let's make a list of "power projects" like this. A bytecode interpreter, a software rasterizer... What else?
I really recommend a raytracer, especially to anyone interested in graphics. It's straightforward, powerful, infinitely expandable with optional features, and opens up a ton of discussion about performance, code complexity, and general organization. Plus it's fun, in an instant gratification kind of way.
Every now and then I get interested in demoscene programming. I've never even been able to get a triangle to render on the screen - except with something like XNA.
Do you think there's any value in going back to say, DOS based VGA programming? People in #osdev thought I was a bit strange for wanting to write a bootable kernel that only put pixels on the screen, but I really enjoy the idea of starting with plotting pixels, then moving on to more complex effects.
Re: My Most Important Project Was a Bytecode Interpreter
#17One of the moments where I really started to feel like I was starting to 'see the matrix' was when I was working on a regex engine to try to make my compiler faster (it didn't, but that's another story). The asymptotically fast way to approach regex processing actually involves writing a parser to process the regex, so in order to write a fast compiler, you need to write another fast compiler to process the regexes t…
I don't get it - what do regexps have to do with compilers and how do they make compilers faster?
Re: My Most Important Project Was a Bytecode Interpreter
#18Also: a software rasterizer. Most people refuse to write one because it's so easy not to. Why bother? It will make you a better coder for the rest of your life. Let's make a list of "power projects" like this. A bytecode interpreter, a software rasterizer... What else?
Strong agree on emulator and particularly stack vm. Would add: TCP/IP stack.
Re: My Most Important Project Was a Bytecode Interpreter
#19Earlier quoted context omitted.
I really recommend a raytracer, especially to anyone interested in graphics. It's straightforward, powerful, infinitely expandable with optional features, and opens up a ton of discussion about performance, code complexity, and general organization. Plus it's fun, in an instant gratification kind of way.
Every now and then I get interested in demoscene programming. I've never even been able to get a triangle to render on the screen - except with something like XNA. Do you think there's any value in going back to say, DOS based VGA programming? People in #osdev thought I was a bit strange for wanting to write a bootable kernel that only put pixels on the screen, but I really enjoy the idea of starting with plotting pi…
You can write raw pixels to the screen with a HTML canvas and JS - no need to do it with low level code and making your own OS.
Re: My Most Important Project Was a Bytecode Interpreter
#20Also: a software rasterizer. Most people refuse to write one because it's so easy not to. Why bother? It will make you a better coder for the rest of your life. Let's make a list of "power projects" like this. A bytecode interpreter, a software rasterizer... What else?
Your own multi tasking OS. Very common to roll your own everything on embedded systems. Especially back in the early 80s/90s