Hacker News Reader

Comment by afandian | Hacker News Reader

Interesting decision to implement a DSL in a programming language when the output is a static data structure. Seems more complex than writing the structure directly as YML or JSON (or a custom language like Mermaid or DOT).

I can see the point of DSLs where the output is used by other code (e.g. builder pattern, LINQ). But this seems like overhead compared with the alternative?

View on HN

I'm biased, but I think it's a bad decision. Programming languages are for writing, well, programs. Programs execute, accept input, have state, and all manner of other things that just don't apply to diagrams. Diagramming in a programming language is just weird.

My counterpoint would be: If you can write data visualizations with code, why not write diagrams too?

Why not write recipes in code too?

Or a screenplay?

(Because there are better formats for them)

How about music as code…Sonic-Pi would like to offer a counterpoint :)

https://sonic-pi.net/

I think the counter-point to that would be that if you're writing infrastructure as code, and your architects are using a specific language anyways (Python in this case), it makes more sense for data governance and editing reasons to just keep things in the existent ecosystem and not worry about having to procure another license.

Vs. Cooking or Writing which aren't coding practices unto themselves.

Recipes absolutely should be written in code. If I could view source, copy the recipe yaml, and paste into my personal recipe manager app, it would be much more convenient.

Screenplays... are already written in code, partly. If they weren't, they'd include quotation marks and "she said" after every line.

I think this is too loose of a definition of code...

Yaml isn't really code in the same sense as python is, and Shakespeare didn't write in code in the same sense that the diagrams in this article are.

Well, you're right about that, but then they were your examples.

You can do it, certainly, but it is overkill. It also limits your potential editors to people who know Python and are willing to install it on their machine. In contrast to Python (or other programming languages), a language like YAML or JSON can be learned in minutes by just about anyone.

This is a program that executes and produces an output. It also has state - every step of executing that DSL is creating and manipulating a piece of state that builds up a declarative description of what the final output should look like.

The other thing you list, input, is optional. I write programs that don't take any input all the time. Monte Carlo simulation, for example. The entire demoscene is largely devoted to creating incredibly sophisticated programs that don't take any input. Postscript is a full, Turing-complete language whose primary purpose is to create programs that generally don't take any input

Programs that produce diagrams should be (and are) written in a programming language. They accept input, execute, and produce output. Diagrams themselves do not execute and have state (unless they are interactive[0]). There's a difference.

[0] https://app.ilograph.com

Be aware the poster has a history of being very active on posts related to diagramming tools to discourage his competitors' solutions and/or promote his own tool without disclosing affiliation.

I don't think its even a DSL, its just Python.

It's an embedded DSL or "eDSL", see https://en.wikipedia.org/wiki/Domain-specific_language#Exter...

Reply on news.ycombinator.com