I have a lot of respect for the FSF. I think GPL v2 is probably the best license out there. I certainly don't think Android is an unalloyed good the way https://ariadnavigo.xyz/posts/what-the-gnu does. And yet, this makes me incredibly sad:
The whole goal of GNU was to combat proprietary software. Deliberately over-engineering software just to distinguish itself from another that also has a permissive license (BSD), how is this making the world better?
@akkartik re "I often find it challenging even to figure out where to ask. Going from a program to its package, dealing with interactions between packages, etc. All of which goes back to simplicity as a core goal."
Programs should strive to have a beginning and end—or at least a well-understood beginning—and for the author to care as much about human reader as the machine.
@akkartik I've come to realize that, as intrinsic as it is in everything exactly like Nelson says it is, uncontrolled hypertextuality is the enemy.
Consider the plot of a book or a movie. Plenty exist that use non-linear storytelling or jump into and out of scenes happening in parallel. Yet we still manage to package them up into consumables.
The act of "linearizing" is an art, but it's doable. It should not be overlooked.
@akkartik the biggest problem, as I see it, is that by the time we get to the point where we're competent to both write programs and notice that we should be striving for this thing, our minds are poisoned by the influence "industrial" software development. Your analysis about Knuth's LP mistakes are extremely salient.
How do we keep from backsliding into, "Some #includes for our program -- don't mind these"?
@akkartik side quest: please nag Adam Spitz to merge PR #1:
(Originally published in 2011 at <http://adamspitz.com/avocado/2011/05/05/open-source-is-not-enough>.)
@colby Funny you (Adam, really) brought up Smalltalk. I've been poking around recently with Glamorous Toolkit, trying to figure out if I should focus there instead of my https://github.com/akkartik/mu. Because my goal is exactly what's stated in that blog post draft: always ship sources with any software, and make it easy to rebuild sources with a single click. Even if nobody can immediately understand it, push-button releases will massively improve things and lay the foundations for more.
@akkartik this is _exactly_ what I'm trying to achieve with triplescripts.org.
> Under the current regime, without triple scripts, it is essentially a given that every programmer will spend some time struggling with their toolchains, pouring untold effort into the steps that are usually described as "setting up a development environment".
@akkartik if I understand what you mean, wouldn't that be reversible? If an executable package P includes as part of its payload bundled source code, then a process R(P) that produces the source code can be defined, and the file format family that P belongs to would be said to enable reversible compilation.
@colby Ah cool, if that's all you need why didn't you just say so?! 😂 "Reversible" sounds a lot more exotic. But if it's just a packaging problem we could do this to C! Python! Just about anything. It's just a matter of how large the binary becomes.
I've started thinking about performing this transform on Mu, which seems particularly well-suited. The toolchain is only 300KB, and it's very hard for edits in one function to corrupt another. Most languages have at most one of those two properties.
@akkartik maybe you prefer the terminology of "non-destructive compilation" better? I have generally focused on it more than "reversible".
You could do it in C, stuffing the sources into e.g. an ELF section. The problems you will run into are more social than technological; you'd have to insist that people abandon their urge to strip them. Baking Loper's IV law into the system design from the beginning is probably the only way, realistically, to achieve this.
@akkartik re C:
AIUI, Justine Tunney does something similar for APE <https://justine.lol/ape.html>. She reports this makes binaries grow 10x.
One strategy for ensuring that SDIPD isn't compromised might be to change the kernel/loader so that there is no chmod-style x bit. Instead, the two work in concert to check for the presence of a source payload and reject anything that doesn't have one, refusing to run that program. There are still downsides to this (e.g. integrity/synchronization).
@colby Ah, I see. I'm not really thinking in terms of graceful degradation yet. Like what happens if people run `strip` on a binary or whatever. I think this idea is still in the "convince people it's cool" phase, not the operationalization and "provide guarantees" phase.
I do have some concerns about doing it with either C or Python. C's unsafe writes will now go to the code segment and be hard to debug. Python includes a lot, that makes it harder to provide a good experience for everything.
@colby So my attitude right now is:
a) Keep it memory safe (unlike C).
b) Keep the available libraries minimal, so we have a better sense of all the different things someone might want to put into an application. If we start with a web app, maybe don't include direct screen graphics, etc. Libraries should be relevant to the app.
Putting these constraints together, I'm thinking of some experiments with minimalist interpreted languages. Maybe Lua, femtolisp, etc.
kosmos.social is a friendly place for tooting, run by the Kosmos open-source co-operative.