cle

Sure! A really simple (and common) example would be a setup w/ treatment A and treatment B, your code does "if session_assignment == A .... else .... B" . In the else branch you do something that for whatever reason causes misbehavior (perhaps it sometimes crashes or throws an exception or uses a buffer that drops records under high load to protect availability). That's suprisingly common. Or perhaps you were hashing on the wrong key to generate session assignments--ex you accidentally used an ID that expires after 24 hours of inactivity...now only highly active people get correctly sampled.

Another common one I saw was due to different systems handling different treatments, and there being caching discrepancies between the two, like esp in a MAB where allocations are constantly changing, if one system has a much longer TTL than the other then you might see allocation lags for one treatment and not the other, biasing the data. Or perhaps one system deploys much more frequently and the load balancer draining doesn't wait for records to finish uploading before it kills the process.

The most subtle ones were eligibility biases, where one treatment might cause users to drop out of an experiment entirely. Like if you have a signup form and you want to measure long-term retention, and one treatment causes some cohorts to not complete the signup entirely.

There are definitely mitigations for these issues, like you can monitor the expected vs. actual allocations and alert if they go out-of-whack. That has its own set of problems and statistics though.

It still misses the biggest challenge though--defining "best", and ensuring you're actually measuring it and not something else.

It's useful as long as your definition is good enough and your measurements and randomizations aren't biased. Are you monitoring this over time to ensure that it continues to hold? If you don't, you risk your MAB converging on something very different from what you would consider "the best".

When it converges on the right thing, it's better. When it converges on the wrong thing, it's worse. Which will it do? What's the magnitude of the upside vs downside?

This is a double-edged sword. There are often cases in real-world systems where the "reward" the MAB maximizes is biased by eligibility issues, system caching, bugs, etc. If this happens, your MAB has the potential to converge on the worst possible experience for your users, something a static treatment allocation won't do.

I can't help but wonder if this is intentionally ironic.

(From TFA: "There's a certain kind of person who's attracted to a shallow, exacting kind of moral purity, and who demonstrates his purity by attacking anyone who breaks the rules.")

Use whatever's lying around. Some more ideas:

  - A shoebox
  - An old binder
  - A food container
  - Some coasters
  - Egg carton
  - Jenga blocks
  - Cereal box
  - Legos
  - Picture frame
  - Tennis ball (cut it in half)
  - Door stoppers
  - Cake pan
  - A screwdriver box
  - A few junk mailer magazines
  - Crumple up a couple newspaper pages

Or better yet, order one of these and make 3 more with the shipping box it came in. That'll help once it wears out, or you accidentally sit on it.

Stick a book under your laptop.

I do know how to profile my code, and I'll also continue to bias towards not doing it now. Even if it could mean more pain later.

I think part of the problem is that the pain it causes is quite visceral, but the opportunity cost is pretty abstract, so it's a lot easier to just focus on the pain and forget about what you're gaining.

I think framing people "staying put" in a solely negative light paints an incomplete picture. I'd bet that the biggest reason people stay put is not anti-social but pro-social--tight community, cultural, and family bonds.

The answer is that it's not binary, despite everyone's insistence on framing it as such. We are a part of nature, but we do have some degree of power and responsibility over it that other species don't. It's not absolute, it's murky and messy, defined by the relative magnitude of power and our estimates of it. I think this framing addresses both our relationship within our ecosystems, above our ecosystems, and in the distant future, beneath some larger cosmic ecosystem that may exist that we don't know about yet.

For me, there are many cases where I copy-paste stuff I've written in the past b/c some tool is a pain-in-the-ass and I can't afford the mental context switch. I usually do understand what's happening under the hood, but it's still cognitively heavy to switch into that "mode" so I avoid it when possible.

Tools that fall into this category are usually ops-y things with enormous complexity but are not "core" to the problem I'm solving, like CI/CD, k8s, Docker, etc. For Make specifically, I usually just avoid it at this point b/c I find it hard to avoid the context switch.

It has nothing to do with miraculous incantations--I know the tradeoff I'm making. But it still runs the risk of turning into the Makefile Effect.

We are agreeing, I'm arguing against that dichotomy from the other direction—you don’t always need to know everything under-the-hood. You also can’t always ignore everything under-the-hood.

Sometimes you can get the job done by using a tool like a genie, and that’s awesome (it’s the goal of abstractions IMO). Sometimes you can’t.

You don't always need exhaustive "proof that it works" other than running the thing and looking at the output.

If you can get the job done with an LLM without understanding the code it wrote, then that's awesome. I've seen it multiple times with non-technical people who just want to do some small thing with a Python script. They solve their problem, send their report/email, and move on.

