Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views


Sign in to follow this  


Hi. My name is James. I'm an optimization junkie. I enjoy blazing across the bare metal of computers' circuitry, dangerously soaring through the lands of computational existence and virtualized memory. I once even saved a kernel from panicking.

I haven't written C++ for 3 years. Phew that feels good. Although I have used C for various smaller tasks, I have generally been able to stay away from lower-level languages. At times, the withdrawal was difficult. Virtual machines? Dynamic types? anonymous functions? Is my program going to be excruciatingly slow, or simply slow? It seemed like those were the only options.

The intervention came when I was forced to program for the web. Suddenly I couldn't justify making code harder to write, read, or maintain for the sake of efficiency. Efficiency usually didn't really matter. I hated giving up my favorite hobby of optimizing, but I started writing shorter code faster, in languages I would have never considered. First came PHP and javascript, and then I started venturing into the lands of Lisp and Scheme. And that's when my world exploded.

Suddenly I was learning about compilers, evaluation, macros, and all sorts of other seemingly magical things. I started learning all sorts of new ways of solving problems. Expressing everything in terms of cons, car, cdr, and fold. And suddenly, as if completing a circle, I started learning about ways of optimizing these higher-level Scheme programs. Writing compilers became trivial, and various techniques allowed me to generally apply optimizations to scheme programs.

Lisp and Scheme, as awesome as they are, are still just tools. Probably the most important thing I've learned in the past couple years is this: use the right tool for the right job. No programming language is a silver bullet. But here's the question: how do you know what the right tool is? I think it takes experience. But even a newbie should be encouraged to think this way, to carefully evaluate what should go into his toolbox. It makes it much easier to manage and improve a project when you have a clear reason why you are doing it this way.

So here's a practical example. I think many people use C++ for graphics development simply because it's the industry standard. I wish more people would play around other languages which can perform just as well, if not better. My choice for low-level programming is PreScheme, a dialect of Scheme which compiles to highly efficient pure C (no virtual machine needed). I wish more people would use type inferencing systems instead of C's horrid type system. etc. etc.

So, that's the goal of this blog. I want to explore using efficient Scheme systems for programming intense graphics. Gambit-C Scheme will be used as the language; it's one of the fastest Scheme implementations out there, with full support for R5RS which includes closures, lists, continuations, and everything else. PreScheme will be used in various places where Gambit-C doesn't quite cut it performance-wise. Hopefully I'll inspire at least one or two people to avoid huge C or C++ codebases for graphics.
Sign in to follow this  


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!