Good points about Lua I’ve seen at first glance:

• Human readable syntax.
• Simple, fast and small virtual machine.
• Secure embedded execution.
• Easy to embed and extend in a C program.

Bad points:

• Syntax is almost too simple – it’s almost 100% identical to a 20 year old BASIC dialect.
• Variables are global instead of local by default – catastrophic design mistake.
• Arrays start with “1″ instead of “0″. Somewhat cumbersome.

The global variables are a kinda big issue, makes it very hard to use scripts in a good way if you have many of them. But of course nothing stops you from sticking a “local” before every use of a variable – which would negates the “human readable” part in the good points though. Oh well.

1 2 3 4 5 6 + – - + -

How long do you need to calculate the result if you just read along letter by letter? A long time, because until you reach the first plus sign, you simply can’t do anything at all but remember the numbers. And we’re bad at remembering many things.

Just to make this clear, do the same in in-fix notation:

6 + 5 – 4 – 3 + 2 – 1

Reading along letter by letter, when you get to the last “1″, you already have the answer of the calculation. This is not because we are used to infix notation more than RPN – it is just because it is the natural way things work.

This also is not only the case for mathematical formulas, but also language. If I say “I gave you a book.”, then in RPN it would be something like “I you book a gave”. Or “I went to the shop and bought a book.” would be “Book a I shop the to went bought and.”

With options, more options not only violate the KISS principle, but also the amount of testing increases. Still, options are not bad. That is – if you allow adjusting any small setting, then yes, this may be bad – many combinations might not make sense, and things get complicated, if not in code then for the user who can not know which settings make sense and which not.

But, if you have no options, you actually do have options – they simply are fixed and forced on the user, without the possibility to choose what they like. Which is very bad.

And, the claim that testing increases much is false, if you do options right. The example that may be given is, if you have 4 boolean options A, B, C and D, then you need to test your program with ABCD first, then ABC[D], AB[C]D, AB[C][D] and so on, 16 possible combinations in total. But that assumes that each option depends on all the other ones. If your options behave like that, they probably are done in a bad way. Good option are done so they automatically work together with any other options.

This is not always simple to achieve of course. So yes, no options is simpler than options. Such as no program is simpler than a program. But a program with good options is much better than a program with no options. Since, at least for part of the users, the hardcoded defaults will be bad defaults.

Optimization is bad. It takes a lot of time better spent on implementing and improving the rest of your program, and the result is code which is hard or impossible to understand or modify, which is less robust, and maybe even has some subtle bugs. Why do something in a convoluted and complicated way, just to save some extra checks or a few bytes of memory here and there?

So, there, that’s my opinion on optimization.

Put in a different way, there is no clear yes or no answer. There’s always trade offs. The first one, it simple takes time to optimize working code. But of course, if you can make the code work better, and maybe even easier to understand, then it’s good to take the time to optimize it. Another trade off maybe, you can either optimize for size or speed, or something else. Such other thing may be robustness, correctness, or code readability. E.g. you could write something in C/C++ instead of Python – but is it really worth transfering your working code to something unmaintanable? In many cases, it is – there simply is no way around it. E.g. you can’t expect to make a graphics application by maintaining your framebuffer as a python list of lists, and then have it update more than one frame / second.

About the used terms, just always assume what makes sense. Everything listed in the same line below means the same to me. Especially note terms in bold who appear more than once:

* base object, super class, parent class, base class
* sub object, derived object, sub class, derived class
* object instance, instance, class instance, ”’object”’
* ”’object”’, class, type
* object method, method, function, class method
* object property, property, variable, class variable, class property
* abstract object, abstract class

Assume, we have an object called Animal, with two methods “eat” and “go”.

{{{#!cplusplus
void animal_eat(Animal *self, char const *what, int howmuch);
int animal_go(Animal *self, int direction, int howfar);
}}}

And, we also have a derived object called Bird.

This is how we could use it:
{{{#!cplusplus
Bird *bird = bird_new(”Sparrow”);
animal_eat(bird, “Apple”, 1);
animal_go(bird, 0, 1);
bird_del(bird);
}}}

Let’s define all the structs, and also add four properties to Animal, “name”, “hungry”, “x”, and “y”, and an extra property “z” to Bird.

