[smilekzs]

I beg to differ. After skimming through the article, it seems that the proposed langauge resembles a general-purpose language (at least superficially resembling lua/javascript) with FFI to C (again what lua is good at). The domain-specific parts are either libraries or covered by runtime (in C), instead of language-level constructs.

IMHO there is no real benefit of creating a "new" language compared to e.g. just using Lua + C.

[sklogic]

In this particular case it's the underlying VM which provides domain-specific semantics, not the language itself. If you could retarget Lua or JS to run on top of this peculiar VM - fine, but building a new language is easier.

[spot]

i don't see anything in that paper that wouldn't fit into a regular API. i did see a line that said the details of the VM were outside the scope of the paper. i would be happy to hear what in those details prevents this from being done with existing languages. are you familiar with it?

also: easier for the developers perhaps but not for users.

[smilekzs]

Could you point to me something in that VM that cannot be equivalently implemented in C FFI for Lua?

[nitrogen]

I haven't read the link yet, but I'm expecting some facility that automatically assigns computational and behavioral tasks to swarm members based on their relative locations.

Literally anything can be implemented in Lua+C, so it's not whether it can be done, but whether the language+VM in question add new ideas to swarm research. If so, maybe those ideas can be translated to other languages people want to use instead.

[smilekzs]

Sorry -- I really meant if there's anything that calls for new language constructs to be reasonably expressive (i.e. alternative being really awkward API calls). I found none.

[sklogic]

Yes, to my taste this language is nowhere near a DSL it should have been, but still, there is a significant portion of VM semantics that is hard to implement on top of an existing VM.

The article outlines it as follows:

"1) Sensor readings are collected and stored in the BVM; 2) Incoming messages are collected and processed by the BVM; 3) A portion of the Buzz script is executed; 4) The messages in the BVM output queue are sent (as many as possible, according to the available payload size; see Sec. IV); 5) Actuator values are collected from the BVM state and applied."

I.e., it looks like a complex synchronisation semantics which runs underneath any language layers and therefore hard to implement anywhere higher than in the VM.