I’ve had to resort to “do not disturb” 100% of the time, with the “allow contacts to bypass DND”
I’ve had to resort to “do not disturb” 100% of the time, with the “allow contacts to bypass DND”
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.
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 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.
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
Also have the option of selectively/strictly enforcing in CI, to get an experience & protections similar to “compile-time type checking”
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.
I think it’s unfortunately a tragedy of the commons/prisoner’s dilemma problem
Simplifying, a single store is not going to be able to improve pay for all the underpaid members of society, but what they can do is run thinner margins while staying in business (pay employees less, spend more on security, etc). Paying only their own employees more also does little to reduce the overall chances of theft.
Perhaps a better global equilibrium exists at higher wage rates, but there are limited options at local levels. For low-end wages, I think the downward pressure exceeds the upward wage pressure of the “free market” b/c the negotiation is between someone making a less profit vs someone failing to make a living – the negotiating power is not balanced. This is why IMO minimum wage to some degree is important.
What’s hard about vanilla Ruby?
What did you go over?
“never see addressed”? What do you think happens in (non-hypothetical, real) cities with good bike infrastructure and few cars?
https://www.youtube.com/watch?v=j2dHFC31VtQ&t=365
Oh look, emergency vehicles work even better on bike infrastructure than on car infrastructure
Bicylists and pedestrians can’t hard block a firetruck the way car traffic can
Feel like some states should coalition together and organize their own agencies
inheritance to avoid code duplication
What no, inheritance is not for code sharing
Sound bite aside, inheritance is a higher level concept. That it “shares code” is one of several effects.
The simple, plain, decoupled way to share code is the humble function call, i.e. static method in certain langs.
If you used good objects, you’ll only have to make the change in one place
IMO that’s generally a retroactive statement because in practice have to be lucky for that to be true. An abstraction along one dimension – even a good one, will limit flexibility in some other dimension.
Occasionally, everything comes into alignment and an opportunity appears to reliably-ish predict the correct abstraction the future will need.
Most every other time, you’re better off avoiding the possibility of the really costly bad abstraction by resisting the urge to abstract preemptively.
How does playing the game bring revenue? Ads?
Also, I would think that the business would be in a tougher situation if game popularity increased while tech workers weren’t around to maintain it
You can reference envs from the host in docker compose, so code it in instead of manually passing tribal knowledge in: https://stackoverflow.com/a/73826410
Simpler to keep everything in one compose file if you can, under a test
service that doesn’t build unless explicitly named
Un-weird that env var and use the normal, boring feature of defining environment
under your test
service
Bravo, a proper application of https://en.m.wikipedia.org/wiki/Paradox_of_tolerance