It was an unconvincing argument then, and is an unconvincing argument now.

I use to be quite fond of short identifiers, especially ones the make the signs “line up”… until I worked with code long enough that I forgot what I did and had to read it again.

As an off-topic observation, whenever I see something like the phrase “operates between the public and the private space” I immediately think: this person definitely went to art school :P

1. lack of native GC, you had to roll your own by providing a runtime.

2. lack of tail-call elimination in V1 of the spec. This essentially forces you to trampoline everything.

Another cool online thing that exists is CP, a language with disjoint intersection and union types:

https://github.com/yzyzsun/CP-next

If I was them I’d be using OCaml to build up functional “kernels” which could be run in a way that requires zero allocation. Then you dispatch requests to these kernels and let the fast modern generational GC clean up the minor cost of dispatching: most of the work happens in the zero-allocation kernels.

That being said, having all drones equipped with cameras could enable a more robust version of what they’re talking about:

If uplink with human operators is lost, but short-range comms between drones exist, they could use their video feeds to autonomously coordinate amongst themselves.

We have two years of footage from Ukraine, where camera-equipped drones are launched from a several miles away at most, and where there are networks of pilots and support specialists to assemble and launch more drones in case of (frequent) failure.

I don’t think it’s wise to wager the success of a 6-month mission deep in enemy territory on a plan with a single point of failure, especially when the alternative is equipping each drone with < $100 cameras.

But sure, you’re clearly the better thinker.

…but if GPS is jammed, and there’s only one camera per fleet, how exactly are the other drones supposed to navigate towards the spotted targets unless they’re all equipped with cameras?

I think you can still have the functionality described in the article: you would send “hole” markers tagged with their level. Then, you could make additional requests when you encounter these markers during the recovery phase, possibly with buffering of holes. It becomes a sort of hybrid DFS/BFS approach where you send as much tree structure at a time as you want.