We're just arguing about abstractions. Do people need to always understand "under the hood" of abstractions? Obviously not, most of us don't know how ADC works or how CPU instructions are pipelined or how light pulses end up as 1's and 0's in a buffer somewhere, but requests.get(...) is a genie that we can still use.

The main disagreement is who the "owner" is in the first place.

I think you have to distinguish between a model, its implementation, and its weights/parameters. AFAIU:

- Models are processes/concepts, thus not copyrightable, but are subject to trade secret law, contract and license restrictions, patents, etc.

- Concrete implementations may be copyrighted like any code.

- Parameters are "facts", thus not copyrightable, but are similarly subject to trade secret and contract law.

IANAL, not legal advice, yadda yadda yadda.

I'm in a similar boat but it's more like "I have nothing I can hide".

These days I just tell friends & family to assume that nothing they do is private.

Yep totally agree these are problems. I don't have a good alternative proposal either, I'm just disappointed with what we're converging on.

The same author also makes a Python binding of this which exposes a requests-like API in Python, very helpful for making HTTP reqs without the overhead of running an entire browser stack: https://github.com/lexiforest/curl_cffi

I can't help but feel like these are the dying breaths of the open Internet though. All the megacorps (Google, Microsoft, Apple, CloudFlare, et al) are doing their damndest to make sure everyone is only using software approved by them, and to ensure that they can identify you. From multiple angles too (security, bots, DDoS, etc.), and it's not just limited to browsers either.

End goal seems to be: prove your identity to the megacorps so they can track everything you do and also ensure you are only doing things they approve of. I think the security arguments are just convenient rationalizations in service of this goal.

> Automatic Reconnection

I wouldn't characterize this as "automatic", you have to do a lot of manual work to support reconnection in most cases. You need to have a meaningful "event id" that can be resumed on a new connection/host somewhere else with the Last-Event-Id header. The plumbing for this event id is the trivial part IMO. The hard part is the server-side data synchronization, which is left as an exercise for the reader.

Also, God help you if your SSE APIs have side effects. If the API call is involved in a sequence of side-effecting steps then you'll enter a world of pain by using SSE. Use regular HTTP calls or WebSockets. (Mostly b/c there's no cancellation ack, so retries are often racy.)

> I find types helps massively with this. A function with well-constrained inputs and outputs is easy to reason about. One does not have to look at other code to do it. However, programs that leverage types effectively are sometimes construed as having high cognitive load, when it in fact they have low load. For example a type like `Option<HashSet<UserId>>` carries a lot of information(has low load): we might not have a set of user ids, but if we do they are unique.

They sometimes help. But I think it's deeper than this. A function with inputs and outputs that are well-constrained with very abstract, complex types is still hard to reason about, unless you're used to those abstractions.

I think it's more accurate to say that something is "easy to reason about" if its level of abstraction "closely matches" the level of abstraction your brain is comfortable with / used to. This can vary dramatically between people, depending on their background, experience, culture, etc.

I could describe the Option<HashSet<UserId>> type in terms of functors and applicatives and monads, and though it would describe exactly the same set of valid values, it has a much higher cognitive load for most people.

> However, programs that leverage types effectively are sometimes construed as having high cognitive load, when it in fact they have low load.

Cognitive load is an individual experience. If someone "construes" something as having high cognitive load, then it does! (For them). We should be writing programs that minimize cognitive load for the set of programmers who we want to be able to interact w/ the code. That means the abstractions need to sufficiently match what they are comfortable with.

It's also fine to say "sorry, this code was not intended to have low cognitive load for you".

Efficiency has always been the key.

Fundamentally it's a search through some enormous state space. Advancements are "tricks" that let us find useful subsets more efficiently.

Zooming way out, we have a bunch of social tricks, hardware tricks, and algorithmic tricks that have resulted in a super useful subset. It's not the subset that we want though, so the hunt continues.

Hopefully it doesn't require revising too much in the hardware & social bag of tricks, those are lot more painful to revisit...

New is an immediate "nope" to a whole lot of people when it comes to legal risk.

This back and forth is so tiring.

I have built web services used by many Fortune 100 companies, built and maintained and operated them for many years.

But I'm not doing that anymore. Now I'm working on my own, building lots of prototypes and proof-of-concepts. For that I've founding LLMs to be extremely helpful and time-saving. Who the hell cares if it's not maintainable for years? I'll likely be throwing it out anyway. The point is not to build a maintainable system, it's to see if the system is worth maintaining at all.

Are there software engineers who will not find LLMs helpful? Absolutely. Are there software engineers who will find LLMs extremely helpful? Absolutely.

Both can exist at the same time.

Getting people to respect that is even harder. And in most cases it isn't even actionable.

