-
#public
-
still very draft - sorry u might not understand my shenanigans here!
-
u can discuss on [https://twitter.com/kiprasmel/status/1446870128721813505](https://twitter.com/kiprasmel/status/1446870128721813505)
-
#[[(hidden) ThXonBLoY]] the react vs angular principle, the debate of having a forkable template vs creating a whole library to wrap around the tools you'd have in the same template -- I just realized the same story applies with linux distros!!! [[arch linux (public)]] + [[larbs (public)]] - minimal, larbs is just minimal utilities/scripts + some default configs of programs e.g. i3, meanwhile e.g. manjaro & others have a lot of stuff abstracted away, some even create wrapper programs that operate on top of existing ones
-
the implications of this are big. one motivates the user to become smarter, to understand how the system works underneath, __and__ allows them to do it, all while not creating wrappers on top of existing programs, meaning that the knowledge you again is just as valuable outside the current setup
-
re: #[[(hidden) URRQcDCig]] - completely opposite - internal tools are very much internal, and if you learn them well, but then leave google - a lot of your knowledge becomes __useless__ ((gu9uGUwpV)). the ultimate golden handcuffs. hell no.
-
-
realized this when I thought that maybe it'd be nice that [[larbs (public)]] could publish the utilities as minimal packages instead of just giving a forkable template ([[voidrice (public)]])
-
but then it'd be harder for the end user of it to modify it (e.g. the util currently lives in `~/.local/bin/`, and if it was a package / program that you'd install, it'd live in e.g. `/usr/local/bin/`, meaning that if u were to modify it, your changes would get overriden - you'd have to contribute directly to the original package by e.g. opening PRs on github, but you don't control if they get merged or not, so now you'd have to fork the repository which contains this program, and then modify it and potentially maintain the fork, plus you'd have the burdain of publishing the package yourself w/ a different name)
-
unless, ofc, the program would be completely extensible, meaning it would provide APIs to extend the behavior without modifying the program itself (O in [[(hidden) Nq8r6-ap2]] - open-closed)
-
https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle
-
but then, the program becomes much more complex, with all the stuff that comes from that! and remember, what we tried turning into packages were actually small utilities/scripts - they didn't have any of the problems - the problems come from wanting to abstract those small utilities into packages
-
the convenience of consumption, at the loss of simplicity of modification
-
what can be learnt from this is that maybe one should never create an #[[(hidden) vzIV5rsdR]] (both 1) a utility function on some "reusable logic" and 2) a library/framework instead of a template) on top of some logic __without__ first using it enough to realize the common use cases to identify the things that can and __should__ be abstracted, and only then start abstracting.
-
because in some cases nothing should be abstracted - then the choice is having a template instead of a library, or copy-pasted / #[[(hidden) imNiDHw0b]] (as opposed to #[[(hidden) AYIfX5dlb]]) code
-
and sometimes very little things need to be abstracted - then we can create & extract more sophisticated & extendable programs but keep everything else as a template.
-
-
-
-
-
-
so in essence, what it comes down to is:
-
1. __at first__ - don't abstract anything - use the existing primitive tools (e.g. the programming language itself)
-
2. then, find: what you end up repeating a lot, or what mistakes you failing at, or similar
-
3. then, think about the absolute minimal solution that would solve your problem (singular)
-
3.1 don't try solving multiple problems at once -- [[(hidden) FO-XsQXEy]] - one small independent thing at once
-
3.2 if you __do__ feel like solving multiple problems -- you might be operating at the wrong level of [[(hidden) SU8hr25lN]]:
-
the hierarchy of your abstractions also matters, and it's hard to balance (this might be the essence of what this is all about, but I'm not sure yet):
-
on one end, you can create hacks on top of your existing solutions (i.e. close(r) to your leaf nodes of the abstraction hierarchy), but that usually doesn't go a long way, and/or cripples everything else.
-
on the complete opposite end, you maybe could create APIs in the very beginning of your abstraction hierarchy (e.g. on the OS level), but that might be extremely hard to 1) do, and 2) do __right__.
-
maybe see also: tree balancing (computer science), tho dunno if any useful (yet).
-
-
-
3.3 make sure 5. still applies to other existing abstractions.
-
-
4. if everything makes sense, you are confident your solution sits at the right level of abstraction hierarchy - implement it
-
5. as time goes on - re-evaluate if the solution still makes sense and still sits at the right level of [[(hidden) SU8hr25lN]]
-
6. repeat from 1.
-
-
[[Luke Smith (linux & life)]] yet again [[(hidden) XnbxpC_RY]] (especially for the specific use case / need that #[[voidrice (public)]]] provides)
-
-
related::
-
[[(hidden) e-ZEmn_qq]] [[(hidden) pEVsXyK9F]]
-
oh shit i just realized I've been using this naming without knowing that an actual "singularity OS" has existed, but it's not the same thing I was thinking about
-
{{[[TODO]]}} mention my version of the singularity os (or whatever I rename it to) as another example in the 1st paragraph of this page
-
{{[[TODO]]}} the "wrapper programs" stuff & how it relates to 1) templates vs libraries, and 2) libraries that abstract stuff away (frameworks ??) vs small utility libraries
-
-
-
damn, I love roam not only because it makes writing fun/the norm for me, but that the act of writing itself lets my mind discover connections between things
-
#[[(hidden) EkNKI3n1D]]
-