[HN Gopher] Dependencies and resilience
___________________________________________________________________
Dependencies and resilience
Author : sebastianingino
Score : 9 points
Date : 2024-04-09 21:59 UTC (2 days ago)
(HTM) web link (ingino.me)
(TXT) w3m dump (ingino.me)
| xamuel wrote:
| I wonder how much dependencies could be reduced by systematically
| searching low-hanging fruit and addressing it ad hoc. For
| example, if commonly-used library A uses one minor thing from
| (and thus imports all of) library B, which in turn imports
| hundreds of other libraries, then someone should add the minor
| thing in question to A and remove the dependency on B there.
|
| It's interesting to think of how this sort of "neighborhood
| watch" could be incentivized, since it's probably way too big of
| a task for purely volunteer work. It's tricky though because any
| incentive to remove dependencies would automatically be a
| perverse incentive to ADD dependencies (so that you can later
| remove them and get the credit for it).
| kkfx wrote:
| The solution exists since decades: instead of having layered OSes
| + application software back at Xerox time Smalltalk workstations
| was an OS as a single application, live framework, "apps" was
| just bits of code. Today it's the same (nearly, all but the C
| core) in Emacs.
|
| This model makes "bad citizens" a nightmare because they are not
| isolated bits that fails individually but "something that fail
| inside the system", this might led to a slow development for
| revolutionary things, very quick development for incremental
| evolution, witch is probably very good.
|
| Unfortunately this model means end-user programming, the power of
| computing in users hands, not the dumb human operating like a
| monkey an endpoint of a remote service/mainframe model alike. A
| thing most IT giants really dislike because it can easily erase
| their business...
___________________________________________________________________
(page generated 2024-04-11 23:02 UTC)