Pkl, a Programming Language for Configuration • Hacker News Board

Re: Pkl, a Programming Language for Configuration

#551

Post by grashalm » Mon, Feb 05, 2024, 8:37 AM UTC

Hixon10 wrote: post #541

grashalm wrote: post #79

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

Do you know, why they use both ANTLR and Truffle?

Truffle has no opinion on how you parse the sources. It cares about how you execute them from an intermediate Truffle guided representation produced by the parser.

In other words antlr and truffle are a great fit. We even use this pairing for our example language simplelanguage.

https://github.com/graalvm/simplelanguage

Re: Pkl, a Programming Language for Configuration

#552

Post by hot_gril » Mon, Feb 05, 2024, 8:56 AM UTC

Fischgericht wrote: post #418

ivlad wrote: post #414

Earlier quoted context omitted.

25 years ago admin would be responsible for one server, that they would setup and then never touch until (and sometimes after) someone hacked it. Now people are responsible for thousands of containers, and GUI simply does not scale. And the configuration of those containers is domain-specific and/or varies enough so that you cannot write a single config file and copy it over. This is why configuration management syst…

Oh yes, people DO develop stuff that is not needed. Back in the 90ies pretty much every nerd sooner or later had to write his own programming language (myself included). The difference between then and today: We did throw it away afterwards. These days every week someone spews out a new "programming language", claiming that the re-invented wheel is so much more round than the others. If fully agree that you might nee…

I'm surprised there's no widely-adopted library for general-purpose languages that handles user-friendly object input and outputs static config (perhaps in JSON) for machines to read. Instead, there are several DSLs that act as dynamic config, and even some that generate dynamic config, or something in the middle like k8s YAMLs.

Have I just not thought hard enough about this problem yet, and a DSL is really needed for it? Or should I go write that lib?

Re: Pkl, a Programming Language for Configuration

#553

Post by hot_gril » Mon, Feb 05, 2024, 9:03 AM UTC

__MatrixMan__ wrote: post #446

Fischgericht wrote: post #418

Earlier quoted context omitted.

Oh yes, people DO develop stuff that is not needed. Back in the 90ies pretty much every nerd sooner or later had to write his own programming language (myself included). The difference between then and today: We did throw it away afterwards. These days every week someone spews out a new "programming language", claiming that the re-invented wheel is so much more round than the others. If fully agree that you might nee…

I stopped using sed because it behaved differently on my coworker's machine than it did on mine.

Same, actually a lot of the listed things are too old-school for me.

Re: Pkl, a Programming Language for Configuration

#554

Post by hot_gril » Mon, Feb 05, 2024, 9:09 AM UTC

mekster wrote: post #457

jwoq9118 wrote: post #337

Earlier quoted context omitted.

Agreed. If we're getting the point where you're saying "it's like writing your configuration in [insert Domain Specific Language Here]" then I'd prefer to simply use that language. I understand the point Pkl is making in that "configuration won't work across DSLs so here's one language for all of them" but I don't know that that's enough motivation for people to adopt it. However, I haven't built anything cool like t…

At one time I just gave up on using any config formats and instead went back to the good old simple "use the programming language as the config file too" approach. It's certainly not cross language capable but when your editor knows exactly what's there and what's not with auto completion from the config file, that was a superior experience than caring about cross language issues that may not even be a problem depend…

Yep, I've always got a config.js. But that's a luxury compiled languages won't have.

Re: Pkl, a Programming Language for Configuration

#555

Post by hot_gril » Mon, Feb 05, 2024, 9:09 AM UTC

flexagoon wrote: post #506

rockwotj wrote: post #282

Earlier quoted context omitted.

Ah just give me typescript, I do not need to learn a new thing for configuration languages and at the end of the day the output is compatible with JSON. Typescript has all the stuff I would want: types, first class json support, an ecosystem of libraries (if you want it, I would probably not for config generation). And the tooling is amazing. Does pkl have LSP, syntax highlighting in every editor, debugger or repl?

> Ah just give me typescript, I do not need to learn a new thing for configuration languages People who don't know Typescript will still have to learn a new thing in that case, so there isn't really any reason to pick TS over any other existing language > syntax highlighting in every editor There is a tree-sitter parser for pkl, so it'll work anywhere where tree-sitter works. And for VSCode and JetBrains stuff, they…

More people know TS (or JS, close enough) than Pkl, it can be used for more, and it's got better tooling/support. Those are understatements.

Re: Pkl, a Programming Language for Configuration

#556

Post by MrBuddyCasino » Mon, Feb 05, 2024, 9:59 AM UTC

asimpletune wrote: post #515

Let us review the progress we've had so far in this area * XML has the advantage of being almost perfect except its too verbose and isn't JSON * JSON has the advantage of being JSON, but is strangely broken at even basic stuff (i.e. comments, no trailing commas) * TOML has the advantage of being "better JSON", for people who like rust, but it is still too limited for a lot of scenarios * YAML is not as limited, but i…

^ This is really the only required comment in this whole thread.

Re: Pkl, a Programming Language for Configuration

#557

Post by konstante » Mon, Feb 05, 2024, 10:45 AM UTC

krajzeg wrote: post #109

grashalm wrote: post #79

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

> ...GraalVM Truffle framework... Futurama Projections... I know it's partly on me for not knowing the domain, but I honestly suspected somebody is trying to make fun of me with some concentrated technobabble. Especially since I wouldn't expect the topic (configuration languages) to require complex mathematical machinery to work with. Now I have something interesting to dig into.

>...suspected somebody is trying to make fun of me...

I think that too, "Futamura projections" are important but they are very very far from "complex mathematical machinery" as you may hear it. They are indeed very simple (even mathematically trivial) and require no special background to understand.

Re: Pkl, a Programming Language for Configuration

#558

Post by Hixon10 » Mon, Feb 05, 2024, 11:06 AM UTC

grashalm wrote: post #551

Hixon10 wrote: post #541

Earlier quoted context omitted.

Do you know, why they use both ANTLR and Truffle?

Truffle has no opinion on how you parse the sources. It cares about how you execute them from an intermediate Truffle guided representation produced by the parser. In other words antlr and truffle are a great fit. We even use this pairing for our example language simplelanguage. https://github.com/graalvm/simplelanguage

Thanks! I haven't seen before usage of Truffle and ANTLR together, but it makes sense.

Re: Pkl, a Programming Language for Configuration

#559

Post by mieubrisse » Mon, Feb 05, 2024, 12:14 PM UTC

ivlad wrote: post #414

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…

25 years ago admin would be responsible for one server, that they would setup and then never touch until (and sometimes after) someone hacked it. Now people are responsible for thousands of containers, and GUI simply does not scale. And the configuration of those containers is domain-specific and/or varies enough so that you cannot write a single config file and copy it over. This is why configuration management syst…

100%. Containers are essentially language-agnostic software libraries, and the config we write for them is analogous to the wiring we'd normally do in a to wire libraries together. Yet, our current tools aren't adapted to write and distribute the "programs" formed from gluing them together.

(Mostly-shameless plug, this is what we're trying to solve with Kurtosis: https://github.com/kurtosis-tech/kurtosis )

Re: Pkl, a Programming Language for Configuration

#560

Post by bborud » Mon, Feb 05, 2024, 12:17 PM UTC

n42 wrote: post #406

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…

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)

Pointing out that a proposed solution to a problem creates more problems is not the same as saying the original problem doesn't exist or isn't worth solving. Nor does it imply that some random other solution is better.