underlying language for the solution

[rdmueller]

I really like the idea to "code" a diagram. With your approach, we get as additional benefit to solutions like plantUML

• better sytax highlighting
• auto-completion
• syntax checks

But I am not sure if I like the usage of java as underlying language. Id adds quite some boilerplate code.

Wouldn't it make sense to use a scripting language in order to avoid some of the boiler plate?
Groovy for example lives in the JVM ecosystem and can create perfect DSLs. I wouldn't be surprised if you could create the exact plantUML DSL in Groovy :-)

[diagramsascode]

Thanks for the common. I'm not that familiar with Groovy, but since it's a JVM language, can't you use Java libraries?
(At least that's possible with Kotlin.)
Otherwise, feel free to write a Groovy port :-)

[rdmueller]

I wonder which parts of a scription language can be used to get still support from the IDE...

[diagramsascode]

One more thing: Java 10 introduced the var keyword that reduces some of the boilerplate.
But I wanted to stay compatible with Java 8, since it is still used a lot.

[rdmueller]

makes sense. you should write an architecture decision record (ADR) for this :-)

[diagramsascode]

There's several I could write, since there were quite a few trade-offs when designing the API.
For example: use a single Diagram builder class (as it is now), or use a separate builder class for each kind of diagram?
The latter would've been slightly more convenient for the user, but at the price to pay for extensibility.
Maybe I'll write something about the design decisions. It's all a matter of time :-)

[rdmueller]

Those design decisions are quite important for other to add features to your project :-) The time is well invested :-)

[diagramsascode]

BTW I added your benefits to the front page.

[diagramsascode]

I simplified the API a bit and released it as v0.1.1.
Examples on main page now with Java >=10 syntax :-)