Scott Logic Blog

I am a tool creator (serious tools count of one) that created a tool out of genuine personal need, in reference to the note linked from " serious contexts of use".

In my case it is in context to the state machine portion of the blog.

The link to Leslie Lamport and TLA+ is informative and the initial point of my tool making was to end up with an executable specification of a state machine that could be translated to TLA+ to allow validation by formal methods.

For functional safety (IEC 61508 and subsidiary standards) this is the Holy Grail for a significant number of applications. Think things like Rail Signaling, Burner Management Systems, Aircraft Landing Gear Hydraulic Sequencing, complex machinery automation and interlocking, to name a very few examples. It can also extend to Cyber Security and transactional systems like banking etc.

In my tool I haven't quite got to automatic translation to TLA+, yet, and maybe I personally won't, because as discussed in the blog and some of it's links, the interface itself prompts a certain level of thinking that is highly beneficial. So I have done everything but an automatic translation to TLA+, but I can see no reason it is not possible, I already automatically translate the specification into controller code.

But the key point arising from the definition of state based behavior, which is what TLA+ is all about, is that implicit state is the enemy. And if all states and transitions are not defined explicitly, then the door is…

Going with the good faith assumption you read it trying to find why instead of why not in the WebUSB standard you can find this paragraph under 3.1 Abusing Access to a Device:

"Lastly, since USB devices are unable to distinguish requests from multiple sources, operating systems only allow a USB interface to have a single owning user-space or kernel-space driver. The UA acts as a user-space driver, therefore allowing only a single execution context to claim a USB interface at a time. The claimInterface() function will fail if multiple execution contexts attempt to claim an interface."

I.e. the keyboard couldn't be claimed even if you managed to get it to list as it's claimed via the OS HID driver so can't be claimed via the userspace driver. HID devices are also hid from the listing (no pun intendend) which is what resulted in the WebHID standard in the first place.

For WebHID understand it's an early draft and that the method described in section 3.1 of blocking access to HID devices that can generate trusted input is actually the go forward implementation plan not merely a suggestion.

.

I don't mind discussing WebUSB further but not if the conversation is just going to be in a "I thought it might work this way, show me the line that says it isn't" way. There are many blog posts that cover it better than I could anyways (such as https://blog.scottlogic.com/2019/04/03/upcoming-webhid-api.html)

Having used Svelte for a couple of projects [1][2], I love it. Compared to my day job working in react/redux, it is much simpler, and feels like it has far less boilerplate.

There are certainly a few rough edges, but it's all related to the immaturity of the language. Specifically, I had a hard time understanding transitions and it wasn't at all obvious how to integrate it with D3. Hopefully as it grows we will see improved docs and examples.

Also, I'm holding out for more mainstream TypeScript support. At that point, it would be hard to convince me to use anything else.

[1] http://musetree.stevenwaterman.uk

[2] http://optimisation.stevenwaterman.uk + https://blog.scottlogic.com/2020/02/17/minesweeper-optimisation.html

> You need to compile and distribute a runtime or, in the case of dynamic languages,

But for all other languages there are easy compilers. Which is why WASM, apparently, is used with such languages mostly[1]

I'd expect that these runtimes can be both distributed with browsers when they become really popular, and can be reduced in size. E.g. Python's runtime is relatively large and ships with a large stdlib. Most of which won't be needed in your code, so I'd expect it to be possible to compile a runtime that only includes what your code really needs, for example.

[1] https://blog.scottlogic.com/2022/06/20/state-of-wasm-2022.html

Great post, thanks for sharing. I wrote something similar a couple of years ago, showing just how simple it is to work with LLMs directly rather than through LangChain, adding tool use etc …

https://blog.scottlogic.com/2023/05/04/langchain-mini.html

It is of course quite out of date now as LLMs have native tool use APIs.

However, it proves a similar point to yours, in most applications 99% of the power is within the LLM. The rest is often just simple plumbing.