Hacker News Reader

Comment by twic | Hacker News Reader

Okay but why not:

  test("Cross own order");
  send(newBuy("IBM", 100, 141.01, 1));
  expect(ack(1));
  send(newSell("IBM", 200, 141.00, 2));
  expect(ack(2));
  expect(trade(1, 100, 141.01));
  expect(trade(2, 100, 141.01));

Because then you'd just need to write a few helper functions in C++, not an entire interpreter.

View on HN

One reason, from our similar experience is that showing non-Technical business people (in some environments) text with brackets, semicolons and the general code annotations you show here effectively “scares” them.

This isn’t always true. But it tends to be institutional when it happens. In some places people learn deeply that code is the realm of the tech teams and they should not engage with it.

Getting them to engage with the executable tests can be fantastically useful but it can also be a delicate sales game, where simple things like using a DSL can be key

That's assuming the "non-tech businness people" are actually going to spend time writing and reading such scripts.

I've never seen a situation where that ended up happening (because they're going to write the script wrong, they're going to need help debugging, etc...)

Their time is probably better spend doing something else. So they will write english in mails and powerpoint, and a tech will write code in a programming language.

The closest thing I can imagine to having biz people "write scripts", is if it's done in a GUI with a lot of assistance and a quick visual feedback loop (think Excel macros.)

Maybe writing the GUI is a better investment than writing a compiler.

The parent comment doesn't say the non-technical people wrote the scripts, but that they were shown the scripts.

Think of it this way: Writing iambic pentameter is hard. Without practice, you're almost certainly going to get the meter wrong at some point. However, reading it is easy, because it's just English.

The same can be true for scripts. You don't need to be able to have business people write them, but it's nice (and in some domains critical) to be able to have them read and validate them.

"So they will write english in mails and powerpoint, and a tech will write code in a programming language."

This reminds me of the old movies where the Executive calls in the secretary to transcribe his words.

"Miss Parker! Take this down!"

Something i've done in the past is write multiple backends for an internal DSL like this. One runs the tests, another one prints out the steps as nice-looking HTML to show to The Business. It means they can't read and edit the source code directly, but in practice, this doesn't matter. We even had one that produced Excel files that could be handed over QA as manual test scripts, so they could reproduce what we were doing.

An old boss once pulled off a hack where code drove a browser test, but you could run it step by step, with the element being inspected or interacted with being highlighted with a red border, and a separate window explaining what was happening in natural language. Non-technical people could follow along with what the test was doing. It was an amazingly effective way of explaining what automated testing was all about.

So show the laymen cute text without Scary Symbols, no? Heck, these days my tests with certain frameworks are automatically inundated with unsolicited fire emojis and green check marks. I'd imagine that isn't particularly difficult with C++, right?

They already wrote

> The tests would have been a real pain to write in C++

so i guess what the script piece above shows wasn't the entire deal. When you have a custom language you have full control over its syntax you can make it do all sorts of things that are hard to do in something like C++.

As an example you can build a tree of key-value nodes using C++ calls just fine, but writing a JSON file is usually much simpler and concise (especially when deep nesting comes into place). And a custom syntax could be even simpler than JSON.

You just described functions.

That just compiles like normal code which is obviously a win in many scenarios but there can be a few downsides. The first is that it can quickly devolve into template/generic hierarchical madness (assuming the real example was a bit more complex then the example), this is more complex to maintain than a DSL parser. The second is users will get crazy meta programming error messages, especially in c++ where you can get some multi page ones. You're probably unlikely to get non-tech people writing these tests but you will get people that want be able to untangle that mess, like QA and interns. There are a few other little things too, like the original including the '$' sign making it clearer what is a monetary value.

Personally nearly every time I write something resembling a DSL it's not for production code though and tends to be written in shell script or awk and will only translate to something like sql.

They could also overload operators for terseness.

The Scala programmer has logged on.

Reply on news.ycombinator.com