Although Lizzie is only in its first initial 0.5 release, and not mature by any measure, I must confess that I have a lot of ideas in regards to it. First things first though, Lizzie will highly likely never grow particularly much in size. This is because of its extendible architecture, that allows you to extend it as you wish. Sure, I’ll fix bugs in it, and I might add one or two additional features, but Lizzie is not one of those programming languages that’ll simply pack features upon features until it’s all fat and muddy.
Not because I don’t want to add features to it, but because it’s not necessary to add features to it, since if I miss some feature, I can simply create a delegate and add to my “binder”, or create a method on the type I bind to it, and such easily extend the language, without modifying it. Below is an example.
// This method will be available as a function in your Lizzie code
[Bind(Name = "write")]
object Write(Binder<MainClass> ctx, Arguments arguments)
public static void Main(string args)
// Some inline Lizzie code
var code = @"
set(@foo, +(foo, 10))
// Creating a tokenizer for our Lizzie code
var tokenizer = new Tokenizer(new LizzieTokenizer());
// Creating a lambda function from our code, using the above tokenizer
var function = Compiler.Compile<MainClass>(tokenizer, code);
// Creating an instance of our class, which we can bind to our Lizzie code
var context = new MainClass();
// Creating a binder, and adding some pre-defined functions to it
var binder = new Binder<MainClass>();
binder["var"] = Functions<MainClass>.Var;
binder["set"] = Functions<MainClass>.Set;
binder["+"] = Functions<MainClass>.Add;
// Evaluates our Lizzie code, making sure we bind it to our instance
// Waiting for user input
Notice how the “write” function is not something that actually exists in Lizzie, but available to my Lizzie code, since the type I am binding my code towards have that method, and have marked it with the “Bind” attribute. This adds a new “keyword” to my Lizzie code, that I can use internally within my Lizzie code, to invoke C# methods, having access to the “context” that my Lizzie code is evaluated within.
With the ability to easily extend a programming language such as I illustrated above, the need to expand on the language simply isn’t there. So Lizzy will probably never grow much in size beyond its current codebase, which is surprisingly small, ~2 KLOC in fact. In such a way, you might argue that C# becomes the equivalent for Lizzie as Macros are to Lisp.
Then the job of authorising whether or not a specific client is legally allowed to perform some specific operation or not, becomes a simple configuration job on the server, allowing me to “declare” which tables and operations a specific client is legally allowed to do, according to some role based security map, which decides which server side methods Lizzie code transmitted from that particular client will load up, and allow that particular client to execute – And if a client is not authorised to execute some specific “keyword”; Exceptions! Which allows me to use the same HTTP REST endpoint to retrieve any data from any table in my database on the server side, including aggregated values and joins, without opening up for security holes, effectively turning Lizzie into the equivalent for servers in general, as what SQL is for your database. Creating methods that are not related to databases is also easy may I add, such as creating a method that allows an (authorised) client to send an email, change a configuration setting, etc, etc, etc – Is obviously equally easy, and can be done securely, without opening up a “can of worms” in regards to security …
In such a way, Lizzie might prove to become the “Structured Server Side Query Language” of computing. Simply put, because what man would I be, if I didn’t have a bunch of fancy acronyms, to describe my axioms … 😉
SSSQL for the masses 😀