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

521–530 of 598 posts

Re: Pkl, a Programming Language for Configuration

#521

Post by HardlyMatters »

ahefner wrote: post #151
randomdata wrote: post #113

Earlier quoted context omitted.

Python is able to load Python code at runtime, so one can use Python for configuration. A solution doesn’t need to go looking for problems that are already solved.

...and yet Python people routinely fail to grasp this and end up writing ad-hoc config language interpreters on top of yaml anyway. Granted the conveniences of Python syntax for code are mostly lost when trying to express tree structured data, and yaml flips that on its head. (Mumble, grumble, something about s-expressions...)

So true. One of the major config mgt utilities which shall remain nameless, (cough, Ansible, cough), is written in python but created an excrable POS config language build on YAML. At least Ant had the excuse that Java was not suitable for a config language. Will people never learn that building scripting languages on markup languages will inevitably end in tears?

Re: Pkl, a Programming Language for Configuration

#523

Post by HardlyMatters »

networked wrote: post #255
baq wrote: post #184

Earlier quoted context omitted.

That’s because it’s impossible to properly sandbox the config parsing. It’s also a horrible experience to debug configs. But it’s still better than templating yaml.

People interested in configuring Python software in Python should look into Starlark. There are Python bindings for two versions of Starlark: Go ( https://github.com/caketop/python-starlark-go ) and Rust ( https://github.com/inducer/starlark-pyo3 ). I used python-starlark-go for a time in a project that ran on x86-64 Linux and had no problems with it. (I stopped because my project's configuration turned out simpler t…

Looks very interesting. Thanks for the pointer.

Re: Pkl, a Programming Language for Configuration

#524

Post by bsdpufferfish »

koromak wrote: post #512
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…

40 years ago I wrote Assembly that ran directly on the CPU. You could modify the registers directly. Then these crazy people came along and made a compiled language? And it outputs... Assembly? I'm sorry, but a huge chunk of todays "developers" really are in the business of creating problems.

except when you moved to C there was no corresponding increase in fixed time which you must spend on tool setup just to program

Re: Pkl, a Programming Language for Configuration

#525

Post by bsdpufferfish »

flexagoon wrote: post #508
pard68 wrote: post #98

Earlier quoted context omitted.

LSPs in vscode suck

Can you elaborate please? VSCode is literally the reason why LSP even exists

They turn your IDE into a distributed system with parsing and serializing overhead for every action.

Re: Pkl, a Programming Language for Configuration

#526

Post by jhardy54 »

bsdpufferfish wrote: post #524
koromak wrote: post #512

Earlier quoted context omitted.

40 years ago I wrote Assembly that ran directly on the CPU. You could modify the registers directly. Then these crazy people came along and made a compiled language? And it outputs... Assembly? I'm sorry, but a huge chunk of todays "developers" really are in the business of creating problems.

except when you moved to C there was no corresponding increase in fixed time which you must spend on tool setup just to program

Yeah, it’s really great that compiling C is a straightforward endeavor that doesn’t require any tools, and definitely doesn’t depend on executables that generate or parse configuration files. I’m confident that no C developers have ever spent time on tool setup just to program.

Re: Pkl, a Programming Language for Configuration

#527

Post by bsdpufferfish »

jhardy54 wrote: post #526
bsdpufferfish wrote: post #524

Earlier quoted context omitted.

except when you moved to C there was no corresponding increase in fixed time which you must spend on tool setup just to program

Yeah, it’s really great that compiling C is a straightforward endeavor that doesn’t require any tools, and definitely doesn’t depend on executables that generate or parse configuration files. I’m confident that no C developers have ever spent time on tool setup just to program.

gcc main.c

Of course tinkerers made some tools you can tinker with as time went on, but you don’t have to let those interfere with velocity, just like I will not be using configuration languages.

Re: Pkl, a Programming Language for Configuration

#528

Post by mirekrusin »

cqqxo4zV46cp wrote: post #105
mirekrusin wrote: post #40

So like cue [0] but more primitive, less principled and in java? [0] https://cuelang.org

Yes. I am sure it’s that simple. I’m sure that there are all downsides and no upsides. This is the first time in history where one technology is a strict superset of a competing technology, from all perspectives. /s I really don’t know why this snark is necessary.

Primitive and less principled doesn't imply "downsides". Go is more primitive and less principled than Haskell, yet it's useful and oftentimes better due to its primitiveness. Cue is written in Go for example.

Re: Pkl, a Programming Language for Configuration

#529

Post by lolinder »

dieortin wrote: post #487
lolinder wrote: post #362

Earlier quoted context omitted.

Step two of installing Copybara is to install Bazel [0], so that doesn't exactly contradict my claim that if you're not already using Bazel you probably won't use Starlark. [0] https://github.com/google/copybara

Bazel is just the build system used to build Copybara. You don’t need to have Bazel in your system to use an already built copy of Copybara

Yes, but:

> Copybara doesn't have a release process yet, so you need to compile from HEAD.

Looks like there's an Arch Linux build maintained by... somebody, but if you're not on Arch then you're going to be building Copybara with Bazel. That this works for them suggests to me that their community has a significant amount of overlap with the Bazel community, so it's not good evidence of Starlark being used outside of the Bazel world.

Re: Pkl, a Programming Language for Configuration

#530

Post by flexagoon »

bsdpufferfish wrote: post #525
flexagoon wrote: post #508

Earlier quoted context omitted.

Can you elaborate please? VSCode is literally the reason why LSP even exists

They turn your IDE into a distributed system with parsing and serializing overhead for every action.

Isn't that true for any editor with LSP support though, not just VSCode? And I personally consider that to be much better than the alternative solution of re-writing parts of the compiler to a different language to integrate them into the editor directly, like JetBrains does.
Post reply on HN