Swift / Apple Development Chat

casperes1996

Power User
Posts
170
Reaction score
139
^ yeah, maybe it’s just a ‘genius’ idea this team came up with and that they’ve been allowed to release and see how it flies…or could be part of some long term strategy in which Apple’s development teams expect to increasingly need something like this. As you say, time will tell.
I think we’ll really know when wwdc happens. If they talk about it more than a quick mention
 

dada_dave

Elite Member
Posts
2,062
Reaction score
2,043
What was most interesting to me was honestly how quiet Apple has been about it. Nothing in the Developer app, nothing on developer.apple.com that I noticed at least. I found out through The Primeagen on YouTube and subsequently read on their GitHub and webpage for it. Also the fact it's written in Java/Kotlin is a bit curious to me. And on their website (last I checked at least) they noted having an x86 macOS build and x86+AArch64 Linux builds. That said, they did have an AArch64 macOS build their documentation just didn't mention it.
Personally I'm not sure exactly how useful this will be; If it will actually simplify configuration and get your out of a pickle or if it'll just be another dependency without really adding enough value to matter. Time will tell - Certainly configuration validation can be useful at least
I have to admit that I am not an expert in this topic, nor increasingly in my own field sadly, but I can see utility for my field where we need to partially specify models or a family of models, often with bounded parameters. That looks much easier and nicer here than YAML/JSON.
 

casperes1996

Power User
Posts
170
Reaction score
139
I have to admit that I am not an expert in this topic, nor increasingly in my own field sadly, but I can see utility for my field where we need to partially specify models or a family of models, often with bounded parameters. That looks much easier and nicer here than YAML/JSON.
Sure. I’ve also not looked deeply enough into it yet to fully understand pkl. What I can say though is that we have a roughly two thousand line long config file in json at work. A requirement was self service by non technical customers so we have a web page that can edit the configuration with easy to use buttons and input fields. I’m curious to see if pkl is capable of improving anything in that flow but kinda doubt it.
 

Nycturne

Elite Member
Posts
1,108
Reaction score
1,417
Apparently Apple has created a new open source data format language with conversions to JSON/YAML, seems to get positive reviews:


Unsurprisingly integrates with Swift. Thought it might be of interest!

Yeah, I saw this a little bit ago. Some interesting ideas that I could leverage in a couple projects to make validation of config files easier, but I haven’t yet had a chance to play with it. But one project gets used by people that tend to skip the documentation and open github issues against the project when they don’t understand what the pre-built example is doing. So if I can reduce the cost to catch these issues early and issue more clear errors to these users, that means fewer github issues I need to resolve. Will need to see if this actually delivers on that.

Sure. I’ve also not looked deeply enough into it yet to fully understand pkl. What I can say though is that we have a roughly two thousand line long config file in json at work. A requirement was self service by non technical customers so we have a web page that can edit the configuration with easy to use buttons and input fields. I’m curious to see if pkl is capable of improving anything in that flow but kinda doubt it.

I don’t think this really replaces anything in your scenario. This is more for scenarios where the expectation is that the user can use configuration files, but you want to be able to constrain the bounds more easily and ensure the configuration schema is followed. If you are already building UIs that include validation, this won’t really add anything. But those UIs with full validation eat engineering resources if the users are supposed to be relatively tech savvy, and using your stuff to compose services with (i.e. docker-based micro services).

^ yeah, maybe it’s just a ‘genius’ idea this team came up with and that they’ve been allowed to release and see how it flies…or could be part of some long term strategy in which Apple’s development teams expect to increasingly need something like this. As you say, time will tell.

This likely was created to make it easier to configure their own internal services/etc, and reduce errors that get found later. With these large scale projects, it’s not easy to be able to hold it all in your head, and with so many people working on them in the first place, you are at the mercy of whatever documentation may or may not exist.

I’ve always been a fan of the philosophy of pushing errors as early as possible. An offshoot of the ‘fail fast’ thinking. Compiler/validation errors vs runtime errors, in this case. Pkl to me seems to be aimed at making it easier to produce validation errors for configuration files, which makes it safer for an engineer to make changes in unfamiliar parts of a larger service such as iCloud or the like.
 

Andropov

Site Champ
Posts
602
Reaction score
754
Location
Spain
I’ve always been a fan of the philosophy of pushing errors as early as possible. An offshoot of the ‘fail fast’ thinking. Compiler/validation errors vs runtime errors, in this case. Pkl to me seems to be aimed at making it easier to produce validation errors for configuration files, which makes it safer for an engineer to make changes in unfamiliar parts of a larger service such as iCloud or the like.
This is the way. Amazing how much cleaner (and reliable!) the code can end up being by failing as early as possible.
 

Nycturne

Elite Member
Posts
1,108
Reaction score
1,417
This is the way. Amazing how much cleaner (and reliable!) the code can end up being by failing as early as possible.
It was one of the reasons Microsoft went a little XML crazy in the 00s. The promise was the ability to fully validate data from the schema using off-the-shelf tools during build time, and libraries at run time that would point out exactly where things went south.
 
Top Bottom
1 2