Earlier quoted context omitted.
I definitely did a double take to make sure they didn’t write Futurama.
I absolutely thought they wrote Futurama until I saw this comment
The mind. It is a curios thing.
Pkl, a Programming Language for Configuration
241–250 of 598 posts
Re: Pkl, a Programming Language for Configuration
#242Too bad, it doesn't have dotnet and C# support...
Re: Pkl, a Programming Language for Configuration
#243Earlier quoted context omitted.
I really like CUE, but for most use cases I have I would want to embed it in an application, and Go is the only language with support. For it to gain more adoption it really needs a rewrite in a low-level language (C/Rust), so it can be exposed in various languages through an extension/FFI.
Making CUE available as a library for other languages is one of our top priorities. Sadly, I can't provide an ETA at this time, all I can say is that I am personally working on this. Getting feedback from the community about what other languages they'd want supported first would be of massive help, however.
Can we have D language support?
For those who want the justifications for CUE, this is an excellent write up.
[1] How CUE Wins:
Re: Pkl, a Programming Language for Configuration
#244Earlier quoted context omitted.
Python would be a terrible choice for this. * It's been dragged into static typing kicking and screaming. * You import the whole Python infrastructure/packaging catastrophe. * It's not sandboxed. If you wanted something Python-like you would you Starlark.
Which of these problems outweigh the complexity of onboarding a new language to an organization?
Probably the infrastructure/packaging mess. That's debatable. If you fix all of them though it's easily worth a new language, as long as it isn't too hard to learn.
This looks very easy. I'd be more hesitant about Dhall or Nix (though obviously Nix comes with even bigger benefits so it might be worth the awkward language).
Re: Pkl, a Programming Language for Configuration
#245I've had a good long think about configuration languages, and after a long-term on/off love/hate relationship with schemas I think I've finally concluded that I don't want rich types in my configs, thank you very much. I use statically-typed programming languages, and for my purposes I'd rather have a config language where the only types are strings, arrays, and hashmaps, and then push all type validation into the pa…
Guess the obvious question is why don’t you want types in your config language? Pushing all the validation to parsing state just makes it hard to write valid config, because you only know if the config is valid when you feed it into your program. Having the ability to pull all that validation forward, and into your IDE, means you can be told about invalid config as you’re writing it. To me the idea of only wanting to…
Yeah, generally, you want to validate as early as practical... catching problems sooner is better than later.
I think the problem might be separation of concerns...
pkl comes in early, and by design is separated from your app and the details thereof. It seems good for validating high-level or external configuration constraints. But suppose you have some constraints based on implementation details of your app. Now you face a choice: eschew pkl and put that validation logic in the app where you lose the benefits of early validation or put it in pkl (if that's even possible) which implicitly makes it dependent on application implementation details. Of course, we devs aren't great at stopping to consider the deep implications of each config param we add, so which one happens in practice in each case probably depends on the dev or dev group and how much they've bought in to pkl... some will pretty much always add a config to pkl because that's what it's there for, while others will ignore pkl whenever they can. I think this is inherent in the ambiguity the choice presents. There's probably a right choice in each case, but devs will only sometimes be that careful about the location of each config validation.
That's my guess anyway, as to why the previous post wants to just put all the validation at the level it's used. If that's your rule the ambiguity is resolved and it works perfectly for config dependent on specific app concerns and pretty well for config that also has high-level or external concerns, since those are less volatile and when they do change, it generally implies app changes in any case.
My gut says pkl is over engineered for the vast majority of cases and people should not reach for it unless they have a specific problem that it will solve for them.
Re: Pkl, a Programming Language for Configuration
#246Re: Pkl, a Programming Language for Configuration
#247Earlier quoted context omitted.
My take on this is that there is not obvious reason not to, but it just so happens that typed configuration languages are not rich enough and not integrated enough to be that useful. Those languages that arrived with the JSON hype train like yaml or toml might be great for dynamic languages, where you can load them to some native object. But in statically typed languages you are gonna declare your types, in code, any…
Ah! Well this is the hole that Pkl does a very good job of filling! Being able to use Pkl code-gen to create language bindings means you can take any arbitrary Pkl schema and turn it into native structures in your language, typed based on the Pkl schema. Then you can let Pkl do all the heavy lifting of parsing and validating a specific config, and turning it into native objects in your language. So no need for double…
To be fair if your config is just a structure with strings then you declare your types only once, too. Minus the codegen, but also minus the editor integration.
I'm not hating on Pkl here, we deserve better in this space, so I'm happy with more developments.
Re: Pkl, a Programming Language for Configuration
#248Earlier quoted context omitted.
My take on this is that there is not obvious reason not to, but it just so happens that typed configuration languages are not rich enough and not integrated enough to be that useful. Those languages that arrived with the JSON hype train like yaml or toml might be great for dynamic languages, where you can load them to some native object. But in statically typed languages you are gonna declare your types, in code, any…
Ah! Well this is the hole that Pkl does a very good job of filling! Being able to use Pkl code-gen to create language bindings means you can take any arbitrary Pkl schema and turn it into native structures in your language, typed based on the Pkl schema. Then you can let Pkl do all the heavy lifting of parsing and validating a specific config, and turning it into native objects in your language. So no need for double…
If you replace "Pkl" with "XML", this is all exactly true for XML. Ten years ago we were generating C# classes, typed validators, and automatic parsers from XSD schemas, with automatic IDE integration and IntelliSense completions when editing the XML documents--is this just XSD for the younger JSON generation? I shipped multiple megabytes of complex manually-written XML configuration this way and it was delightful. We never would have pulled it off without XSD.
Re: Pkl, a Programming Language for Configuration
#249Pkl was built using the GraalVM Truffle framework. So it supports runtime compilation using Futamura Projections. We have been working with Apple on this for a while, and I am quite happy that we can finally read the sources! https://github.com/oracle/graal/tree/master/truffle Disclaimer: graalvm dev here. Edit: typo
> ...GraalVM Truffle framework... Futurama Projections... I know it's partly on me for not knowing the domain, but I honestly suspected somebody is trying to make fun of me with some concentrated technobabble. Especially since I wouldn't expect the topic (configuration languages) to require complex mathematical machinery to work with. Now I have something interesting to dig into.
I'm not sure if it was part of the humor, so pardon me if it was, but it's actually "Futamura" as in Yoshihiko Futamura, not "Futurama".
https://en.wikipedia.org/wiki/Partial_evaluation#Futamura_pr...
Re: Pkl, a Programming Language for Configuration
#250Does this support fancy symbols in bare identifiers? Even the huge reference page is blank on that, and the only working links to grammar are to the ANTLR website, but even if they did work, the grammar is also blank as it simply references an internal grammar function And there doesn't seem to be any online playground to test
Yes: quoted identifiers are represented using backticks (which do not then form part of the name), so:
local `My Variable` = 42
Do you happen to have a link to the missing/blank reference page on this?
EDIT: perhaps I misunderstood the question - if it's about whether you can use non-ASCII characters in identifiers without quoting, the answer is "sometimes":
``` local `abde` = 42 // Only works when quoted
local `teʝ` = 42 // Works fine (as expected)
local teʝ2 = 42. // Also works fine ```
It might be interesting to expand the docs to cover the precise rules here without having to resort to ANTLR grammar, as you say.