> You're original argument was that mathematics can model things that we might arrive at intuitively, without looking at the model - such as assuming commutativity in package manager installation order - correct?
No, certainly not -- the right choice of model is key (a trivial example: one system for strings would be one in which there wasn't an identity element (that is, the empty string), thus making strings non-monoidal; that would complicate matters like concatenating a list of nullable/optional strings). I'm not claiming that to be the case, nor do I think the Pijul authors are claiming that. I think we both would say that there exists a model of any given domain that is the most suitable for for that domain (not that just any given model will suffice), and that it's math that helps you discover it. I read that blurb on the site as (the slightly tautological) "because we chose a good mathematical model, you can expect that the entities and operations on those entities can be composed as advertised, rather than unintuitively yielding unexpected results (bugs) or unnecessarily prohibiting some composition of operations that is clearly logically be sound (which is also unintuitive -- why the special cases, when these things should compose?)".
> I'm simply saying that mathematics can also describe things which are surprising; counter-intuitive even [...]
Sure. An example: non-commutativity in in package managers that only support one version of a given package to be installed. As someone who uses more flexible package managers, I'm often surprised when I'm using another package manager and discover its operations aren't commutative (which inevitably is due to, as I discover shortly thereafter, that it only supports installing one version of a given package at a time). That model requires extra brainpower to think through how I'm going to coax the package manager into installing what I need without conflicts (of course, after I've jumped through hoops to uninstall all the bad versions first). A mathematical model can be given for these systems, and they surely are convoluted and bad -- but just because we can come up with convoluted messes in math doesn't make math any more antithetical to intuition, that's just user error.
In this case, the package manager developers never set out to codify the formal semantics for these systems -- they just grew organically from initial needs. If they had started with an explicit mathematical model and iterated on that model, and assuming they had any math proficiency here, they would have done the convenient thing and allowed multiple package versions, and would consequently have commutative package installation (and I wouldn't have a notepad full of notes on how I need to carefully serialize my installs so that I don't get conflicts).
>> based on a mathematical model of collaborative edition
>is not sufficient for having that:
>> behavior matches intution, [sic] every time
Sure, not sufficient, but necessary (unless you count the possibility of just randomly stumbling into the best model). It's also necessary that you chose the best model for what you want (where "what you want" is surely a subjective matter, but efficacy can often be measured objectively in terms of, say, how much time is spent doing the same thing in two systems (assuming a similar level of mastery in both systems)).
> It just doesn't follow. Not least because one man's intuition differs from another's.
Ok, intuition is a subjective measurement, but I think there's still value in trying to find a pattern in what people generally find intuitive, rather than dismiss the topic entirely. I'm suggesting, anecdotally, that fewer arbitrary edge-cases is easier for human brains to deal with, and I think few would argue with that. Math is, to a large extent, the process of shaking out those generalizations from a bunch of concrete observations, so I would surely trust a system where someone could point out their logic in the construction thereof, over some system where the authors shrug and say "I dunno, that's just the way I built it." (which is most software I've come across). Seeing that note on the Pijul site inspires confidence: even if their model isn't maximally generalized (yet), I know that it's something they have an appreciation for, so I can come in and propose improvements (the same cannot be said for projects where the leadership can't appreciate such proposals due to a lack of the mental/mathematical framework necessary to conceive of the positive consequences thereof).
Given my heuristic for intuition ("as few edge-cases as possible"), it would seem that math would be requisite here. Do you disagree with that, or do you perhaps interpret that blurb from the Pijul site as claiming that (any unqualified) application of math is sufficient for developing an intuitive system?
> You're original argument was that mathematics can model things that we might arrive at intuitively, without looking at the model - such as assuming commutativity in package manager installation order - correct?
No, certainly not -- the right choice of model is key (a trivial example: one system for strings would be one in which there wasn't an identity element (that is, the empty string), thus making strings non-monoidal; that would complicate matters like concatenating a list of nullable/optional strings). I'm not claiming that to be the case, nor do I think the Pijul authors are claiming that. I think we both would say that there exists a model of any given domain that is the most suitable for for that domain (not that just any given model will suffice), and that it's math that helps you discover it. I read that blurb on the site as (the slightly tautological) "because we chose a good mathematical model, you can expect that the entities and operations on those entities can be composed as advertised, rather than unintuitively yielding unexpected results (bugs) or unnecessarily prohibiting some composition of operations that is clearly logically be sound (which is also unintuitive -- why the special cases, when these things should compose?)".
> I'm simply saying that mathematics can also describe things which are surprising; counter-intuitive even [...]
Sure. An example: non-commutativity in in package managers that only support one version of a given package to be installed. As someone who uses more flexible package managers, I'm often surprised when I'm using another package manager and discover its operations aren't commutative (which inevitably is due to, as I discover shortly thereafter, that it only supports installing one version of a given package at a time). That model requires extra brainpower to think through how I'm going to coax the package manager into installing what I need without conflicts (of course, after I've jumped through hoops to uninstall all the bad versions first). A mathematical model can be given for these systems, and they surely are convoluted and bad -- but just because we can come up with convoluted messes in math doesn't make math any more antithetical to intuition, that's just user error.
In this case, the package manager developers never set out to codify the formal semantics for these systems -- they just grew organically from initial needs. If they had started with an explicit mathematical model and iterated on that model, and assuming they had any math proficiency here, they would have done the convenient thing and allowed multiple package versions, and would consequently have commutative package installation (and I wouldn't have a notepad full of notes on how I need to carefully serialize my installs so that I don't get conflicts).
>> based on a mathematical model of collaborative edition
>is not sufficient for having that:
>> behavior matches intution, [sic] every time
Sure, not sufficient, but necessary (unless you count the possibility of just randomly stumbling into the best model). It's also necessary that you chose the best model for what you want (where "what you want" is surely a subjective matter, but efficacy can often be measured objectively in terms of, say, how much time is spent doing the same thing in two systems (assuming a similar level of mastery in both systems)).
> It just doesn't follow. Not least because one man's intuition differs from another's.
Ok, intuition is a subjective measurement, but I think there's still value in trying to find a pattern in what people generally find intuitive, rather than dismiss the topic entirely. I'm suggesting, anecdotally, that fewer arbitrary edge-cases is easier for human brains to deal with, and I think few would argue with that. Math is, to a large extent, the process of shaking out those generalizations from a bunch of concrete observations, so I would surely trust a system where someone could point out their logic in the construction thereof, over some system where the authors shrug and say "I dunno, that's just the way I built it." (which is most software I've come across). Seeing that note on the Pijul site inspires confidence: even if their model isn't maximally generalized (yet), I know that it's something they have an appreciation for, so I can come in and propose improvements (the same cannot be said for projects where the leadership can't appreciate such proposals due to a lack of the mental/mathematical framework necessary to conceive of the positive consequences thereof).
Given my heuristic for intuition ("as few edge-cases as possible"), it would seem that math would be requisite here. Do you disagree with that, or do you perhaps interpret that blurb from the Pijul site as claiming that (any unqualified) application of math is sufficient for developing an intuitive system?