231–240 of 598 posts
Earlier quoted context omitted.
This. I’m willing to bet I talked to one of the people who use this internally at Apple a few years back when I interviewed there (before they decided to do away with remote hires). They didn’t mention it, but it fits the context.
Yes, I was using it when I joined Apple in mid 2020
(Pkl, not Apple :p)
Congratulations Phil!!
Earlier quoted context omitted.
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…
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…
Earlier quoted context omitted.
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…
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…
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 declaring types. Declare them once in Pkl, generate the equivalent types in your language, then just start using those types like any other primitive. The Pkl bindings will handle the loading glue for you.
I'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…
I mostly agree with this, but I've been a big fan of having primitive types in config. Most of the time if I have something I want to configure, it's either one of the following (or a map/list-based structure consisting of): - scalar value - feature toggle - URI/enum option/human readable display text Having float/long/boolean is trivial to validate in the config language itself, and if they're useful and simple enou…
Anything development related from Apple is inherently disinteresting unless it's aimed at Apple, is for Apple and you're building for Apple. Apple has done nothing cross platform or open source or community oriented so if they come out with something that's intended to be more general is has no base, no users, no audience of non-Apple developers to land on. I'm not anti Apple - I love MacOS and Apple is my main machi…
> Apple has done nothing cross platform or open source or community oriented Cups - https://en.wikipedia.org/wiki/CUPS Swift - https://en.wikipedia.org/wiki/Swift_(programming_language) Zeroconf - https://en.wikipedia.org/wiki/Bonjour_(software) I think they're bad, opaque opensource maintainers, but they did release some popular things that have communities on other systems. I do wish they just contributed to nickel…
They’re contributing to a ton of OSS that’s NIH:
https://opensource.apple.com/projects/
K8s, spark, cassandra, netty, zookeeper, solr, containerd
Earlier 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…
The whole _point_ of Pkl is that it is both rich enough and integrated enough though?
"Enough" is the keyword here, time will tell I guess.
Pkl 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