I'm the researcher who designed Buzz. I'd like to explain a few things, since I see that a few reasonable points have been raised by the commenters.

This article is a repost.
The old post was made by us, while this new one wasn't. I'm sorry this happened, but it's out of our control.

This could have been a library.
This is a reasonable proposition, but it misses the point of why we went for a language instead. Buzz is a domain-specific language. The concept that some of its features could have been implemented with a library is correct, but irrelevant. The point is whether a library makes more sense than a dedicated language for the domain under study. In our opinion, a DSL makes more sense. This is our proposition, and the basic point of our work.
In our opinion, the peculiar features of robot swarms (decentralization, locality, self-organization, spatiality) already expose the programmer to a high level of complexity. Using a library can entail significant amounts of overhead we can't afford (e.g., Python with ROS) or expose the programmer to unnecessary details (e.g., memory management in C or C++, node compilation and management in ROS).
On the contrary, a DSL allows one to concentrate only on the concepts that are relevant for the domain. To make a different example, there is nothing one can do with R or Matlab that can't be done with a C/C++ library, or with SciPy. Yet, these languages exist and are used because they allow people to concentrate on the problem they want to solve, and little else. Buzz goes towards this direction.
Personally, I have 10 years of experience programming robot swarms. I have done it mainly in C++, and experienced first-hand how much useless detail goes into this activity. The motivation to design Buzz came from the need to diminish the necessary work to even get to a 'hello world' program, and the observation that students exposed to robot programming lost 90% of their time fixing a segfault or trying to make sense of ROS node management. The choice of a JavaScript-like syntax is done exactly because we want people to think 'I know exactly how this works' (principle of least surprise). Similarly, the choice of the new constructs to add (i.e., neighbors, swarm, and virtual stigmergy) were made with the explicit intention of offering a minimal set of powerful, easy-to-understand, and concise constructs. If you feel you get how to write a Buzz program in 5 minutes, then our work is a success.

There is no need for a new VM.
We developed our own toolchain (parser, assembler, VM) because we intend to study much more than just the language. For us, this is just a small step towards a wider goal - providing a full-fledged, streamlined framework for robot swarms. For instance, among the several research directions we are taking, we are currently working on modifying the byte-code generated by the compiler to allow for transparent mobile code. With an existing VM, this would be extremely complex - we would need to study the internals of the VM, hope it was designed to allow for the changes we want, and then execute the changes.
With a custom VM, instead, we have a piece of software designed in advance for the type of research we intend to pursue. All of the comments neglect the fact that Buzz is a research language, that is, a piece of software intended to conduct research. At its current stage, Buzz is a tool to explore new concepts, not a ready-to-use solution. We hope that, over time, Buzz will indeed evolve into a wide-spread language, but, at the moment, we're not there.

I would like to thank everybody for the comments. I appreciate the time you dedicated to read and criticize our work. I am open to further discussion if anybody is interested.

I never heard the phrase "internal DSL" to simply mean "software interface". Anyway, I posted an answer to your question here.

I'm not familiar with the concept of internal and external DSL. Could you please explain what you mean?

I indeed started with a BNF. I just haven't had the chance to publish it yet.

I replied to this question here. Thanks for your feedback!

I'm the lead researcher on this project. Thanks for your question!

We gave your concern quite a bit of thought.

In brief, we found no language with the features we wanted that would fit <16KB or <32KB. We wanted a dynamic language with closures, with a VM powerful enough to work in a networked environment with highly volatile topology, and that would be easy to modify to accomodate features such as swarm management and virtual stigmergy. We considered Python and Lua at first, but Python is just too complex to fit the requirements (I studied TinyPy for a week, and it's too limited) and Lua VM makes it hard to fit networking the way we wanted it.

In the end, we thought that a dedicated language with the right features might be a good choice. After all, Python does nothing C++ doesn't do - but the level of abstraction that Python offers makes developers way more productive. With Buzz, we hope to offer a tool that makes people more productive when the problem is coordinating hundreds of robots. There's obviously lots of work to do towards this goal, and the current implementation of Buzz is just a step in that direction.

I'm the lead researcher in this project. Thanks for your questions! I'll try to address all of them.

Q. Why an external language?
A. Robot swarms are a special kind of system. It's not just a collection of computers (like a network would be), but a collections of autonomous devices that occupy space and form networks with very volatile topology. Sure one could use C/C++/Java/Python to program them, but it gets fast very complex, due to the large number of interactions among robots. We believe that it's much better to have a language that natively provides you with the right kind of abstraction, and hides whatever is not necessary for swarm-level coordination.

Q. It looks like C.
A. It's directly inspired by JavaScript and Lua, which in turn look like C. We wanted this, so people can get productive faster and don't need to learn a whole new syntax from scratch. The entire point of our effort is to make something people would want to use.

Q. Why not flex/bison/LL parser ecc.
A. No specific reason. These are just development tools - we could have used Lemon, we found it easier and more fun to make our own thing. The fact that the VM is custom is a necessary feature - it weighs only 12KB, and this means that we can put it on very resource-limited robots.

Q. There's no BNF available.
A. I'll publish it, it's just not on the website yet. We just went public, there's lots of work to still. Good suggestion!

Q. Semantics are vague.
A. That means the paper was not written clearly enough. If you have more precise feedback on this, I'd be happy to hear you.

Q. Unknown symbols are cumbersome and potentially confusing.
A. I see your point, and I agree. I am currently working on a way to make the debugger aware of this issue, because I think that having robot-specific symbols is an interesting idea. You raise a good point, though.

Once more, thanks for your feedback!