What’s special about server-based services vs other services? Should they also be obligated to publish their IP if they cease operations?

> However, reducing traffic speeds in cities could be a positive intervention for enhancing access to nature. Technological solutions, such as the widespread adoption of hybrid and electric vehicles, and urban planning strategies like integrating green spaces into transit routes, offer potential opportunities to mitigate the impact of noise pollution and benefit humans in urban environments.

For me, I constantly experience acute stress from ambulance/fire/police sirens which are required by law in most cities. I wonder to what degree that contributes to overall stress compared to background traffic noise. There are also other things like honking, though it depends on the city (looking at you, NYC). I don't consciously mind as much the white-noise-ish sound of background traffic nearly as much as these sounds designed to stress me out and distract me.

Here's the full list, base64-encoded (since HN doesn't support spoilers...)

    QSBSb29tIG9mIE9uZSdzIE93biBieSBWaXJnaW5pYSBXb29sZgpUaGUgTWFuIFdpdGhpbiBieSBHcmFoYW0gR3JlZW5lCkhlbnJpIE1hdGlzc2UKVGhlIFNvdW5kIGFuZCB0aGUgRnVyeSBieSBXaWxsaWFtIEZhdWxrbmVyCkZyaWRhIEthaGxvCk1hZ2ljayBpbiBUaGVvcnkgYW5kIFByYWN0aWNlIGJ5IEFsZWlzdGVyIENyb3dsZXkKRHVrZSBFbGxpbmd0b24KTWFnbmlmaWNlbnQgT2JzZXNzaW9uIGJ5IExsb3lkIEMuIERvdWdsYXMKQ2hhcmxlcyBJdmVzCkEgRmFyZXdlbGwgdG8gQXJtcyBieSBFcm5lc3QgSGVtaW5nd2F5ClRoZWEgdm9uIEhhcmJvdQpCZXJsaW4gQWxleGFuZGVycGxhdHogYnkgQWxmcmVkIETDtmJsaW4KUm9iZXJ0IENhcGEKTGF1Z2hpbmcgQm95IGJ5IE9saXZlciBMYSBGYXJnZQpDb2xldHRlCkxvb2sgSG9tZXdhcmQsIEFuZ2VsIGJ5IFRob21hcyBXb2xmZQpBdWd1c3RlIEx1bWnDqHJlClByb2Nlc3MgYW5kIFJlYWxpdHkgYnkgQWxmcmVkIE5vcnRoIFdoaXRlaGVhZApEYXVnaHRlciBvZiBFYXJ0aCBieSBBZ25lcyBTbWVkbGV5CkFkb2xwaCBHb3R0bGllYgpHb29kLUJ5ZSB0byBBbGwgVGhhdCBieSBSb2JlcnQgR3JhdmVzClRoZSBTdG9yeSBvZiBNeSBFeHBlcmltZW50cyB3aXRoIFRydXRoIGJ5IE1haGF0bWEgR2FuZGhpCkxpbCBHcmVlbgpBbGwgUXVpZXQgb24gdGhlIFdlc3Rlcm4gRnJvbnQgKHRyYW5zbGF0aW9uKSBieSBFcmljaCBNYXJpYSBSZW1hcnF1ZQpUaGUgR29vZCBDb21wYW5pb25zIGJ5IEouIEIuIFByaWVzdGxleQpIdWRzb24gUml2ZXIgQnJhY2tldGVkIGJ5IEVkaXRoIFdoYXJ0b24KVGhlIE1hcmFjb3QgRGVlcCBieSBBcnRodXIgQ29uYW4gRG95bGUKQW5uZSBTZXh0b24KTGVzIEVuZmFudHMgVGVycmlibGVzIGJ5IEplYW4gQ29jdGVhdQpEb2Rzd29ydGggYnkgU2luY2xhaXIgTGV3aXMKRG9uYWxkIEdvaW5lcwo=

It’s using purego: https://github.com/ebitengine/purego

And linking against libtcl and libtk.

This is using purego which is still using FFI, it is dynamically linking the C libs so you still have the same shared library issues. You don’t have to setup a C compiler toolchain though which is nice.

> By creating an account you agree to the Terms of Service and Privacy Policy.

> The Bluesky App is a microblogging service for public conversation, so any information you add to your public profile and the information you post on the Bluesky App is public.

What did they expect? I don't know how they could make it more clear. It doesn't say "information you post will only be used by people you like". It is public.

Anybody can write like 10 lines of Python and start consuming the firehose.

Depends on the org and how information travels. Knowing tricks like this are the superpowers of people who move up quickly in large orgs and make things happen. You can sometimes do fine without knowing this, and going through the "official" route of the direct feedback loop. If you can figure it out elsewhere though, it'll usually build more trust with your superiors.