Bit off loss is fine, esp if it's storing extra "free" renewable energy that would otherwise just be thrown away/not collected
I think article directly emphasizes the hope that it's sustainable, scalable, and available. For example, pumped hydroelectric isn't as available because it needs just the right terrain of two nearby lakes separated by as much elevation as possible
For me, the more relevant adage here is "a bad abstraction is worse than no abstraction".
IMO many abstractions in Java are terrible in this regard, either via commonly proliferated patterns or via language design issues. Abstractions large and small are all forcibly locked into place very early on in the name of formalism and safety, ultimately leaving us with poor versions of the former and weakened versions of the latter. Where is "encapsulation" when certain classes only work when hooked up in very particular ways to other distant classes? Where is "type safety" when certain methods simply raise "not implemented for this sub/super-type"?
These faults are often hand-waved as "all ecosystems have rough patches", but my point is that Java's bad abstractions in particular are supremely more stubborn and persistent in comparison with other ecosystems. I understand many consider this a strength aka stability, but IMO at the extreme being unable to shed the past means negatively hindering progress. I think modern Java versions show a budding shift in mentality, but I've already moved on -- it's just not for me.
Maybe their communities are blank slates where innovations in "distributed power grid" systems can happen? Have heard that traditional power grids are "unidirectional" and have had some trouble with solar installations popping up.
It's a container with certain behaviors and guarantees making them easy and reliable to manipulate and compose. A practical example is a generic List, that behaves like:
List[1, 2, 3], i.e. ("new", "unit", "wrap") to create, containing obj(s)map(func) to transform objs inside, List[A] -> List[B]first(), i.e. ("unwrap", "value") to get back the objflat_map(func), i.e. ("bind") to un-nest one level when func(a) itself produces another List, e.g. [3, 4].flat_map(get_divisors) == flatten_once([[1, 3], [1, 2, 4]]) == [1, 3, 1, 2, 4]Consider the code to do these things using for loops -- the "business logic" func() would be embedded and interlaced with flow control.
The same is true of Maybe, a monad to represent something or nothing, i.e. a "list" of at most one, i.e. a way to avoid "null".
Consider how quickly things get messy when there are multiple functions and multiple edge cases like empty lists or "null"s to deal with. In those cases, monads like List and Maybe really help clean things up.
IMO the composability really can't be understated. "Composing" ten for loops via interlacing and if checks and nesting sounds like a nightmare, whereas a few LazyList and Maybe monads will be much cleaner.
Also, the distinction monads make with what's "inside" and what's "outside" make it useful to represent and compartmentalize scope and lifetimes, which makes it useful for monads like IO and Async.
Python deps can be dynamic, so it can be necessary to download the package and execute code just to find out.
Would be nice to see a resource that lists out the statically defined ones, though. Perhaps that'd pressure the dynamic ones to change -- it's a cause for some of the notorious pain of Python packaging.
IMO it will "succeed" in the early phase. Pre-seed startups will be able demo and get investors more easily, which I hear is already happening.
However, it's not sustainable, and either somebody figures out a practical transition/rewrite strategy as they try to go to market, or the startup dies while trying to scale up.
We'll see a lower success rate from these companies, in a bit of an I-told-you-so-moment, which reduces over-investment in the practice. Under a new equilibrium, vibe coding remains useful for super early demos, hackathons, and throwaway explorations, and people learn to do the transition/rewrite either earlier or not at all for core systems, depending on the resources founders have available at such an early stage.
First suggestion is impractical. Not going to be able to memorize 100 names to look up and research later
Second suggestion should already be happening, but doesn't capture the desired use case.
The use case is this: in physical life, there is a gradient of "boundaries/leashes" to match maturity and development. For example, the gradient of movie ratings, or:
We could argue about whether a gradient is too steep or shallow, but the point is that one exists.
In contrast, digital in many ways is very often all-or-nothing
Not saying digital should be "gradient-ed" in all cases, that leads to tone-deaf rules and bad security practices. Just trying to show what the problem is
I think there is a difference. Because software is so flexible and quick to build, it's orders of magnitude easier to build something known and understood.
A promising startup with its systems in a knot, but their initial team is still on retainer? Brains can be picked, abstraction boundaries placed, surgical rewrites deployed. Despite the mess, they still understand it, and development can expand.
It remains to be seen if AI-generated code is recoverable, if any existing strategies can be applied so humans can contribute, or if the company is forever beholden to AI providers to release a better AI to manage/improve what they've already got.
In my experience, LLMs aren't really that good at summarizing
It's more like they can "rewrite more concisely" which is a bit different
Thinking about that quote, it sounds nonsensical
At the outset, all businesses seek to grow faster than the average/stock market. Five years later, half will do better than average, and half will do worse than average.
Saying that the half that did worse should have instead invested into the market, five years ago, is kind of meaningless.
Thought it was possible to lob the ball up and over?