The syntax looks a lot like Coffeescript, which I use for defining and generating data.
Cue – A language for defining, generating, and validating data
151–160 of 167 posts
Re: Cue – A language for defining, generating, and validating data
#152Earlier quoted context omitted.
What if you're using multiple programming languages?
Then just pick one of them. This may be simpler than introducing another language to the project.
Some web projects validate inputs in JavaScript, then in a possibly different backend language, then (unusually) in the database with CHECK statements. Even when it's all JavaScript the validations are different because the frontend and backend frameworks are different.
And some projects have multiple backend services written in multiple languages.
Re: Cue – A language for defining, generating, and validating data
#153Earlier quoted context omitted.
The problem is not that there are too many configuration languages. The problem is that none of them are any good. The way to solve that is to keep trying new ones until we find one that is good.
Or the premise is a false one, that a configuration language is not the right approach. And everytime yet another such language falls flat only serves to reinforce this very point.
Configuration languages succeed and work just fine most of the time, despite their inadequacies and quirks, but no one ever complains about them when they work.
Go ahead and write your configuration as a fully Turing complete sub-application in whatever language you like. It will do everything you could possibly want, and in a few years it'll grow so complex and hairy that it will need its own fully Turing complete sub-application to configure it, lather, rinse, repeat. If you're really clever, every configuration layer will be written in a separate language with its own dependency tree, test framework, and toolchain.
Personally, I prefer not having to recompile just to change some variables and settings. I'm fine with INI or JSON (although I prefer Lua tables) when they're appropriate. The problem is not that configuration languages are a bad idea, the problem is interminable Turing creep and developers wanting every aspect of their applications to be as flexible and powerful as possible.
The premise of having a separate config language is fine - somewhere, somehow, inevitably, you're going to need a read-only data store for globals and references to system settings. You can hardcode all of those variables in your application or put them elsewhere.
Re: Cue – A language for defining, generating, and validating data
#154Earlier quoted context omitted.
We do indeed. XML is awful, YAML is a clusterfuck, JSON is often insufficient, and so is INI. TOML looks promising, but might not make it out of its niche. If Cue is basically a better YAML with built-in schemas, that sounds pretty good.
> XML is awful I never really understood this. This seems to be an oft repeated truism from mid 2000s with little backing it up. The only awesome thing that JSON did, was lose type information as well. In fact, the only thing that I can see that JSON brought to the table was easier editing by those who didn't have IDEs, at the expense of losing type information.
My main complaint with XML is that it’s far too complex for most use cases (like config files), and thus requires an unhealthy amount of tooling to work with.
I can’t just load the file and run it through a parser and get an easily accessible object structure back, I’ll need to navigate the document with DOM or XPath.
JSON with comments (aka JSONC) is in my opinion the best format in wide use today. It has structure and types, but not too many, and not a lot of magic, like YAML has, but for the most complex cases, JSON(C) falls short with its lack of extensibility and inheritance.
Re: Cue – A language for defining, generating, and validating data
#155If configuration starts becoming more complex than looking up key value pairs, why not just write it in the programming language you are using? More languages / serialisation just adds another layer of complexity. Config as code is actually really neat.
> If configuration starts becoming more complex than looking up key value pairs, why not just write it in the programming language you are using?
Because you want to write a config file, not a program?
What next, config files, build systems and unit tests for your config files?
No thanks.
Re: Cue – A language for defining, generating, and validating data
#156It looks like an alternative to Jsonnet which has schema validation & strict types. IMO, Jsonnet syntax is much simpler, it already has integration with IDEs such as VSCode and Intellij and it has enough traction already.
Cue seems like an e2e solution so it's not only an alternative to Jsonnet, it also removes the need of JSON Schema, OpenAPI, etc. so given that it's a 5 months old project, still has too much time to evolve and be mature.
We're heavily using Jsonnet for our data modeling (https://github.com/rakam-io/recipes) and pretty happy with it. We also have plans to add support for JSON Schema which is adopted by many of IDEs so that VSCode makes us feel like we're writing Java, not a Jsonnet file.
Cue is Google's 6th attempt and given that Jsonnet already has traction and works well out of the box, I would invest my time into Jsonnet at this time.
Re: Cue – A language for defining, generating, and validating data
#157If configuration starts becoming more complex than looking up key value pairs, why not just write it in the programming language you are using? More languages / serialisation just adds another layer of complexity. Config as code is actually really neat.
> If configuration starts becoming more complex than looking up key value pairs, why not just write it in the programming language you are using? Because you want to write a config file, not a program? What next, config files, build systems and unit tests for your config files? No thanks.
But this is a language, so it needs to be a program to run?
Oh wait.. feel like I miss the joke.
Re: Cue – A language for defining, generating, and validating data
#158Earlier quoted context omitted.
> XML is awful I never really understood this. This seems to be an oft repeated truism from mid 2000s with little backing it up. The only awesome thing that JSON did, was lose type information as well. In fact, the only thing that I can see that JSON brought to the table was easier editing by those who didn't have IDEs, at the expense of losing type information.
XML and especially XML schema are hugely complex and almost laughably difficult to bind to any mainstream programming language. It took Java over a decade to produce a binding that could (perhaps) handle an arbitrary schema. Types boil down to sums and products, I'm not convinced the designers of XML/XSD understood this. XML has so many overlapping concepts: elements, attributes, enumerations, choices, unions, sequen…
> XML and especially XML schema are hugely complex and almost laughably difficult to bind
I'm not very well versed in XML schema but if it were needlessly complex, it's probably not a good idea to throw baby out with the bathwater?
XML seems more type safe, easier to fold larger XML documents than JSON or YAML and it seems safer to edit.
Looks like, we're now reinventing all the XML advantages with a new config language, one at a time.
First, JSON came because it looks simple at first sight, but looks hard as soon as the JSON is huge, no different or better than XML, in fact, probably worse.
Then YAML appeared because, now it even allows you to add comments to config files, but it's a nightmare to edit, one wrong indentation and the YAML will blow up at runtime.
And looks like, we're now coming up with other languages to add in the missing functionality that XML already provided.
Re: Cue – A language for defining, generating, and validating data
#159Earlier quoted context omitted.
> XML is awful I never really understood this. This seems to be an oft repeated truism from mid 2000s with little backing it up. The only awesome thing that JSON did, was lose type information as well. In fact, the only thing that I can see that JSON brought to the table was easier editing by those who didn't have IDEs, at the expense of losing type information.
My main complaint with XML is that it’s far too complex for most use cases (like config files), and thus requires an unhealthy amount of tooling to work with. I can’t just load the file and run it through a parser and get an easily accessible object structure back, I’ll need to navigate the document with DOM or XPath. JSON with comments (aka JSONC) is in my opinion the best format in wide use today. It has structure…
> I can’t just load the file and run it through a parser and get an easily accessible object structure back
Huh, I'm surprised by this. Normally, I just read an XML file and get a POJO out of it and this is probably why I find XML to be so natural and easy.
Re: Cue – A language for defining, generating, and validating data
#160Would like to know more on how its a good fit for database schemas? Does anybody here use any DSLs for database schemas? If yes, what and why?