Am I missing something? Why is there a need for a separate programming language for a use case like this? Don't we have enough programming languages to get by? Why a library wouldn't suffice?
It just does not seem reasonable to me to dump an ecosystem built by an established programming language to solve a domain problem
> No, not even nearly enough. Every little problem domain needs its own language.
> Then you really do not understand the value of DSLs. And you don't have to dump anything, eDSLs allow everything to co-exist nicely.
How about using a language that lets you build DSLs from it? Lisps are especially good choice.
I don't really see the point in createing a new language that is 95% identical to everything else, only to tweak that last 5%. Yes, you're still using a library, you're just hiding it inside the compiler.
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.
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.
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.
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.
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.
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.
API leaks abstractions and does not provide any domain-specific semantics. Imagine an API for, say, parsing. A DSL would have a nice BNF-like syntax and abstract any implementation details away. API - well, you won't ever get any further than Parsec, and Parsec is awful.
So, yes, as long as you have a sufficiently powerful meta-language, eDSL is almost always better than a library. But yet, if your language is not powerful at all, DSLs (standalone) are still better then the libraries, they're just a bit more complicated to implement.
Same thing - leaky abstraction. Too much host language semantics leaking into the problem domain. It's not a pure BNF, and therefore it's faulty by design.
It just does not seem reasonable to me to dump an ecosystem built by an established programming language to solve a domain problem