[stelonix]

You're completely right and I thought this would be obvious. I never prompted anything remotely closely to "make a facebook clone". Instead, I make an explanation of how it should work. To give you an example:

  I need a python script that
  
  1) reads /etc/hosts
  2) find values of specific configured hosts (read from a .conf which) eg server1, localhost, etc
  3) it'll assign a name to those configs eg if the .conf has
  
  [Env1]
  192.168.0.1 production-read
  192.168.0.2 production-write
  192.168.0.27 amqp
  
  [Env2]
  192.168.0.101 production-read
  192.168.0.201 production-write
  192.168.1.127 amqp
  
  Basically format:
  
  [CONFIG_NAME]
  <ip> <hostname>
  
  Like an usual hosts file
  
  4) And each of those will be stored in memory
  5) if in /etc/hosts it matches one of those, it sets the "current env" as the configname
  
  5) It'll create an icon on the top-right of ubuntu 22 default gnome with
  6) that icon could be the text of the current config name or if nothing matches, "custom" text would show
  7) When the user clicks the "tray"/appindicator(or whatever gnome is calling them) it'll list the config names in a   simple gtk/gnome
  8) When the user clicks one config, we create a backup of /etc/hosts in ~/.config/backups/ named   hosts-%UNIX_TIMESTAMP%
  9) we then apply it to hosts file (find only the line with the hostnames to change and modify only those)

And that one-shotted a simple gnome app indicator env switcher. Had to fix a few lines here and there but it mostly just worked. If you give the proper spec to the LLM, it'll do it right. You can even fake a DSL to describe what you want and it'll figure it out.

[Mossy9]

Juxt's Allium https://juxt.github.io/allium/ is an interesting entry in this 'pseudo DSL' space to define and store system specifications and requirements. I think it's likely that this sort of 'persistent specifications to help bots work correctly' will be a good approach when things finally cool down a bit.

[skydhash]

That's the kind of stuff where you would write a few lines of shell script or perl and not bother with the whole GTK stuff. Because GTK would be accidental complexity to the task (unless you used something like zenity).

This is one of the reasons I like the OpenBSD and suckless projects. There are solutions that are technically correct, but are overengineered.

[stelonix]

Well I would never write shell because I loathe it's grammar/syntax. I enjoy GUIs and am a heavy mouse user, so the GTK part isn't really an "accidental complexity" but a must have for me. If a LLM can one-shot all the GTK boilerplate it's a win.

That's (as shown in my sample prompt) one great thing I've been using LLMs for: making GUIs for arcane Linux-based OS/userland settings that I have no interest in doing "sudo gedit yadda yadda" or learning man pages for. It's been 30+ years, we deserve a better desktop experience.

I've used suckless packages in the past, but it feels to me too close the GNOME/Apple way of giving zero settings and having opinionated defaults whose opinions do not ring well for me. I have zero desire to change my shortcuts/hotkeys to something random devs chose based on their past computer experience, mostly unix-based. Muscle memory > *.

[skydhash]

And that’s fine.

I was pointing out that a simpler solution exists. I prefer simple solutions, because I want to test whatever idea I have in real world situation first before I go for a more complete one. Kinda like doodling before committing to do a sketch (or spend weeks doing a painting).

> It's been 30+ years, we deserve a better desktop experience

That desktop experience would need to be like smalltalk (where it’s trivial to modify the gui). The nice power of Unix is having the userland being actually a userland. Meaning you can design a system for your workflow and let the computer take care of that. Current desktop environment doesn’t allows for that kind of flexibility.

Also it’s the nature of unix that makes such basic utilities possible (and building them with raw xlib or tcl is easier than gtk). Imagine doing the same on macOS or Windows where everything is behind an opaque database where some other process fancies itself as its owner.

[Izkata]

There's also a pattern based on the simple solution that used to be more common: One command-line program for updating and querying the current state, and a second GUI one that just acts as a dumb interface for the first one. Even aside from separation-of-concerns purity, there are two more practical benefits: this gives you scriptability (say, automatically choosing an environment on startup) as well as easier support for multiple desktop environments (two different dumb GUI frontends for the actual complexity in the command-line backend, or updating the GUI because of a change in the APIs without worrying about breaking the important logic).

[necovek]

Experience has taught us that the two operating modes are different enough by nature, that you need slightly different APIs for each (look at tools wrapping CLI programs: they generally suck one way or another).

What the industry settled on is building an API (library or service) around the data model and business logic, and then building UIs on top.

When done well, UIs are relatively shallow wrappers around the library, but do allow being creative about the UX too.

[LtWorf]

That's easily more spec than script.

[popcorncowboy]

> You're completely right

I mean, no comment

[Culonavirus]

Lol if you know you know (I'm becoming paranoid... I think... help)