[sklogic]

> Am I missing something?

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.

[TeMPOraL]

> 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.

[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.

[altrego99]

An API would do the job just fine.

[sklogic]

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.

[TeMPOraL]

> A DSL would have a nice BNF-like syntax and abstract any implementation details away.

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.

[sklogic]

That's exactly the approach I'm preaching. I've built entire layers of languages above Lisp using this kind of eDSLs: https://github.com/combinatorylogic/mbase

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.

[eutectic]

What do you have against parsec?

[sklogic]

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.