[errtnsd]

Honestly, at a glance, the library design is horrible. A mix of C macros and global variables. The project is really small, to fix it all you need is a single struct pointer that gets passed to around.

[panic]

I think calling this "horrible" is pretty harsh. I wish programmers wouldn't be so eager to put down each other's code instead of taking the time to understand the reason why it is written that way. In this case, I think the library accomplishes its goal quite well: to provide a straightforward, logo-esque syntax for procedural drawing.

[guillaumec]

the library allows to define and undefine the macros at any point so that you don't pollute your namespace too much. Without the macros, you would have to prefix all the commands, like SQUARE(n.X, 10, x.S, 0.5), etc...

[fsloth]

Code has different design constraints depending on where the code should run, how large the codebase is and what the project structure around the maintenance work is. Had this been a middleware component library and were there any reason for the routines to run in parallel threads I would have agreed.

Here, however I find your critique in bad taste and poorly thought out for code whose main value is the art generated by code, where brevity and simplicity of the code base is a value in itself.

There is no one true way to write code. Global state is not an evil in itself unless it causes hidden side-effects. For small single threaded programs a large global state can simplify things a lot.

It's like a lumberjack grumbles to an artisan wielding a penknife that it's far too small to cut down a tree.

[zeeed]

Thumbs up on the initiative and result -- but why macros?

From the code samples it appears more that the author has created a DSL using C macros than providing a library. Such a bummer.