Hacker News Reader

Comment by mmastrac | Hacker News Reader

Has anyone attempto'd to combine this with state machines in a way that you could specify rules in an english-like way, with a computer checking that you've resolved all ambiguities?

For example, a system that starts and stops based on observing parts of another system, but also allowing a user to input explicit start/stop commands would require additional rules:

  The system is stopped if the subsystem is in state A.
  The system is started if the subsystem is not in state A.
  The system is stopped if the user sets the stop flag.
  The system is started if the user unsets the stop flag.

  Error: ambiguous state if subsystem not in state A and user sets the stop flag.

There's some real value here in allowing non-programmers to work through all the edge cases of a system, while simultaneously adding tools to convert standard English to ACE (eg: identifying ambiguous English and asking them to rewrite pronouns or split sentences up).

View on HN

Have you seen Cucumber? https://cucumber.io/docs It's a system that attempts to enable specifications for a software product to be written in a way that can be parsed by an automated testing framework.

In theory, you carefully say what you want the software to do in given scenarios, human developers understand the spec as-is, and automated tests can read and execute the spec as-is as a test.

I have no professional experience with it because all the docs make it look like something I would run from: lots of in-code scaffolding and talking like a computer just to get the same job done. But maybe you'll like it.

FWIW, the "specifications can be tested" is nothing magical. It binds statements of the Cucumber spec to snippets of code using regular expressions. (The effect is about the same as titles given to blocks of code in Ruby's RSpec).

The "it's not code" part of Cucumber is that the test document is something that a non-programmer won't freak out at manipulating. (But a developer would still have to make sure the code snippets bind to the statements, so...).

Still, I like it. I really like the suggested tactics discussed in Specification By Example https://gojko.net/books/specification-by-example/

I have found that test suites solve this problem about 98% of the time and are easier to teach people to debug.

That last 2% is pretty damned awkward though. When you have 2 preconditions your tests go cartesian, you have to pick a dominant one. It's always a matter of one sucking less than the other, but that situation isn't stable. It tends to flip as bugs are identified or requirements shift.

Thing is, if it's 3 concerns, and definitely by 4, you're probably due for a refactor anyway, instead of reaching for Cucumber or a similar tool.

It seems like you could perhaps write a translator from ACE to TLA+ or another specification language

https://en.wikipedia.org/wiki/TLA%2B

and formally verify properties (but perhaps that's something that the ACE developers already do).

That would be very interesting. I couldn't find any references to TLA+ and ACE together, so it might be a novel area of research.

Reply on news.ycombinator.com