Comment On Classic WTF: We Use BobX

Christian’s first day at his new job started out just like many others in the professional IT world.

“Welcome aboard!” exclaimed Brian with an outstretched hand, “Great to see you again, c’mon in and we’ll get you all set up.”

Brian took Christian to the security room to get his ID badge and toured him around for a meet and greet with the other departments.

“Communication is key around here,” explained Brian with a sweep of his hand, “We have these half-wall cubicles installed for good reason! The server, infrastructure, and database teams all work closely with each other on a daily basis.”

Pleased that he had chosen a good IT organization to work for, Christian inquired what server platform they ran PHP on.

“Umm…that’s the thing, you won’t be developing in PHP,” explained Christian’s manager, “we use something else.”

“We use BobX.”

It’s Better than PHP!

Swallowing the reactionary urge to blurt out "WTF am I doing here then?”, Christian calmly asked for some explanation, after all, when he interviewed with Brian for a PHP position and all of the technical questions related to hardware demands, logical approaches and pitfalls with regards to developing web applications in…PHP.

“You see, we've had a lot of previous developers just couldn’t keep up with Bob,” Christian's new bossed grinned, “he’s a bit of a recluse, but boy-oh-boy is he sharp. You’ll learn a lot here, and you’re a pretty smart guy, so I’m sure you’ll keep up just fine.”

Brian went on to explain that the IT organization had somewhat shadowy figure in the form of a recluse programmer on its payroll. Brian explained that he had never exactly met Bob, the inventor of BobX, face to face, and in fact nobody in the company had. However, years ago back when the term “Information Superhighway” was all the rage, based on total cost of ownership, BobX was chosen for all web development in the corporation.

“To be frank, I don’t know if Bob lives on a boat, a nuclear bunker, a shack in the woods, or down the road, nor do I care,” explained Brian, “but I do know this – finance has cut him a check every month for the past 10 years and he provides servers, environments and adds features to BobX freeing up the guys here to handle everything else.”

For a second, Christian considered that handing back his badge and walking out, however, after some thought, he decided to take it in stride in a "let's see where this goes" sort of way.

Christian decided to give being a full-time BobX developer a shot.

Might as Well be Brain Fu**ed

Some languages work out really well because they make it easy to work on abstract problems, many are designed to work in enterprise environments, and others have advantages of being really fast. However, Christian came to learn was that BobX was in fact none of these.

In his first "simple" task, Christian needed to change the ordering of a single screen in the company’s in-house developed ERP system. In many languages, this would be a ten minute job, with five being spent searching for the code in source control. But not in BobX.

As Christian came to learn, rather than SQL queries (which were deemed "security risks" in the documentation), BobX relied on things called "assistants". Configured on a screen that makes nuclear reactor control panels look simple, you could create, modify, or delete assistants or join together two or more assistants to create a super-assistant. However, there was one little 'gotcha' - you couldn't concatenate fields "on the fly" when returning results. This limitation resulted in many workaround fields named "CustomerNameFirstnameLastname" and "CustomerInitials" and, of course, gems like "TmpTestingDeleteThis" with comments warning "Do Not Remove or Financials Interface will Break!". Also, as a bonus, no unique identifiers allowed.

"You should consider yourself lucky!" Christian's boss quipped, "We made that interface screen using BobX in house - before, we had to do all that linking by hand!"

When it came time to inspect the "web" source, Christian could tell there was definitely genius at work, but whether or not it was evil, twisted, or evil and twisted, he couldn't tell for sure.

For example, if you need a list, you just say something like this:

<xbobloop statement="AssistantName" >
<xbobprint> .. write table content here .. <xbobprint>
<xbobendloop>

If parameters need to be initialized, they can be done like this:

<xbobdefine userid="1" >
<xbobdefine findall="false" >

Need an if statement? BobX has you covered.

<xbobif condition="amount <= 12" >
...Some HTML here...
<xbobendif>

Need more than one condition tested? Easy. Just nest your xbobif statements and you're in business!

After three days of churning through his "easy" task, Christian was bleary eyed and exhausted. He spent an entire afternoon tracing a HTTP 500 server error down to a particular xbobdefine statement (BobX was very whitespace sensitive as it turned out), and out of frustration, typed <?php phpinfo(); ?> into a BobX script. When he ran it in his browser, he was amazed to see the server's PHP configuration appear before his eyes.

A Dastardly Plan

Christian came to learn that BobX was, in fact, written in PHP. A parser written in a parser, BobX did a great job at hiding its underlying platform. When Christian tried adding normal PHP code to a BobX script (such as echo "hello world";), he would receive a xboberrorcode 59:INVALID FUNCTION CALL FOUND. It was only when he had a single function in the first <?php ... > block that it seemed to do anything PHP-related.

Armed with this knowledge Christian hatched a plan. Rather than code up his solution in BobX, Christian wrote a simple function to allow the injection of his PHP code. When he ran the form, it worked! Now excited that he had finally defeated BobX, Christian tried out his theory on other web screens - they worked too! Weeks passed and Christian started plowing through assignments earning accolades from management and users started to take notice too - even the most complicated apps were taking seconds instead of minutes to load.

Overjoyed with his newfound energy and motivation, Christian decided to come clean about his workaround and started penning up a summary for his supervisor, however, as fate would have it, soon after starting, Christian's boss Brian appeared at his desk, sweaty, red faced, and obviously fuming mad. He breathed a few times to lower his color and asked, "I received an email from Bob. He says you hacked the production server, did you?" This was definitely not the reaction that Christian expected.

Christian did his best to explain the method and how it could simplify things, but it was no good. Apparently, Bob was hopping mad, reporting that not only had his server been compromised, but also to throw acid on the situation, he threatened to pull out of his contract, taking his servers, infrastructure, and know-how with him. In the end, cooler heads prevailed when Bob and Brian struck a deal - if the code would be reversed to pure BobX, all would be as it was.

Christian's marching orders were to revert the code back to the way it was previous to his starting at his job and then re-implement his 'hacked' code in BobX. ASAP.

Ultimately, Christian complied with the first part quickly, but decided that his best option might be to call it quits, and join the ranks of developers who just couldn’t keep up with BobX.