successor to free software which avoids libertarianism and encodes rights https://circumstances.run/@hipsterelectron/112475230792340206

d@nny "disc@" mc²

@samir the build xor pkg thing is like crucial to my Grand Unifying Theory and it also directly bleeds into several reasons cargo sucks https://circumstances.run/@hipsterelectron/113662844632964027

d@nny "disc@" mc²

@samir another post on same https://circumstances.run/@hipsterelectron/113534635833989257

d@nny "disc@" mc²

@samir so it's very important to me but when i say "this one is mine" i just mean i personally need to make sure it happens so if you get far enough ahead i will actually just use yours actually so kinda nvm. but since it's something i expect to use myself frequently it will be hard to cede that entirely to someone else

samir, mad idea generator

@hipsterelectron Tell you what. I will get around to writing this thing up properly one day (the vision, not the current state) and if it resonates with you, great. If not, I think it’s fine if we both do it.

(Before I do that, I have an idea I’ll never implement for how to fix search, and I’m halfway through writing it up. Gonna send the draft to you if you’re interested.)

samir, mad idea generator

@hipsterelectron Just remembered I already did, kind of, though it’s unfinished: https://gist.github.com/SamirTalwar/6d0fbf8695a87ec6dda88818913a3dfb

I might have even sent you this before, no idea.

(It’s OK if you hate it, I won’t mind.)

d@nny "disc@" mc²

@samir i am thinking of something which is clear in my head but only vaguely defined here for build tool process and i/o orchestration including execution caching https://circumstances.run/@hipsterelectron/113680773285135674

d@nny "disc@" mc²

@samir i agree re declarativity enabling a graph interpretation

d@nny "disc@" mc²

@samir i have an extremely negative association with calling excel a build tool and/or programming language for deeply specific personal reasons https://circumstances.run/@hipsterelectron/113679884627777286 especially the build systems a la carte paper which ignored our existing tool that proved its main thesis false but had the gall to call excel a build tool but your specifics seem good i just emphatically do not consider excel empowering simply because it's widely used, because it's a monopolistic product line from a monopolistic company. i wish discussion about its capabilities for empowerment would not take its widespread (forced) uptake as evidence of it therefore being empowering. the rest seems good and i would want to see it

samir, mad idea generator

@hipsterelectron Regarding Excel: I agree with everything you say, and perhaps “spreadsheets” would be more accurate, because I think they’ve been the most popular programming languages since Lotus 1-2-3. Excel is just the commercial monopoly incarnation, as you say (though Google Sheets is pretty popular, it’s basically a clone with no additional benefit except a JS scripting interface).

Which was the build tool that disproved the paper? Pants?

samir, mad idea generator

@hipsterelectron BTW, I love your build xor pkg concept and it helped me understand that what I’m going for is a build tool and absolutely never a packaging tool, instead leaning on other tools to make that happen.

d@nny "disc@" mc²

@samir packaging tools are cool as hell too btw!!! and maybe i might accept one that merges both iff it tries REALLY hard to offer divergent interfaces for both of those features. but it seems very difficult to me to do that so i'm just sticking with making them different tools! and packaging protocols over impl-defined is the other really important thing

samir, mad idea generator

@hipsterelectron So assuming that you’re correct and it’s better to keep them separate, how do you bind them? Does build call pkg, pkg call build, or a third thing calls both?

I’m leaning towards build calls pkg, but I could be persuaded otherwise.

d@nny "disc@" mc²

@samir a build system (i prefer "build tool") is a decision made by the individual codebase regarding how to organize their code, and how to compile it into modules (this interacts with the language module facility). as you identified, this will usually involve calling a package manager to obtain dependencies—which the build tool is then able to integrate into the code/module organization

Cassandrich

@hipsterelectron @samir As a user building FOSS, I *don't want this*. I don't want a tool touching the network at all. I want clear documentation a human can read for what the dependencies are and which let me decide whether to use the ones I have that were packaged by my distro or previously built by me, ir whether to obtain them myself.

d@nny "disc@" mc²

@dalias @samir not sure how what you said conflicts with what i said

Cassandrich

@hipsterelectron @samir I don't think it conflicts, but I'm saying that build tools built for the devs tend to be obstacles in my way as a user who wants to build the sw (maybe with minor changes) myself.