everything wrong with free software
"obedience breeds foolishness"
*originally posted:* jan 2022
i responded to a coder just like this one years ago, who complained that he didnt understand programming even though he was already doing it.
> Fri 15:36:18 │ SomeH4x0r │ I ended up not realizing what "programming" actually is, and of course I can't succeed learning something when I don't even understand what I'm learning [...] e.g. I can create some basic CLI program using some basic C syntax, but not some GUI program, where I have no idea what to do and what to use [... (in response to someone elses comment)] yes, it is another issue. I wonder why does old code refuse to build.
programming is very simply "telling the computer what to do", more specifically "writing instructions that tell the computer what to do". it never needed to be more complicated than that.
in previous decades (and occasionally in this one) computing was taught at the expense of application training. later, application training was taught at the expense of people learning computing. both can be taught, but the monopolistic ambitions of those pushing for application training are more than a small factor in this.
we moved to application training to help companies build their monopolies on various computing tasks; moot is the fact that many tasks sometimes means a handful of monopolies.
in this environment, computer illiteracy is a support product for these companies-- it actually helps sell (and increase the desirability of) tools that suck.
since the desire for literacy once realised is difficult to quell, literacy too must be co-opted and turned into another shitty product.
a product that sustains itself or reduces the neediness of the user is the anathema of large tech companies; they want treadmills that continually throw out useful knowledge and training so users have to start over (and over) again.
this is how big tech designs applications, so it is also how they redesign "literacy".
a light-bulb that glows for decades means that no replacement bulb is needed. it is a given that tech will evolve, that new methods will be developed, the goal of monopolies is simply to control and maximise that inevitability for self-serving reasons-- at the expense of reliability.
this is why the gnew project and the more libre software directory stands against "nebulous programming interfaces". an npi is really a webapi posing as a downloadable, installable programming language. the fact that you can "download" and install such a thing locally IS a good thing, but it is a farce when the language is so unstable that applications break over and over and over without being constantly maintained.
note where the blame for this goes:
> I wonder why does old code refuse to build.
old code doesnt refuse to do anything; new versions of tools neglect existing code BY DESIGN. it is not an accident, it is a conscious decision. tools that cant build existing code have a bug-- that bug can either go fixed, unfixed or very often goes "wontfix".
complaints about such unreliability are often met with condescension, apathy and even derision. there is some idea that we are here to constantly rewrite all our codebases on behalf of developers: https://www.fsfla.org/ikiwiki/blogs/lxo/pub/new-dawn.en.html
> Why, then, do some of the FAQs at the Python 2 sunset page seem to be responding to user frustration out of a recommendation to upgrade by a certain date? I suspect, after years of propaganda and abuse turning them into passive consumers, they just don't realize they have a choice, or even that they should have it.
the idea that python developers are somehow obligated to maintain python 2 is a straw man.
the truth is, its a shame they routinely ignored and marginalised the users who found python 3 to be utterly broken.
the other truth is, that pypy continues to support python 2 in a way that would help (at least) quite a few users, but this truth pales in comparison to the industry notion that we should be first of all, mainstream in everything (an argument that if followed consistently would force us to discard all macbooks and gnu/linux laptops for windows machines) and second (more insidiously) that people who (THEMSELVES) support alternatives to please disenfranchised users are somehow part of the problem.
in other words, "youre hurting python if you support python 2". but this is bollocks, and monopolistic. python 3 is an even more nebulous interface than its predecessor. python 2 was a labour of love, 3 is very much co-opted by industry giants like google and microsoft. of course youre free to use both.
but the point of all this is not simply that languages are redesigned to support and sustain monopolies-- it is the effect these redesigns have on education.
just as education was hijacked to train application use (subjugation of the user) instead of teaching computing, languages (and thus education in those languages) have been hijacked to subjugate programmers and transform them from people who understand programming to people who know how to develop in something-- but not how it works.
slowly but surely, the industries are doing to languages (OUR languages) what they did to computing itself.
this is a necessity, because insomuch as people learn how to write software DESPITE application training miseducation, that knowledge must also be co-opted and turned into a tool of monopoly.
a language is a language-- but we tend to use IMPLEMENTATIONS of a language: compilers and interpreters. and implementations of language are SOFTWARE. they can be co-opted and monopolised just like ANY OTHER software.
when computing was hijacked by monopolies, the result was that people could use computers, but now their understanding of computers was lacking.
when programming was hijacked by monopolies, the result was that people could write code, but now their understanding of coding is pinned to the treadmill of nebulous and unstable interfaces.
the result is plain to see: a generation of people who learn languages, and then claim (in their own words) not to understand them.
in part 2 i will explain how i have personally addressed these issues. the goal here is not to say that i have all the answers, but to point out that this is a real problem and we need to work on solutions to the deliberate and nebulous simulation of cloudapis with traditional development tools.
the simulation works this way:
1. first you have a stable and reliable language
2. then you add features. this is done along the same lines as any other systematic takeover of existing tools, and programming language implementations (being software) are just as vulnerable
3. now you push people away from using SIMPLE reliable constructs, as python does routinely (python is far from alone in this, it is one very good example)
gui programming in particular (but not by itself) is a MOTHERFUCKING MESS. it is a joy to avoid gui programming, and also a joy to find a RARE but reliable, SIMPLE gui interface. most of these get hijacked and broken.
note that monopolies CANNOT BE MONOPOLIES by offering stable products-- it would be like trying to be in the lightbulb business selling 20-year lightbulbs (that actually last 20 years. anybody can SAY 20 years as long they dont mean it).
monopolies dont care if their own products die-- it is better, then they make new products. if you make stable products yourself, they will buy or bribe them and then make them unstable.
the result of this is that even the simplest projects often die after being co-opted. its not enough to make something simple, you must also defend it (SOMEONE at least, must defend it) from being hijacked. if it is hijacked, it will be tossed aside after getting exploited for a bit. theyll turn a 20-year lightbulb into another throwaway.
when languages are nebulous, it increases burnout. the tech treadmill runs on unreliable software, and it is incredibly inefficient. that inefficiency is made up for by sheer servitude on the part of users.
but the result of this servitude is not only burnout, but the feeling that you never understood programming in the first place-- again, this is not my wording of it. i am conveying something i see coders who are likely more skilled than i am, who lack any confidence (and voice this lack) that they even know how these things work.
the confusion comes from a campaign of lies. essentially, the industry gaslights its users into thinking that staying up with pointless, nebulous trends is what "understanding" really is.
but what understanding coding really is, is understanding the KEY concepts and being able to apply them.
its easier (and more fun in the long term-- it doesnt create so much burnout for one) to understand the concepts then the constant treadmill of abstractions.
there is a parallel to this in many industries im sure, but one i read about not long ago was the parallel of "biking".
biking is really simple-- you pedal with your feet and the bike goes forward, you move the handlebars and it steers. brakes are also quite useful.
everything else is an abstraction over these simple things, but what the industry does is push people to adopt a range of accessories (some useful, but shouldnt you decide that instead of them?) and activities, which collectively constitute (and complicate) "biking".
what ive been fighting for years is the notion that all these complications are MANDATORY-- in fact, most of them are ARBITRARY.
as the industry implies and insinuates their INTRINSIC relationship to programming, programmers develop a cognitive dissonance and feeling that they dont understand what they actually understand.
basically, the industry gives us chaos-- and dangles order always a few steps ahead like a carrot, telling us to work for it when really, we are only working for them.
this is what the biggest cults do to grift money from followers. and then when they reach the highest level, they simply add more.
programmers are logical people, or people who love logic, OR (this is what i think) people who have DEVELOPED their capacity for logic into a practical skill. i do mean develop, because logic is not a trait one is simply born with or not. the human brain does logic (among other things). developing that is like learning to ride a bicycle. and its NOT rocket science. programming is not complicated-- unless someone complicates it.
in 1964 a programming language called BASIC aimed at non-computing majors was so accessible that it filtered into high schools and secondary schools.
in the same decade, a programming language called LOGO was developed, which was so accessible that 7-year-olds were able to use it and develop their logical skills in the process. logic was not treated as a prerequisite for coding like it commonly is now-- you learned logic FROM using the language. this teaching philosophy and approach to programming is so practical that it has been developed into paper playing cards that simulate logo using human interactions. but it is still the same logic used in programming.
many people who already understand programming are being led to believe they dont. the industry gaslighting leads to confusion, miseducation and burnout. but this doesnt serve users, it only serves monopolies.