But IMO that's one reason weird UX/design is not uncommon and can persist in dev ecosystems. The intended users are more proficient than average and most are able to work around most issues.
If the goal is evaporative distillation, it makes no sense to use a process that begins with filling and conaminating the entire system with contaminated water
You'd have more success keeping the container clean (full of air) and pumping all the air out of it, which is still probably less efficient than other means like boiling
Seems that configuration can only assist/augment the buttocks muscles? Doesn't seem to be a way for it to assist the hamstrings and calves, let alone the feet for stability and balance, i.e. the entire chain of muscles working in concert. E.g. suppose my calves get tired first -- this exoskeleton doesn't seem like it could help.
IMO wardrobe concerns should come far behind health. Is this not a serious "all hands on deck" health situation? Are you sure considering custom tailoring is the correct life prioritization to take right now?
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.
IMO it's time for a reckoning of what's systematic/automated vs what's not.
For example, "no expectation of privacy in public" meant you should be okay with appearing in someone else's (manual) photo while out in public. However, I don't think that should extend to persistent systematic surveillance, e.g. suppose every Tesla's camera captures were combined with person recognition systems and tracking.
Just because something is theoretically okay at a small scale doesn't mean the same applies at large scales.
Another example: Society funds public roads via government taxes for personal use and for regulated commercial use. Uber systematically consumes public road space under the guise of personal use vehicles, for commercial use.
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 obj
flat_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.
Highly recommend having some scripting/interpreted language in your stack -- in fact you likely already do (consider how shell scripting makes up a significant part of Dockerfiles)
It's an incredibly useful intermediate between freeform-but-non-executable text/docs/wikis and "industrial-grade"-but-inflexible tooling
In other words, a great fit for capturing this partial/incomplete/tribal knowledge space the post is talking about. I personally even go a bit further and actively advocate for converting "onboarding/operational docs" from wikis into scripts that print out the equivalent text that can be committed and incrementally automated.
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.
Yes, I've seen a video file that changes resolution mid-video, but it's more of a party trick since not all players handled it well
Specifically, I saw a group chat program rendered it "correctly" (Discord? I don't remember), so the embedded video would re-flow the rendered chatroom while playing
The screw gate biner image definitely looks inverted. The "to the climber" rope looks like it's going down and the braking rope looks like it's going up.
it lacks clear and enforced type restrictions which help with clear code contracts
Not anymore! Gradual typing is supported by the core language and pyright is a fantastic incremental type checker that you can use both in your editor and in CI.
But IMO that's one reason weird UX/design is not uncommon and can persist in dev ecosystems. The intended users are more proficient than average and most are able to work around most issues.
Maintaining vacuum is difficult and most likely more expensive than just using a cheap energy source
For example, a solar salt distillation system can be totally passive, even if slow and space inefficient: https://en.m.wikipedia.org/wiki/Solar_still
If the goal is evaporative distillation, it makes no sense to use a process that begins with filling and conaminating the entire system with contaminated water
You'd have more success keeping the container clean (full of air) and pumping all the air out of it, which is still probably less efficient than other means like boiling
Seems that configuration can only assist/augment the buttocks muscles? Doesn't seem to be a way for it to assist the hamstrings and calves, let alone the feet for stability and balance, i.e. the entire chain of muscles working in concert. E.g. suppose my calves get tired first -- this exoskeleton doesn't seem like it could help.
IMO wardrobe concerns should come far behind health. Is this not a serious "all hands on deck" health situation? Are you sure considering custom tailoring is the correct life prioritization to take right now?
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.
I've had to resort to "do not disturb" 100% of the time, with the "allow contacts to bypass DND"
IMO it's time for a reckoning of what's systematic/automated vs what's not.
For example, "no expectation of privacy in public" meant you should be okay with appearing in someone else's (manual) photo while out in public. However, I don't think that should extend to persistent systematic surveillance, e.g. suppose every Tesla's camera captures were combined with person recognition systems and tracking.
Just because something is theoretically okay at a small scale doesn't mean the same applies at large scales.
Another example: Society funds public roads via government taxes for personal use and for regulated commercial use. Uber systematically consumes public road space under the guise of personal use vehicles, for commercial use.
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 whenfunc(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
forloops -- 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
forloops via interlacing andifchecks 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.
Highly recommend having some scripting/interpreted language in your stack -- in fact you likely already do (consider how shell scripting makes up a significant part of Dockerfiles)
It's an incredibly useful intermediate between freeform-but-non-executable text/docs/wikis and "industrial-grade"-but-inflexible tooling
In other words, a great fit for capturing this partial/incomplete/tribal knowledge space the post is talking about. I personally even go a bit further and actively advocate for converting "onboarding/operational docs" from wikis into scripts that print out the equivalent text that can be committed and incrementally automated.
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.
https://f-droid.org/packages/de.t_dankworth.secscanqr/
Yes, I've seen a video file that changes resolution mid-video, but it's more of a party trick since not all players handled it well
Specifically, I saw a group chat program rendered it "correctly" (Discord? I don't remember), so the embedded video would re-flow the rendered chatroom while playing
The screw gate biner image definitely looks inverted. The "to the climber" rope looks like it's going down and the braking rope looks like it's going up.
Also have the option of selectively/strictly enforcing in CI, to get an experience & protections similar to "compile-time type checking"
Not anymore! Gradual typing is supported by the core language and pyright is a fantastic incremental type checker that you can use both in your editor and in CI.