{{{#!cplusplus
typedef struct AnimalInterface AnimalInterface;
typedef struct Animal Animal;

struct AnimalInterface
{
void (*eat)(Animal *self, char const *what, int howmuch);
int (*go)(Animal *self, int direction, int howfar);
};

struct Animal
{
AnimalInterface *vt;
char *name;
int hungry;
int x, y;
};

struct Bird
{
Animal super;
int z;
};

}}}

As you can see, this is defined using two C structs, one for the Interface, and one for the object itself. The interface simply is implemented as a vtable pointed to by the object.

Next, we define some housekeeping stuff.

{{{#!cplusplus

AnimalInterface *animal_interface;
void animal_init(void)
{
animal_interface = calloc(1, sizeof *animal_interface);
animal_interface->eat = NULL;
animal_interface->go = NULL;
}
}}}

This is an initialization function for the module. It defines an interface – but since our Animal is sort of an abstract base class, the methods are filled in as NULL.

{{{#!cplusplus

void animal_initialize(Animal *self, char const *name)
{
memset(self, sizeof *self, 0);
self->vt = animal_interface;
self->name = name;
}

Animal *animal_new(char const *name)
{
Animal *self = malloc(sizeof *self);
animal_initialize(self, name);
return self;
}

void animal_del(Animal *self)
{
free(self);
}
}}}

We defined a constructor, and a destructor. The constructor can have parameters, and we have a version of it which will not allocate, but just initialize.

{{{#!cplusplus

#define BIRD(_base_) ((Bird *)_base_)

void bird_eat(Animal *super, char const *what, int howmuch)
{
Bird *self = BIRD(super);
super->hungry -= howmuch * get_nutrition(what);
}

int bird_go(Animal *super, int direction, int howfar)
{
Bird *self = BIRD(super);
if (collision()) return 0;

super->x += cos(direction) * howfar;
super->y += sin(direction) * howfar;
super->hungry += howfar;

return 1;
}

int bird_fly(Bird *self, int howfar)
{
if (collision()) return 0;
self->z += howfar;
return 1;
}

void bird_initialize(Animal *super, char const *name)
{
animal_initialize(super, name);
super->vt = bird_interface;
Bird *self = BIRD(super);
self->z = 0;
}

Animal *bird_new(char const *name)
{
Bird *self = calloc(1, sizeof *self);
bird_initialize(&self->super, name);
return &self->super;
}

void bird_del(Animal *self)
{
animal_del(self);
}

AnimalInterface *bird_interface;
void bird_init(void)
{
bird_interface = calloc(1, sizeof *bird_interface);
bird_interface->eat = bird_eat;
bird_interface->go = bird_go;
}
}}}

Here, we actually define the methods of the Bird object. The last function is the module init function again, which creates an interface, and this time, with both methods filled in.

We also have a constructor, again with a separate intialization function, and a destructor. The instance of the object always is passed as the type of the base object, Animal, and we use a macro BIRD if we need to access it as the derived object.

If you remember the initial example:
{{{#!cplusplus
Bird *bird = bird_new(”Sparrow”);
animal_eat(bird, “Apple”, 1);
animal_go(bird, 0, 1);
bird_del(bird);
}}}

Then this could of course be written as:
{{{#!cplusplus
Bird *bird = bird_new(”Sparrow”);
bird_eat(bird, “Apple”, 1);
bird_go(bird, 0, 1);
bird_del(bird);
}}}

And then maybe also:

{{{#!cplusplus
bird_fly(bird, 1);
}}}

But, the advantage of the former simply is that we might now know what types of animal it is, like, assume, this is a game involving 100 different animals, who can eat things and go around. Then our main program can be written without needing to know the type of the current animal.

There are also various possible variations, e.g. instead of the “super/self” and so on parameters we could have used “super/sub” or “animal/bird”. It is also possible to have deeper sub classing, e.g. a class Sparrow derived from Bird. And object may be created in a different way than the constructor function, for example there could be a mapping of strings to classes, then a function “Animal *animal_create(char const *name) could create the appropriate one. Classes who don’t need any own variables don’t actually need their own struct, but just a new vtable.

* http://ludumdare.com
* http://www.freelunchdesign.com/cgi-bin/codwiki.pl?LudumDare

