Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pkl, a Programming Language for Configuration

pkl-lang.org

Post reply on HN
Print view View original

421–430 of 598 posts

Re: Pkl, a Programming Language for Configuration

#421

Post by mixmastamyk »

ivlad wrote: post #416
Fischgericht wrote: post #411

Earlier quoted context omitted.

ONE actual standard that everyone uses would be fine. For non-tree (nested) configurations, an ini file would do. It's a standard that worked well in 1990, and still does today. For nested data, it doesn't matter to me if it's JSON, YAML, TOML or whatever. Just agree on ONE format. TOML also is a good example of "creating problems instead of solutions": They deliberately (!) broke compatibility to the INI format due…

> TOML also is a good example of "creating problems instead of solutions": They deliberately (!) broke compatibility to the INI format due to "I can't stand unquoted strings". Yeah, emotional feelings about CONFIG FILE FORMATS. INI is hard to parse because without quotes the parser would not know whether it’s a “True” as a string or True as Boolean value. Formal parser that can be included into a program as a library…

Schemas are often better than syntax typing. In other words the program decides what the type is, not the file.

Re: Pkl, a Programming Language for Configuration

#422

Post by cqqxo4zV46cp »

Fischgericht wrote: post #411
afavour wrote: post #405

Earlier quoted context omitted.

That strikes me as a very uncurious perspective. There’s absolutely nothing that could be improved about configuration files? An 87MB binary feels like a very arbitrary measure of worthiness.

ONE actual standard that everyone uses would be fine. For non-tree (nested) configurations, an ini file would do. It's a standard that worked well in 1990, and still does today. For nested data, it doesn't matter to me if it's JSON, YAML, TOML or whatever. Just agree on ONE format. TOML also is a good example of "creating problems instead of solutions": They deliberately (!) broke compatibility to the INI format due…

It’s pretty clear that you are putting “things that I [think I] understand above things that are better. Have you ever written an ini parser? If you have, I doubt it was good, because none of them are, because ini is a flawed format.

Re: Pkl, a Programming Language for Configuration

#423

Post by mixmastamyk »

cqqxo4zV46cp wrote: post #422
Fischgericht wrote: post #411

Earlier quoted context omitted.

ONE actual standard that everyone uses would be fine. For non-tree (nested) configurations, an ini file would do. It's a standard that worked well in 1990, and still does today. For nested data, it doesn't matter to me if it's JSON, YAML, TOML or whatever. Just agree on ONE format. TOML also is a good example of "creating problems instead of solutions": They deliberately (!) broke compatibility to the INI format due…

It’s pretty clear that you are putting “things that I [think I] understand above things that are better. Have you ever written an ini parser? If you have, I doubt it was good, because none of them are, because ini is a flawed format.

The Python parser has worked well for decades.

Re: Pkl, a Programming Language for Configuration

#424

Post by Fischgericht »

cqqxo4zV46cp wrote: post #422
Fischgericht wrote: post #411

Earlier quoted context omitted.

ONE actual standard that everyone uses would be fine. For non-tree (nested) configurations, an ini file would do. It's a standard that worked well in 1990, and still does today. For nested data, it doesn't matter to me if it's JSON, YAML, TOML or whatever. Just agree on ONE format. TOML also is a good example of "creating problems instead of solutions": They deliberately (!) broke compatibility to the INI format due…

It’s pretty clear that you are putting “things that I [think I] understand above things that are better. Have you ever written an ini parser? If you have, I doubt it was good, because none of them are, because ini is a flawed format.

No, I am a Pascal guy. Turbo Pascal had an INI parser, Delphi has one, FreePascal has one, and they all work flawlessly.

From what I see, 20+ years proven parsers are available for pretty much any language there is.

And yes, the format is a bit flawed. But it gets the job done.

Re: Pkl, a Programming Language for Configuration

#425

Post by Fischgericht »

ivlad wrote: post #416
Fischgericht wrote: post #411

Earlier quoted context omitted.

ONE actual standard that everyone uses would be fine. For non-tree (nested) configurations, an ini file would do. It's a standard that worked well in 1990, and still does today. For nested data, it doesn't matter to me if it's JSON, YAML, TOML or whatever. Just agree on ONE format. TOML also is a good example of "creating problems instead of solutions": They deliberately (!) broke compatibility to the INI format due…

