Jump to content
  • Advertisement
  • entries
  • comments
  • views

The new language

Sign in to follow this  


Making a new language:

  1. brainstorming, code mockups
  2. feature triage
  3. design specs
  4. experiments
  5. implementation

I've been iterating on the first 3 steps for a year, my specification is pretty well nailed down, and now I'm laying down plans for a compiler. Turns out I'm closer than I thought. In 2010 I was experimenting with a Lisp-APL hybrid, then I had some doubts about Lisp so I set it aside unfinished. But the main parser/compiler functions were working, and that's all I need for a gamedev language without Lispy stuff like closures and GC. However, for games I'll need the ability to write game code that links with C/C++ libraries, and to that end I dug up some old ELF loader/linker code from my 2003 osdev projects. Still works, just needs some 64-bit support. So I'll do a few experiments with that, let the design stew for a few months, then try to bang out a working prototype in a week whenever I'm able to clear the decks.

Gotta say gamedev has been incredibly liberating. Compilers are easy compared to games and game engines. Text files in, machine code out, no big deal! biggrin.png
Sign in to follow this  


Recommended Comments

Designing the language is a way bigger task though. Also implementing optimizations, although this depends heavily on how much abstraction is there (if the abstractions are good enough, you'll put the most critical stuff into them so there's less need to optimize the code written in the language).

Share this comment

Link to comment

Indeed. At some point I just have to lock down the design, build it, and use it for a few years. I'm sure I'll discover design flaws, change the language, and update all my code. Should be saner than webdev though!


Funny thing, the latest incarnation isn't far from my first attempt at language design in 1997, before I heard the siren call of Forth, Lisp, Scheme, etc, before I'd studied any theory at all. The main thing I've learned is that dynamic convenience features come back to bite you; 'static determinism' and 'state separation' are the key qualities needed for compilers (and programmers) to 'understand' the code, detect errors, optimize, etc.


I'm not too concerned about optimization... just basic things like memory alignment, small size for better caching, inline functions. Fancy optimizing compilers still produce some horrible machine code. I'd rather have a simple compiler with a clean interface for inline assembly and custom machine code generation (at compile-time and runtime too).

Share this comment

Link to comment

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!