Do One Thing - <AUTHOR> http://radar.oreilly.com/2015/10/do-one-thing.html <comment><USER3> On the 'do one thing and do it well' issue, there seem to be two spectrums:

        1. suitability of a tool to multiple tasks
        2. number of features a tool has

This makes for sort of a field with four quadrants:

        1. simple but flexible tools
        2. complex and featureful tools
        3. specialized but simple tools,
        4. highly specialized and highly featureful tools

So take a tool like grep and it clearly belongs in the first quadrant. You can do a lot with it, but it's pretty simple to learn and use. Emacs (or Eclipse) belongs in the second quadrant as it can basically be used for anything and is complicated to learn. Something like MyPaint belongs in the third category and there are numerous domain specific tools that belong in the fourth.

So the question that remains when one is asking for a tool that 'does one thing well' is, do you mean for it to be specialized, or simple, or both?

<comment><USER4> In this context...

"specialized" = Do one thing

"flexible" = and do it well.

That said, the key ingredient of the Unix philosophy that is missing isn't specialised, flexible tools, it's composability of those tools. Imagine if you couldn't pipe grep output to another program, wouldn't it be a lot less useful? I'd say so.

There are ways we can get around this, but they would require a fair amount of development time. To give you one example, consider how the JACK audio server allows programs to share audio streams. Similar data streaming arrangements could be made for other types of data.

<comment><USER5> How does flexible mean do it well?

"Do it well" is so vague of a saying that it really could mean any of those things, whether it be flexibility, or simplicity, or etc.

<comment><USER3> My understanding of the phrase 'do it well' isn't as an injunction but as a way of saying that if you restrict your program to one thing, you'll have the ability to do it very well. It's to contrast it to a program that does multiple things, not so well.

</comment></comment></comment></comment><comment><USER6> I had two thoughts while reading this.

1 - The need for the web to be profitable in some way makes 'single tools' hard to build. You have to grow users, add features, etc, etc. So even if you have an API or something useful it likely won't scale economically. Unless it's government supported or behind a foundation of some sort. The Twitter API comes to mind here.

2 - This is tricky because for the web to meet the UNIX philosophy, everyone has to agree. You can't have the team that manages the equivalent of the `ls` website decide to change their output, or strike up a deal with the `diff` team to force `diff3` out.

Once again, capitalism ruins everything fun. That's hyperbole, kinda :-)

<comment><USER7> > Once again, capitalism ruins everything fun

And creates everything fun.

<comment><USER8> Depends. I accept the capitalism's ability to raise resources (capital) for larger-scale projects, but generally profit motive fucks everything up. The Internet was fine until every pathetic "enterepreneur" out there smelled easy money and come to ruin it all. It happens in every industry. Capitalism creates abundance - but abundance of worst possible crap sellers can still get away with.

<comment><USER9> The Internet wasn't even accessible to the general public without capitalism motivating the creation of ISPs.

<comment><USER10> That may be true. But, the Internet existed because of massive multi-decade investment from folks without a profit motive. All of the fundamental Internet protocols were created through those organizations.

Look at what capitalism gave us as an Internet like experience: compuserve, aol, etc. Those were all horrible closed wall systems.

<comment><USER9> But there are many massive investments at the academic and government research level that lead to nothing directly useful for consumers due to lack of investment interests in bringing it to market. Just look at the next generation Internet architectures that go nowhere. You can't ignore economics.

</comment></comment></comment></comment></comment></comment><comment><USER11> I'm definitely guilty of holding onto a philosophy and thinking it applies universally, so I can't blame people that hold onto the Unix philosophy extremely strongly. But I can't help but think that the world requires a hell of a lot more pragmatism than the Unix philosophy can provide.

The first problem I see is that "One Thing" is really subjective. Some people might see Postgres as doing one thing really well (It is, after all, an incredible Relational Database). But others might look at Postgres entirely differently: It is a client and a server. It is a data protection and credential management system. It is an in memory caching layer. It is a NoSQL key value engine. It is a SQL database. It is a data retrieval operation optimization system. It is a storage format. Hell, it does a million SQL things that other SQL databases don't...databases that probably also qualify as doing "One Thing" in other people's eyes.

The second problem is that the world is really fucking complex, and sometimes doing one thing well is impossible unless you also do one other thing well. Rich's big example in this article is Evernote, and his claim was that Evernote did one thing well, which was note synchronization. But notes are almost always more than just text...which was why they added photos and tables and web clippings. Who would ever want just the text aspect of their notes synchronized across devices, but not their photos that they took of powerpoint slides, their data tables, their diagrams, their emails, etc.? If Evernote wanted to do "Note Taking" well, they couldn't just stop at text synchronization across devices. So they should have stopped trying to do "Note Taking" well, because someone only used them for the text synchronization that they already did? Evernote is dying, that's for sure...but its not because it did more than one thing, it is because it didn't do them well.

I get it. People like simplicity. But the world is complex, everybody's view of the world is different, and that means that sometimes you just end up not being the target market. And I also get that some things actually do do one thing and do it extremely well. But trying to extrapolate that out infinitely across all things (or even just across all software things) just doesn't pan out in reality. And what does that mean for the philosophy? It should probably just be extended to "Do things well". But that is no longer a distinctive philosophy, is it?

<comment><USER12> > but its not because it did more than one thing, it is because it didn't do > them well.

