successor to free software which avoids libertarianism and encodes rights https://circumstances.run/@hipsterelectron/112475230792340206
-
d@nny "disc@" mc²replied to d@nny "disc@" mc² last edited by
@samir i agree re declarativity enabling a graph interpretation
-
d@nny "disc@" mc²replied to d@nny "disc@" mc² last edited by
@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 generatorreplied to d@nny "disc@" mc² last edited by
@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?
-
@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.
-
@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 generatorreplied to d@nny "disc@" mc² last edited by
@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.
-
@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
-
@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.
-
-
@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.
-
P [email protected] shared this topic
