It seems like a truncated Pkl file can still be a syntactically valid file? This is a problem with TOML and YAML (but not JSON) where the language itself doesn't protect against truncations, and applications will need to add end-of-file markers or something similar in their config schema. I am not sure if Pkl has some built-in feature related to this sort of thing.
Pkl, a Programming Language for Configuration
311–320 of 598 posts
Re: Pkl, a Programming Language for Configuration
#312so we're reinventing lisp yet again?
I have been looking into alternatives to YAML templating, the Helm abomination, etc. and was utterly surprised how no one ever apparently has thought to create a configuration/templating system that's basically a fancy library on top of Scheme. I truly believe every company is still reinventing the wheel because of a lack of serious foundational knowledge in most engineers, so they are doomed to recreate subpar, shit…
what about guix? could that be used for this purpose?
Re: Pkl, a Programming Language for Configuration
#313Earlier quoted context omitted.
That’s what I’m seeing as well. Curious to try it out to see how its expressiveness compares to Cue. Looks like it’s Turing-complete as opposed to Cue, which is a plus… but that comes with downsides. One thing I like to see is the direction of “declare types and validations in a single place, integrate with any language”. My daily codebase atm has types declarations in typescript, cue, pydantic and for our database……
What advantages does Turing-completeness provide for a configuration language?
Many data transformations that you take for granted in other languages are either impossible or require amazing feats of contortion of the language to make happen.
Re: Pkl, a Programming Language for Configuration
#314It seems like a truncated Pkl file can still be a syntactically valid file? This is a problem with TOML and YAML (but not JSON) where the language itself doesn't protect against truncations, and applications will need to add end-of-file markers or something similar in their config schema. I am not sure if Pkl has some built-in feature related to this sort of thing.
That's a feature, not a bug. Truncated files should not be accepted as valid
Re: Pkl, a Programming Language for Configuration
#315Earlier quoted context omitted.
Because there are a thousand ways to describe the same thing in JSON. This: city = { "id": 3, "name": "Foo", "lat": 3.555, "long": 4.11, } Is the same as: city = { "id": "3", "name": "Foo", "coordinates": [3.555, 4.11] } But you want to normalize that. Something like Cuelang will: - Define the schema that will let you know what you should put inside. - Allow you to inflate that schema into a full file, providing only…
Sounds like a job for JSON Schema https://json-schema.org
Jumping back and forth between a JSON schema and writing valid JSON is not a very fun task
Re: Pkl, a Programming Language for Configuration
#316Earlier quoted context omitted.
What advantages does Turing-completeness provide for a configuration language?
There are three (maybe more?) ways things can be Turing-incomplete: 1. You are limited to N evaluation/reduction steps. 2. The language doesn't include primitives like recursion or loops. 3. You can have recursion or loops, but the language makes you somehow prove that your program will terminate. I think (1) would be fine, but I don't know any configuration languages that use this approach. (2) is restrictive/annoyi…
I think there is another option:
2a. The language includes limited primitives for recursion or loops.
If that’s done right, somehow proving that your program will terminate becomes trivial.
For example, allowing looping over a previously defined array with (key,value1) pairs to generate many more complex definitions that include common value2, value3, etc fields trivially guarantees termination, but a generic “while” loop doesn’t.
That will make you language less powerful, but IMO shouldn’t be problem for a configuration language.
In this example, I’m not sure you would even need that, as the language has ways to share common config values.
Re: Pkl, a Programming Language for Configuration
#317Isn't this similar to gradle (which is based on groovy lang)? Syntax and functionality looks similar.
Re: Pkl, a Programming Language for Configuration
#318I'm having a little trouble understanding the problem(s) Pkl is trying to solve.
After reading the title, my assumption was that Pkl was yet another newer, better configuration language (a la TOML), but now that I've read the article, it sounds like it's more a language for _generating_ config.
Unless I'm mistaken, it sounds like an abstraction on top of your config files meant to help you build & re-use configuration in a more standardized way, rather than yet another config language into itself.
A problem space I'm familiar with is having a bunch of Terraform or Cloudformation configuration you want to share/repeat in multiple projects. Doing-so can get hairy quickly, as the path of least resistance is to copy-paste a bunch of config you barely understand from some other project, and then perform trial-and-error surgery to find and change a couple of lines to suit your project.
Is Pkl designed to help address that sort of problem? Or am I missing something?
Re: Pkl, a Programming Language for Configuration
#319I appreciate what the language is trying to do and simplified configuration that is repeatable / re-usable is the goal.
However I can’t help but wonder why systems don’t simply start adopting full programming languages once they hit a certain complexity. Having to use another language just to reproduce YAMl or what have you in a repeatable fashion is a symptom of the problem IMO
Re: Pkl, a Programming Language for Configuration
#320See also https://pkl-lang.org/index.html (via https://news.ycombinator.com/item?id=39239265 , but we merged that thread hither)
Did all the timestamps get reset? Seeing most (all?) comments at about 30min ago
Ah sorry - that was an unintended side-effect of re-upping the original submission. I must have done some of the steps in the wrong order.