Less Retarded Software

Hello,

I'm absolutely new here, found reactionary software via saidit where I posted about one of my project I've been working on for quite some time now: Less Retarded Software(/Society). In general I agree with the points of reactionary software, it is pretty similar to LRS. I like what you're doing. I think people here might be interested in things I write so if you allow I would like to invite you to read my LRS wiki at:

https://www.tastyfish.cz/lrs/main.html

I've also started an article on reactionary software (https://www.tastyfish.cz/lrs/reactionary_software.html). Please forgive if I misinterpreted something -- let me know if something is factually wrong etc., I'll fix it.

As part of LRS I also write a lot of very minimal and extremely portable public domain software in C that can run even on extremely weak computers (embedded) such as 3D graphics and physics engine, chess library, and my own minimalist programming language (currently work in progress), you can find all e.g. at https://codeberg.org/drummyfish (I understood you may hate Git -- I just use Git hosting sites to host my code on the Internet, I don't really care about VCSes, I don't collaborate with anyone).

Anyway thanks for spreading the word about degenerating technology and its causes, I was genuinely glad to find this community as it showed me there are more people seeing the issues of current society. Let me know what you think about LRS -- don't worry, I am used to getting hate comments, you can be honest :)

drummyfish

We obviously have a lot in common.  The core difference is the meaning of simplicity.  For me, simplicity means simplicity to use, not simplicity of implementation.  For example when comparing Git with Mercurial, I have no idea about the implementation of either one.  But Mercurial is much simpler to use.  A good programming language is one where code written in that language is easy to read.  That means that the language should contain things like garbage collection and a virtual machine for portability because these things make programs written in the language simpler.  Of course the language implementation should implement these things as simply as possible internally.  Complex implementations tend to make software behave unpredictably.  But when I talk about bloat in software, I mostly mean adding many useless features which makes the software more complicated to use.

Unix reflects my view by making everything into a stream of bytes.  This adds complexity to the implementation of Unix but makes Unix easy to use.

Oh, that makes sense, I'll update the article a bit :) There is no doubt simplicity of usage is important, we're on the same ship (questions such as whether GUI is actually objectively simpler to use for common people than CLI or whether it's a culturally established "fact" is for another discussion).

To me internals are at least of the same importance -- I guess this stems from an image of ideal society I have in mind in which programmers (and other people who deal with the internals) are ALSO users, and programmers are more common than in today's world divided to a minority of programmers and masses of users dependent on those programmers. In my world the line between programmers and users is more blurry because programming is easier and more people are practically able to modify e.g. their operating system or browser (thanks to simple internals, trivial compilation etc.), i.e. programmers become users and users become programmers (if only programmers that insert a few if statements to their configs): programmers are users of libraries, programming languages, APIs and other components made by other programmers, so they should have to deal with as simple as possible stuff too. The issue of complex and obscure internals is in today's society manifesting as the issue of "right to repair" -- minimalist software in my opinion addresses the root cause of this issue. Technology that's minimal on all levels is in my view the only truly free technology actually controlled by their users -- true freedom is conditioned by simplicity, i.e. basically great accessibility. Even if you yourself can't modify your OS, then if that OS is simple there is a great chance some of your tech savvy friend can do it for you. Anyway, I hope I made my view a little clearer :) Thanks for your clarification too.

EDIT: About git -- it's pretty complicated if used as a tool for mass collaboration, that's true (even if that complexity IMHO really results in some great properties over other VCSes, it's not completely unjustified). If you use it solo as a lone programmer to manage your own projects (and possibly here and there accept some small pull request), it's pretty easy and simple to use, the only commands I ever use are basically just clone, add, commit, push, pull and stash -- all very simple. It allows you to work offline, easily push to multiple mirrors and sync between machines, and it doesn't create any dependency for my projects (I can just stop using git at any time without any damage). So I'm OK with it, but I also liked attempts as simpler systems like Darcs -- I wouldn't even be against an idea of using plain FTP with regular snapshot backups of code or whatever, I'm not a diehard Git fan, just offering my perspective again.

My ideal society would have 3 classes of people: end-users, application programmers, and system programmers.  End-users would be people who just don't like dealing with technology.  For these people, all software should be like an easy to use appliance.  Application programmers would write software for end-users.  This should be a much bigger group of people than programmers today.  They should tolerate dealing with technology but not really be interested in the details.  They should program in a very easy to use scripting language where they can focus on building their application, not on technology.  I wrote Luan for this group.  System programmers should write libraries and tools for application programmers.  This should be an elite group that is interested in technology.  For more on this approach, read Scripting: Higher Level Programming for the 21st Century written in 1998.

Regarding Git:  Before using a tool, I like to read about it and understand the core idea.  This is much easier with Mercurial than with Git.  For example Git's staging area is a totally useless complexity.  And Git's commands are inconsistent.  So I rejected Git as a lone programmer after reading about it and briefly playing with it.  I consider Git to be the ultimate example of bad tool design.