> TOML also is a good example of "creating problems instead of solutions": They deliberately (!) broke compatibility to the INI format due to "I can't stand unquoted strings". Yeah, emotional feelings about CONFIG FILE FORMATS. INI is hard to parse because without quotes the parser would not know whether it’s a “True” as a string or True as Boolean value. Formal parser that can be included into a program as a library…

Yes, agreed. On the other hand, there are quite a few people using Javascript, a language where this distinction also isn't really done in a clean way.

If you would de-serialize an ini-file into Objects in memory you would typically have meta-data about your object (RTTI/Reflection for compiled languages, given for scripting languages).

But yes, INI isn't without flaws. Parsers typically will need to accept everything from "true", "True", True, true, 1, "1" for boolean fields.

Re: Pkl, a Programming Language for Configuration

#426

Post by Fischgericht »

cqqxo4zV46cp wrote: post #420
Fischgericht wrote: post #413

Earlier quoted context omitted.

Creating complex layers upon layers just to "solve" a very simple problem is not innovation. It's shittification.

Misappropriating a trendy word to use as a descriptor for anything you don’t like. This is how someone speaks immediately before taking a look in the mirror and realising that they sound like their parents. You are not the be-all end-all and your drive-by analysis of a technology is going to be biased by its suitability for what you do day-to-day. No amount of experience justifies your attitude.

I am sorry if the wording of my opinion has offended you.

My parents most likely would have complained that they'd need 58 floppy disks to run this programming language. :)

Re: Pkl, a Programming Language for Configuration

#427

Post by crabique »

filleokus wrote: post #307
jaseemabid wrote: post #7

Pkl was one of the best internal tools at Apple, and it’s so good to see it finally getting open sourced. 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. Would gladly recommend this to anyone and I’m ex…

Was about to ask if you had k8s api models available internally, and that someone should create some tool to generate that from the spec. But turns out it already exists in the open! https://github.com/apple/pkl-k8s-examples

Why yes, I would like to see more of those in my k8s, so glad we finally have the technology

https://github.com/apple/pkl-k8s-examples/blob/96ba7d415a85c...

Re: Pkl, a Programming Language for Configuration

#428

Post by n42 »

Fischgericht wrote: post #413
n42 wrote: post #406

Earlier quoted context omitted.

Yes, the windows registry, the peak of our craft. No need to innovate, this one’s solved, wrap it up and move on Try taking more time to consider the problems you don’t have that others do, instead of writing anything off that doesn’t make sense to you (and simultaneously gatekeeping an entire industry)

Creating complex layers upon layers just to "solve" a very simple problem is not innovation. It's shittification.

If your configurations are simple, you don’t need this. If they are not, you might.

Because you have not run into the problems this has addressed in your career, does not mean that you know better than Apple how to solve them. In fact, it means like you are uniquely unqualified to solve them. Acting like you are in a severely condescending dismissal of the engineers who worked on this makes for boring conversation.

Re: Pkl, a Programming Language for Configuration

#429

Post by flir »

n42 wrote: post #428
Fischgericht wrote: post #413

Earlier quoted context omitted.

Creating complex layers upon layers just to "solve" a very simple problem is not innovation. It's shittification.

If your configurations are simple, you don’t need this. If they are not, you might. Because you have not run into the problems this has addressed in your career, does not mean that you know better than Apple how to solve them. In fact, it means like you are uniquely unqualified to solve them. Acting like you are in a severely condescending dismissal of the engineers who worked on this makes for boring conversation.

Maybe give us an example?

It's an interesting question - just how complex are our biggest configuration problems today?

Re: Pkl, a Programming Language for Configuration

#430

Post by jayd16 »

Fischgericht wrote: post #401

25 years ago pretty much every program had a GUI to do the configuration. With help texts. On Windows, programs then either saved stuff into an ini file or the windows registry, both you could also edit manually. Today we have a programming language coming as a 87 MB binary to create config files. And to run that programming language you need to manually crate a ... config file. So what we are missing now is a 500GB…

> manually crate a ... config file.

Wouldn't you want to self host the config?

Post reply on HN