Live data from Hacker News

Hyprland 0.55 announced the switch to Lua for its config files

hypr.land

91–100 of 146 posts

Re: Hyprland 0.55 announced the switch to Lua for its config files

#91
post #58

It's just part of what I call the config pendulum. 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.…

Emacs seems to do a pretty good job handling this with the "Customize" interface. Presents a bunch of variables the user is intended to customise in something resembling a familiar interface, then it inserts the values into the Elisp init file. Someone could use and customise Emacs for years and never really touch Elisp directly. But then, oh, those text fields actually take lists, which in Emacs Lisp is the same as taking code. Maybe you use that for a while until you get comfortable and wanna try modifying something not surfaced in "customize", where you can discover init.el, etc. Etc. It's not perfect, but to me it's really close, it's the model of progression I wish all UIs for customisation used, personally.

Re: Hyprland 0.55 announced the switch to Lua for its config files

#92
post #89
post #6

I have grown pretty negative opinions of “using a programming language as a config language” after semi-recently having to spend a lot of time screwing around with someone’s Gradle Groovy abomination. Not even to mention how quickly Nix can get annoying. 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 complicat…

> I have to ask…why do people want a Turing complete language to configure stuff? 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…

I think having good plugin support is a better way to do it. Keep the most obvious configuration options behind a "dumb" config language like JSON or something, but create a framework to add functionality via a plugin API.

Re: Hyprland 0.55 announced the switch to Lua for its config files

#94
post #58

It's just part of what I call the config pendulum. 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.…

That's clever insight. If it was lisp from the beginning, maybe would be more straightforward. It's as simple as code can get, according to Uncle Bob, while still being expressive. It's no wonder Emacs still reigns supreme. Well, I am happy with Niri's kdl approach for the time being.

It can be Lisp if you want it to be. Just use Fennel. That's what my Hyprland config is written in.

Re: Hyprland 0.55 announced the switch to Lua for its config files

#95
post #11
post #6

I have grown pretty negative opinions of “using a programming language as a config language” after semi-recently having to spend a lot of time screwing around with someone’s Gradle Groovy abomination. Not even to mention how quickly Nix can get annoying. 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 complicat…

So you don't like using programming languages as config languages, so you: 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…

> 2. ... and when that inevitably fails, you... use a programming language?

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.

Re: Hyprland 0.55 announced the switch to Lua for its config files

#96
post #11
post #6

I have grown pretty negative opinions of “using a programming language as a config language” after semi-recently having to spend a lot of time screwing around with someone’s Gradle Groovy abomination. Not even to mention how quickly Nix can get annoying. 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 complicat…

So you don't like using programming languages as config languages, so you: 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…

Those aren't the only two options. There are non-Turing complete config languages like Cue, Dhall, and Jsonnet that are designed to complete and be consistent. They work well when did to generate static config from some dynamic input generated by regular program.

Re: Hyprland 0.55 announced the switch to Lua for its config files

#97
post #6

I have grown pretty negative opinions of “using a programming language as a config language” after semi-recently having to spend a lot of time screwing around with someone’s Gradle Groovy abomination. Not even to mention how quickly Nix can get annoying. 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 complicat…

If you look at hyprland config, you can see why they went with it. 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 wo…

It looks like the previous hyprland config language was already getting close to being Turing complete;

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.

Re: Hyprland 0.55 announced the switch to Lua for its config files

#98

Earlier quoted context omitted.

That's clever insight. If it was lisp from the beginning, maybe would be more straightforward. It's as simple as code can get, according to Uncle Bob, while still being expressive. It's no wonder Emacs still reigns supreme. Well, I am happy with Niri's kdl approach for the time being.

It can be Lisp if you want it to be. Just use Fennel. That's what my Hyprland config is written in.

I saw an interview with one of the main contributors for Neovim and they use fennel for everything. All roads lead to Lisp

Re: Hyprland 0.55 announced the switch to Lua for its config files

#99
post #58

It's just part of what I call the config pendulum. 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.…

I like to have a simple config AND a real scripting language. That way, the UX for changing "simple" things remains straightforward (you can even add a config editor panel), while for less simple things you can use a real programming language (reducing pressure from the "simple" config to turn into a DSL).
Post reply on HN