Tips for coding using hostile tools? [closed]

Question

I am developing an application using the wrong tools. I don't wish to get into the rights or wrongs of this - the platform has been blessed as Strategic and nothing is going to change that now. But I'm hoping somebody can give me some tips on how to make the best of the situation.

We use a server-side language, let's call it X, and client-side HTML/JS/CSS (on IE6). X is primitive from an application development point of view (but excellent for data processing, which is why we are using it); it doesn't even have the concept of user-defined functions, so trying to make the application modular in any way is a challenge. Think tens of thousands of lines of nested if/then/else statements.

My current assumption is that reducing the spaghetti-factor of the code will not be possible, and that really great documentation is my only weapon against this becoming a totally unsupportable nightmare that ends up on TheDailyWTF.

Anybody got any other ideas?

(I don't mention what language X is simply because I'm hoping for answers to the general problem of working with deficient tools, not any particular tactics for X.)

Edit:

Ok, for the morbidly curious, X is SAS. I didn't want the question to focus on whether function-style macros are functions (they are not, and cannot implement design patterns), or to blame it - given the constraints of this particular project, I actually agree with the decision to use it! I am also sure that the majority of software is developed in incredibly non-optimal environments (broken tools, bad management, overbearing legacy burden, etc.), and that there must be strategies for making things work even so.

Answer 1

Are you familiar with Church thesis?

If you can't solve "A" in Y but you can emulate Z in Y and Z can solve "A" then by definition Y can solve "A".

Maybe you can write some generalized routine that somehow makes X more effective for the problem at hand? A sort of extension to X, or, even better, a little-language implemented in X?

It seems that others tend to conflate "little language" with documentation. While you can try to go that way (in this case I suggest you have a look at Robodoc) I was thinking something closer to Wasabi, in approach - i.e. really using your tool X to create a sort of interpreter for X++ or even Y, without knowing what X is I can't be, of course, more specific than that.