On Customization I compare all customizable software to GNU Emacs, which in many cases features ideal characteristics for flexibility. However, in many ways Emacs is too flexible: Primitive interfaces to variables use functions returning the value, purely because this is the only good way most Lisp systems provide to restrict the shape of data easily. A system in which anything can be redefined is a system in which nothing can be restricted. Most programs feature a litany of unnecessary restrictions of all forms, which is the opposite extreme. Neither approach guarantees correctness and neither kind features it normally. A middle ground of sorts would be a program which protects itself during operation, which is still both kinds in different senses. Yet another idea would be a kind of program always able to dump its entire state to be reloaded in a different version of itself, or something implementing its protocols. There are likely good spots for all of these kinds and more, but one is overrepresented. Some kinds of software shouldn't be changed trivially during operation, such as that lowest floor on which everything the user touches stands, lest the foundation collapse; whereas others should impose no restrictions whatsoever, such as a browser program which has no place telling the user not to add or subtract some button or shortcut for anything. The mechanisms for directing these changes should also be extremely simple, and the error should be in the direction of too simple for certain changes rather than not simple enough, for some desires can always set undue complications upon some system. In general, software which is perfect can be made difficult to change, like the code which automates the regulation of a vehicle's engine, at least for much older models that is. The more reason there is to want change, the more reasonable change should be. That EVAL function of a Lisp system can be implemented in hardware without worry, for another EVAL could be built in terms of it and sit above. In general, the more directly visible software is, the more likely it should be to tweak and easily. I believe software should be modified directly for customizations, generally. One corollary of this would be that software should be small to allow this to happen practically. Software too big is too big to change at all in most cases, most regularly. Another corollary would be that software should be required to be loaded from its source code upon each use and never otherwise, so that it's always available. Failure to recognize this corollary is why a similar idea, propagated by idiots who call themselves by the name ``Suckless'', fails in practice; it's far too easy to end up with an artefact that can't be modified, not that their choice of language damns them not in other ways nevertheless. This conundrum could be considered a form of the problem of visibility, the simple inability to tell what the machine is doing at some time, which comprises most current computing problems in some way. I believe this because software can become simpler when it has no explicit configuration method, but this relies on an underlying system enabling it, very importantly. Lisp systems have been made free from a great many issues begetting issues entirely because of the system underneath precluding them. I still see not Lisp as the single best system that can be, and greatly prefer tools over languages. I've been having a great deal of fun using Decker lately, which exhibits some of these ideas. While a Deck can be modified haphazardly, which is the only way to customize a deck within Decker, widgets called contraptions have a minor barrier of a sorts: Contraptions can expose fields behaving just as the built-in widgets, the explicit options for customization, but users must click another button to tinker with them arbitrarily. This reminds me of Alan Kay's remark on one Smalltalk system, and how a ``fence'' between user and system code is likely a better approach than free-for-all environments. Importantly, Decker decks are changed in largely the same ways they're used and stacked in the first place, not as inert code in some editor. While I could modify a short program as lines of code very easily, not everyone should be expected to know how in the same way not everyone is expected to be a plumber or electrician, and I too would much prefer a rich editor of dynamic objects in place of it. It incenses me to see people argue that software can never be finished, no differently than how they argue it must be flawed; I figure arguing with such deranged people to be akin to the British trying to teach Indians not to eat cow shit and not to bathe in sewage, both of which they still do wearing smiles on their faces. Indians make for a nice example of how hundreds of millions can be wrong for very long periods of time, and make an excellent argument against the stupid attitudes of C language programmers making the case for their cult of imperfection and mysticism they think coats the world. Software is most often argued to be perpetually unfinished, always imperfect, since this gives cause to control it forevermore and even charge rent for the disservice. If most software weren't forever flawed, the misnomer ``upgrades'', better thought of as mere ``changes'', would be harder to enforce with an air of tutelage. As there should be no distinction between using a computer and programming it, there should be no need for large corporations to provide software and maintain control over its users through it. Most programs nowadays lack even the concept of an event that can be recorded and displayed or replayed, which is likely that single simplest form programming can take; I've seen GNU Emacs provide this feature I've come to see as incredibly simple and foundational, yet nothing else. Still, I see software too small to need the help system resulting to have a different kind of charm. Related to all of this is the concept of ``cardboard software'' as described in ``The Day the Phones Stopped'', software so simple and cheap that it's discarded at the first inconvenience. Nowadays, I see many using neural network nonsense to plagiarize the work of others, and call it by some similar name, perhaps the appropriately less creative ``disposable'' instead; an important part of cardboard structures are their small size, however, which comes not from such nonsense. Customizing software, just as building using cardboard, still requires knowledge in proportion with those changes desired, little for changing a colour and a little bit more for stitching together wildly different projects. .