In general I agree with your line of thinking, but I will nitpick on this particular sentence (or the way it's phrased) and say: the whole idea of doing only one thing is that if you try to do more than one thing, you will definitely not do them all well.

I do agree with you though. The "many things" that postgresql does are all actually just one thing: database system.

Yea some people could argue that under the cover it's many different things, but the whole idea is about focus, not about counting features. There are always multiple aspects to the "one thing" (whatever your one thing happens to be). Doing the one thing well means tackling all of these aspects.

The reason you can't do multiple things well is that each one of the multiple things you want to do will in itself have many aspects, and your focus will be fragmented trying to tackle too many things with very limited resources.

<comment><USER13> What if something if really good at being a website?

<comment><USER14> Or really good at being a platform.

</comment></comment></comment></comment><comment><USER15> It sounds like what he's actually arguing for is cohesion, not just simplicity. And if that's the case, I'm with him.

Cohesion is achieved when the degree of complexity is determined by both domain and audience, so Photoshop's relative complexity and Pixelmator's relative simplicity are both fine - in each case the domain is satisfactorily handled for the needs of the respective audience. They're both cohesive tools. Now if Photoshop decided to throw in a chat client (hello gmail), we'd be having a different conversation.

However, if the author is actually advocating breaking up Photoshop into a thousand pluggable little tools that everyone would have to piecemeal assemble into some sort of shared "workspace," that's where we (and most non-geeks) part company.

</comment><comment><USER16> 1\. Unix shell solved one thing very well: (unary) function composition based on a text protocol. It gets complicated already when you want to beyond a pipe - e.g. A graph like a makefile. Then you need to leave the pipe metaphor in nost cases and deal with artifacts like files. Even more so, map-reduce was a big shift that went beyond the unic metaphor.

2\. There was a different metaphor that had its merits: object composition through standard interfaces, e.g. OLE/COM and the likes. One might argue about its implementation (embedding a Visio object in a Word document still produces crashes, 25 years later), but as a UI metaphor it was very powerful.

3\. The web's metaphor is coupling of disparate content through URLs and HTTP (and HTML). One of the most mind-boggling metaphors ever introduced to man (talk about doing one thing well). Today we use REST APIs as the atomic pieces (do one thing well) and Javascript/ObjectiveC/Java as glue. Same thing.

4\. As for application it goes, "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp" (Greenspuns tenth rule). Slightly updated this means that as programs get more complex, they tend to become more integrated abd customizable, to the point where you use a high-level language to glue the different parts. If you're lucky they may have replaced a custom common lisp with a mature V8 engine, but the lore is still the same.

5\. Outside of academia, people (product managers in particular) tend to be focused on solutions, not abstractions. And for good reason: solutions are often shortcuts for common applications of abstractions, and therefore they provide lots of value. File.ReadAllLines() vs. doing the same with 3-4 Java classes in the old days is the best example.

6\. In the end, we need people to think about abstractions: unix pipes, map- reduce, URLs. And we need other people who think about solutions: The IPhone, the Google world etc.

7\. As for the OP: curl might be a good start of a pipe. Add a program that parses tables, and a program that posts to REST APIs...

</comment><comment><USER17> _> That philosophy was great, but hasn't survived into the Web age._

The modern "web operating system" is Amazon's AWS, and I'd argue that the unix philosophy survived surprisingly well there. AWS has many services; each one does a specific job really well, and they interoperate very well together. That's the very embodiment of the unix philosophy.

<comment><USER13> Yep. AWS is a great example. Many products that can be used very well together (S3 and Cloudfront, for example), but the chosen abstractions are such that they can be used independently as well.

</comment></comment><comment><USER18> I would like to propose a "cloud" addendum to Zawinski's law, which states that "Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can".

My addendum is: "Every cloud app expands to the point where it can host group chat. Those apps which cannot so expand are replaced by ones which can."

I think it's also possible that I may have to augment the addendum to "group chat and screen sharing."

<comment><USER19> I suggest it is package manager. Everything has it's own little little plugin management tools, for retrieving, installing etc.

<comment><USER20> If you're NOT writing a web browser, and the little voice in your head says something like "I know! I'll solve that by writing a plug-in system and let other developers write to my API, and all their code will run in a sandbox, and I'll write a virtual filesystem for them to use, and I'll provide an installation/uninstallation system, and maybe a debugger..."

STOP

Get up and walk away from the keyboard for a bit. Maybe take a refreshing shower. Clear your head and let yourself think this through a bit. You'll come to the right conclusion. Now go back to your keyboard and work on something that delivers value for your customers :)

</comment></comment></comment><comment><USER21> Unix pipes only work in the CLI with a text based interface and even then they break down when the applications aren't able to parse the data.

So one always ends up massaging the data to make them be understood.

Piping concept was actually more powerfull in Xerox PARC systems by using the respective language REPL and do LINQ style data transformations.

However the problem of the article is that once you scale out of the CLI, you need a standard communications API to this type of stuff.

One that is able work in distributed systems, dealing with all types of failure issues.

If anything, native programming on the mobile offers some kind of piping thanks to intents, contracts and extensions.

<comment><USER22> The Amiga ecosystem perfected this: most (good) software featured an ARexx 'port' \- an API, based on the REXX language, that enabled any one program to communicate with another. Or one could simply write an ARexx script to automate a process.

Here's an example of the first occasion I seriously used this, when producing a 3D anaglyphic animation for video: graphics frames - two images for left and right - were rendered in VistaPro (the original 3D landscape generator); as soon as rendering was complete, ImageFX (image processing software) picked up the output and combined the channels to make an anaglyph; this was then sent to the PAR animation recorder (a video recorder). So, THREE separate large packages from different software companies, working in synchrony with each other via ARexx. The whole operation worked so smoothly and efficiently, first time, that I still recall it with awe.

Sadly, yet another killer Amiga feature that never made it to modern computing...

<comment><USER21> The libraries concept used to extend the OS were another cool Amiga feature.

I would say the closest we have today to ARexx experience are Powershell and AppleScript.

</comment></comment></comment><comment><USER23> I am a great fan of the Unix philosophy and can sympathize with the author and his points, but I really don't know how realistic the whole "make the Internet a new Unix"-scheme is.

As others have pointed out, there are great practical difficulties in integrating different web services. Unix has pipes built into the core of the OS - anything analogous would have to be "bolted on" to the Internet, and thus probably turn out to be not as powerful or simple to use. And how about the UI and user friendliness? On Unix, every program has more or less the same UI - <USER2> couple of lines of text on a black background. The Internet? Everybody has a different fancy graphic layout. If you can do everything within the same "walled garden", that reduces confusion on this count.

For these (and other reasons, such as the aforementioned capitalism), I do not think that the mainstream Internet is ever going to behave the way the author envisions. What I could imagine, however, is a sort of parallel Internet that displays this property to some extent - a range of services explicitly targeting technical users (who are more likely to value the "do one thing well" approach and less likely to care if the GUI isn't quite as snazzy). These services would never grow big, but they could build up a loyal following. Kind of like HN, really...

<comment><USER24> The internet already has a very simple interoperable protocol, HTTP. There is nothing to bolt on really since the pipe is just a channel for text and sockets on port 80 can just as easily act as those channel.

<comment><USER25> But HTTP is one-directional (disregarding Websockets which is a client thing).

<comment><USER26> HTTP is asymmetric (the two sides are not interchangeable), but the information flow is bidirectional. I don't see how that it prevents something like Unix piping from being implemented between web services using it. Seems to be mostly a UX design issue.

</comment></comment></comment></comment><comment><USER27> I agree on the face of things, but what the web is missing from the unix philosophy is an equivalent to |.

Without the ability to string multiple, focused tools together even tools that did one thing well(i.e., Evernote) will continue to add features until it does a bunch of things meh.

<comment><USER28> Absolutely! And just follow that to logical conclusions, to me it seems to answer the question of why we don't have it, right?

On the web, "|" (pipe) means integration with other services, and it comes with all the associated trials and tribulations. To make web pipes work, just to even get started, you first have to solve authentication and data format/transfer standards. Those things are a big pain, its not surprising that most services attempt to provide the service directly.

Unix pipes were designed for builders, technical people who understand the structure of the data they're piping around. Posix commands come in a minimum standardized set that work well together, and while there are some commands here and there to pipe structured and/or binary data, the core set and what most people use pipes on and love pipes for is plain text.

The internet just doesn't have the same foundation or purpose or user base, its usage is not centered around technical people building pipelines, so its not surprising that web services by and large haven't flocked to meet a unix analogy -- its technically much harder to do than writing unix, and its not even clear its even close to a useful thing to do, for most people.

<comment><USER29> The other big factor is that pipes only work because of the power of plain text. The output of every UNIX command is ASCII text, and most of the time, it's ASCII text with columns delimited by \t and rows delimited by \n. And there are command-line utilities like awk, cut, sed, & xargs for parsing & rearranging that text, and funneling it into formats that other commands understand.

The web has a variety of other content types - images, videos, applications, structured data - that don't map well to this model. Before you have interoperable webapps, you need to define common data formats for them to interop.

<comment><USER8> I disagree with that. Pipes seem to work _in spite of_ plain text, being only made incredibly inefficient by it. A much better way is to send data structures through them (for which, btw. modern web is perfectly well-suited, with present JSON domination) - you can always render the data to text if you need, but you don't have to write arcane and bug-laden shotgun parsers with sed and awk because every step in UNIX polka means throwing away metadata.

Also: ditch plaintext for structured data and suddenly handling of other content becomes much, much easier, and they map perfectly to this model.

</comment></comment></comment></comment><comment><USER30> There is some merit to "doing one thing well", but taken to the extreme it can be horrible in a different way:

 _tar cvf - FILE-LIST | gzip -c > FILE.tar.gz_

([https://xkcd.com/1168/](https://xkcd.com/1168/))

<comment> ainar-g Rob in that comic clearly hasn't used Unix long enough to know about the Arnold mnemonic[1].

[1] [http://i.imgur.com/Vf0An8J.png](http://i.imgur.com/Vf0An8J.png)

<comment><USER31> What kind of tar are you both using that doesn't detect the compression type? tar -xf FILE is fine.

</comment></comment></comment><comment><USER32> Since no one mentioned Plan 9, I thought I will mention one of the many features that makes Plan 9, one notch above Unix to make it easy in the web era.

In Plan 9, literally everything has a file abstraction. This also includes sockets. So, even shell programs can be network programs without external programs like curl or wget or anything like that. For anyone interested, look at webfs(4). You may say that this _can be_ implemented with fuse. But having something first class, designed to operate well within the file abstraction, is very different from something that has been added as an afterthought. In some sense, the BSD folks who added sockets into Unix really screwed it up and missed the Unix philosophy altogether.

<comment><USER32> Modern 'Linux' systems are full of programs that violate Unix philosophy.

cdrecord, ffmpeg, emacs, dbus, imagemagick, all modern browsers ... the list goes on and on. plumber(4) does what dbus is trying to do, with very little amount of code and text file based rules.

I see it as a missed opportunity for linux kernel and hence to the wider audience to experience a computing environment that is a joy to use.

</comment></comment><comment><USER33> Ironically, his own blog includes a screen reader that appears whenever you select some text. Don't blind people already have good screen readers? I select text to remind me the place I'm up to, and get annoyed when little buttons pop up.

</comment><comment><USER34> economic incentives typically lead firms to look for new sources of revenue. they hope to achieve this extra revenue with minimal cost, ideally by not creating new products or developing new customer relationships. the natural side-effect of this situation for software companies is that they add feature- upon-feature to existing products in an endless quest for growth. at the very end of the road this situation doesn't usually work out well for the product, the user, or the company.

on the other hand there are plenty of services/applications that keep stable interfaces for many years at a time. they do not extend themselves too far beyond solving the problem they originally tried to solve. we can all imagine what craigslist would look like in the hands of short-term profiteers, endlessly tweaking the interface for more ad clicks and "user engagement".

the success of sites like the original google search, craigslist, and HN proves that the "do one thing, keep it simple" model is successful and can often be very profitable in the long term. sadly, it is very easy to forget about such ideals when people are constantly dangling fresh money in your face and/or you have salaries to pay. while page rank might be considered the key element to google's genesis and explosion, we also owe much respect to the people that decided and continually insisted that the UI stay clean and minimal.

</comment><comment><USER35> There is always <iframe>. You can easily embed a youtube or vimeo video even if your core product is not displaying videos. I always felt that iframe is a bit of lost potential, what it needs is a javascript api so that you can communicate back and forth with the frame/plugin, last time I checked this was not allowed due to same origin policy.

After the communication channel is in place it needs a few standard interfaces, maybe there could be some video player interface with play/pause/seek functions. These dont have to be included in any w3 standard, its more of a de facto standard or agreement that if you make a video player and don't implement the IAwesomeVideoplayerInterface, websites will not allow embedding of your product.

What's sad is that it seems like vendors are trying to move away from this model, Facebook is the prime example of this with hosting of a copy of embedded videos and displaying linked news inline in their own format.

</comment><comment><USER36> IMO there is a limited market for mature ideas that is often much smaller than the previous prediction. When startups start meeting this boundary, instead of reigning in expectations and become an efficient tool serving a small market, it's "go big or go bust" with desperate attempts to validate the previous market size predictions.

Sooner or later, you're bumping into the markets of other companies and it's impossible to compete against them b/c you're using your weaknesses against their strengths.

There is only so much money and attention (time) in the world for people to spend on things. The low hanging fruit in developed countries has already been plucked clean so it's quite hard to 'grow' new markets. Your new tv series better be REALLY good if you're competing with game-of-thrones and breaking- bad.

Interestingly enough, the Chinese companies actually have many more features and are often better (for their users) than the american counterparts. The population is more homogenous and has more of a crowd mentality. Network effects are huge. Monopoly-like companies also prevent too much fragmentation meaning technology as a tool becomes standardized. Rather than 20 different things competing for the attention of everyone, there is one big company with apps that do everything that is trusted and reliable and thus the 'best'.

While american companies compete for slices of a certain size of pie, one chinese company owns the entire huge pie. As long as the users have pie, they are happy.

In allocation of limited resources, this usually fails as equal distribution of resources leaves everyone poor which creates huge incentive for corruption and hoarding. For abundant resources that can be duplicated infinitely and have network effects to boot this is perhaps a better strategy.

After all, it's all about everyone having an abundance of pie, not who has more or less pie.

</comment><comment><USER37> There is nothing inherently wrong with complexity. Complex things can be made to appear simple, usable and open too. It is just that, when it comes to software, we haven't yet figured out a way of building complex systems that are beautiful (in a very broad sense of the term). Whenever we try to create anything complex in software it inevitably turns into a mess.

Also software engineering sounds unglamorous today and research in the field seems to have stalled. And therefore the craving for the simplicity of the Unix philosophy. Not that the Unix way of working actually solves the problems posed by software complexity, it just asks us to avoid complexity.

</comment><comment><USER38> > The first person to create a tool that can pipe a table from a browser into > a spreadsheet...

Wait a minute. This is called the clipboard. Try it -- you can just copy and paste the table into a Google Doc and it Just Works. What's missing?

<comment><USER39> It's missing the ability to build an automated process. Clipboard operations are designed to be manual.

<comment><USER21> Or called by a script. Problem solved.

</comment></comment></comment><comment><USER40> Evernote never even did the one thing well. I would add an item to a list on my computer, and then later add another one on my phone, and the next day both sources would be missing one of the edits.

</comment><comment><USER41> Hardware suffers from the same "walled garden" mentality. Why the heck would I want a "smart TV"? A TV exists to display video. It should have lots of inputs and maybe some outputs for audio. If I want to get video from a VCR, a flash drive, or a web service, I should be able to plug in a device to do that. And unplug it when it becomes obsolete.

</comment><comment><USER42> Then along came systemd....

</comment><comment><USER43> > I've been lamenting the demise of the Unix philosophy: tools should do one > thing, and do it well.

1983 was a while ago: [http://harmful.cat-v.org/cat-v/](http://harmful.cat-v.org/cat-v/). That's a long time to lament something.

</comment><comment><USER44> >The first person to create a tool that can pipe a table from a browser into a spreadsheet, a Google doc, or even a text file without massive pain will be my hero.

Pigshell.com

</comment><comment><USER45> Everyone wants to be the walled garden [https://xkcd.com/927/](https://xkcd.com/927/)

</comment><comment><USER46> "That philosophy was great, but hasn't survived into the Web age."

As one who still writes shell scripts for my work that do such a thing, and programs, too, I disagree as every Unix and BSD coder I know still does these things. It still serves us very well; far better than the glut of so-called package managers that pretend they can do better than 'make'.

I chalk a large portion of this up to those creating web pages without any real programming knowledge, training or background. Those who only know how to cut/past/npm everything they do. These are the same who think Unix is old and not modern.

I took an interview with a small company yesterday. There the creative director asked me what tools I knew and spewed out everything but the kitchen sink that they use. I was aware of all of them but questioned why he needed any of them.

You see, I've been running a web dev company for 11 years and have never found an advantage to any of it. He asked how we survived without npm or bower or etc. but, when I asked him if he knew how to write a Makefile, he didn't even know what it was or what it did.

A lot of the tools we use are things we built up over time ... or last week. Today's "modern" tools may be "instant on" for those who can't write a Makefile either but that's a fault and not a feature. If you need npm or bower to manager these things then what happens when something breaks, goes away, or becomes unsupported?

I stuck with npm and bower cause, when I tried to write about Angular and other things it got too long winded.

One of my points is, all the tools you need are already built into any Unix/BSD system so why look elsewhere? Those who do are only looking for quick fixes, as I pointed out earlier, and not interested in the science behind it. Creatives who want to build a web site but have no interest in the technology. They can get it to work, eventually, but "it works" is good enough.

No it's not. That's why smart companies hire mine.

<comment><USER47> What does your comment have to do with interoperability between web services?

<comment><USER46> Part of my comment was about his statement that the Unix philosophy is something of the past, which is false. Parts of the rest of my comment dealt with what he said about the plethora of "one size fits all" tools people are using now instead of the simple tools.

Can you not make the connection?

<comment><USER48> The OP was talking about web apps. What do Makefiles and npm have to with Evernote or Dropbox?

<comment><USER49> Why use a web app to take notes when one has vi or emacs?

<comment><USER50> Because it's really convenient to be able to make a note on your phone or tablet, then access it and make additional post-meeting notes shortly thereafter, on a laptop, all in the same interface (so you have the same features, or at least a set of common features).

That's just one, assuming you never want formatting, tables, pictures, etc.

<comment><USER8> Oh Emacs does tables[0] better than anything out there, except maybe MS Excel. Definitely eats stuff like Evernote or Google Drive for breakfast.

[0] - [http://orgmode.org/](http://orgmode.org/)

<comment><USER51> I love org mode but due to the fact that emacs doesn't run on my phone and Evernote does, I take notes on Evernote when I'm not at my computer

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER52> People mean a lot of things when they say "one thing". "Do one thing" can mean "replace all occurrences of one string with another". Or it could mean "browse the web", which of course isn't really one thing but a thousand things.

<comment><USER53> I've always wondered how Emacs fits with Unix philosophy? With it you can replace strings AND browse the web, but also play games, do file management, email, chat, etc...

<comment><USER54> Emacs doesn't really fit with the Unix philosophy. Emacs came from the MIT AI Lab and ITS, not Bell Labs and Unix - it got included with most Unix distributions later.

Editors that do fit with the Unix philosophy (they were written by its original developers) are ed sam and acme.</comment></comment></comment>


How Bochs Works Under the Hood (2012) [pdf] - <AUTHOR> http://bochs.sourceforge.net/How%20the%20Bochs%20works%20under%20the%20hood%202nd%20edition.pdf <comment><USER2> I did a bunch of hacking on bochs for a little virtualization toy project last year and found the source pretty easy to follow, at least much more-so than qemu. Wish I knew about this overview doc before then...

</comment><comment><USER3> I would love to have a 3DFX->GL plugin. Also, some optional JIT, but that breaks Bochs' philosophy. If it was X86 focused, it would work as DOSEmu. Fast but without falling into the virtualisation trap.

As a curiosity, I tried NT4 under Bochs and Unreal Engine based games worked well... albeit at 3-4 FPS. That emulated under an AMD Turion64 from ~2005-6.

Bochs emulates a VooDoo and 2/3 are WIP, so in a near future it mayb be an easier to setup alternative to PCE/Box86.

A Ryzen probably will be able to push Deus Ex under Bochs with no issues at all.

</comment><comment><USER4> The document states:

>"In order to reduce the complexity a bit, all the decoding of the operand fields is done first and then the instruction is executed by one of many hundred small methods that don't have to care(much) about their operands."

I'm confused by this, the operands are decoded first and then the op code is decoded? Or am I reading this incorrectly?

</comment><comment><USER5> > Some of them are gross speed hacks, to cover up the slow speed that C++ > causes.

That's certainly an interesting sentiment in 2012…

<comment><USER6> I don't know about 2012 but in general if used correctly C++ can often be faster than C due to the widespread inlining and the use of templates. (On the other hand, if one writes C++ as if it was Java - the code will be faster than Java's but often can be optimized further indeed.)

<comment><USER7> If you write C++ like it's Java, it will be slower, mostly for two reasons:

\- A C++ compiler cannot do speculative devirtualization. Which hurts if you split everything into small virtual functions.

\- If you are churning through lots of small allocations and aren't maxing all CPU cores, a garbage collector running in parallel is nearly free - unlike the bookkeeping your C++ deallocations have to go through.

<comment><USER5> > A C++ compiler cannot do speculative devirtualization.

Yes, it can! For example: [https://godbolt.org/z/-JtSiJ](https://godbolt.org/z/-JtSiJ)

<comment><USER8> A AOT compiler (almost all C++ compilers are AOT) can't do speculative devirtualization _based on dynamic runtime feedback_. (PGO is one-shot.) That's what the OP meant.

<comment><USER5> Fair enough. That's why there's the push in modern C++ for compile-time static dispatch :)</comment></comment></comment></comment></comment></comment>


Ask HN: Are SF and NY the best cities for programming jobs? - <AUTHOR> <comment><USER2> All you need is one job. One solid reliable job. Find that job in any city you like and you have found the best city for the programming job you like.

This is my own personal disclaimer, I don't believe in seeking "fun jobs." I believe in bringing fun into my work environment, whatever the hell it is. If I'm writing Cobol, Java, Python, a book, cooking or mowing the lawn. Find a way to make it a joy!

I also believe that you should make the most of the city you live in.

With that said, I'm in Detroit, having a grand time both in the city and with my tech job. :-D So, go find your best city and your best job!

<comment><USER3> > I also believe that you should make the most of the city you live in.

Care to talk more about this. I know it might seem obvious, but I would really love to hear how you make the most of living in Detroit for instance.

<comment><USER2> It's like any city, there are tons to do. When we talk about Detroit, we talk about the Detroit Greater Area, not just the city of Detroit. But all the cities around it.

There is an awesome tech scene here too, Detroit downtown is bubbling with a lot of startups, and we interact with the scene in Grand Rapids and Ann Arbor. Lots of tech meetups.

If nightlife is your thing, there are tons of places for that from Windsor, Ontario which is just across the river, to Royal Oak, Rochester, Birmingham, Dearborn.

If you're a foodie, there are tons of great restaurants out here, my favorite are the hole in the wall spots with great and cheap food. Tons of farmer's markets if buying fresh and preparing a meal is yours.

Lots of golf courses, Michigan ranks #6 by golf.com. If water is your thing, there are lot's of waters, boating is big. Michigan has always been the #1 country by boat registrations in the US until California just took over, we are still #2.

Big on sports, we have an NFL team, NBA team, NHL, MLB and of course college sports team, we have Univeristy of Michigan and Michigan state with great teams.

Proximity to other places is not too bad, 4 hrs drive to Toronto, 4hrs drive to Chicago, 3 hrs to Columbus or Cleveland.

Cost of living can be cheap, you can buy a $50,000 4 bedroom house or a million dollar 4 bedroom house. If you are wise and buy in the cheap areas, you can save a lot of money for your future.

</comment></comment></comment><comment><USER4> I've lived in both -- SF for an internship and NYC as a startup cofounder for a year.

Coming from a university where 90% of people go into banking (NYC), and as someone who has never really enjoyed socializing with computer science people outside of work, I prefer NYC to SF. It's nice to leave work and chill with people of a different variety than I interact with all day. No talking shop, just hanging out with friends.

There's no shortage of programming jobs in either city, and the salaries minus cost of living are roughly equal. The biggest difference to me is that SF is a monoculture centered around tech, whereas NYC has a couple different monocultures, banking being the dominant one.

I really despise monocultures in general so I like that NYC has options to choose from. Also, lots of my friends live there.

All that said, I'm now a "digital nomad" traveling the world and switching cities every month. I am 100x happier now than I was in either NYC or SF.

</comment><comment><USER5> I'm surprised to hear you mention NY in the same context as SF. Has it really come up so much? I'm willing to believe they've developed a respectable industry out there, but so far as I have heard it's mostly just financial and ad industry stuff, nothing terribly interesting.

<comment><USER4> There are a lot of startups in NYC. Also, if you want to found a startup, there's a lot of capital and the angel scene is quite big.

Digitalocean is a good counter example to your stereotype of NYC companies.

</comment></comment><comment><USER6> Define "best". There's a lifestyle associated to those cities that not everybody prefers.

<comment><AUTHOR> It should have a good support system for you as a programmer (lots of programming related meetup, etc) and lots of other programmers.

<comment><USER7> Then yes, SF/Silicon valley is the place for such things. Don't know about NYC

<comment><USER8> You could not attend half of the tech meetups in NYC. Columbia, NYU, CUNY, Cornell, SUNY Stony Brook -- Boston is a 30 minute shuttle flight from LGA -- indeed the whole Ivy league plus CMU, MIT, Northeastern, BU &c., are handy, so a lot of innovation is going on. And most of the money is here.

That said, Seattle has to be in the running.

</comment></comment></comment></comment><comment><USER9> Depends on what you want to do both have strong market demand for very different sorts of programers.

Do you want to work on the web or on a mobile app then SF is the place to be. There is also tons of Machine Learning, and infrastructure companies in SF.

Do you want to work in financial services (market related, not personal as much)? Then go to NYC!

Can you be a web guy in NYC or a financial services guy in sf?You sure can, but each is the land of opportunity for a certain category of programer.

</comment><comment><USER10> Best, in terms of what?

In terms of volume of jobs - definitely and as @lazyant mentioned, there's a great support network that comes with it.

If you measure 'best' by quality of jobs, I would agree as well.

Other cities which you may want to check out are Seattle, Austin, Dallas which have a chunk of 'good' jobs as well!

</comment><comment><USER11> This popped up recently: [https://www.glassdoor.com/blog/25-best-paying- cities-softwar...](https://www.glassdoor.com/blog/25-best-paying-cities- software-engineers/)

Which compares cost of living to wages to number of jobs.

</comment><comment><USER12> Also depends on your experience. Junior/Entry-level positions _can_ be harder to come by in SF. Then again, I am just biased since I've been looking since February.

</comment><comment><USER13> Depending on the industry you can find jobs in different places.

You have medical and defense that is far from solely represented in the Valley and New York areas.</comment>


Low Quality Offensive Ads Degrade the Web Experience - <AUTHOR> http://blog.louisgray.com/2010/02/low-quality-offensive-ads-continue-to.html?utm_source=feedburner&utm_medium=twitter&utm_campaign=Feed%3A+LouisgraycomLive+%28louisgray.com%29

<comment><USER2> Get rid of rebills and you will get rid of about 90% of those ads. They exist only because (affiliate) marketers get $30+ per action to get someone to pay $4.99 for a grant kit, a bottle of diet pills, etc. The fine print, of course is the victim gets billed $80 in 7-30 days if they don't cancel (which is nearly impossible to do).

As a result, the marketers will jump through just about every hoop possible to get you to click. They don't care what you think, they don't care if you're offended, they want their $30+ and they will do whatever it takes to get it.

Also: I'm still pretty convinced there are huge opportunities in the ad space on the internet and in mobile. We're just getting started, which is why the whole online ad game still has a "wild west" feel to it.</comment>


Against Librarization - <AUTHOR> https://write.as/p3csqbmkyno8pb99.md <comment><USER2> Is this a joke?</comment>


Chef Part 2 - Performance - <AUTHOR> http://engineering.voxer.com/post/45944103472/chef-part-2-performance

<comment><USER2> To me this seems kind of like what I was afraid of way-back-when, when choosing a CM system. I eventually went with Puppet because basically I was afraid of this kind of thing happening. Because Chef uses Ruby for the configuration language this seemed to me both an advantage and a huge disadvantage.

Basically, Chef is giving you enough rope etc. With Puppet at least, you CAN get into trouble and make your manifests take these kinds of length of time to compile, but it's relatively difficult. Additionally, I believe the equal of 'searching' in Chef is PuppetDB. In my experience at least, resolving stored facts from PuppetDB is extremely fast, as in, fast enough that you don't know it's actually doing much of anything on a database level.

Really I think the take-away from this is be careful what you do with CM. It could end up making more, not less work for you!

<comment><USER3> Well, searching in Chef isn't like querying a DB, it's a full search against Apache Solr, a nice wrapper for the Lucene search engine and is capable of various powerful searches.

<comment><USER4> There is something very wrong, if you can't search a corpus of 200 documents of roughly 512kb size each with solr in milliseconds. Especially on something as simple as a simple field/facet search for node role match. 2-3s per search sounds like something else is the bottleneck rather than solr.

<comment><USER5> +1 for this comment. 2-3s per search is TERRIBLE performance, and disgusting given the document count / index size.

</comment></comment></comment></comment><comment><USER6> There is a partial_search available with chef server 11 that makes this problem much less painful. Search returns the entire node object for each match, which can be a ton of data as the node count rises. With partial_search you specify just the attributes that you to be returned.</comment>


A new study uses camera footage to track the frequency of bystander intervention - <AUTHOR> https://www.citylab.com/life/2019/07/bystander-effect-stranger-danger-crime-public-safety-video/593755/ <comment><USER3> The infamous murder of Kitty Genovese in 1964 was reported the medias as 38 witnesses in an apartment block saw or heard the murder but none did anything to save her, not even call the police. In 2007 someone digged into the story and discovered that this was wildly exaggerated. Only a few witnesses has seen the violence and they did in fact call the police - the police just didn't respond in a timely manner.

[https://en.wikipedia.org/wiki/Murder_of_Kitty_Genovese](https://en.wikipedia.org/wiki/Murder_of_Kitty_Genovese)

Of course the original story resonated because it played into the eternal narrative that people "these days" don't care about each other, society is falling apart etc.

<comment><USER4> > people "these days" don't care about each other, society is falling apart > etc.

Interesting point.It was 1964. The same people that complain about the current generation.

I think that it's great that this myth of debunked. People wants to be good. Give people education and means and they will run a society smoothly.

<comment><USER5> Every generation thinks they invented casual sex, every generation thinks the new generation is ruining the world. This has been true as long as history has been recorded.

<comment><USER6> /insert lyrics from "We Didn't Start the Fire"

</comment></comment></comment></comment><comment> pure-awesome I had a realization the last time we had a fire drill:

It wasn't scheduled, so when the alarm went off, we all looked at each other for a few moments like "is the siren just on the fritz or should we walk out?" After awhile we decided we'd better get going so we all lazily strolled outside.

On the way, I noticed one of my coworkers in a fire marshal uniform, in the corridor, calling out for people to evacuate.

I realized this is a perfect way to prevent the bystander effect: just give a random person a "uniform" (a whistle, a badge, a hat, or a vest, anything simple like that works) and tell them that when the alarm goes off, they are responsible for telling people to leave.

It's as simple as that. Instead of us staring at each other trying to decide whether the group considers it serious enough to go along with, just having that person singled out as the "official" one was enough to get the momentum going.

<comment><USER7> Relatedly, if you ever need to delegate something like a 911 call, you're supposed to single out a person and tell them, specifically "you, go dial 911" rather than shouting "someone call 911!"

Apparently this makes it far more likely to actually happen.

<comment><USER8> Interestingly the standard procedure in The Netherlands for medical emergencies (the ones where you find someone on the ground) changed to actually calling yourself over asking a random bystander. Aside from calling you should also put the phone on handsfree and lay it next to the person (on the ground).

This as 112 (911) asks loads of questions. Age of the person, conscious yes/no, what does the skin look like, feel like, etc. If it's about CPR it'll be way easier of course... but procedure is also to call asap. Meaning right after you find the person on the ground.. not after you checked.

I had to call 112 this week. In practice things are often different than any procedure ;)

<comment><USER9> I find this approach of taking individual responsibility much better than handing over authority to a "person in a uniform" as the GP stated. Sure it's easier to blindly trust the "official" one, but it sets up a disempowering dynamic where the group is clueless and only looking for a charismatic leader to point them in the right direction. For something cut as clearly as a fire alarm, there is no reason why everyone over 10 years old can not respond properly as single unit.

> Instead of us staring at each other trying to decide whether the group > considers it serious enough to go along with, just having that person > singled out as the "official" one was enough to get the momentum going.

<comment><USER10> Authoritarian structures work quite well in crisis situations, where acting quickly is imperative. It's why the military has such a rigid command structure and political leaders have emergency powers.

Democratic processes work better for longer term planning when there is time for debate, compromise, and developing a deeper understanding of the issues.

</comment></comment></comment></comment></comment><comment><USER11> Two things:

\- Cameras may have caused the Hawthorne effect: [https://en.wikipedia.org/wiki/Hawthorne_effect](https://en.wikipedia.org/wiki/Hawthorne_effect)

\- The article (the news one, haven't read the original yet) talks about the increase of probability that _some_ bystander will act, with increase in group size. The bystander effect study talks about the decrease of probability that _a particular_ individual will act, with decrease in group size. These two things may very well both be true and there may be some non-linear effect at play (i.e. after a certain group size, the increase in the probability of someone acting wins out over the decrease in any one person acting.

<comment><USER12> We should also consider that if there's a larger crowd of bystanders, an individual will feel more sure that others will help them as long as they act. "Safety in numbers" so to say.

<comment><USER13> My first experience I put down to bystander effect:

I was giving first-aid to a guy with severe lacerations to his hand/arm and didn't want to leave him (partially panic on my behalf) - in a UK city, albeit a side-road, with shops and people walking past - but needed to call for an ambulance.

Nobody would stop and help:

"Help! I need you to call an ambulance."

and people just carried on walking.

In the end I was able to makeshift a bandage with some clothing and leave the guy sitting on the floor long enough to use the phone in the shop I was working at.

The ambulance, despite having the address and business name, drove past and I ended up running after it down the street ... overall an awful experience and very eye-opening.

My takeaway is that I'd give up much sooner seeking help from others, depressing as that is, and - contrary to my first-aid training - leave the patient and call an ambulance myself.

Aside: I wonder if there's a villager/townie effect too?

</comment></comment></comment><comment><USER14> A relevant, classic bystander-effect experiment (Darley and Latane 1968) put several participants, all subjects of the experiment, in a waiting room. Smoke began to come into the room through a vent. In most groups, no one acted for a very long time, even after the smoke led to breathing problems for participants. By contrast, when only one person was in the room, not a group, that person would almost always leave the room or call for assistance.

Differences from the OPs (very interesting) study: 1\. In the smoke room, participants know they are in an experimental setting, though they do not know that the waiting room is part of the experiment. 2\. The entire group is visible in the waiting room. (In a crowd outside, you don't know who else might be acting or watching. In the waiting room you can see that no one else is doing anything.) 3\. The threat is to you personally as well as to the others in the group - an injury or a fight involving others is less personally affecting than smoke that is making you cough in an enclosed room. 4\. D & L experimented with small groups including a single person and saw dramatically different results in the latter case. I'd be interested in seeing what happens late at night when there are just one or two people around - what do the camera show then?

Of these I suspect 2) has the greatest effect. If I see that literally no one in the room is doing anything, I may figure that the situation is probably under control or isn't a big deal. In a big crowd outdoors I can't draw that conclusion as clearly.

<comment><USER15> Could it be that in 1968 you felt social pressure to keep cool and calm and unafraid? In that experiment, the presence of "confederates", people who cooperated with experimenters made everyone much more passive.

In 2019 you feel social pressure to act to look responsible and less pressure to look unafraid, so we think differently.

</comment></comment><comment><USER16> This is all anecdata, but the article and the study are totally contrary to my experience.

Over the years I've witnessed a variety of incidents where bystanders did nothing -- however once someone makes the first move, it seems to become easier for others to lend a hand.

When I was a teen, I dated someone who was a red cross volunteer, which prompted me to take a couple of first aid classes. This has easily been the most useful subject I've ever studied.

I've been witness to a suicide attempt, a cardiac arrest in a bar, an elderly lady who fell down the stairs at the opera, several cases of guys beating on their wives in public, two drunken attempted robberies, a variety of (literal) gay bashing, random subway violence, and oodles of shit I can't recall. The latest was two weeks ago: a hit and run with a teen victim with a very nasty headwound.

In every one of those cases, no one did anything. The old lady at the opera was the worst, I hadn't seen it happen, but I noticed a crowd of people on the staircase on my way out. Maybe 20 people standing around her in a circle. I asked if anyone had called for an ambulance yet, and no one even gave a coherent response...

I've also been the victim of a random assault, in a very busy park in broad daylight, and no one helped out. No one even dialed the emergency number, no one even approached me to ask whether I was ok afterwards. There were probably around a hundred witnesses.

I don't know whether this is a regional problem; most of these incidents occurred in Belgium. Belgians aren't the most outgoing or the most eager to take risks in general, but still.

Don't count on others to make the first move. Learn first aid and help out whenever someone is in trouble. Even if it does mean you'll be late for that important meeting or you could get blood on your shirt.

Violence is a bit trickier; what's worked well in my experience is to walk up to the aggressor, but to pick someone else from the crowd and plainly tell them "give me a hand". That gets the ball rolling.

Edit/addendum: every time something like this happens, I get an adrenaline rush and am scared out of my mind. I'm sure this happens to the other witnesses as well. I get it, it's hard to push through that, but do it anyway.

<comment><USER17> > several cases of guys beating on their wives in public, two drunken > attempted robberies, a variety of (literal) gay bashing, random subway > violence, and oodles of shit I can't recall. The latest was two weeks ago: a > hit and run with a teen victim with a very nasty headwound.

Wow, I had no idea Belgium was so violent!

<comment><USER18> And you still have no idea. These are anecdotes collected over a long period from which you can infer nothing.

<comment><USER16> Indeed. I certainly did not mean to imply that Belgium is particularly violent. These anecdotes span about two decades. Having spent most of that time living in dense population centres, usually in the poorer parts of town, has certainly added some bias to my sample.

</comment></comment></comment></comment><comment><USER19> It's quite shocking to me how many social science and social psychology experiments have been debunked in recent years. It's as if the whole field is filled with false research. They should do what psychology has done and start a massive replication effort of most cited results. [0] That should bring back some credibility back to the field.

[0] [https://www.smithsonianmag.com/science-nature/scientists- rep...](https://www.smithsonianmag.com/science-nature/scientists- replicated-100-psychology-studies-and-fewer-half-got-same-results-180956426/)

<comment><USER20> Social psychology is very hard. Making correct experiments is hard, costly, often unethical and highly culture-dependent.

You can only get so far with questionnaire handled to middle-class/high-class university students...

<comment><USER21> Plus I would expect it would also be a function of the legal system. Some countries like France are typically hostile to self-defence / vigilanties as opposed to a country like the US. If you intervene and the assaulter gets hurt, you might be in significant legal troubles.

<comment><USER22> I was shocked to learn about the difference a while back, especially concerning first aid. In Germany you are facing criminal charges if you dont aid injured people, by either first aid or calling an ambulance. Then you have countries where not even dragging a person out of a burning car is protected under good Samaritan laws.

</comment></comment></comment></comment><comment><USER23> Besides the dangers of getting involved, it's sometimes hard to tell whether something is a serious incident or just people fooling around. I've seen both sides of this: Guys I assumed to be friends jokingly greeting each other while in fact one was starting a serious fight and the other one was too drunk to react appropriately. At some other time, I saw a woman yelling at a man, while he was somehow holding her. Seconds later, they were laughing and walking off side by side.

</comment><comment><USER24> I know this is an "armchair academic" comment, but I wonder if `places that are likely to have active surveillance` strongly intersects with `places that the bystander effect is less likely`. In other words, I wonder if there's a crippling selection bias.

The reason I think this is possible is because I'm way more likely to help someone if I don't think I'm endangering myself by doing so. Areas that are actively surveilled are probably more likely to be safe areas for me to do so.

<comment><USER25> Surveillance cameras do not correlate with "not in danger". It's not like people are watching these things in real time and jumping to action when they see something. After all, if that were the case, then there'd be no reason for bystanders to even get involved in these incidents at all.

<comment><USER24> I'm not as confident as you that they "do not correlate with not in danger." And I'm much less confident that they don't correlate with "perception of danger."

They definitely correlate with a lot of things. They correlate with buildings and power lines. And other things. And I think some of those things correlate with perception of safety.

</comment></comment></comment><comment><USER26> The article only uses footage from a few cities of Western culture. Good Samaritan laws are not universal and the lack of one can have a chilling effect on whether people will help. This is especially prominent in China where there are a number of famous cases where the victim sued the Good Samaritan claiming they caused the damages. It's so prevalent that Alibaba is trying to help promote social good by offering insurance in case you help the elderly and are sued for it: [https://www.chicagotribune.com/business/ct- china-good-samari...](https://www.chicagotribune.com/business/ct-china-good- samaritan-insurance-20151020-story.html)

<comment><USER27> That's not the bystander effect though. In China, they're afraid of legal repercussions. In the bystander effect, it's diffusion of responsibility. Same effect but different causes.

<comment><USER26> Fair and interesting point. The same outcome is irrelevant to the supposed phenomenon that causes it, though the study wouldn't be able to tell the difference.

</comment></comment></comment><comment><USER28> > Instead of more bystanders creating an immobilizing "bystander effect," the > study actually found the more bystanders there were, the more likely it was > that at least someone would intervene to help.

Perhaps with more people around one person considers that he will gain support, so the danger of acting will be minimized.

<comment><USER29> Or simply that in this case, the bystander effect didn't occur.

It's also why today when something goes wrong, people are told to look directly at specific people and say "call the cops"/ "hold their head" and so on,

<comment><USER30> Or that the bystander effect _did_ occur, but that X% of people aren't affected by it, and in a larger group it becomes more likely that one of those X% of people will be around.

<comment><USER31> Or maybe we all learnt about the bystander effect and were inoculated against it! :)

</comment></comment></comment></comment><comment><USER32> If the bystander effect did exist, even the ambient possibility that you might be under surveillance at any given moment (as might be felt increasingly around the world, in 2019, regardless of who you are, time or place) seems like it would make dramatically less likely that the effect would actually occur.

</comment><comment><USER33> isn't it also possible the fact that alot of people have heard of the bystander effect they more willing to do something because they believe no one else will?

<comment><USER25> You could also argue the opposite: That because the bystander effect is well- known now, surely that means other people in the crowd will be more willing to act, and therefore you don't have to.

<comment><USER13> Or your lack of helping is normal and so is excusable and one motivation (fear of doing wrong) is depleted.

</comment></comment></comment><comment><USER34> This article incorrectly claims that the bystander effect is when a group of people are less likely to help than an individual, when in fact the bystander effect is when an individual becomes less likely to act in the presence of a crowd. The article repeatedly makes this claim, but it's not hard to look up how the bystander effect is described and defined to see how completely wrong this is.

<comment><USER35> Um, what? The article doesn't do this at all. This is straight from the 2nd paragraph:

"The "bystander effect" holds that the reason people don't intervene is because we look to one another. The presence of many bystanders diffuses our own sense of personal responsibility, leading people to essentially do nothing and wait for someone else to jump in"

It's clearly talking about individual behaviour in the presence of a crowd. You basically restated this exact point, then claimed the article didn't make it!

<comment><USER36> But does it really debunk that effect?

The article essentially claims that the more people there are the more likely it is that _someone_ will intervene. Which isn't the same as no one feeling less inclined to help since there are other people around.

<comment><USER25> The whole point of the "bystander effect" is that this diffusion of responsibility leads to nobody intervening. Nobody cares if the chances of a _specific_ bystander intervening goes down when there's a crowd, all that matters is whether someone intervenes, and the bystander effect claimed that a crowd meant the chances of intervention would go down overall.

<comment><USER37> I'm understanding that's not the finding, although that's the popularly understood point. You would expect each person to be individually less likely to help when there are other people around. Somebody else _might_ have already intervened, and you might just be getting in the way. Not everybody can help, at least not at once. I mean, in some situations, people actually fear to intervene, and have a legitimate fear for their own safety, but if they can call the police once they're secure (or if they are clearly secure e.g. viewing from a distance), people do it. A lot of people called about Kitty Genovese as it was happening, watching it from their apartments. That became a newspaper article - which was basically typical right-wing linkbait: it wasn't slow police response, it was the heartless crowd that killed Kitty.

That Slate dot com tier take became a theory, developed experiments, and discovered something that was obviously mathematically true: if not everybody in a group helps someone that they see in distress (only a subset do), but individuals always help when alone, then in groups, the average time before response _for each individual_ is going to go up, and the average likelihood of any response at all from a particular individual is going to go down.

This would be true even if people were _always_ helped faster by groups rather than individuals, and a subset of every group _always_ intervened. The types of people that bystander experiments found to be likely interveners could just adhere to the stereotypes that people think of as physically authoritative and look to when something occurs. People look to them to intervene (large, male, athletic, maybe ethnic or rough looking in criminal/street situations) maybe those people intervene because there no one for them to pass the responsibility off to.

</comment></comment></comment></comment></comment><comment><USER38> I'm confused here. What is the Bystander Effect?

> The bystander effect, or bystander apathy, is a social psychological > phenomenon in which individuals are less likely to offer help to a victim > when other people are present. The greater the number of bystanders, the > less likely it is that one of them will help. Several factors contribute to > the bystander effect, including ambiguity, group cohesiveness, and diffusion > of responsibility that reinforces mutual denial of a situation's severity.

Does that mean each individual is like likely to help _individually_ or does it mean that each _situation_ have less intervention?

Because if we're measuring individual response, then sure, I agree - if I'm hurt, I don't want 10 people rushing to me anyway.

i.e. if 1 bystander with 1x persons intervening = 100% response and then 2 bystanders with 1x persons intervening = 50% response...... I think this is a terrible way to measure it.

[1][https://en.wikipedia.org/wiki/Bystander_effect](https://en.wikipedia.org/wiki/Bystander_effect)

<comment><USER39> The claim is that when there are several people standing around and some emergency arises, everyone will just assume someone else is going to help, and no one will end up helping.

<comment><USER26> I've been taught multiple times that due to the bystander effect, should you take command of a situation and need to delegate you should always delegate specifically (e.g. tell one person to call 911 rather than shouting that someone should)

<comment><USER25> While that's certainly good advice, I don't think that's really a "bystander effect" correction as it is if there's multiple people and nobody takes charge then nothing gets organized, and if you don't delegate specifically then nobody knows who you're talking to and this produces confusion.

<comment><USER40> The last two times I took a first aid course I was told to do this _specifically_ to override the bystander effect. Both times, the instructor named and explained the bystander effect, and said the best way to overcome it was to assign tasks to specific individuals.

</comment></comment></comment></comment></comment><comment><USER41> There are two issues with how this study is discussed and it may not be a reproducibility issue exactly. 1) published in american psychology - <USER2> europeans and south africans... Without sampling Americans where the effect was first displayed I don't think we can call it 'largely a myth'. There are huge potential cultural factors here for why someone might intervene or not. 2) There's a sampling issue. Looking at police reports means committed crimes, while something intervened may not be reported to the police

</comment><comment><USER42> Cultural background probably has a lot of influence on this.

Where I grew up (a small city in Eastern Europe) it would be unthinkable not to intervene in many cases (although some things like gang or drunk fights would be excluded). The mentality in a capital would be completely different. As people move their habits can significantly influence prior "general findings".

<comment><USER43> And yet this study took place in a capital city, a major urban centre and a country tow, but found no significant difference in the results between them. That's despite big differences in the local crime and violence rates (I expect Cape Town being the outlier).

<comment><USER44> Cape Town has some areas that feel like an European town and some areas just filled with home-made sheds. I imagine that the crime rates are different in the places where there are actually cameras.

</comment></comment></comment><comment><USER45> Are the surveillance cameras clearly visible and the bystanders are aware of them? I wonder if the bystanders would react differently if they weren't aware that they are being recorded. Another thing I wonder is if they refuse to help then maybe they think there'll be repercussions like being ostracized when the footage goes public.

</comment><comment><USER46> Its absolutely amazing finding....it teaches to trust more and be little more secure someone out there will take care of me if in trouble. That kind of gives so much sense of hope and debunk that "fear stranger" or "no one is gonna help you" myth which pertuated for decades.

</comment><comment> your-nanny Just noting here that there is no necessary contradiction between the probability of at least one bystander helping increasing with number of bystanders, and the individual propensity of helping going down with an increasing number of bystanders, even assuming that people have the same propensity function.

</comment><comment><USER47> I do think the bystander effect is true. But not always. It's part of the zeitgeist. In the past, people were more assertive. Then we became sheep somehow. And recently I noticed that people know they have to do something.

</comment><comment> your-nanny Does the paper account for whether bystanders knew the individuals involved? You can't treat a group of people on the street as an unstructured independent sample...

</comment><comment><USER48> Most people I know are conceptually aware of the bystander-effect. It could be that awareness stops the effect.

</comment><comment><USER49> Faith in humanity: restored.

</comment><comment><USER50> Great

</comment><comment><USER51> totally un-scientific but i just feel like things like "identitism", "communitism", nationalism, etc. have been on the rise in the past decade for some reason. and by protecting the group they belong to, people also end up protecting individual making up these groups.

</comment><comment><USER52> Of course the real problem is the uplifting attitude that is written.

Where really violent crime is happening as now in Western European cities, London, Berlin, etc. people got to know the very real consequences of 'intervening' frequently resulting in seriously harming oneself or even getting killed. There have been instances where the police was not able to help. There are regular occurances of rescue teams being attacked to prevent them rescuing the victims of attacks. The even started a campaign to promote not attacking rescuers.

Also, in a democracy the use of force is supposed to lie with the administration only and of course there should only be very limited room for 'bystanders' 'to self-police to protect their communities and others' unfortunately we know the opposite is true.

<comment> semi-extrinsic Hmm, searching around for the type of statistics you are talking about, I get articles to a couple of anecdotal stories that are frequently repeated on sites like Jihad Watch, Voice of Europe, RT, etc.

Unless you can provide some actual statistics, I would dismiss this as unfounded far-right propaganda.

<comment><USER53> It's conflating a couple of recent examples (london bridge knife terror attack trial reports is one) where the police protect themselves and wait for backup but the public try to intervene against their orders and trying to imply there's an agenda by the police to let these things happen.</comment></comment></comment>