Development

So I built a little language for substituting strings, meant for passing arguments into actions. It has two features:

1. $[n[ ... ]] operator prints one string if an argument is present, prints another one otherwise (or print nothing);
2. ${n} substitutes arguments for placeholder variables.

For example, "I have $[1[${1}$||no]] problems$[2[ but a ${2} aint one]]" , with the arguments {"99", "Regular Expression") becomes "I have 99 problems but a Regular Expression aint one." With the arguments {"99"} it is just "I have 99 problems." With no arguments, it is "I have no problems." This becomes practical when you have a string like "dictionary.php$[1[?word=${1}]]" , which would allow you to use one action for going to a dictionary page and passing the word to lookup in as an argument, instead of defining actions for every word you want to lookup on the page. This is a good thing.

Speaking of good things, here's a silent round of applause for regular expressions. They've saved my butt on any number of occasions and never asked for nothing in return. On the other hand, shame on you, high-level programming languages, for adopting 20,000 different formats for specification of regular expressions and capabilities thereof. There is no way to effectively learn the differences between the way language x does regex and the way language y does it. Trying to learn one is useless, since that knowledge will quickly be replaced or confused with knowledge from the other.

And shame on all those who fail to organize documentation for their regular expressions in a logical, tabular format (I'm looking at YOU, Adobe). Preferably INSIDE the API documentation. KTHX.