Reminds me of [HCL](https://github.com/hashicorp/hcl), but without all the providers to deploy the config?
Pkl, a Programming Language for Configuration
381–390 of 598 posts
Re: Pkl, a Programming Language for Configuration
#382I feel I have seen it all already.
Imperative DSLs created out of XML+XSD or fears which become exploited by expressiveness and nightmares to maintain after a while.
This is why I still prefer Maven (XML) instead of Gradle (Groovy DSL) for Java project configurations.
And the definitive question: can pkl configure pkl?
Re: Pkl, a Programming Language for Configuration
#383Built-in fetching of http resources and reading files from the filesystem[1] combined with turing-completeness are features that I wasn't expecting from a configuration language. I wonder if the complexity this brings is justified. 1: https://pkl-lang.org/main/current/language-reference/index.h...
Those sound like features that will eventually lead to major security issues.
Re: Pkl, a Programming Language for Configuration
#384Re: Pkl, a Programming Language for Configuration
#385Earlier quoted context omitted.
I'm very wary of anything Java-based, having been burned by Java tooling in the past. I work on a few different Android projects and I have to switch between three different JDK versions depending on which I'm working on. What happened to "write once, run anywhere"?? I really like Pkl's comparison page, which includes its weak points as well! https://pkl-lang.org/main/current/introduction/comparison.ht... Pkl’s nativ…
There are reasons Oracle sued Google over Android and you just articulated one of them.
It’s not Android per se that’s the problem, it’s that Android uses Gradle as a build system and Gradle uses Java.
The Gradle compatibility matrix is pretty complicated: https://docs.gradle.org/current/userguide/compatibility.html...
I’ve also used Facebook’s Buck build system, as an attempt to get away from Gradle, and it’s also fussy about JDK versions.
Re: Pkl, a Programming Language for Configuration
#386Earlier quoted context omitted.
Don't leave is hanging, how was your experience? (Pkl, not Apple :p)
I absolutely loved it and I’ve been extremely impatient to see its release. I used it to generate k8s manifests, Terraform, all infra config files. Very flexible and fun to use
Do you know of any public resources about it's use cases?, other than the one linked in this submission of course.
What bout Pkl made it easier to write Terraform/K8s manifests/etc.?
Re: Pkl, a Programming Language for Configuration
#387Earlier quoted context omitted.
Yeah I actually haven't found a great answer yet. Here's everything I've tried and why it sucks: * JSON. No comments. Deal-breaker * JSONC. No unique file extension so its difficult to distinguish from JSON. Poor library support due to library authors drinking the "comments are bad" koolaid. * JSON5. This would be an excellent option IMO except that library and IDE support is not great. * JSON6. This just complicates…
Do you have 5 minutes to talk about TOML?
Ha I forgot about that. TOML is pretty awful too. It's fine as long as you only need 1 level of nesting. As soon as you need to go deeper than that you end up with [[weird syntax]] that is very not obvious. I would say it's less obvious than YAML and YAML is already pretty unintuitive.
Re: Pkl, a Programming Language for Configuration
#388Earlier quoted context omitted.
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. W…
What you're expressing here is that many of the ideas from that period of xml-centricity were quite good and useful!
But xml itself was not a good language for this, because its legibility is terrible. It's just not a good format for human reading and editing. (But it also isn't a great format for machine interaction either...)
So yeah, I see it as a good thing that this seems to be able to do all that useful stuff you were doing with xml and xsd a decade (and more) ago. But it's (IMO) a much nicer way to do it.
Re: Pkl, a Programming Language for Configuration
#389Earlier quoted context omitted.
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…
> 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. There's Clojure's extensible data notation: https://github.com/edn-format/edn
It seems cool at first sight, but I feel it is overengineered for a configuration language: why would one need to indicate whether a variable is a list, a vector or a set? These are implementation details, they should be represented as lists, and it is the application underneath that choses the appropriate representation.
You only need Scheme, quoting and quasi-quoting, and s-expressions.
`((username "foo")
(password ,(getenv "PASS")))
Re: Pkl, a Programming Language for Configuration
#390It's 2024 and the software industry has not solved the problem of configuration yet. Umpteen solutions every year - languages, formats, etc - all for just doing configuration. Just wow! It amazes me. It would be so much better if all the great minds focused on real issues than keep spinning on the hamster wheel of config file formats. Just look at the # of comments here.