Lingo: A Go micro language framework for building Domain Specific Languages
41–50 of 54 posts
Re: Lingo: A Go micro language framework for building Domain Specific Languages
#42When I think of a DSL, I think of a language with specialized syntax , grammar , or constructs suited to the problem domain. Think SQL, AWK, or regular expressions. This is just a LISP variant with a typical host-side API for registering function names. I'll never get how merely having function names that reflect the use case, plus a stripped down or absent standard library, qualifies as a DSL. I know some people hav…
Re: Lingo: A Go micro language framework for building Domain Specific Languages
#43Re: Lingo: A Go micro language framework for building Domain Specific Languages
#44Unfortunately the given example doesn't give - mere mortal like me- idea on how this make sense to use. Instead of using whatever scripting language available, or just json. Or probably grule? [1] https://github.com/hyperjumptech/grule-rule-engine
This is just another scripting language available. It only differs from something like Lua or Javascript in that it claims to have less complexity. Complexity which, while not fully elaborated on, apparently bogged down their efforts when they originally tried using Lua and an embeddable Go engine.
Re: Lingo: A Go micro language framework for building Domain Specific Languages
#45This 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 sh…
At what point do you sit back and ask, is there a way to reduce complexity here? Is it not until you're joining a team where the last guy made dozens of DSL's for all his tools?
That was the main reason I was expecting more than a few real world use cases rather than generalized examples and no examples from their workplace.
Re: Lingo: A Go micro language framework for building Domain Specific Languages
#46Disclaimer: this is a neat project. DSLs are such a trap for most projects that think they need them. Use lua or something off the shelf for scripting. CEL exists for Go and (safely) solves many of the problems you might also want a DSL for. The case for DSLs is often hard to justify in a project that has to be maintained for years.
CEL seems very much in line with the Golang ideology. It looks like CEL doesn't really have any upsides at all, except for being non-turing-complete. It looks like it is more of a convenience food, for people, for whom any other syntax than what they know from mainstream programming languages is "too adventurous" or "too foreign". As if they cannot be trusted to be able to cope with another syntax. This might even be…
Re: Lingo: A Go micro language framework for building Domain Specific Languages
#47 #!/usr/bin/env ruby
require "csv"
puts CSV.foreach(ARGV[0], headers: true).sum { _1[1].to_f }.round(2)Re: Lingo: A Go micro language framework for building Domain Specific Languages
#48There is already programming language called Lingo, though probably nobody uses it anymore: https://en.wikipedia.org/wiki/Lingo_(programming_language)
Re: Lingo: A Go micro language framework for building Domain Specific Languages
#49When I think of a DSL, I think of a language with specialized syntax , grammar , or constructs suited to the problem domain. Think SQL, AWK, or regular expressions. This is just a LISP variant with a typical host-side API for registering function names. I'll never get how merely having function names that reflect the use case, plus a stripped down or absent standard library, qualifies as a DSL. I know some people hav…
I would agree with your sentiment. This is basically a lib with some extra syntax to parse CSV Files. A 'proper' DSL would require a very specific domain where it is applied to. Like document creation, or solving a certain problem and only that but not much else. Turing completeness is usually not required as well. For example Matlab or LaTex are domain specific as well as SQL. Those are used to do math, create docum…
1. Given that their stated use-case for this tool is generation of data for testing purposes, why would input configuration be relevant?
2. It doesn't have any CSV-associated features to begin with. If for some reason you wanted to use this for that, you would interact with your own bound Go functions to facilitate working with CSV, just as demonstrated in the article. Within those functions, you can setup any configuration your heart desires.
Re: Lingo: A Go micro language framework for building Domain Specific Languages
#50There is already programming language called Lingo, though probably nobody uses it anymore: https://en.wikipedia.org/wiki/Lingo_(programming_language)
You'd think they'd do a quick check on the name before committing to it. I remember using Lingo with Macromedia Director, it was a nice little language
At my last job, we spent 3 years building an electrical systems product with the same name as an eye scanning company. We had invested in marketing and sales that was practically useless once the executives finally agreed they needed to rebrand. It was the sort of thing that was pointed out on day zero, but the man in charge was too proud of the name. It wasn't even a very good name for our product.
And that was a bet-the-company type of choice. Lingo here is just some little library of no import to Gitlab's business.