You might try "Seven Concurrency Models in Seven Weeks" for a high-level overview of different approaches.
https://pragprog.com/book/pb7con/seven-concurrency-models-in...
2,350 karma · joined May 18, 2009
https://pragprog.com/book/pb7con/seven-concurrency-models-in...
Henry, for example, gets punished for the sin of VANITY -- he doesn't stop in the tunnel in order to shirk work, but rather to avoid getting his nice new paint messed up.
To see the difference between the shows, just try to imagine Mr. Rogers presenting a puppet show about bricking a character up in his room as punishment for not wanting to get his new suit wet in the rain. And imagine him, in that Mr Rogers voice, saying "I think he deserved that punishment, don't you?"
Similarly, there's a story where one of the trains gets off the tracks in order to smell flowers, or play, or something of that sort. The cure is to hide people in the field, who jump out and scare him back onto the track.
Overall, the message of the books is that if you work hard and never question authority, you can avoid punishment. The odd thing about them is that the authority figure (the Fat Controller) is presented as mildly risible.
My brother and I used to laugh / shudder at how much our nephews loved these books. I myself never read them until uncle-hood, when I was well past the age when the mere fact that they were written about trains had any appeal.
They are quite happy to print line drawings, comics, and full-page photos, so it's not like they're scared of non-text content. Yet I've seen them devote multiple paragraphs to describing a scatterplot that stunned some scientist they were profiling.
I call them "thought tanks" exactly because all the thinking has been done well before any particular question gets asked.
Kind of puts "old timers" in perspective...
The script optimized the placement of samplers in a building, in order to maximize the probability of detecting airborne pollutants, or to minimize the expected time required to detect. The rewrite cut the runtime down from 2-3 days to sub-hour.
Some of the speedup was intrinsic to the interpreted/compiled divide. However most of the speedup came from the greater control Fortran gave over how data got mapped in memory. This made it easier for the code to be explicit about memory re-use, which was a big help when we were iterating over millions of networks.
Re-using memory was helpful in two ways, I think. First, it avoided wanton creation and destruction of objects. Second, and more importantly, it allowed bootstrapping the work already invested in evaluating network `N` when it came time to evaluate a nearly-identical network `N+1`. Of course, I could have made the same algorithms work in R, but languages like C or Fortran, which put you more in the driver's seat, make it a little easier to think through the machine-level consequences of coding decisions.
That experience actually taught me something interesting about user expectations. When the Fortran version was done, my users were so accustomed to waiting a few days to get their results, that they didn't run their old problems faster. Instead, they greatly expanded the size of the problems they were willing to tackle (the size of the building, the number of uncertain parameters, and the number of samplers to place).
This has been a big win in terms of the readability of the code, which has in turn made me more aggressive about adding features.
I think you hit the nail on the head when you called it a generic technical rule -- it's not a value that distinguishes the culture of the company. So while it might be sensible corporate policy, it doesn't really say anything about the company culture (not sure I would call it bland, but that's just wordsmithing).
Taking that a step further, suppose company policy included that and a host of other "bland technical rules" with which most practitioners agree. Then company values might state "We follow industry best practices." You can imagine an inversion, "We feel free to ignore best practices if it helps ship a product early", that would express something meaningful about the culture of working there.
While the blog post you linked to claims that the work finds "implausibly large effects", it doesn't clarify what the author finds implausible about them (and the author admits to only spending 30 minutes looking at the literature).
I would agree that the graphic in the PDF linked in this HN discussion, and in the paper referenced by the blog post you cited, uses alarmist labels (e.g., "dysfunctional" for performance scores at 25th percentile and below). However, the full version of the report, as linked by post, states that the percentiles are based on the reported scores from 20k other administrations of the test.
Therefore this report simply implies that some of the reported variation in some of the historical scores might be explained by variations in room CO2 concentrations. What's so implausible/impossible about that?
Disclaimer: I know several of the authors of this report, and have good regard for their scientific integrity, so my gut-level reaction to an undocumented accusation that their results are implausible, was skeptical.
Usually when they have this sort of sale on a holiday weekend, they spin up some new 50% off sale the following day, so check in again Sunday if you missed it today.
At work, we had a speaker who talked about his company's diversity hiring approach. I don't recall specifics, but I believe it was a bank that was pretty well-known for having good representation across race and gender -- which was the basis for the invitation to come speak.
The bit that stood out for me was the claim that they never hired merely to increase diversity. Instead, they hired only based on the merit of applicants.
To achieve diversity, however, they were very aggressive about inviting minority applicants to apply, for example, posting job notices in places where under-represented groups were likely to see the notices.
Applying that idea to OSS, one could imagine active outreach as a means of increasing diversity among contributors.
The larger question of why one should care about having diverse contributors has, I think, been largely addressed by other commenters already. In addition to the UI issues others have mentioned, I might also guess that, from the perspective of Free Software Foundation, they probably also want to understand and engage minorities' privacy concerns.
So it's possible that the imbalance in "words spoken" can be partly laid down to a conscious decision that "it's just funnier that way."
In my reading, the author doesn't even complain that it's a security issue, just that it will likely fail on systems with certain security measures. And the author never says it's bad simply because it's self-modifying; rather, that the self-modification is a "platform-specific reimplementation of a linker".
These sorts of tests also aim at helping guide the first response. For a long time, there was an ongoing debate about the proper response to an attack on a subway (it's probably still going on, but I haven't talked with this crowd in a few years). For example, suppose a CCTV spots a bunch of passengers going down in a particular terminal. Should you shut down the ventilation system, in order to try to contain the material? Or should you crank up the system, in order to dilute the hazardous material? How should those decisions change depending on the type of material, the amount released, the atmospheric conditions, and the timing of the response? Should you stop all trains in the tunnels, or should you run them to the nearest station for evacuation? All of this requires estimating potential health impacts, to those on the platform, in the rest of the system, and downwind of the affected stations.
Subways are really interesting beasts from the point of view of people who try to model the transport and fate of airborne materials. The trains themselves pump material through the tubes, the cars entrain material in their wake, and the cars capture and carry material along with the passengers (meaning you can disperse material even after a car comes out from underground). All this is intermittent and bi-directional, following the train schedules. And then it's all tightly coupled to the city's above-ground airflow patterns, both because the train stations have massive ventilation exchange with the outdoors, and because there can be passive vents at street level.
Particles add another layer to the problem. As the article states, they deposit out of the air, and they can resuspend, e.g., due to human activity. They can also hitch a ride on people and things. They also get captured in ventilation system filters. Finally the rates at which they do all these things depends strongly on the particle size -- and the particle size can change due to things like coagulation.
Examples:
+ The title of this HN post promises it uses Lidar data, but one of the three examples I looked at had nothing to do with Lidar, and the other two didn't mention Lidar at all.
+ That first example shows a drone-based measurement system, but it wasn't clear the measurements were done by the website, as opposed to the data's originator.
+ The second example I looked at purports to show a volumetric analysis of a concrete plant, but it has no description, and I don't see any actual analysis taking place. On the other hand, my laptop slows to a crawl whenever I'm on that page, so it must be doing something. The comments on that page did promise that I can "activate" a map, but gave no indication what that means, or why I should want to do so.
+ The "upload" page states that in three steps I can start measuring my data, but it doesn't give me any reason I should upload my data to somebody else's website, rather than just take measurements myself. What's superior about the website's tools? What formats are supported? No indication, and apparently no way to find out unless I sign up and start trying to upload data.
+ The "plans" page implies, without making explicit, that if I upload with a free account, I will automatically share my data with others, but not be able to measure it, nor be able to download somebody else's data. So let's say I get a free account. What can I do with my data? Conversely, let's say I pay for an account. What measurements can I make? How do I discover what data are available for me to download? And what indications do I have of the quality of the data (e.g., what's the spatial resolution, what are the errors in the measurements, and have the data been vetted in any way to ensure there were no processing errors)?
So where's the value?
Note I'm not saying there's no value here. Maybe there is. But the website doesn't do anything to make its value proposition clear -- unless I'm willing to poke around through enough of their examples, and the examples I looked at didn't show me anything useful.
In exactly the same way that recirculating air from inside the vehicle is easier on your air-conditioner, recirculating interior air is easier on the filter.
With the A/C, you want some minimum outside air to get rid of CO2 and whatever other effluents the passengers and materials in the car are generating. But if you were driving through a plume of toxic gas/particles, you wouldn't mind smelling your armpits and a little extra CO2 if it meant extra protection from whatever is out there.
Hence I believe that if you were really designing a Bioweapon Defense Mode, you would cut the intake of outside air to an absolute minimum. You might not go for zero flow, because you might want to pressurize the cabin a bit (in the U.S., most building mechanical systems are set up this way). But I wouldn't expect to cycle through enough outside air that you could halve the concentration in that bubble (which is probably 10-20 car volumes or more) in less than 15 minutes, as their graph shows.
Their filter does a good job cleaning particles out of the cabin air. Good on them.
Nevertheless, calling it "Bioweapon Defense Mode" is clearly a prize bit of marketing. A system designed to protect against an external bioagent wouldn't run huge amounts of outside air through the filter. That would just load the filter more quickly, impacting its performance (for chemical agents) and/or its energy requirement (for particles). Instead, you would cut the outside air intake as much as you could get away with, in order to buy the occupants time to drive clear of the plume.
Since they claim that the car is responsible for the decrease in the particle concentration in the test chamber, they must be running a pretty high flow of ambient air through the system. Of course, the ambient concentration would decrease even without the car's filter, due to particle deposition, and possibly due to losses in the sampling instrument. But then you only report those other loss rates if you're interested in science, rather than in marketing.
Or by getting rid of the notion of apportionment altogether.
There's no reason, in an always-connected society in which people can telecommute to work, that people's votes should be aggregated (counted up and applied) based on their geographic proximity.
Instead, votes should be aggregated exactly at the level of governance to which they apply. For example, representatives to city government should be elected by city-wide ballot, not ward-by-ward. State reps should be elected by state-wide ballot, not district-by-district. National reps should be elected by national ballot, not state-by-state.
Forcing geographical aggregation on people just strips geographically-distributed minorities of their power. If, say, 5% of the country's population consists of radical vegetarian pacifists (RVPs) who would vote for a RVP slate, then why shouldn't 5% of the nation's representatives (give or take) come from an RVP party? Yet if those 5% are distributed evenly throughout the country, they can have no party, and no dedicated direct voice, because the current system dilutes their votes among those of people who happen to live near them.
"Let the people gerrymander themselves!"
Of course, this would require changing the system, and would reduce the power of those who control the current system. Therefore it is extremely unlikely ever to happen.
(By the way, some might object that such a change would make small states lose their voice at the national level. But everybody who thinks their state's interests are threatened by some national policy, can form a party and vote its representatives into office. I'm not saying geography shouldn't be considered at all-- I'm just saying it shouldn't be the only means of aggregating votes.)
See, for example, this (unfortunately now defunct) radon risk website: http://www.columbia.edu/cu/pr/00/01/radon.html
Data science might also help you recommend where to sample.
Trouble with all this, of course, is collecting enough data to start making useful recommendations.
To make my example explicit above, suppose I have a "directory" structure with dirs like `conf`, `conf/iaq2016`, and `conf/gmu2012`. Then a search in `conf` will not turn up results in `conf/iaq2016` or `conf/gmu2012`.
Believe me, I check this once every few months, always hoping that google will have improved their "tag" implementation.
I do appreciate your tip about multiple browser windows, though. In general, I don't like having multiple windows open to the same application-- but that's my problem, and not a design flaw in Gmail's search.
Suppose, for example, I have set up a subdir for conferences. That subdir contains a bunch of subdirectories for individual conferences. I know the e-mail I'm looking for is stored in there, because it relates to a conference publication I wrote. However, that subdir itself is "empty" as far as gmail search is concerned (because it's a "tag" rather than a true subdirectory).
The net effect of these hollow imitations of directories is I can either target the search to a specific tag, or I can search throughout my entire collection of messages. (Or, I suppose, I can tag every e-mail with every single sub-tag represented in the directory hierarchy I have mentally set up, just in case I might want to search for it someday.)
The gmail ideal, of course, is that I abandon the notion of directories altogether, and just let all my messages stew in the ocean of e-mail that one accumulates over the years. Supposedly their "powerful" search capabilities will help me find what I want. In my experience, though, under this approach most reasonable searches produce multiple pages of possible matches. This, of course, is hardly efficient.
It would also be nice if I could perform a search and then pull out that page of returned results into a separate screen/window for ongoing reference. Often when I'm searching for something, I'm looking broadly for resources or related conversations, rather than for a specific message.
Another place where I feel gmail search is brain-dead is its lack of regex capability (which @devdas has already mentioned).
http://www.naturalhistorymag.com/picks-from-the-past/12476/s...
This happens for a variety of reasons. Often funds are allocated specifically to develop what industry calls a minimum viable product-- with the understanding that if the project is deemed successful, the research group can seek further funding to improve the tool.
There is also a model, in government research funding, that says the government's role is mainly to point the way, or to open up markets. In this model, if version 1 of the software proves itself useful, then an industry partner can step in and it take over. However, if nobody shows interest, then the government should _not_ sustain the effort, because the lack of interest implies a lack of utility to the public.
For example, the OpenEIS project [0] was funded specifically to produce "reference code" that a company can use to check the output of a professional implementation. The reference code is not at all intended to be fast or robust. It's intended to demonstrate the algorithms, and to document the expected output for a variety of reasonable inputs. As a programmer on the project, I knew from the start that my work would end with the first deliverable.
One thing that jumps out at me, having returned to R after several years in the Python world, is how obtuse its documentation can be.
The standard format for R documentation does a few things that I find impede understanding. First, the help pages are organized into sections giving the high-level description, the arguments, the details, and the results ("values"). The "details" generally are organized by argument keyword, and the arguments section draws on the language laid down-- usually in a vague, high-level way-- by the description section. Finally the practical effects of the details are deferred till the results section. That means unless you already know what's going on, you end up having to jump around among sections, trying to synthesize everything.
This is particularly a problem for those help pages-- and there are a lot of them-- that describe a raft of related functions all at the same time. Describing a bunch of related functions in the same place sounds like a good idea (it should help you figure out `apply` vs `sapply`, right?). Yet this is exactly when the documentation organization results in the most scattershot reading, because in addition to having to synthesize between sections, you have to mentally prune away text that, for one reason or another, doesn't apply to your particular case (for example, because different functions don't all share the same arguments, or because you want to read about the values for just one variation on the function).
Another idiom I dislike in the standard R documentation is how the examples don't actually show any sample output. There are generally some attempts at comments to explain what the sample code should or shouldn't do, but they are very much written in the style of programmer's comments, not in the style of documentation or learning points. So you end up having to run the code, and sometimes puzzle over the results for a while.
Here's an example, from the help page that I happen to have open right now, `help(sample)`:
# sample()'s surprise -- example
x <- 1:10
sample(x[x > 8]) # length 2
sample(x[x > 9]) # oops -- length 10!
sample(x[x > 10]) # length 0
Overall, I feel like R's documentation is a bit like a conversation among experts, with a rather sink-or-swim attitude towards newcomers.
Documentation is far from the first thing that stands out about R vs Python, but it's the most salient, I think, in the context of the original article.
It's no doubt interesting to know that your account is being targeted by your own or some other government, but identification seems secondary to detection and response.
You can find instances where they devote an entire paragraph to describing some plot that the subject of an article produced or saw, and which astounded that person or changed their world-view. Surely such a transformative graphic merits more than a paragraph of thin description. This is especially galling in a publication that prides itself on the sophistication of its readers.