It just does not seem reasonable to me to dump an ecosystem built by an established programming language to solve a domain problem
It just does not seem reasonable to me to dump an ecosystem built by an established programming language to solve a domain problem
Yes, you're missing an entire huge world of the domain-specific languages.
> Don't we have enough programming languages to get by?
No, not even nearly enough. There is no such thing as a general-purpose programming language. Every little problem domain needs its own language.
> Why a library wouldn't suffice?
Because libraries enforce leaky abstractions.
> It just does not seem reasonable to me to dump an ecosystem built by an established programming language to solve a domain problem
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.
> 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.
IMHO there is no real benefit of creating a "new" language compared to e.g. just using Lua + C.
also: easier for the developers perhaps but not for users.
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.
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.
Use powerful enough language.
https://en.wikibooks.org/wiki/Common_Lisp/External_libraries...
Here, you can pretty much write out your BNF directly and get a parser out of it.
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.