A Lexical Mistake

I realize that A Lexical Mistake has been somewhat dark for the last few months so I figured since my current project is starting to look more likely to actually happen I’d put this post up.

See I’ve also been reflecting on the last few projects I attempted and the core problems faced while working on those projects (why I dropped them).

Most of my effort in my personal projects has been focussed over the last couple of years on learning and understanding new programming languages. The problem is that while learning new languages can be very enlightening and quite fun, I found myself wanting to return to my original interest in software development—that is, game development.

The problem is that, while looking at various project ideas, and even attempting a couple (one of which can be found in an earlier post, although the code has been pulled since), I’m still faced with a number of inefficiencies that scream right towards my language design interests.

For a start, if you wish to provide a sandboxed game code environment then the only real option is to combine two languages using the bridge between them as the sandbox. This isn’t really a problem if your interested in simply creating a game now of course, and you don’t have to use a sandbox unless you want to run downloaded game code, but I don’t feel that these technologies really respect the time restricted resources of a small-team game developers (hobbyists, Open Source, relevant Independent gamedev companies).

Respectively, this is also what killed my Haskell gamedev project. That doesn’t mean I don’t intend to look into Haskell further—just not for gamedev tasks in the near future.

And furthermore, both conventional languages and embedded languages almost always require a restart before new code can be tested. I think that by reducing the turnaround time on new game code (or even engine code), the game programming process could be made significantly more accessible to smaller development teams for both smaller ideas or bigger, possibly open source projects.

So what have I actually been doing then?

I’ve actually been putting together a collection of notes and though experiments designed to push my understanding of Smalltalk and programming language design in general enough to put together a cohesive conceptual design for a decendant of Smalltalk, not to mention brushing up on my understanding of existing Smalltalks and the what the various Smalltalk related communities are working on.

Until recently however, I wasn’t convinced that there was an existing language that suited my somewhat unusual requirements for implementing this Smalltalk (or should that be preferences?) Recently I finally figured it out.

As it turns out, I believe that the best language for the early prototypes is The Java Programming Language!

I realize of course that Java won’t give me the best performance, nor will it be the simplest implementation, but when it comes right down to it, I’m just not familiar enough with another language with the necessary UI capabilities that actually conform to the conventions of the underlying operating system. I should even be able to take advantage of several library bindings before tackling C!

So there you have it, a post almost devoid of any real content, announcing my new programming language and both the interpreter and the design in general are coming along nicely so far, so you can look forward to more interesting details in the near future (like the core principles of the language design or the purpose of the language).

Oh, and one thing before I forget, I’ve named it The Mention Programming Language.

After reading Torsten’s nugget of truth in Planet Smalltalk recently I couldn’t help but be reminded of a Smalltalk based language I’ve been throwing around lately. Not because my language is interesting yet—I don’t even have a prototype concrete syntax—I’m actually referring to my immediate reaction when he wrote:

“Smalltalk is not a language — it’s a dynamic object system with the language built in… [sic]

This is, in my opinion, more cautious than it needed to be. Smalltalk really is just a dynamic object system, but beyond that, I would argue that the language is really just a collection of DSLs.

The first, method definitions is kind of the core DSL of Smalltalk. While not necessarily as small as a simple DSL it provides all of the behavioral elements that make Smalltalk code actually do stuff, all of which can be replicated by generating AST objects, programatically.

More obvious however, is the class definition syntax. This quasi-message-send actually causes so many hacks and side effects that suggesting that it resembles any kind of message programmers would be comfortable sending normally is just outrageous! Really it describes the structure of a class and allows us to manage that structure. Oh, we can also file-out that sucker, too!

(The OMeta parser generator can also be used to write methods. The tool support was iffy last time I looked at it though.)

My point is, Smalltalk is really just a collection of DSLs that allow us to effectively program with a pure object system, and it’s this phenomenon that I believe will allow us to dramatically improve both the appeal of the language as well as its usefulness in the future.

— Lorenz