FR version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
67% Positive
Analyzed from 4759 words in the discussion.
Trending Topics
#config#language#configuration#lua#programming#turing#more#complete#things#toml
Discussion (113 Comments)Read Original on HackerNews
Simple config -> (Need to do more complicated things) -> Add override levels -> (Need even more flexibility) -> Add a Turing complete language -> (Things get ridiculous, lots of spaghetti code outside of version control. Time for a reset) -> goto "Simple config"
It's fine. I am not saying it's wrong or right. I've gone through the cycle a few times in some projects. On the other hand, think of it as your project is lucky to be used long enough to have these problems. To feel better about it think of it as a spiral. The next "Simple config" is a slightly better version of the first.
I like your spiral metaphor though, since you learn some things along the way.
I am sure there are other projects picking up json from a previous xml + xpath + other ...xml junk.
I would disagree on that one. Ninja config might not be turing complete, but they're generated by turing-complete tools (usually cmake). Nobody writes ninja by hand, thus I would argue it's irrelevant!
That's because setup.py was objectively a mistake. In order to know how to run the package you need to know its dependencies, which requires evaluating setup.py, but you cannot evaluate setup.py until you know the dependencies, which requires you to evaluate setup.py, and so on. The pyproject.toml is plain text where you specify the build backend and its options, and the build system can be as complex of a program as need by.
If anything, pyproject.toml is an example of taking the idea of programmable configuration to its next conclusion. The build system is part of the configuration and it's more than a simple script, it's an entire application. You just plug in its name into the universal entry point pyproject.toml.
Granted, it's a "simpler" config syntax, but the total system complexity has not decreased.
I have to ask…why do people want a Turing complete language to configure stuff? I use Sway personally, which is very configurable but for any even remotely complicated logic I shell out to a set of Rust programs.
Much like vim/neovim config, people want to do things like register a callback that fires to determine the window title and things that are much more advanced than that, like layout management.
When I was using sway, I was using its IPC or worse (https://github.com/johnae/persway) to do advanced things, and Lua scripting in the first class config would have been a much better UX.
Already has variable substitution and math, it seems to falls short of Turing completeness only because I don't see any form of recursion. But recursion is something it could accidentally gain if someone decided to add templating to the language.
Besides, looks the config files can call out to external executables, which absolutely are Turing complete. And moving to lua might actually simplify configs by allowing more things to be done inside the config system, rather than calling out.
I never found that Sway too annoying to just use the shell commands to grab/modify the current state of Sway (https://github.com/tombert/rs-swanbar) and just use a "real" programming language to actually do any kind of programming logic. To each their own!
1. Use a declarative-style format for config, which is fine, I guess; 2. ... and when that inevitably fails, you... use a programming language?
Some people -- not all, but some -- may prefer to skip the first step and go straight for the second option. Particularly if it's a complex thing indeed like a build system and not, y'know, configuring your blog.
The problem is shitty config languages. I wouldn't group xaml in the same category as dhall for example.
Now it's all a single simple lua function and 3x as fast... I think this change is great.
Maybe it fails because you are trying to solve a problem with a configuration when it should be solved by a function implemented in the program you are trying to use.
This assumption is doing a lot of work. Surely the question was precisely why it would fail?
The absolute moment you find yourself thinking of putting conditional logic, or string substitution, or anything like that, in your pure config format, switch to a real programming language, before you end up managing several times the complexity of one with only some of the benefits. No need to end up contemplating some sort of for-loop macro with another key referencing the loop variable, when you can just have a for loop.
I find TOML, in addition to being very readable, to be great at automatically restricting config complexity by making nested lists of tables miserable. If your config sucks at being TOML, it should be JS or Python. (Not a fan of Lua.)
That’s where you add a plugin system or an ipc mechanism, not a whole programming language.
Lots of people start out with a non-programmable config format. But, as their situation becomes more complicated, they end up shoehorning in programmable-ish features until they realize they are running straight into https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule and decide to do it properly.
I guess I just feel like if you feel like you need programming constructs in your configuration, its approaching it from the wrong angle, and it should instead be handled via plugins.
I feel like configuration itself should be a "dumb" format like JSON, and when you want to do anything that can't be accomplished by plain JSON, you should allow for easy development of plugins.
Like comments? ;)
- For personal application config (window manager, shell, text editor, etc), I find I often want to have site-specific configuration, but I also want identical configuration files at every workstation. My laptop probably needs slightly different keybindings than my desktop, my $PATH and text editor needs to be configured a bit differently for work than for personal use, etc. When the configuration is done with a real programming language, this is always straightforward, when it's done via a json/yml/toml file, it's usually a huge pain in the ass.
- You want templating for your configuration, to improve readability, reduce typos and configuration drift, &c, but if you give programmers an inch with any sort of templating system, they will eventually take a mile and figure out how to smuggle Turing-completeness (or, at least, for-loops and variable binding and probably closures) into their configs. If you have a real programming language, this is fine, because the programming language was designed to make loops and conditionals and function calls readable, and probably has decent tooling to boot, but if they're doing it with, say, Mustache-templated YAML, you will have an unreadable mess that is extremely unpleasant to work with.
Still, its a valid design choice with different design decisions compared to sway. But that's the point you get to choose.
Hyprland is much more "build your workspace with legos" so having a full lang like lua makes sense to properly integrate the various pieces.
At a certain point it becomes incredibly tempting to just give up on playing whack-a-mole and let the most demanding users do it themselves using a proper programming language.
I think I've found balance by using a Python daemon as a "companion" for my i3 configuration. It listens and react to event. It enhances the configuration, so when it's broken, it's not a big deal. And the interface exposed by i3 is smaller, so less risk of breakage. https://vincent.bernat.ch/en/blog/2021-i3-window-manager#i3-...
I don't understand this either. IMO, the current SOTA tool for configuration is CUE, because it is the only one that lets you write schemas for arbitrary refinements. I haven't used it myself, but my understanding is that everybody should be writing configurations in something like this instead of YAML, TOML, HCL, or a custom DSL with no tooling. And yes, definitely not in a Turing complete programing language.
I CANNOT imagine what horrors it would be to do it all with helm or templating.
the current state of the art tool for configuration is CUE (https://cuelang.org/). FTFY. Gotta love these acronyms.
What's the alternative? Petition the maintainer to add every little feature any random user might want? Or just do it yourself in a few lines of code?
Case in point, when I was still using BSPWM I did no like how if there was only one window on the desktop it would still get an outline. So I wrote 14 lines of Awk (BSPWM lets you use any language) to get what I want. This was only possible because BSPWM gives me all the primitive building blocks and lets me go wild with them. Sure, if all you want to do is set a few colors and numbers that's overkill, but any power user will sooner or later find himself thinking "oh, if only I could do X when Y unless Z".
Personally I have grown a bit frustrated with Lua as a language, but at the same time can see why it would be a good choice for this use case.
At least in this case it is an actual programming language instead of XML or YAML like so many of them.
An alternative slightly more charitable interpretation is this is the engine/gamelogic pattern. But the difference between the two is more subtle than it naively appears depending largely on proper layer segmentation.
Turing complete configuration languages suck and makes everything slow, janky and difficult to reason about.
The intersection of INI and TOML would be perfect.
If you don't like certain things, just don't use them in your configs (i.e. tables)
Not from TOML, just from my config language. TOML has other applications that require its complexity.
I'd still keep simple INI style sections in my config lang, but they wouldn't have deeper meaning apart from grouping.
Past experience has shown what while Turing complete config is powerful, it is also a double edged sword and I would be wary of using it.
Same here. I like the openbsd approach of small DSL (pf, doas) or just simple ini-like key-value config (sysctl, rc.conf). If you want more, just patch the software and be done with it.
A programming language is OK if the intent is to build a platform (Emacs, Vim) but for something that is purely an application software, it's very much not necessary.
because it lets me configure programmatically. Practical recent example, I use Wezterm which uses Lua as a config language but I tried out Ghostty and because I use all operating systems regularly I have a lot of 'if this then that' in my Wezterm config, different default shell, different key bindings etc. With Ghostty my only option is to maintain different config files per machine.
And what's worth pointing out is that Ghostty does have an operator for this('?' I think) which means there's already a bit of programming in it, except what always happens is that software with declarative config files invent their own scripting an templating languages as more and more people demand it, so just give me lua or lisp from the beginning and we're good.
This turns out to be a benefit IMO.
Ghostty supports include files. You can have all of your shared config in 1 main config and then have small files that are included which are machine specific. My dotfiles uses it and it supports Linux and macOS. Example: https://github.com/nickjj/dotfriedrice/blob/master/.config/g...
You can have something like this in your Ghostty config: config-file = ?config.local
And then on each machine that's different, you can have your machine specific config in ~/.config/ghostty/config.local or whatever you decide to name the file.
It works out nicely because config options are merged, so the local file can overwrite what's in the main config. This lets you deviate from the original git committed config without needing to modify it. Super handy for public dotfiles.
I was pretty happy the day I could move some Jenkins jobs to a Groovy script. I've worked with HCL significantly, but once I learned the idiosyncrasies of Pulumi, scripting infrastructure via a programming language was a better experience (good IDE autocomplete simplified things), though it requires more discipline.
Even without working with the Nix scripting language I'll dismiss it. When I looked at it was some kind of bastardisation of Bash with Haskell ideas. A hobby project idea at best, yet forced upon all Nix users. Guile Scheme is a nice small language, and Guix uses that, and I think that is a better approach.
Nix doesn't have much in common with Haskell.
Nix is a really small language, and you can learn pretty much all of it in a few minutes: https://nixcloud.io/tour/?id=introduction/nix
This is what happens when software is created by too-smart teenagers, that change their mind as fast as they improve at programming, and expect that everyone is spending 12 hours a day configuring their desktop environment while hanging out in ‘ricing’ discords (“what do you mean you have a day job?”)
Worse, if you dare criticize it, the fanboys come out of the woodwork saying you should really just use an LLM to convert to Lua and that you are dumb trying to do it manually. The hubris is untenable.
After 3 or 4 breaking changes over the years, I decided I’d rather use some other desktop environment honestly, until the core team literally grows up. Niri is great, and its author is much more… mature.
My first hyprland experience was with ML4W (nothing against the guy) but as soon as you download it you get 10 config errors and you don't know where to begin. I took the same philosophy as arch, I install only what I understand, and this way my config grew over time, my games where spawning in 2nd monitor? I look up manual and fix it, etc..
it gives "rewrite it in rust" vibes in the way they rush in to re-do everything without understanding why things were the way they were or if, in fact, anyone was using that obscure feature. maybe they'll sort it all out in time; maybe not. wish they could at least take less of a "we don't care if we break your shit" attitude in the meantime.
/rant
It uses KDL (an established document / config language) and slightly extends it to add useful things like being able to include files.
For example, here's mine: https://github.com/nickjj/dotfriedrice/blob/master/.config/n...
What you end up with is a config file that's natural to read with no prior knowledge about anything and if you want to look something specific up, you know it's officially documented and not some home grown pattern someone created. There's a certain amount of comfort and stability you get with a "what you see is what you get" approach.
I never felt like I needed variables, conditions, functions or loops with niri's config.
In this same space, https://codeberg.org/emersion/scfg/ is pretty widely used. The curious thing about scfg is that it's not really a "new" format: the syntax described has been in use by different tools for decades. They just didn't call it scfg, and it's mostly the name itself that's new.
Seems like hyprland is on C++ so maybe not a direct use case but thought Lua people in general might be interested.
[1] https://github.com/ianm199/omnilua
Thinking I'll wait as long as I can and then just get an LLM to translate current config to lua once the internet has been seeded a bit with examples
I wish we wouldn't keep going back to it. I understand the appeal for some use cases, but pleeeeeeease can we just move on to a new language that fulfills the same use cases but with more typical conventions?
Closest thing I've seen so far is Roto: https://roto.docs.nlnetlabs.nl/en/stable/index.html
Basically everything about this looks great - Rust-style syntax, static type checking, sane type system, easily embedded. The only slightly odd things are that it has built in types for IP addresses, AS numbers, and `filtermap`. But I guess you can just ignore those if you don't need them.
Not odd to have those data types at all…
This works for dwm because it compiles in two seconds and has minimal dependencies. I don’t know about hyprland.
https://dwm.suckless.org/customisation/
Pontification added later: And it has a beneficial side-effect. I’m not much of a C programmer these days (if I ever was), but I found I was able to understand the dwm code well enough to make some small changes in behavior. So the dwm approach encouraged me to go beyond changing definitions in the headers. (This is aside from 3rd party patches. I was even able to contribute one of those.) This is really in the spirit of free software.