2026-10-25 16:28 UTC
Replies (11)
-
@hendrik@palaver.p3x.de 2026-10-25 16:36
On the other hand a programmer rarely knows exactly what I’m trying to accomplish. Do I want to count the characters in a textfile? Or the words? Do I want to sort the files by size? age? filename? And which of those am I trying to move? What if I want to delete all files older than 30 days which don’t have the word “elephant” in them? I mean sure, you can implement all of that in a very complex program with a very convoluted user interface… Or you do it the Unix way and give me seperate (simple) tools to count, a tool to sort, search text… and a way to connect it to the delete tool.
-
@brainwashed@feddit.org 2026-10-25 17:07
I think the Unix way is a great ideal if you develop composable cli tools, functions or libraries. In each its easier to reason and recombine a thing, that does one specific thing. More complex user problems are then solved by combining multiple simpler components. Lots of modern graphical user interfaces neither think about what the user might want to do, just offering everything, nor prescribe a specific workflow, which just leaves users that have a only a vague idea of what they want to do or a porgram could do, confused. Being more unixy would be great for mobile apps as well. iOS for example has these app shortcuts which expose functionality of an app to be combined with other apps featuers. I think once siri AI takes hold this could be done. I think, however, the monetization realities of most software will always pressure them to do lots of things and lock the user in.
-
@thedeadwalking4242@lemmy.world 2026-10-25 17:16
I think a big portion of the unix philosophy is to be easy for development. Not for consumers or customers. The idea is that it will be easier for developers more complex software and flexible software if the pieces they are working with are well defined.
-
@banana_pie@piefed.zip 2026-10-25 17:18
Unix is dead. Everyone ships RESTful services + web UI. Underlying platform doesn’t make a difference. You could ship it on Windows server and no one would notice.
-
@TrollAccount69@lemmy.ml 2026-10-25 17:30
The Unix way isn’t for people who can’t integrate those tools. Ever been in the drivers seat of an 18 wheeler? Even just getting into one requires more physical exertion than getting into your car. When you’re up there you have a million gauges and controls meant to provide the operator the tools they need for any situation they might encounter and to interface with a galaxy of stuff that can be hooked up to the back. You need a special license which encapsulates this different paradigm of use, operating a gigantic vehicle under much different and more variable conditions than the everyday driver (in addition to approaching normal road conditions and functions like turning left with a different outlook and awareness). It’s why I often tell people not to switch to Linux. It’s not for them.
-
@BCsven@lemmy.ca 2026-10-25 18:08
In one way it is a simpler task to fix a single tool, than update a bunch of complex tools that suffer a problem. BUT this was before the GIT method of pulling changes into a main branch, so maybe nowadays it doesn’t matter as much as their is much less effort updating a bunch of tools for a problem, than manually editing and recompiling. Srill when we talk to users about our software use we alsways recommend using as much out of the box functions to get done what you need, rather than coding new tools for the Open API. Because a software update (should) fix all your workflow and automation that you have leveraged, rather than recoding dozens of apo addons.
-
@non_burglar@lemmy.world 2026-10-25 18:35
The UNIX philosophy does look like “do one thing and do it well”, but it’s really a means of working in such a way that one doesn’t introduce scope creep to a point of Drupal.
-
@jollyrogue@lemmy.ml 2026-10-25 21:47
I think you’re missing the difference between professional software development and a QnD script thrown together to accomplish a task. The UNIX philosophy is also related to The Agile Manifesto and “worse is better”. People are supposed to have the power to solve their problems. Unix provides primitives and tools to people, and they are expected to learn enough to use the system. It’s from a very different time. Well before the “don’t make me think” crowd showed up. In programming languages, integrating various modules to achieve a goal is already a complex task because we often have to handle numerous failure modes and edge cases. Now ignore all of the failure modes and edge cases except those that a script is going to directly run into, and that should simplify the requirements. This is “worse is better”. Perl, Python, and Ruby are supposed to be approachable and easy to get started with. They were never supposed to be industrial programming languages like C, C++, Ada, Pascal, Java, etc., and what you’re noticing is the software industry not understanding there needs to be levels which address the different needs of people. Sometimes people need a simple tool, and not everyone needs to master the professional tool which takes two hours to set up and adjust. The software industry destroying easy, simple to use software is another discussion.
-
@nik282000@lemmy.ca 2026-10-25 22:06
Qualification: I am a certified moron, I used nano as my IDE for 8 years because I did not know about VS code. I still structure my python like the qbasic I learned in school. I have never mastered object oriented thinking. Write your scrips one chunk at a time, make them modular, make intermediate scripts if you have to, and have each part output a data structure that you nail down early in the project. Having a ass-load of little parts chained together means you can tweak or entirely replace tools at a later date without fucking the whole process. If your project is a monolithic do-all be-all monster it means even the tiniest change involves reevaluating your entire codebase. You’re giving yourself all the problems of cuckcoding with none of the time savings.
-
@sudoer777@lemmy.ml 2026-10-26 02:52
I like tools to be separated enough that I can do scripted/CLI calls with them through standard interfaces (as opposed to being a GUI/TUI monolith). All sorts of stuff can be done when tools output structured data like JSON that’s easy to parse and manipulate, or being able to interact with DBus APIs or services in other ways. What I don’t like is when core tools try to be “smart” and reimplement things that other tools already do and end up making them more difficult to work with. Like package management, we already have Nix, Mise, and a billion other package managers, we don’t need another one. And turning the compiler into a package manager (cough Typst, .NET) is just stupid. Also programs editing their own configuration files is annoying as well, I can edit them myself and I don’t want them touching my edits, and if other people don’t want to do that then maybe a custom interface could be put in a UI/add-on of some sort that’s not part of the core tooling. Also web browsers and web applications are basically bottom of the barrel in terms of scriptability. The stuff the Nix ecosystem had to do to make Firefox configurable is nightmarish, and Electron is an overall mess. Although with everyone wanting to make the programs work with AI agents now, maybe this will improve.
-
@hirihit640@sh.itjust.works 2026-10-27 02:44
I’m confused what you’re trying to say here. It sounds like you are trying to say that unix philosophy fails to address the difficulty of actually composing and integrating the simple primitives provided by GNU/Linux. But you could say that for any programming language. Unless you are saying that the shell should have intermediate tools that are more specialized than the primitives. Like libraries or frameworks built on shell primitives. But I think for that sort of complexity, shell scripts are too slow and counterintuitive, and you should just use a proper programming language, like all the other complex specialized cli tools in the Linux ecosystem (nmcli, systemd, etc). I see shell primitives as relics of the past, and I treat them like you might treat the buttons on a GUI. There’s a button for copying items called cp, a button for moving items called mv, etc. I rarely compose these tools into complex scripts, and I almost never write bash scripts longer than like 10 lines. For any sort of complexity I use Python or Go.