5,665 karma · joined December 22, 2019
Update your browser to access this website
An example from something I've had to iterate on: When explaining an event loop multiprocessing runtime sort of thing, I eventually found I had to hand-wave "and your CPU hates that" to establish an appropriate premise to the problem and solution (referring to item-by-item dynamic dispatch with a large number of task types as the specific demon which needed to be slain while discussing that subset of the design). People in the know didn't need more understanding. People not in the know were happy to brush their lack of microarchitectural understanding under the rug. With that premise, both crowds were able to understand what followed.
That wasn't my first attempt. I have a bad habit of trying to explain those missing details as well, especially when it's clear the listener doesn't know them yet -- trying to get them into a position where they could've built the thing themselves -- but that only lands well with like 1-5% of people I've met.
Critically, agreeing with you, that's a communication failure, not an engineering failure. I understood the problem just as well in both cases; I just didn't understand the full extent of the people problem.
The proposed change doesn't do much for me personally (memory safety is ensured in other ways, and if it weren't I wouldn't be annoyed debugging the allocator-observed errors), but I could see myself using it at some other point in time for the same class of usages, or I could see other people relying on it when they choose that class of coding.
I think the whole problem is that they don't. Their systems are wholly unsuitable for _fully_ automated killing. Random schools and fishermen don't need to die because an administration stubbornly refuses to properly confront reality.
As I'm looking at it right now, there might be some nuance I'm missing in how HN works, but the post doesn't seem to be greyed out or anything, suggesting that if it is being downvoted then the upvotes are counterbalancing sufficiently.
> banning speech patterns
AI is prevalent and often bad. Society is reacting quickly but maybe not quickly enough. Blanket speech "bans" are part of that. Is that bad? Eh. It's not ideal. It's to be expected though. I work with the society I'm given, not the one I should have.
Not yet. Maybe soon. I'm not placing bets on timelines.
> What do CEOs do
No clue. I'm not there yet. Maybe it's critical. Maybe nothing.
> and other managers
There are a lot of bad managers. I'm halfway not terrible. A significant part of my job is setting technical direction in the same way I did as a staff+ engineer but without the overhead of asking somebody else's permission. Another large part is the "shit shield" function -- somebody thinks they want something, and they either find themselves blocked by me or immediately satisfied with whatever code I'm able to cook up between meetings, not breaking the team's concentration. A huge part is basically just being a teacher, and I love teaching (if it weren't so pessimized by society that might actually be my career). A large part of it is navigating organizational nonsense (for "reasons," I'm rambling, ask if you're curious). And... whatever. My job didn't get easier going into management. Not all of it should have to exist in the abstract, but in any specific company it's still an important function.
You're probably totally innocent, but this comes across as being AI-written, especially in the context of an AI problem and when your response is pro-AI. For the next 3-12 months (maybe more, we'll see), I suspect you'll have a lot more success if you shy away from those speech patterns.
Edit: This plays into something I observe in most "data-driven" organizations. Having a statistic available about recovery costs makes it easy to shift the conversation toward that statistic, when you actually ought to be asking questions about (in this case) the causal impact of that intervention on the subway's overall profitability, the need for easily available public transit and whether there ought to be a fare in the first place, the public good (or maybe harm -- the point is that we ought to be discussing it one way or the other) done by using fare-jumping collections as a mechanism for training people to be less antisocial in other aspects of their lives, or whether that obscene cost of fare collection is actually a reasonable baseline and should be improved. Your statistic, while interesting, is almost useless when trying to figure out what we should do next, at least by itself, and when paired with human psychology it can be actively harmful.
In music, you have voicing sparsity, changes in voice count, preferred pitch ranges, tension/release cadences, embellishments, richness, playfulness, and a host of other characteristics. Rachmaninoff, for example (among other things), favours active, moving octaves quite deep in the base, extremely rich chords in the middle treble, simple (local) rythymic patterns, and expanding simple ideas like repeated arpeggios into large parts of a piece. He has more voices than other pieces typical of his time, though they tend to be combined somewhat simply when contrasted with counterpoint exercises and other techniques typically involving fewer voices.
In writing, you have sentence length, sentence complexity (they're different), typical volume used to express an idea, specific word choices, whether you tend to observe concrete or abstract ideas, the level of "truth" in your statements (in many flavours -- deadpan humour being quite different from a boldfaced lie directed toward the reader), technique choice used for signposting, willingness to violate "rules," and so on. If you picked even one project proposal from me at $WORK, you could reliably separate it from those written by hundreds of other engineers just by a few quirks -- habitually providing one level of motivation deeper than is typically expressed in technical writing (not just what we're doing, but what we're not doing and why we made that choice), a tendency to use British spellings and US words, a pattern of contracting any verb tense, sometimes with multiple apostrophes (e.g., "there'll've been"), refusing to terminate a non-exhaustive list without informing the reader that it's non-exhaustive, and so on. If you look at the reasons and motivations for one of those quirks, it's that I tend to have complete ideas (in technical domains) and want to express them completely and have found that every missing detail causes eventual problems -- only tempered by the fact that the requisite length tends also to cause important details to be overlooked on a casual read, which provides a mild damper on length. Understanding that motivation makes it easy to apply it as if you were me even when you don't have concrete examples regarding specific quirk/scenario interactions.
The exact way I did, with an additional clause afterward appropriately scoping the statement and thereby not stating something overly broad :) The point is that destroying evidence, by itself, is not a crime. Additional elements are required.
> irrelevant to some other question
That's true. I just saw something not quite true (your police on the porch example) and thought somebody might find the extra nuance interesting.
Interestingly, digital vs physical _does_ also matter a little in a few ways (e.g., whether it's even evidence in the first place if it's digital). However, as that's worked its way through the court system over the years, it is practically true that in most cases you're right, at least as it pertains to this charge AFAICT; digital evidence has similar properties to physical evidence in the eyes of the courts.
To the legal search example, suppose the police frequently stop by your house to discuss neighborhood gremlins. If they happened to accidentally see the boxes of evidence you'd be in trouble. You're allowed to destroy them though, and you might have a habit of destroying evidence for each of these gremlin chats. Doing so is legal.
Later, the police show up with a warrant (your example). If you think you're doing your normal gremlin evidence destroying and not blocking that warrant, destroying that evidence is still legal even with the police waiting on your porch to legally, forcibly search your house. The _intent_ behind your actions, at least in this case, is a core component of the crime.
Mind you, nobody will believe you, so you'll still have a hard time in court proving it (this is mildly in your favour because it's actually the prosecution's duty to prove your intent rather than your duty to prove lack of intent, but they're not exactly going to have a hard time convincing a jury that when you destroyed a bunch of evidence with police on your porch with a warrant it was because of that warrant), but it's still legal.
"Multiprocessing" (multiple CPU cores independently executing and only able to coordinate via some message-passing system -- a definition which encompasses both multi-core CPUs and horizontally scaled distributed systems, contrasting slightly with the normal definition) is challenging for a few reasons.
Firstly, the details are an open math question, but I'll blindly state that some problems aren't amenable to parallelization. I.e., no algorithm can meaningfully improve performance via parallelization no matter the implementation. Think through how you would more quickly compute hash(hash(hash(hash(...)))) for example. The serial dependency makes things challenging. That isn't too dissimilar to the problem TB faces.
Secondly, message passing is expensive. If the only way two CPU cores can coordinate is through a multi-level cache, at best you're incurring ~tens of nanoseconds of latency per message. Contrast that with a base rate of 512 bytes processed per nanosecond with enough attention to detail on typical modern server hardware (4 pipelined AVX512 instructions at 2GHz). Messages are several orders of magnitude worse than your normal work, so if you need very many of them then you're hosed from a performance perspective (worse with longer delays, like networked computers). Even very parallelizable problems at an abstract level can suffer performance losses by trying to add even one extra core. This blog post [0] doesn't perfectly capture the idea, but it's close (and a fun read regardless).
Thirdly, message passing is an insanely complicated programming abstraction to reason about. My first two points were more about what TB was saying -- realities of modern hardware -- but the programmer experience is important too (even if you don't believe that post-2020, the LLM experience doesn't differ much from the human experience; bad code begets more bad code, slowly). The core mechanism for correctness in most software is being able to reason about "this thing is true, therefore that thing is true" and iterating. You rely on invariants like "this is sorted" to build other working theories. The invariants in multiprocessing code are much more nebulous and less amenable to accidental discovery, also less amenable to being able to build or compose them into other stronger invariants as you add code. The main reason for that is that you know almost nothing about the relative order of those messages with respect to each processer's view of which instructions happened when (and for purely multi-core "multiprocessing" the story is even worse; while my description of message-passing being the core primitive is correct, that's not what's exposed to you as a programmer, and different memory models can have even weirder interleavings than your code would naively suggest -- i.e., your code is being decomposed into smaller subunits than even a single assembly instruction, and the message passing happens at that level). The combinatorial explosion (an exponential explosion really, but big numbers either way) of states you might be interacting with makes it very difficult to understand _anything_ about the system you're examining. That's why you see a handful of primitives used over and over -- if you can decompose your problem into a parallel map plus an associative reduce then you can probably figure out some way to make it better through parallelization (not always, especially if the framework is too generic, see the linked blog post [0] if you weren't enticed to read it previously). If you can't decompose it into know primitives then it's an open research problem every time.
The crux of that third point (and we could definitely add more explanation and additional problems) is that there's a huge cost to multiprocessing. You have to be buying something substantial to even want to reach for it, else you have to be in one of the "easy" problem spaces where somebody else has done the hard work (e.g., stateless webservers).
TB isn't that. Their whole raison d'être is state management, and not in a way that's easily amenable to parallelization.
[0] https://adamdrake.com/command-line-tools-can-be-235x-faster-...
But my target is to waffle around 20% or so on average.
No, obviously that's not what they're saying. There must be some reasonable interpretation then, right? Let's look at the chat thread and see what we can find.
> be very cautious about evil uses of seemingly safe technology when developing initial capabilities
>> that's super hard since most things can be repurposed
>>> (your other comment) it's actually easy though, just look at how we could repurpose these death machines
>>>> (their comment) but...that's wildly inefficient
The subtext to their answer is going an entire opposite direction to your rant. People are saying that turning anything into a killing machine is easy, and their comment is saying that doing so is sometimes Pareto-suboptimal, and so wildly so that no semi-rational-at-least-a-little-bit-sometimes military is going to bother trying to weaponize your silicone basting brush or what have you.
They're not saying that you should mass-murder people, as you, yourself speculated.
1. For every natural, you can find a path of that length.
2. Therefore (nonstandard chicanery), for every hypernatural you can find a hyperpath of that hyperlength. Pick one for some infinite hypernatural.
3. Restricting that hyperpath to the original graph yields the infinite normal path you were looking for.
Whole problems melt away entirely as soon as you don't have to worry about clumsy "limit-based" approaches.