I didn't want to hijack the other (already long) thread, but this needed a response because I can pile WTF on top of the basic ground-level WTF. In the other thread, Blakeyrat asks this:
"What the... where does this come from? Who uses an in-house scripting language in 2012?"
One scenario are those who developed the script in the 1980's, sold it as part of the software package to hundreds of customers, and then had to maintain it, and as technology improved they had to make it work with the newer stuff. Let me elaborate:
The base product was a mixture of Cobol and assembler that ran on DEC Vaxes, then later Alphas, and ultimately Itanium. That sets the stage. The scripting language was developed a few years after the personal computer became popular in the business world, about the time when businesses wanted to ditch the stupid old VT terminals and use Windows client/server apps. We (I wasn't actually working there yet, but I'll just use team language to make it easy to describe) developed the scripting language first as a way to provide a Windows front end app that communicated Via DECNET to the Vax. It emulated the character cell UI of dumb terminals and was horrible and barely worked. When Windows 95 became a success, we improved the script to support a GUI and talk to the Vaxen over TCPIP. From that point on, we generally improved the networking performance and UI. It's still in use to the best of my knowledge.
Here's the second layer of WTF: As best I can figure (with all records lost to time) they decided to go that route instead of using something like Visual Basic because the customer base didn't want to learn a programming language or hire programmers. So at first, they tried to make the scripting language easy for non-techies to work with. That fell by the wayside quicker than you can say "we need more functionality". The few customers who tried to work with it scared the rest (there was a national user group), so we ended up always having to support it for everybody. At a price of course, which worked well for us. There was no standardized upgrade and release path, enhancements were completed only for customers who asked. There was one guy - the original author - who was able (or allowed) to make changes to the script language, and it was controlled by distributing only the .exe for the script parser. Nobody else had access to the parser's source code.
But wait, it gets better. He had crappy version control, so we were always tripping over bugs and when he fixed bugs in the parser he didn't send an updated exe to everybody. The only way to know what version your .exe was, was to run it and type a version command. If you didn't have the right type of script to go with that version of the parser, it would puke before you could even type a command, which meant you generally had to have several "stub" scripts laying around that you could test the .exe with. He had no QA, but would tweak things and send us an .exe to test and see if he fixed what we complained about.
He maintained a document that explained the script functions, but it was in .txt format and was the typical engineer stream of consciousness format. At one point I massaged the thing into MS Word format with a table of contents so that you could at least search and find things, but he would only ever update his .txt version.
So over a 20 year evolution of this nightmare, one net result is this: one guy who learned quite a bit about Windows programming, and a cadre of developers (us, not the customers) who gained 10+ years of experience programming a custom script language not used in any other company.
So.... how many WTF's have you guys been able to count?