221–230 of 598 posts
The first thing the page shows is generating configurations in existing formats like YAML. For most of my use cases, there is tooling that does some updates of the configuration (e.g. bumping dependencies), so I'd really need bidirectional support to convert the updates back into Pkl.
I'm sorry, can someone explain why one would want to translate from one data description language to another (Pkl -> JSON, or whatever)? Why not just write JSON (or whatever) to begin with?
The amount of problems I've had with JSON in my career makes me think almost anything could be better than it. There's so many weird edge cases in the JSON spec that you can hit that it just becomes endless levels of hair pulling.
Serious question - why not just use python?
Edit: and moreover, you probably do not want config files that can run arbitrary code with full access to the Python standard library.
doubt I would use it elsewhere instead of JSON but if this is an indicator that .plist in xcode will go away then I'm all in - .plist is probably one of the worst formats human can work with.
The biggest drawback was limited number of types, imho. It seems like encoding issues were another drawback which led Apple to use XML when OS X launched. JSON want a thing yet, so XML probably looked like a good option.
0 - https://code.google.com/archive/p/networkpx/wikis/PlistSpec....
I'm sorry, can someone explain why one would want to translate from one data description language to another (Pkl -> JSON, or whatever)? Why not just write JSON (or whatever) to begin with?
The amount of problems I've had with JSON in my career makes me think almost anything could be better than it. There's so many weird edge cases in the JSON spec that you can hit that it just becomes endless levels of hair pulling.
Earlier quoted context omitted.
The services teams at Apple are more agnostic than what you’d think.
In the not-eating-our-own-dogfood sense?
Though, even if they weren’t going to provide a server OS, it seems like they could still offer IDE support for the droves of web devs working on Macs a deploying to Linux (like I assume their devs do).
Can somebody tell me real use cases they would use this for? I've seen their usecase documentation entry. And I understand the benefits this could have. But I think I need some hands-on usecases, to fully grasp why or how I would use this. Thanks
> My team migrated several kloc k8s configuration to pkl with great success. Internally we used to write alert definitions in pkl and it would generate configuration for 2 different monitoring tools, a pretty static documentation site and link it all together nicely.
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…
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…
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, anyway. So configuration providing types doesn't really do much.