Progress

/!\ Broken Needs work (./) Useable {*} Finished

{1} Immediate priority {2} Normal priority {3} Low priority >:> problematic

|| State/Priority || Module || Notes ||
||<=> (./) || [:Land/Base:Base] || ||
||<=> (./) || [:Land/Widgets:Widgets] || ||
|| {*} || base widgets || ||
|| {*} || reference counting || ||
|| {*} || properties || ||
|| (./) || menus || ||
|| (./) || lists || ||
|| (./) || scrolling || ||
|| (./) || sliders || ||
|| (./) || buttons || ||
|| (./) || text || ||
|| /!\ || edit || ||
|| /!\ || options || ||
|| /!\ || checkboxes || ||
||<=> (./) || Themeing || ||
|| (./) || Borders|| ||
||<=> || Fonts / Text output|| ||
|| (./) || Truetype|| ||
|| (./) || Bitmapped|| ||
|| /!\ || Glyph pair kerning || ||
||<=> (./) || Display || ||
|| (./) || Drawing primitives|| ||
|| (./) || OpenGL integration || ||
|| (./) || Destination clipping|| ||
|| /!\ || Palette support|| ||
|| /!\ || Non- 32bit support || Currently, some places just assume 32-bit RGBA textures ||
|| (./) || Views || ||
||<=> (./) || [:Land/Images:Images] || ||
|| (./) || Loading|| ||
|| (./) || Source clipping|| ||
|| || Drawing into images|| ||
||<=> (./) || Tile engine || ||
|| {*} || Rectangular grid || ||
|| {*} || Isometric grid || ||
|| (./) || Hexagon grid || ||
||<=> (./) {1} || Sprites || ||
|| /!\ || Bounding box collision || ||
|| (./) || Grid hash || ||
|| /!\ || Quadtree || Saves memory for sparse maps ||
|| (./) || Pixel perfect || ||
||<=> (./) || Containers || ||
|| (./) || Dynamic arrays || ||
|| (./) || Linked lists || ||
|| (./) || Hash maps || ||
|| (./) || Queues || ||
||<=> || [:Land/Documentation:Documentation] || ||
|| (./) || Source format.|| Python docstrings ||
||<=> (./) || Input || ||
|| (./) || Keyboard || ||
|| (./) || Mouse || ||
|| /!\ || Joystick || ||
||<=> (./) || Sound || ||
|| (./) || Mix single samples || ||
|| /!\ || Stream wave data || ||
||<=> (./) || Network || ||
|| (./) || Send packets || ||
|| || Automatic connection handling || ||
||<=> (./) || File formats || ||
|| {*} || png || ||
|| {*} || jpg || ||
|| {*} || gif || ||
|| {*} || bmp/tga/pcx || ||
|| {*} || mpg || ||
|| {*} || ogg || ||
|| {*} || ttf || ||
|| {*} || it/xm/s3m || ||
|| || mid || ||

This has a big advantage: You only need to write the code once, so if something changes, then you do not have to adjust multiple versions, with the big risk of doing it wrong in one or forgetting one. Of course, the same could also be done without templates or macros, by using some runtime mechanisms to choose the right version, but that involves conditionals or lookups, and will be much slower. With templates or macros, the compiler will be able to run all of its optimizations ”after” the code was instantiated. So in the end, there indeed will be multiple versions, but you as programmer only have to maintain one.

Still, the solution is flawed. In C, writing ‘macroed’ code is not nice, you probably will end up with lots of \ characters after each line, put stuff into #include files, and generally your algorithm will be much harder to read than the specialized version. Often it will be easier to e.g. maintain three separate functions stuck together in some file than having a single function using macros for the three different possibilities.

The same, unfortunately, is true for C++. No doubt, for many things, it usually is nicer to have a templated C++ version than using C macros. But it still makes the code more unreadable than using a fixed version.

This is what I solve with my approach. The idea is simply to use a meta language. So sort of a very powerful #define. I simply write my algorithm in Python, writing out the C code for the compiler to use. That way, I can do it in a way like with #defines or templates, but in many case, can do much better. That’s the main idea behind scramble. Keep the simplicity of C, and get all the more powerful features by having the whole Python interpreter as preprocessor.