The Robot Framework language
4 points by Rovanion
4 points by Rovanion
We used to use this in $DAYJOB. Migrating away eventually became an incredibly pressing priority, despite us having plenty of other work to do.
The examples are clean and all, but the moment you have a reasonably complex application (mind you, "reasonably complex" here just means "CRUD with some rules on the operations") it becomes an indecipherable mess, that only a single colleague understood and only because he spent years maintaining it.[0] Nowadays we use a browser harness like everyone else. It has its own ugly warts and I prefer to only touch it if I really need to, but it can at least be comprehended by someone who hasn't spent ages on it.
[0]: One may argue we made a mistake by letting knowledge like this end up silod. I kinda agree, but also the root cause here is that RF has such roundabout logic, that nobody else really had the time to learn the whole thing while also doing their job.
not familiar with this specific tool, but over the years I had built this view that
are dead-ends that make simple things simple, but moderate complex things, very difficult to maintain.
This has to do with the fact that building systems requires engineering discipline, therefore:
a) designing strategic, composable, re-usable, parts.
b) managing evolution of the system design.
c) having formalized maintenance (debugging, QAing) and release processes.
The no-code, or English-first, or Visual-first systems do not offer better (or often, even comparable) means to address the above
I agree that “English-like” syntax is a bad idea. It results in read-only code: it looks simple, but then you find out the actual grammar is much more restrictive than it looks.
I worked on AppleScript 1.0, though not on the language itself. Unfortunately the natural language syntax was a requirement when the project was first started, based on the success of HyperCard. I don’t think we would have kept it if we’d had a choice.
RF has such roundabout logic
Could you expand on this a bit? An example would be great :)
I elaborated in my other comment, but largely it was the difficulty of discoverability. Here is a (slightly changed) example, that we removed from our code:
Rejects Requests with no auth token
Given an API session is open
When I make a request id=${ValidId}
... header=${WithoutToken}
... expected=403
Then the API forbids me
And the reason is ${REASON_NO_TOKEN}
As I've said, the intent is fairly clear, but just here things are declared in three separate places and there is no indicator what comes from where. Given, When, Then, and And are built in. an API session is open, I make a request, the API forbids me, the reason is are custom, declared in another file. ValidId, WithoutToken and REASON_NO_TOKEN are also custom, declared in yet another file.
It reads like one cohesive structure, but unless you're keenly aware of the moving parts, actually figuring out the sources of this invocation is a challenge. And doubly so if there is a mistake somewhere, because the error messages have been very unhelpful as far as I remember.
It's a very poetic language, it can be pretty and it can be really hard to understand.
Does it compare to more traditional RPA tools like UiPath? Or is it a different beast entirely?
No idea, sadly. I've never worked with RPA tools.
The big idea of RF is that you can create commands that read very much like English text. "Log into database" could very well be a command. "Write data into field" could be another. I totally see where they're coming from, because the immediate intent of the code is obvious at a glance, but the issues start when some test isn't passing. We found that IDE tooling was awful (even syntax highlighting struggled at times) and everything was defined under several layers of abstraction. For instance, that "Log into database", both the command "Log into" and "database" are defined somewhere, but you'd really struggle to know where. Sometimes it's your own codebase, sometimes it's some library that you can't find because it was built in.
It was hellish and the amount of false negatives we got made it unusable.
Interesting, but like every other "write plain human language" programming language ever, I expect that it runs into the problem that.... plain human language does not make a very good programming language.
I found the design of this language very interesting. Bare strings are delimited by at least two space. The first bare string on a line seems to always be a symbol. If not followed by two or more spaces, it is taken as the name of a procedure, if so then the symbol refers to a function and the next value is its first argument.