Cue – A language for defining, generating, and validating data • Hacker News Board

Re: Cue – A language for defining, generating, and validating data

#161

Post by breck » Sun, Sep 01, 2019, 3:49 PM UTC

DannyBee wrote: post #147

breck wrote: post #115

Earlier quoted context omitted.

Fact: I've commented on fewer than 1% of HN posts today alone. Fact: my post is very relevant to the OP and I'm offering to help them. Fact: I've been a member of this site for over 12 years, and never comment on a post unless I think it adds value to the discussion or would be helper to the parent.

Fact: What you wrote was essentially a private, directed comment that should have been a private email, and added literally nothing to the discussion.

> should have been a private email

That's a good suggestion. I didn't think of that. But thinking about it, I guess I don't want to bother the OPs inbox. If they are interested, they can get in touch.

> added literally nothing to the discussion.

I disagree. When I post a new language, and someone shares a link to a related language, those are often the most valuable comments.

Validating, defining, using data: sound like things Tree Notation syntax is perfect for. Cue's semantics are great, and presentation and execution, I just think potentially a syntax switch is worth exploring. I understand the strategy to be able to parse JSON as cue, and that's probably the way to go for now, but in the future Tree Notation syntax might offer compelling advantages.

Re: Cue – A language for defining, generating, and validating data

#162

Post by leg100 » Sun, Sep 01, 2019, 4:05 PM UTC

krapp wrote: post #153

leg100 wrote: post #150

Earlier quoted context omitted.

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 s…

> 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

I'm genuinely intrigued to see a non-trivial example of this, a configuration in use by an organisation with complex needs, describing its applications and its cloud infrastructure, while avoiding the pitfalls you describe that bedevil the use of Turing complete languages.

Re: Cue – A language for defining, generating, and validating data

#163

Post by justicezyx » Sun, Sep 01, 2019, 4:12 PM UTC

ithkuil wrote: post #142

star-trek-fleet wrote: post #48

Earlier quoted context omitted.

I am pretty sure you placed the hate on the wrong target, you probable are hating borgcfg, instead of the GCL/BCL language. Disclaimer: was borgcfg owner 2016-2019.

I had my own qualms with the language itself too. My team had very complex Borg configs, so complex they took more than a minute to evaluate. Luckily the GCL team at the time was working on a new interpreter (gclx? IIRC), which was indeed much faster (I wrote a mandelbrot PNG generator in pure GCL to prove the big speedup and convince my team that switching was worth the effort). Unfortunately there was no formal spe…

Talk to the borgcfg team, and let your organization's tech leaders know as well.

A few executives are not friendly to borgcfg. Their agenda, appeared to me, has been to deprive it's resources so it can die from rotting. That's bad engineering and totally unnecessary. A healthy BCL/borgcfg will die easier, because they'll allow an easier path migrating to something new.

Re: Cue – A language for defining, generating, and validating data

#164

Post by ithkuil » Sun, Sep 01, 2019, 7:50 PM UTC

justicezyx wrote: post #163

ithkuil wrote: post #142

Earlier quoted context omitted.

I had my own qualms with the language itself too. My team had very complex Borg configs, so complex they took more than a minute to evaluate. Luckily the GCL team at the time was working on a new interpreter (gclx? IIRC), which was indeed much faster (I wrote a mandelbrot PNG generator in pure GCL to prove the big speedup and convince my team that switching was worth the effort). Unfortunately there was no formal spe…

Talk to the borgcfg team, and let your organization's tech leaders know as well. A few executives are not friendly to borgcfg. Their agenda, appeared to me, has been to deprive it's resources so it can die from rotting. That's bad engineering and totally unnecessary. A healthy BCL/borgcfg will die easier, because they'll allow an easier path migrating to something new.

I left the company half a decade ago. Just to be clear I actually loved borgcfg, just shared a war story. I'm happy to hear that the tooling improved. I'm unsurprised to hear that many still have mixed feelings towards GCL and ecosystem.

FWIW I'm the current maintainer of https://github.com/bitnami/kubecfg whose name is shameless xoogler bait.

Re: Cue – A language for defining, generating, and validating data

#165

Post by slifin » Sun, Sep 01, 2019, 10:27 PM UTC

A lot of these systems ignore the querying side of a schema i.e. in graphql you can define a schema then query only certain parts of the schema so only parts of the schema are enforced at runtime

Re: Cue – A language for defining, generating, and validating data

#166

Post by philipov » Mon, Sep 02, 2019, 5:12 AM UTC

pvg wrote: post #140

bhk wrote: post #132

Okay, so I've spent some time trying to understand this, and I think it's actually really cool, but I found the "About" and "Concepts" documents tumid and murky. Here is my understanding of the basic concepts: - It allows a schema-like set of constraints to be declared for JSON (and therefore for YAML & TOML) in a syntax that is an extension of JSON. - Cue deals with types (sets of values) where JSON deals with singl…

tumid and murky This should have its own word. Murid is too close to 'lurid'. Tumky, perhaps, though it lacks a certain heft and judginess.

how about "obtuse"

Re: Cue – A language for defining, generating, and validating data

#167

Post by mixmastamyk » Mon, Sep 02, 2019, 4:54 PM UTC

preommr wrote: post #41

mixmastamyk wrote: post #14

Earlier quoted context omitted.

A safer yaml: https://hitchdev.com/strictyaml/

I am really curious why people are downvoting this. I've always thought that a more restrictive and simpler version of yaml would be a good alternative.

Folks upset at the sibling comment weren't here at the time. The reaction was swiftly negative, and there are few charitable reasons to be found for that.