rocketnia: "I once wanted to design languages such that nobody would need to fork them, but I don't put much faith in that anymore, so I see it as a lower priority."
akkartik: "Welcome! :)"
rocketnia: "Er, welcome what? XD"
akkartik: "To the club :) It's a pretty select club, I think. Too much effort is expended to avoid forking in the name of 'reuse', IMO.
"But reuse in what context? Reuse all across the universe? I think the notion of reuse is often ill-posed. The only reuse that matters is in the context of a codebase. And as long as a codebase only has one fork of any software you can have unlimited forking in the world without reducing reuse.
"(This also kinda feeds into our conversations about namespaces and libraries and backwards compatibility.)"
Well, sorry to have to disappoint you. :)
Before, I valued reuse. Therefore, I tried to make it easy for a programmer to patch up any existing code for their purposes, no matter how buggy or out of place it was.
Now, I value reuse. Therefore, I'm trying to make it possible to build a foundation of absolutely impeccable libraries that don't need to be adapted. One library isn't everything to everyone; that's what making a new library is for.
These two approaches may be able to coexist, but the design of the first is contingent on the design of the second.
Ever since I started working on Blade and Penknife, I expected that even if my own products weren't impeccable, a community could take up that slack given the right tools.
"But reuse in what context? Reuse all across the universe? I think the notion of reuse is often ill-posed. The only reuse that matters is in the context of a codebase."
Advanced research often finds its way into some specialized language that uses model checking or static typing to establish some necessary global assurances about the program. I specifically want to make a programming ecosystem that can harbor these meticulously concocted biomes. Convenience-centric styles will probably fit in the ecosystem too. Ideally, programs will start as hackish prototypes, then gradually harden into trusty, reusable foundations as the need arises.
"And as long as a codebase only has one fork of any software you can have unlimited forking in the world without reducing reuse."
I agree with this. I would like for each codebase to specify its dependencies as precisely as possible, even down to specific code revisions if necessary.
If necessary, it should fork the library and specifically use the fork instead of the original.
"This also kinda feeds into our conversations about namespaces and libraries and backwards compatibility."
I don't believe in perfect backwards compatibility, but I do believe it makes sense to update a utility while preserving its informal properties, as long as there's a clear indication of this informal development influence from the start.
To get started though, I'm also considering the option of a single global namespace that guarantees no stability at all. :-p I like the idea of designing the language so that I can tack on different namespacing options as necessary.
I think we're mostly in agreement. Perhaps we're just using different words.
"Would you rather we spin our own cloth, etc.?"
There's multiple ways to answer this:
a) There's a distinction between an end-user's view of the world and a developer/manufacturer's. From that perspective the analogy with spinning cloth might be misleading.
b) You're absolutely right that there always must be some set of abstractions we rely on, and that it can't be turtles all the way down. I'm not claiming everyone needs to fork every library they use. I'm claiming that even if they do so it shouldn't be cause for worry to anyone (besides themselves).
c) There is in fact lots of different ways to spin cloth. I don't think people in the cloth-spinning industry worry that somebody else in the world might use a different way to spin cloth. Think about all the competing kinds of wrenches, on metric vs imperial scales, etc. I think I might have found this disquieting and kinda ugly if I thought about it a few years ago. Now I have no problem with it. The tower of babel seems like a relatively minor issue to me now. If you're manufacturing a car or a crane you just decide what kind of wrench you're going to rely on and keep on cranking. Just avoid mixing multiple wrenches in the same assembly line.
For me there's no distinction between adapting an existing library and creating a new one. Perhaps the distinction is whether you try to move your patch upstream. You're trading some pain now for mitigating merging pains later. Depending on the context it might be worthwhile. However, it is valuable to think about this tradeoff rather than just flinch instinctively away from making changes to any libraries and try to patch them from the outside.
Well, it seems like I agree with all your possible answers. :) The interpretation I intended was b).
"For me there's no distinction between adapting an existing library and creating a new one. Perhaps the distinction is whether you try to move your patch upstream. You're trading some pain now for mitigating merging pains later. Depending on the context it might be worthwhile. However, it is valuable to think about this tradeoff rather than just flinch instinctively away from making changes to any libraries and try to patch them from the outside."
When you say it like that, it seems we're part of the same club after all. Glad to join you. ^^
"The programmers did not handle the exception because the assumption was made that the program was correct until proved at fault, apparently a feature of the programming culture for this system, (this observation is worth an article in itself)."
Unit tests and type checkers are both part of this culture. They prove a program is at fault, and if the program passes, they have nothing further to say.
What's missing is mathematical proof and, for the remaining informal properties, unbiased empirical testing (including empirical testing of the proof checker).
The best way I know to integrate mathematical proof throughout a codebase is total functional programming with dependent typing. Unfortunately, precise dependent types are notable for being inhibitive to code reuse. (But don't take my word for it; I'm just passing along rumor here, lol.)
A straightforward approach to bring reusability to mathematics would be to study the possible faithful translations from one mathematical discipline to another. This field of study already exists: It's category theory.
I don't have any recommendations for empirical testing. :)