Lingo: A Go micro language framework for building Domain Specific Languages
1–10 of 54 posts
Re: Lingo: A Go micro language framework for building Domain Specific Languages
#2This seemed like nuclear overkill for most problems I can think of.
And where it should be used, I can't imagine you can't find a pre existing language (Cuelang maybe) instead.
I was expecting a section at the end where they demonstrate which services need a new language written just for it's configuration, but nope, just general examples.
Also, this should have a (2022) in the title.
Re: Lingo: A Go micro language framework for building Domain Specific Languages
#3This seemed like nuclear overkill for most problems I can think of. And where it should be used, I can't imagine you can't find a pre existing language (Cuelang maybe) instead. I was expecting a section at the end where they demonstrate which services need a new language written just for it's configuration, but nope, just general examples. Also, this should have a (2022) in the title.
I think that a Domain Specific Language without the scaffolding of a language like python to generate test data is a great use case.
You have a specific DSL to generate test data and store code written using your DSL with your test cases.
You then have a security model that separates the responsibilities of the test team from that of other developers. The team can generate many test cases in a secure environment. You could then seek community input into your test processes with having to worry about rogue code.
Re: Lingo: A Go micro language framework for building Domain Specific Languages
#4Regarding the Ruby example, why did they use Float("...") instead of #to_f?
Re: Lingo: A Go micro language framework for building Domain Specific Languages
#5Regarding the Ruby example, why did they use Float("...") instead of #to_f?
Probably because `Float()` is stricter and will raise an error if the string isn't a valid number, whereas `#to_f` will silently return 0.0 or do a best-effort conversion (e.g. "1.2abc".to_f => 1.2)
Re: Lingo: A Go micro language framework for building Domain Specific Languages
#6This seemed like nuclear overkill for most problems I can think of. And where it should be used, I can't imagine you can't find a pre existing language (Cuelang maybe) instead. I was expecting a section at the end where they demonstrate which services need a new language written just for it's configuration, but nope, just general examples. Also, this should have a (2022) in the title.
It is nuclear overkill for most problems you can think of.
But when you hit a problem that you need something like this for... you need something like this. The attempts to get around it or avoid it or do some unbelievably hacky thing leads to piles and piles of terrible, terrible code.
In 2024, though, I do try very hard to embed my DSLs in an existing serialization. It doesn't always work out, but, the case they show of directly embedding an AST into YAML is a worst-case scenario. In real life I've done things like specify a particular field carries an expr[1] expression to do that sort of thing, and then the structure of the rest of the file just follows normal serialization format.
[1]: https://github.com/expr-lang/expr , but I'm sure many static languages have something like this. If you don't know one, it's a good tool to put in the belt in case you ever need it.
Re: Lingo: A Go micro language framework for building Domain Specific Languages
#7 > Some popular DSLs most software developers use on a regular basis include Regular Expressions for pattern matching, AWK for text transformation or Standard Query Language for interacting with databases.
Re: Lingo: A Go micro language framework for building Domain Specific Languages
#8> Some popular DSLs most software developers use on a regular basis include Regular Expressions for pattern matching, AWK for text transformation or Standard Query Language for interacting with databases. Isn't it Structured Query Language? Or are both variants used?
> In the early days of the system there was divided preference between Standard Query Language and Structured Query Language but it did not make a whole lot of difference since most people most of the time called it by the acronym SQL. Now the overwhelming but not complete preference is for Structured Query Language.
Re: Lingo: A Go micro language framework for building Domain Specific Languages
#9> Some popular DSLs most software developers use on a regular basis include Regular Expressions for pattern matching, AWK for text transformation or Standard Query Language for interacting with databases. Isn't it Structured Query Language? Or are both variants used?
> In the early days of the system there was divided preference between Standard Query Language and Structured Query Language but it did not make a whole lot of difference since most people most of the time called it by the acronym SQL. Now the overwhelming but not complete preference is for Structured Query Language. [0] https://www.sjsu.edu/faculty/watkins/sql.htm
Thanks for that!
Re: Lingo: A Go micro language framework for building Domain Specific Languages
#10This seemed like nuclear overkill for most problems I can think of. And where it should be used, I can't imagine you can't find a pre existing language (Cuelang maybe) instead. I was expecting a section at the end where they demonstrate which services need a new language written just for it's configuration, but nope, just general examples. Also, this should have a (2022) in the title.
I wouldn't think of it for generating configuration. The example given implies they use it for fuzzing program inputs. It's purpose in the article is simple: generate a CSV with two columns and floats.
However, a DSL could be made to do anything. Generate particular kinds of PDFs, Excel files, intentionally incorrect CSV/TSV files, zipbombs, and etc.
All that is required is to wire it up in the Go side of things and then write a script to make use of it.