Why Early Detection Is the Best Way to Beat Cancer - <AUTHOR> http://www.wired.com/medtech/health/magazine/17-01/ff_cancer

<comment><USER2> I read through the article (first published in 2008, it appears) to see what issues were considered, and what the background of the article author is. "Deputy editor Thomas Goetz (email@example.com) wrote about the Personal Genome Project in issue 16.08. He has a new blog about health and medicine at www.thedecisiontree.com" is what I see at the very bottom of the article. His blog appears to be updated every once in a while, to promote the article author's 2010 book.

The article submitted here is a popular article by a layman, and popular to a fault in that it discusses trade-offs in different screening methodologies, but doesn't even introduce the reader to important concepts like sensitivity and specificity of medical tests.

<http://en.wikipedia.org/wiki/Sensitivity_and_specificity>

It's very important that HN participants digest the article kindly submitted here with a compare-and-contrast reading of "The early detection of cancer and improved survival: More complicated than most people think"

[http://www.sciencebasedmedicine.org/index.php/the-early- dete...](http://www.sciencebasedmedicine.org/index.php/the-early-detection-of- cancer-and-improved-survival-more-complicated-than-most-people-think/)

by David Gorski, M.D., an experienced cancer researcher and experienced blogger about science-based medical decision-making for popular readers. His conclusion, "The bottom line is that the ever-earlier detection of many diseases, particularly cancer, is not necessarily an unalloyed good. As the detection threshold moves ever earlier in the course of a disease or abnormality (in the case of cancer, to ever smaller tumors all the way down to the level of clusters of cells), the apparent prevalence of the disease being screened for increases, and abnormalities that may never turn into the disease start to be detected at an increasing frequency. In other words, the signal- to-noise ratio falls precipitously," is a necessary caution in predicting the benefit of early detection of what appears to be cancer.

The American Cancer Society has a good 2012 publication, "Cancer Treatment & Survivorship: Facts & Figures 2012-2013"

[http://www.cancer.org/acs/groups/content/@epidemiologysurvei...](http://www.cancer.org/acs/groups/content/@epidemiologysurveilance/documents/document/acspc-033876.pdf)

that provides more details on what it means to survive a case of cancer.

<comment><USER3> David was the one who taught me about the Will Rogers phenomenon. Merely by reclassifying something, you can make it look like all categories improve, while overall no improvement happened.

[1]<http://en.wikipedia.org/wiki/Will_Rogers_phenomenon>

</comment></comment><comment><USER4> There are huge drawbacks to early detection, though. Surgery, radiation therapy and chemo-therapy are very invasive techniques, doing huge amounts of damage to a person's body as well as to the cancerous cells. It very often is the case that the cure is worse than the disease. Early detection also submits people to the huge mental stress of thinking that they're going to die soon.

And that's the case even if the early detection techniques were perfect. They aren't, far from it. They have a significant false positive rate. Many people who don't have cancer are subjected to the mental and physical stresses of cancer treatment. They then think that this treatment saved their lives, so they say to everybody they know: go get tested!

The other problem is the prevalence of cancer. 80% of men in their 70s have prostate cancer. Some of them will die from it, but most will die from heart disease or another cause. Treating them for prostate cancer will cause a huge decrease in their quality of life for no benefit.

Yes, early detection of cancer is a very potent tool for saving people's lives. But it's not a panacea.

[EDIT: the article actually does discuss most of these issues, I just wanted to try and balance things. Read the article.]

<comment><USER5> > Surgery, radiation therapy and chemo-therapy are very invasive techniques

A not so well-known fact to drive that home: cytostatics (the bulk of traditional chemotherapy) are derivatives of some of the nastiest chemical weapons developed in WWI, specifically mustard gas.

<comment><USER6> More than that, Mustard Gas was fairly important in the development of chemotherapy after US Army Doctors noticed it's effect on white blood cells following an air raid in WW2 when a ship carrying Mustard Gas was bombed. From there, in part, was sparked the idea of using similar drugs to attack cancers.

[http://www.the- hospitalist.org/details/article/243771/From_W...](http://www.the- hospitalist.org/details/article/243771/From_Weapon_to_Wonder_Drug.html) [http://en.wikipedia.org/wiki/Sulfur_mustard#Development_of_t...](http://en.wikipedia.org/wiki/Sulfur_mustard#Development_of_the_first_chemotherapy_drug)

</comment></comment></comment><comment><USER7> There are a number of reasons why early detection is often oversold as a way to improve survival rates (which is not to say that early detection is bad, it just might not always help). The article doesn't seem to reference all of them directly, though I'll admit to skimming a bit. Here's a brief list, paraphrased from here: <http://www.ncbi.nlm.nih.gov/books/NBK20938/>

Lead-Time Bias: The earlier you detect, the earlier the clock on your survival starts. 5/10 year survival rates go up simply because the cancer is at an earlier stage when we started tracking how long people survive, not because early detection necessarily lead to more effective treatment.

Length Bias: More screening means a higher probability of finding cancers which would have stayed relatively benign for a very long time (as opposed to cancers presenting very obvious symptoms). Survival rates appear to go up simply because you're detecting less threatening cancers. I believe the article references this idea.

Overdiagnosis: Heavy screening means finding cancers that may never have become threatening at all (as the referenced link states, an extreme example of length bias). Survival rates go up, but not because screening helped. It's been suggested that countries which screen more often have better survival rates simply because they find cancers which would have benignly resolved themselves and gone unnoticed in countries which screen less often.

Patient Self-Selection: Patients who seek out screening may be more likely to live healthy lifestyles.

</comment><comment><USER8> I've long thought that machine learning would be a great tool for detecting cancer and other diseases. There is a small but growing body of research to support this idea, but very few practical implementations. [1] [2] [3]

Ultimately detection is an issue of pattern recognition, and computers are really good at that. The two biggest barriers are the amount of data that needs to be collected and annotated, and the sensitivity of medical data. If someone reputable were to start a large scale data collection effort, we could make huge strides toward identifying some of the key cancer indicators. It would even benefit people who can't afford top quality medical care (servers are cheaper to deploy than doctors).

Cancer is the ultimate medical opponent. It comes in so many forms and can change into so many more. Many cancers spend 10-20 years as harmless lumps of cells before doing any serious damage. It seems like the best bet is to every tool available to find them long before they become a problem.

[1] [http://cs229.stanford.edu/proj2011/Planey- Machine%20Learning...](http://cs229.stanford.edu/proj2011/Planey- Machine%20Learning%20Approaches%20to%20Breast%20Cancer%20Diagnosis%20and%20Treatment%20Response%20Prediction.pdf)

[2] [http://www.mendeley.com/research/data-analytic-strategy- prot...](http://www.mendeley.com/research/data-analytic-strategy-protein- biomarker-discovery-profiling-high-dimensional-proteomic-data-cancer/)

[3] [http://www.popsci.com/science/article/2011-11/new- computer-m...](http://www.popsci.com/science/article/2011-11/new-computer- model-examines-breast-cancer-better-doctor)

</comment><comment><USER9> The concept of early detection or screening is very attractive, but for many cancers the results have been disappointing:

Prostate cancer: (not effective) [http://summaries.cochrane.org/CD004720/screening-for- prostat...](http://summaries.cochrane.org/CD004720/screening-for-prostate- cancer)

Breast cancer: (evidence conflicting, minimal improvement) [http://summaries.cochrane.org/CD001877/screening-for- breast-...](http://summaries.cochrane.org/CD001877/screening-for-breast- cancer-with-mammography)

And as other commenters have noted, early detection does not mean the ultimate outcome will be improved -- some cancers have a spectrum of presentations, with some persons having more slowly growing / indolent tumors that can be detected and treated (but may not have actually been likely to harm the person harboring the lesion), while other persons develop rapidly growing and very aggressive tumors that will be fatal (but are hard to detect with screening because they develop and spread rapidly). Only carefully constructed and controlled studies can determine if screening for a particular cancer with a particular screening test actually improves survival or reduces morbidity -- short term or uncontrolled studies can be very misleading.

Also the whole subject is subject to anger and political correctness issues -- some good hearted persons want to believe that some screening metholodogy must help because they want it to help, the evidence be damned! So there can be more heat than light ... anybody who says a specific screening test not helpful can be accused of running a "death panel".

</comment><comment><USER10> In the case of ovarian cancer, as described in the article, it's likely that "early" ovarian cancer is a separate disease from disseminated ovarian cancer.

Assuming that one leads to the other has lead to a large research effort that has failed to help. Screening is ineffective at best, and probably harmful as it:

picks up the earlies that would have been detected and cured in an ad hoc fashion; picks up a host of benign pathology, removal of which leads to iatrogenic harm; fails to pick up aggressive cancer which spreads almost immediately and may even arise in multiple locations at the same time.

The current best methods for prevention are using the contraceptive pill, removing the Fallopian tubes (50% of "ovarian cancers" are probably tubal), and removing the tubes and ovaries of people in high-risk families after childbearing.

Screening does not work.

<comment><USER6> Sources to back up the idea that early stage ovarian cancer is separate from late state ovarian cancer?

<comment><USER4> The article mentions the hypothesis that the particularly malignant ovarian cancers are actually fallopian cancers that have spread.

</comment></comment></comment><comment><USER11> My unfounded $0.02 is that the best way to beat cancer is the same as the best way to beat HIV: multidrug targeted molecular therapy to prevent resistance. This is currently mostly a pipe dream as our targeted molecular therapies are few.

Early detection is useful if you can treat appropriately. Early detection of HIV (where 'early' means no AIDS-defining illness) is an example here. Early detection is a tool, but it's not the point. It's the debates, but not the election.

Again, I am not a cancer biologist but the parallels have long struck me. The goal IMHO is to make cancer a typical chronic disease that you live with but can tolerate for decades. Perhaps I am not dreaming big enough, but I think this would be a huge stepping stone. If you can cure a cancer already, of course, by all means do so.

<comment><USER12> The problem with cancer is that, much like with the HIV virus, the immune system is fooled into thinking the cancerous cells are part of the human body.

From what I hear researchers are optimistic that any such disease can soon (i.e. within the next 20 years) be cured by injecting blood-cell sized nanobots that can reliably target the foreign cells or viruses in your body and kill them (and, unlike chemotherapy, don't destroy the good parts, too). I think the chronic disease is just a crutch that'll soon be obsolete.

<comment><USER13> Cancerous cells are part of your body — they've just mutated such that they don't respond to signals that tell them to die or slow their rate of replication. The reason your immune system doesn't recognize them is because they are literally part of you. This is why specifically targeted cancer cures are so hard: there's almost nothing that distinguishes cancer cells from normal cells.

</comment></comment></comment><comment><USER14> Single Page Version: [http://www.wired.com/medtech/health/magazine/17-01/ff_cancer...](http://www.wired.com/medtech/health/magazine/17-01/ff_cancer?currentPage=all)

</comment><comment><AUTHOR> The article concludes with the hope that Contrast-Enhanced Ultrasound (CEUS) could be extremely useful as another step towards reducing false-postives. This article was written in 2008 and even though it's 4 years later, according to the Canary Foundation's website ( [http://www.canaryfoundation.org/research/ovarian-cancer- clin...](http://www.canaryfoundation.org/research/ovarian-cancer-clinical- studies/) ), they are STILL waiting on FDA approval for the CEUS microbubbles...</comment>


DOJ Calls for Apple to End Book Deals, Link to Rival Bookstores - <AUTHOR> http://allthingsd.com/20130802/doj-calls-for-apple-to-end-book-deals-link-to-rival-bookstores/ <comment><AUTHOR> Apple's obligatory response:

"Plaintiffs' proposed injunction is a draconian and punitive intrusion into Apple's business, wildly out of proportion to any adjudicated wrongdoing or potential harm. Plaintiffs propose a sweeping and unprecedented injunction as a tool to empower the Government to regulate Apple's businesses and potentially affect Apple's business relationships with thousands of partners across several markets. Plaintiffs' overreaching proposal would establish a vague new compliance regime—applicable only to Apple—with intrusive oversight lasting for ten years, going far beyond the legal issues in this case, injuring competition and consumers, and violating basic principles of fairness and due process. The resulting cost of this relief—not only in dollars but also lost opportunities for American businesses and consumers—would be vast."

[http://allthingsd.com/20130802/apple-slams-feds-proposed- e-b...](http://allthingsd.com/20130802/apple-slams-feds-proposed-e-book- remedies-as-a-draconian-and-punitive-intrusion/)

<comment><USER2> Seems a weird solution, given they aren't the gorilla in the ebook market - but what comes to mind when reading this, are the battles Microsoft had with regulation. I wonder if this is the beginning of the same era for Apple.

<comment><USER3> > Seems a weird solution, given they aren't the gorilla in the ebook market

While some of the remedies are related to the market that was affected by the illegal actions they were found to have engaged in, the remedies as a whole aren't limited to the ebook market, and it seems more concerned with Apple using its mobile position and related retail platforms to facilitate similar publisher schemes in other markets to the one it engaged in in the e-book market.

Which, IMO, is what you'd expect of a company that wasn't found to be leveraging a monopoly or otherwise abusing power as a dominant player in one market, but instead was found to have used a significant-but-not-necessarily unique position in one market to provide a pivotal role in a price-fixing conspiracy among producers in another market.

<comment><USER4> "...the remedies as a whole aren't limited to the ebook market, and it seems more concerned with Apple using its mobile position and related retail platforms to facilitate similar publisher schemes in other markets to the one it engaged in in the e-book market..."

Wait...

So Amazon bought all their eBooks on the wholesale model, basically, they pay a fixed price for the book, maybe $5 and sell the book for whatever... including selling for a loss if they choose.

Apple came along and said we will sell for whatever the publisher of the book wants us to sell for... and then we will take a percentage of that.

Now forgive me for my shameless selfishness here...

but that immediately calls to mind the App market to me.

So I have a question...

Would "...in other markets..." mean that Apple could conceivably be barred from letting me sell my App for whatever price I wanted on the App store? Or does it mean that they would just have to provide a link to my app on another store that would be selling my app at a loss?

I hope that's not true. In this case, that would mean that Apple, Amazon and Google would get to set the price at which one could sell one's app, since they own the store, and I would be just the publisher.

Well... technically, they couldn't set the price I could sell my app at, they could only refuse to buy my app and put it on their store for anything but their "wholesale" price.

I hope none of this applies to the app market.

Sigh.

Maybe I should have gone for that Law degree.

<comment><USER5> I've read articles saying that Amazon's App store does this. i.e. if they see you selling your app cheaper for iOS, they can go pricematch it. Or, if you give it away for free, Amazon can do the same thing an pay you nothing (since a percentage of zero is zero). AFAIK, Apple won't do the same thing, they'll just reject your app if it uses the wrong APIs or competes with a market they want to own in the near-term.

</comment></comment></comment></comment></comment><comment><USER6> You gotta love antitrust regulators that work hard to further entrench the dominant competitor.

Get your External Antitrust Monitor resumes up on LinkedIn kids, xmas is coming early this year.

<comment><USER7> That's because being the dominant competitor is not illegal. Price fixing and colluding to drive competitors out of the market by extending a powerful position in one market into another market _is_ illegal.

<comment><USER6> I haven't claimed that Amazon did anything illegal or that Apple didn't. The claim I'm making is that the remedy for Apple's transgression needn't be a gift to Amazon. And while the DoJ _could_ decide to look into Amazon's own actions for various reasons, does anyone seriously think a proper penalty might include the DoJ enabling a "Buy at Barnes & Noble" button on Amazon.com?

<comment><USER7> I read your post. The point I was trying to make was that Apple did something illegal and got busted for it. Amazon either hasn't done anything illegal, or hasn't gotten busted. The judgement for Apple isn't to help Amazon, it's to pay back the damaged they have done to their competitors. Since it was deemed that Apple hurt Amazon, Nook, etc, they now have to pay that back by hurting themselves.

What would be Apple's punishment? A fine? That's hardly going to deter the world's most valuable company. What they did hurt their competitors. The punishment is that they now have to help their competitors regain what they lost. This is not unprecedented by any means. In the two cases where Microsoft was deemed to have an illegal monopoly, they had to give their competitors access to their proprietary APIs (US v Microsoft, a gift to Apple and Linux vendors) and include downloads to competing browsers (EU vs Microsoft, a gift to Google, Mozilla, and Opera).

<comment><USER6> I think most of the punishments they set up for Apple are perfectly reasonable and on top of those I'd go ahead and yeah I'd add a huge fine. IDK on the amount, something at least as large as everything they've made on books and then tripled or perhaps based on the avg price of ebooks before and after times the volume i.e. what consumers paid based on the price increases Apple was responsible for.

I think the record companies (et al) might want the ability to raise Apple's prices without the governement ok-ing it so that item maybe could be modified with their input.

I think the Amazon gift is silly. You say "What they did hurt their competitors." but that's not what Apple is accused of. Apple is accused of hurting consumers while Amazon profits actually increased. You bring up Microsoft but Apple does not have a monopoly on ebooks like Microsoft did in browsers. Not even remotely. They aren't even the largest competitor. By a mile.

<comment><USER7> Was IE dominant in the browser space in 2007? It feels like Chrome or Firefox had surpassed them by then. Microsoft still got hit because it was the Most Favored Browser on the most dominant OS platform.

Again, having a monopoly isn't illegal. Abusing a monopoly to force unfair competition in a new market _is_ illegal. Apple isn't taking the hit because they're dominant in ebooks, but because they're not playing fair with ebooks when it comes to the mobile device market where they _are_ a strong player.

</comment></comment></comment></comment></comment></comment><comment><USER8> >allow for two years rival e-book retailers like Amazon and Barnes & Noble to provide links from their e-book apps to their own e-bookstores without paying any fee or commission to Apple on sales made through them.

This doesn't exactly seem fair to all the other companies who would still have to give up 30% commission over to Apple but can't raise their price (e.g. Netflix, Dropbox, etc).

<comment><USER3> > This doesn't exactly seem fair to all the other companies who would still > have to give up 30% commission over to Apple but can't raise their price > (e.g. Netflix, Dropbox, etc).

The term at issue is a remedy for harms done by Apple's role in the ebook publisher price fixing scheme, which isn't relevant to Netflix, Dropbox, etc.

Insofar as the kind of thing Apple did here would be relevant to app makers in markets other than the ebook market, those app makers are beneficiaries of the provisions of the propsed remedy that exist to prevent Apple from engaging in schemes that are similar to the ebook scheme in other markets.

<comment><USER5> I could understand why apple would get a 30% of scamware f2p shit recoded flash games that couldn't exist without their ripoff platform. But why should they get 30% of book sales when they don't even care about piracy or make any serious efforts to stop it?

</comment></comment></comment><comment><USER9> I've heard quite a bit about this case over the past month or so, but don't understand it.

Can someone explain what Apple 'fixing' e-book prices means and how that is illegal?

<comment><USER10> Amazon used to buy all their eBooks on the wholesale model; the same one used for print books. They would buy the books from the publisher at a fixed price (say $10 each), and then sell them at whatever price they wanted. Amazon often sold the books at/below cost to get people to buy Kindles.

So when Apple decided to start the iBook store, all the publishers decided to use that as an opportunity to band together and force Amazon to use the agency model, which is how Apple sells apps (publishers set the price, Apple gets a cut).

The had the effect of causing book prices to go up (because, again, Amazon often sold at or below cost). Because Apple was the new player whose contracts caused this, they got in trouble.

Many people find this quite questionable. Prices will go _up_ with this settlement because publishers get more control. Amazon had a _de facto monopoly_ , which Apple actually broke up. Also, this wasn't Apple's idea, _it was the publishers_.

Of course, Apple was more than happy to take advantage of the situation, so they weren't exactly innocent.

It's a really a strange case.

<comment><USER11> Why do people keep bringing Amazon into this? It's like asking a criminal on his philosophy to life. It simply doesn't factor into the law. Amazon is not a party to the case, and it is not a defense.

They fixed prices, and theres no situation where this yields a upside to customers. And in fact, it didn't. That's why they had to pay up, and Apple, failing to come to terms with the DOJ, will now have to pay much much more dearly for ever bringing this into a court.

<comment><USER10> Amazon's position in the market before this case is one of the things that makes it interesting. If Apple went to into a competitive market and pulled this it would be pretty clear cut. But instead they went into a market dominated by a de facto monopoly. In fact many people believe that _Amazon_ should have been investigated for it's practices in the 'pre-iBooks' era.

> They fixed prices [...]

This is something I'm not sure about. From what I've read it sounds like all the publishers already wanted to do this and Apple was just the perfect opportunity to force the issue.

But as I said above, Apple clearly knew this was the case and used it to their advantage. They didn't set out fix prices, but they weren't against it.

> And in fact, it didn't.

This is a little odd too. Because of the agency model and the most favored nation contracts, prices went up. But if prices were artificially low before hand, was this a harm to consumers or a correction that would have happened eventually anyway?

There are some interesting twists in this case that make it a lot less clear- cut than most price fixing schemes. Apple probably deserves some kind of punishment for their behavior. On a personal level I'd really like the ability to buy books in the Kindle app, that seems like a fair punishment. I love my Kindle, but I do think Amazon might have been abusing their monopoly.

Of course the publishers were all guilty as hell, but they settled quickly. If they had tried to fight this too, I wonder if we'd hear as much about Apple. They're the only ones left standing and fighting.

</comment></comment></comment></comment><comment><USER12> Wow, this opens up the market a LOT. Fortuitous timing for B&N's ailing Nook division?

</comment><comment><USER13> Puts this in a whole new light: [http://qz.com/87184/the-steve-jobs-emails- that-show-how-to-w...](http://qz.com/87184/the-steve-jobs-emails-that-show- how-to-win-a-hard-nosed-negotiation/)

HN discussion: [https://news.ycombinator.com/item?id=5752212](https://news.ycombinator.com/item?id=5752212)

</comment><comment><USER14> Anyone have insight into what sort of timeline this is on? How long Apple could drag this out until books disappear from iTunes and consumers are stuck with the Kindle iOS app and it's non-native text selection bullshit?

<comment><USER6> I don't think it prevents them from recontracting immediately with the publishers, just they can't get most favored nation.

"entering new e-book distribution deals _which would free it from having to compete on price_ "

</comment></comment><comment><USER15> This was interesting _" without paying any fee or commission to Apple on sales made through them."_

It is interesting because I see it as a request to keep Apple from enriching itself but abolishing the fee entirely makes for a really harsh sanction. We'll see what, if anything, the court decides is reasonable.

</comment><comment><USER16> It's sad and terrible to see the last, best vestige of old media being constrained by supposed innovation.

</comment><comment><USER17> I can't wait to see links to iTunes on the Amazon web site one day.</comment>


Climate Change Cause..Effect..Cure - <AUTHOR>

Of course I don't have a background in science but whenever I walk into the woods on a hot day the temperature is quite a bit cooler. Usually startlingly, though refreshingly, so. I believe a large scale effort to plant forests would be a necessary step to take as well as focusing on energy. Changing our energy usage may stop the harm but I believe it's the forests that will heal. Forests also have a profound effect on the weather.<p>Of course there is the possibility that the Earth is heating on its own and there is nothing we can do about it anyway. But it still seems like planting forests and stopping deforestation would do about the only good we can presently do. <comment><USER2> The problem is how much energy enter the Earth and how much energy exits the Earth.

Forest only move some heat, bot the total amount doesn't change. The part inside the forest is cooler, this makes the part outside the forest hotter.

Actually, it's more complicated. If the forest view from above is lighter than the previous landscape this will make more light bounce and more sun energy will go to space and make the Earth cooler. But if the forest view from above is darker than the previous landscape this will make less light bounce and less sun energy will go to space and make the Earth hotter.

Actually, it's more complicated. The trees transform some carbon dioxide to wood and to part of the soil. So this is good if the sequestered carbon dioxide is more than before.

Actually, it's more complicated, there are a lot of effects to consider..., that why you should try to get more science background.</comment>


Verizon FiOS iPhone update slowdown? - <AUTHOR>

In trying to download the iOS 8 update for iPhone, estimates range between 24 and 48 hours on my laptop.
I have a few servers in the Amazon cloud, so I connected to one of them and downloaded the update from there. It took about 10 seconds to download from Apple's servers to my server!
Then, transferring the update file from the amazon server to my machine took about 7 minutes at a download rate of 5.7MB/s.
Is this indicative of a purposeful slowdown from Verizon? Seems like a Net Neutrality issue. <comment><USER2> Could be, but also it might be the Apple/Akamai/LimeLight CDN have capacity constraints tied with their router interconnect with Verizon. By going via Amazon, you are likely connecting via a different router port.

</comment><comment><USER3> Had the same problem. Also with the OS X 10.9.5 update on the same day.</comment>


Rescue shackspace, the german hackerspace in Stuttgart - <AUTHOR> http://rescue.shackspace.de/ <comment><USER2> I'm starting a hackerspace in Bilbao and will probably find myself in the same situation in 1-2 years. We have a huge awesome space (944m^2) for free but if it gets sold or rented we'll have to move out. The plan is to use this year to recruit members and save money to be able to rent a smaller place when we move out.

What you should do is just raise the fees for the members. 20e (8 for students) is a really low monthly fee for a hackerspace. Lots of spaces have monthly fees around 80$ with some reduced memberships (40-50$) for students or "starving hackers". Until now you were able to keep the membership cheap since you weren't paying rent but you should definitely raise the fees, a lot, if you want to survive.

I guess that you have already debated and voted on this. If you raise the fee so drastically you will probably lose half the members but at least you won't have to depend on donations. A couple years ago I was part of local Linux Users Group, we had a nice space with only 20 members and a 75e monthly fee. Raising the fee to pay the rent filtered the the people who didn't really commit to the project.

Find a smaller place if you need to but reducing the group to people who really "get it" will probably get you a smaller and much nicer hackerspace. Of course, if someone cannot pay but is really interested and can help around, you should make some exceptions.

The site says that you need 3000-3500e to move. If you have 80 members it's just 40euros per member, if the members really want to have a hackerspace it shouldn't be too hard to reach.

<comment><AUTHOR> To be clear: It isn't true that we where not paying any rent until now. Our monthly costs are ~1000EUR a month at the moment and we are able to afford that.

Th problem is also not the money we have to pay for rent. It is the money we need to pay for moving and renovation costs.</comment></comment>


Early paper money from British Colonial America - <AUTHOR> http://blogs.bl.uk/americas/2017/04/early-paper-money-from-british-colonial-america-in-the-british-library.html <comment><USER2> If you're in SF, the SF Federal Reserve Bank has a display of early colonial and other US currencies. Not sure if it's open to the public all the time, but there's probably a tour. [http://www.frbsf.org/education/teacher- resources/american-cu...](http://www.frbsf.org/education/teacher- resources/american-currency-exhibit/independence/)

</comment><comment><USER3> This is very interesting. I was surprised to learn that the British had three currency zones, the Pound Sterling, the Dollar and the Rupee. [1]

The Rupee was used throughout the Indian subcontinent, East Africa and Middle East wherever the British had some sort of colonial presence from the mid 1800s till after World War I.

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

</comment><comment><USER4> I keep this thread bookmarked [1] as it provides a nice history of paper money in the U.S. and seems relevant here:

[1] [https://www.reddit.com/r/TrueReddit/comments/22c5sp/one_curr...](https://www.reddit.com/r/TrueReddit/comments/22c5sp/one_currency_one_price_new_study_shows_the_euro/cglvri0/)

</comment><comment><USER5> Thirty Shillings

To counterfeit is DEATH

How prevalent were counterfeit notes in this period vs now?</comment>


First Node.js Secure Development Training is April 30, at Portland - <AUTHOR> https://blog.liftsecurity.io/2014/03/28/Secure-Development-Training-Coming-To-Portland

<comment><AUTHOR> [https://blog.liftsecurity.io/2014/03/28/Secure- Development-T...](https://blog.liftsecurity.io/2014/03/28/Secure-Development- Training-Coming-To-Portland)

The team has been hard at work designing a great training experience and we are proud to announce that the first live edition of the Node.js Secure Development Training will be on April 30, in Portland, OR.

Tickets are going to be released April 1st, register your interest today! As this event will have extremely limited seating!

[https://ti.to/lift-security/node-sec-dev-portland](https://ti.to/lift- security/node-sec-dev-portland)</comment>


Tell HN: Who is hiring needs it's own monthly section - <AUTHOR> It's near impossible to navigate the monthly job posting thread anymore. Possible solutions are to make the post submissions more parseable with special formatting and we could utilize a bookmarklet for filtering. <comment><USER2> Perhaps this might help: [http://whereis-whoishiring- hiring.me/](http://whereis-whoishiring-hiring.me/)

</comment><comment><USER3> there are a bunch of tools: [https://hn.algolia.com/?query=show%20hn%20hiring&sort=byDate...](https://hn.algolia.com/?query=show%20hn%20hiring&sort=byDate&prefix&page=0&dateRange=all&type=story)

</comment><comment><USER4> Here are a few decent options:

[http://hnhiring.me/](http://hnhiring.me/)

[http://hnjobs.io/](http://hnjobs.io/) (I think was giving errors last time I checked)

<comment><USER5> Yep, getting an error with that one

</comment></comment><comment><USER6> It exists.

I've seen it, but am drawing a blank as to how to find it right now. I've seen a couple different formats.

Wish I could be more helpful, but I'm in a meeting at the moment.

</comment><comment><USER5> There should be a link in the index bar that just takes you to the current month's thread

No biggie

</comment><comment><USER7> And a separate thread for REM0TE jobs.</comment>


Mexico's Carlos Slim knocks Bill Gates off his top billionaire perch - <AUTHOR> http://www.techflash.com/seattle/2010/03/carlos_slim_knocks_bill_gates_off_his_top_billionaire_perch.html

<comment><USER2> Bill Gates has been giving away his money for the last 5 years to charities...

<comment><USER3> I like to think of it as him giving away _our_ money to charities.</comment></comment>


Ask HN: How do you deal with Learning Anxiety? - <AUTHOR> I am not sure if that is an actual term.  What I am referring is the crippling anxiety felt when I pick up anything to learn (or read).  I try to mostly learn Technical stuff, a language, a framework, a project etc..
The factors that freak me out include:
1.  Is this even worth it?  Am I wasting my time?
2.  Others are doing so much!  What am I learning this for?
3.  There is so much to learn!  I am never getting around any of it!
4.  I should just leave learning and do my job.
5.  How do they know so much!
etc.
This has prevented me from learning anything substantial since almost a year now.  Things weren't as great before that as well.  Is there anyone else facing this?  How do you deal with it?  I am sorry if this has been asked earlier.  If so, please point me to those posts.
Thanks HN. <comment><USER2> Can you try something please?

\- Clone the repo of any software you respect.

\- Do a `git log --reverse`

You will see the commits from oldest to newest, and the path authors took to build that beautiful code you admire so much.

Bonus: it's also a way to learn.

<comment><AUTHOR> Thanks! This is a good idea.

</comment></comment><comment><USER3> I find that when I have anxiety about things or people are unsure of things, it's always important to drill down into the 'why'.

"Why am I doing this thing I'm anxious about?"

If its because I have to for adult reasons or some other goal and there's no better alternative, then I just suck it up and do it, it's not gonna get any easier.

If its because of societal expectations I ask myself "Do I care about conforming to this societal expectation? What will it cost me if I don't?" and then I go from there. If I truly don't care about it, but it will cause issues later, like flaking on an event and then friends won't invite me if I do it too much, then I'll decide that the cost outweighs the amount I don't care.

In the end, it all comes down to identifying the 'why' for me and then doing a cost-benefit analysis of the tradeoffs of: 'how much do I care?', 'what is the cost of not doing it in terms of money, stress, or societal expectations?', and 'is there a different option, if so how do the costs compare?'.

In your case, I feel that you are doing this because you think you need to get better and all these other people know things you don't, and you don't want to look stupid. You need to decide if you even care on all that.

I had the desire to learn and get better cause I always felt behind before as well. I don't know if it quite manifested as learning anxiety, but I had some things that helped me. I knew that while these people knew more about Mathematics or more classical computer science things, I had other things they didn't such as knowledge of foreign languages and cultures, or I wrote better code from a readability/maintenance standpoint. I'm sure you have some other piece of knowledge they don't even if its something like world history. It may not seem useful or applicable but every piece of knowledge can be applied in some other context some way, even if its just realizing that the problems are similar so you know to look up how it was solved previously in a different domain.

So step one is stop comparing to them. Step two is to sit back and decide if you actually want to be learning these things, and why. Step three is deciding which things are going to be the most immediately applicable, and if you need to learn something first to learn it, then do so(learning algebra to learn calculus). Step four is moving on to the next thing after you have that to a good enough base knowledge.

You don't have to be an expert in any fields here. Just get to a point where you can easily learn more. I imagine you can most likely do two new tech domains at once as long as they aren't too similar, but don't bite off too much. Just do at least a little bit of study a day. Even some more boring technical books that are 300 or so pages can be tackled in a month at 10 pages a day! But don't stick too hard and fast to things like that. It might be easier to do a 5 page chapter now, and then a 15 page chapter the next day. Stopping points like that help. Also if you read too much you could affect retention.

Look into some things about learning techniques such as spaced repetition stuff like Anki or Supermemo. Things like that pay dividends by making you spend less time overall and you won't need to learn the same thing twice if you keep up with it. Gaps in studying can be bad cause you don't progress but you also regress at the same time, you can see that after semester breaks in school when you go to the next level of class and everyone forgot half the previous semester. The worst thing than a gap in studying is a longer gap. A one or two day gap sometimes is no issue really but a month is, and three months is worse! Habits make perfect. Some analogical advice from my time as a recovering alcoholic would be this:

"Stumbling and falling down looks dumb in front of everyone and it's embarrassing and it sucks. No one is denying that. However, not getting up and just continuing to lie on the floor looks even dumber, and you'll be in people's way. Get up and keep on walking and eventually you'll learn how to not stumble anymore, or if nothing else most of your time at least won't be spent on the floor."

I know this is a lot of stuff to think about and so I'll make a quick little TL;DR.

1\. Figure out the 'why' and if its worth doing 2\. Figure out if there's a better way 3\. Figure out the best way to do it

<comment><AUTHOR> This is a great help. Thanks.</comment></comment>


Ask HN: What book have you given as a gift? - <AUTHOR> What book have you found so amazing that you have given it as a gift? This could be a tech book, biz, self-help, or other books. Also, you can help me too https://read.gift/u/notoriousarun <comment><USER2> I swapped a copy of start with why by Simon Sinek

for

Thinking fast and slow by Daniel Kahneman

Both great books.

Start with why is good to understand how marketing and branding works, and how to do it better.

Thinking Fast and Slow is a great take on being conscious of your own cognition. It explains how to know whether we are making decisions with the correct thinking mode.

A lot of the time we rely on past experience and gut feel - the fast thinking mode. We do this in situations where actually the slow thinking mode might be better.

It's important to understand and be self aware of which one you are relying on, and strike the right balance.

Also a great book on how to get things right is the Checklist manifesto by Atul Gawande.

It's a fantastic story, of how the humble checklist can improve workflow quality tremendously. From pilots running pre-flight checks to avoid plane failures. To surgeons performing pre-surgery checks, vastly improving patient outcome and surgery success statistics.

We use checklists in our company to ensure we are building high quality products, and our customer support is to a high standard and uniform.

I would recommend all three.

<comment><AUTHOR> Thanks, your recommendations are great.

</comment></comment><comment><USER3> The books I always fall back on giving as a gift:

Superintelligence by Nick Bostrom A superintelligence is a hypothetical agent that possesses intelligence far surpassing that of the brightest and most gifted human minds.

Einstein's Dreams by Alan Lightman A modern classic, Einstein's Dreams is a fictional collage of stories dreamed by Albert Einstein in 1905, when he worked in a patent office in Switzerland. As the defiant but sensitive young genius is creating his theory of relativity, a new conception of time, he imagines many possible worlds.

Remembrance of Earth's Past by Cixin Liu It is hard to explain how deep my love for this series is. My all time favorite science fiction but what it is is just page after page of ideas that get more and more fantastical. Can't recommend this enough

The Three Body Problem (PartI) The Dark Forest (Part II) Death's End (Part III)

<comment><AUTHOR> I would surely read Einstein's Dreams and SuperIntelligence.

</comment></comment><comment><USER4> "This is not my hat": [https://www.amazon.co.uk/This-Not-Hat-Jon- Klassen/dp/1406353...](https://www.amazon.co.uk/This-Not-Hat-Jon- Klassen/dp/1406353434/)

The humour is subversive, the illustration is lovely, and these ("This is not my hat" is another) are great books for younger children. My child loved it, and the people I've given this to have gone on to buy other books by the writer or illustrator.

"Mr Birdsnest and the House Next Door": [https://www.amazon.co.uk/Birdsnest- House-Next-Door-Little/dp...](https://www.amazon.co.uk/Birdsnest-House-Next- Door-Little/dp/1781125759/)

Little Gems are a set of books printed on reduced contrast paper, with a large clear font. They're short, simple, but fun. They're good for younger readers or for slightly older reluctant readers. My child enjoyed reading this book, and loved the illustration. The other child I gave this to took out other books in the Little Gems series from the library, and bought other Julia Donaldson books with her pocket money.

"Code: The Hidden Language of Computer Hardware and Software" [https://www.amazon.co.uk/Code-Language-Computer-Hardware- Sof...](https://www.amazon.co.uk/Code-Language-Computer-Hardware- Software/dp/0735611319) I had a friend who knew a lot about the software, and knew a lot about hardware but their hardware knowledge was a bit patchy. Code helped solidify their knowledge. If I could have afforded it I would have given them The Art of Electronics and the companion Student Manual. (This was in the 1990s. I haven't read the new version and I don't know how well it works today.)

"Bomber Command" [https://www.amazon.co.uk/Bomber-Command-Pan-Military- Classic...](https://www.amazon.co.uk/Bomber-Command-Pan-Military- Classics/dp/0330513613/) I liked this book because it describes how we (the UK) went into world war 2 with ethical notions around not bombing civilian populations and ended up fire-bombing several heavily populated German cities. It's also eye-opening about the scale of this part of the war, and the cost in lives of aircrew.

<comment><AUTHOR> I would surely read "Code: The Hidden Language of Computer Hardware and Software"

</comment></comment><comment><AUTHOR> Clickable Link: [https://read.gift/u/notoriousarun](https://read.gift/u/notoriousarun)</comment>


On the Impact of Programming Languages on Code Quality - <AUTHOR> https://arxiv.org/abs/1901.10220 <comment><USER2> A common thread I'm seeing in the discussion here is confusing the claims from the _original_ paper with conclusions made by _this paper_. This is a replication study, and it starts by stating what the original paper found. What the original paper found is not what this paper finds. For the most part, this is a replication failure, for a myriad of reasons, including several kinds of misclassification.

From this paper:

 _The reanalysis failed to validate most of the claims of [18]. As Table 6(d-f) shows, the multiple steps of data cleaning and improved statistical modeling have invalidated the significance of 7 out of 11 languages. Even when the associations are statistically significant, their practical significance is small._

The reference [18] is [https://dl.acm.org/citation.cfm?doid=2635868.2635922](https://dl.acm.org/citation.cfm?doid=2635868.2635922), which is the original paper that this paper is a replication study of.

<comment><USER3> Yes, definitely. This is mostly a _non-replication_ of the original study. I was a little disappointed that they didn't look at defects per line of code, even though that's already a fairly well-studied metric.

I think the lesson here is that you can write good or bad code in any language, but choose one that's fit for purpose. Using proper abstractions (including those builtin to languages) probably does more to reduce the incidence of bugs than anything you can do other than writing automated tests.

<comment><USER4> The practice that most reduces the incidence of tests is code review: [https://kevin.burke.dev/kevin/the-best-ways-to-find-bugs- in-...](https://kevin.burke.dev/kevin/the-best-ways-to-find-bugs-in-your- code/)

<comment><USER5> Emphasis on "Formal code review" which is practiced in far fewer shops than "code review".

For those who don't happen to know the difference, formal code review basically uses a check list of common best practices and possible defects to look for versus doing each code review ad-hoc.

<comment><USER6> I thrive on checklists and hate the ad-hoc way I do code reviews on my team. This sounds great, I'm going to go look for some basic formal checklists. I need language agnostic versions and/or versions for javascript, php, and python, if anyone has suggestions.

<comment><USER7> The Art of Software Testing by Glenford Myers has an excellent language- agnostic checklist. See the chapter on "walkthroughs"

<comment><USER8> That is a book that, even in the third edition, has a paragraph that disparages random testing.

It's difficult for me to see how, in the era of jsfunfuzz, Csmith, AFL, and other such tools, such a source should be taken seriously.

<comment><USER7> I've never found a book on software I agreed 100% with. Even my favorites have some bits I think are dead wrong. It doesn't mean the other parts aren't valuable.

<comment><USER8> It means the book has not been updated, at least in that part. And the first edition of the book was written back when computing power was seven orders of magnitude more expensive (or more). Is advice about testing from then really going to be valid now?

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Seems like they're just doing associations, and not controlling for a lot of factors. For example, you can come up with some narratives to explain a lot of these findings:

* Python, JS, PHP, Java, C++ are all very common first languages; I'd imagine the average experience level for these is dragged down a bit compared to others like Golang, Haskell, or Scala. One of the recent Stack Overflow Developer surveys found Golang use to be strongly correlated with age, and since I'm assuming bug count would negatively correlate with age you'd see a confounding factor here.

* Ruby's community has an obsessive culture towards unit testing, that could impact bug levels.

* The trade-offs that make C and C++ attractive such as memory performance are double-edged swords and will naturally correlate with more bugs. For example, I work a fair bit in embedded systems which use MISRA C out of necessity; I've also worked in large scale data processing which chooses C++ for its memory mapping performance over Java or Go. If "number of defects" is your primary measure then you're ignoring some of the reasons languages are chosen. Sometimes a language that minimizes bugs is not a viable option.

* I'd guess there is a skill correlation here: an engineer who is willing to seek out a specific less-used language and learn to use it effectively is _probably more likely_ (not guaranteed) to do a better job than one who is just going with the default choice.

It'd be very interesting to see a regression done that accounts for these factors.

<comment><USER10> _Ruby 's community has an obsessive culture towards unit testing, that could impact bug levels._

Like Smalltalk, they're forced to do this to catch the errors that would've been caught by type annotation. So then, could the argument be made that less stringent type annotation hurts code quality by removing effort from unit testing?

<comment><USER11> > Like Smalltalk, they're forced to do this to catch the errors that would've > been caught by type annotation.

Very few of the unit tests I've written for Ruby/Python catch errors that would be caught by typical type system use in C/Java/etc. (Haskell, maybe, but...) The main thing I miss in dynamic languages vs. static is the more powerful automatic testing possible when test specs can leverage type information (e.g., QuickCheck/ScalaCheck), not an absence of need for testing.

<comment><USER12> I've only ever done property based testing in Scala, but I thought it was pretty popular in dynamic languages like clojure and erlang. What would prevent it from working in Ruby/Python?

<comment><USER11> Without type information already in the code (for parameters, etc.) there would be a lot more overhead in setting it up; it's possible, but higher marginal friction in the ideal case.

Plus, AFAIK, no one has written the libraries, making it even higher marginal friction in practice even more than than is true in the ideal case.

<comment><USER13> Type information generally isn't used when doing property testing in Elixir, and Python has a very mature library too (hypothesis). If there's a difference in popularity, it could just be culture. The Erlang/Elixir community is rather fanatical about reliability.

<comment><USER11> Hypothesis uses the same type annotations as Python's optional typechecker as a tool to select appropriate input data generators without additional test- specific description. That's a fairly common feature of property-based testing tools; I don't know for sure, but I wouldn't be surprised to find that hypothesis and mypy tend to be used in the same segments of the Python community.

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> The problem is that "code quality" isn't just bugs per line of code. Maintainability, extensibility, readability, expressivity all factor into it.

Suppose I have to write 100,000 lines in language B to write something doable in 10,000 lines of A. Who cares if the defect rate is twice as high per line of A: I still have five times fewer defects due to ten times fewer LOC's.

Another thing to consider is the nature of defects. A defect that allows a remote execution exploit is not the same as an incorrect result being ignored and propagating to later calculations, is not the same as terminating with a diagnostic.

<comment><USER15> Very much agree. This type of analysis is hard to quantify but anecdotally I don't know many people who have written Go, Rust or Typescript that would prefer python, ruby, java, javascript or c++ for their daily work after using them.

</comment></comment><comment><USER16> The most practically relevant finding of the original paper remains in effect: the choice of language has an effect of less than 1% on the bug rate[1]. The original paper explains: "With effects coding, each coefficient indicates the relative effect of the use of a particular language on the response as compared to the weighted mean of the dependent variable across all projects." So the entire discussion is on the relative effect of particular languages _relative to the total effect of language choice, which is less than 1%_. The original paper reported stronger _relative_ effects for particular languages, while this one found the effects to be smaller, and in many cases they disappeared altogether, thus summarizing the effects of the languages as "exceedingly small."

So even the comparison of C++ vs. Haskell, that has ~25% difference, is _within that 1%_. This is similar to a study comparing the effect of running shoes on running speed that shows that Nike positively affects your running speed 25% more than Adidas, to the extent running shoes affect your speed at all, which is less than 1%.

\-----

[1] _One should take care not to overestimate the impact of language on defects. While these relationships are statistically significant, the effects are quite small. In the analysis of deviance... we see that activity in a project accounts for the majority of explained deviance... The next closest predictor, which accounts for less than one percent of the total deviance, is language._ ([https://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf](https://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf))

<comment><USER17> Two things this studies haven't measured are time to deliver features, and the number of developers necessary. For example, if a project in Haskell can be delivered faster by a smaller team than an equivalent project in C++, that would be an important factor.

<comment><USER18> There's a concept I discovered in the realm of political science, the "fundamentally unanswerable question" \- ones where it's not actually possible to generate the kinds of counterfactuals you'd need to try and run an experiment.

I think this is probably one of those. Haskell and C++ are very different languages, that are designed for very different purposes, and are popular in very different problem domains. To start with, that would make it difficult to come up with a task that wouldn't handicap one language or the other. (For example, a video game would favor C++.) Even if you found that, you'd have a hard time coming up with a good test. Under random assignment, Haskell is presumably going to be handicapped relative to C++ by the fact that most languages are imperative and use Algol-style syntax. You could try to avoid that by using participants with zero programming experience, but then you're studying learning curve for absolute beginners rather than productivity among experts. And so on and so on.

Long story short, probably best to leave this one to the spittle-flecked Internet arguments.

<comment><USER17> I really don't see how that would be the case. Both Haskell and C++ are general purpose languages, there are plenty of projects written in many overlapping domains. The test would to treat projects as black boxes, and look for trends across many projects. If you saw a trend that Haskell projects are consistently delivered faster by smaller teams, then you could make a hypothesis that Haskell is a factor. At the end of the day, we've come up with ways to test hypothesis like quantum mechanics. I'm pretty sure measuring impact of a language on software development process is a tractable problem.

<comment><USER16> As someone who develops mostly in C++, I can tell you that productivity is a very small concern. We are well aware that most GCed languages are significantly more productive. Virtually the only reason people use C++ nowadays is for performance (and/or footprint) (that is partly because we have seen reports that Java delivers better productivity in the early '00s, so those who care about that have switched a long time ago; in fact, the effect was so large that they didn't have a choice). Now, if someone showed that Haskell has a significantly better performance/footprint than C++ that may cause someone to shift.

<comment><USER17> Sure, in some domains you have to use specific languages because of the constraints of the domain. However, as you yourself state, a language can play a significant impact when it comes to productivity.

For example, immutability provides similar benefits to GC. Instead of the developer having to manually manage references across the project by hand, the language takes care of that work. This frees the developer from doing additional work, and removes a source of errors. This also directly leads to the ability to do local reasoning about code resulting in developers needing less context to understand code. So, if GC plays a significant enough role then it's highly likely that immutability does as well because it addresses a similar set of problems.

</comment></comment></comment></comment></comment></comment><comment><USER19> My own take of this:

\- This study tries to enhance the original work by better metrics (e.g. confusion with C/C++), using better statistics (e.g. uncertainty).

\- Automatically evaluating the quality of a code is hard and time-consuming. They had to use peer review of labellisation.

\- Most of the old claims are not confirmed.

\- Only 2 languages in this study had both a significant impact (impact coeff) and enough fiability (p-value): Clojure and Haskell. But the impact is still small, and there may be other influencing factors.

\- They propose several ways to further enhance their work (e.g. taking regression tests into account).

<comment><USER20> _"... and there may be other influencing factors."_

Selection bias? Consider the type of person likely to be attracted to languages like Haskell or Clojure.

(Note, didn't read the original study so I don't know the selection criteria. Were code samples in different languages from the same programmers compared, or were there different sets of programmers per language? My comment really only applies to the latter case.)

<comment><USER21> What is the type of person likely to be attracted to languages like Haskell or Clojure?

<comment><USER22> I can think of selection bias effects both in-favor of more defects and against it.

On one hand, Haskell or Clojure probably attract more academic types who have a reputation for (consistent with my experience) on-average worse-quality code.

On other hand, the barrier-to-entry for these languages is higher so they tend to be programmed by more experienced folks. I assume that people pick functional languages in part because they believe the functional paradigm leads to higher-quality code, so the sample probably cares more about code quality to begin with.

<comment><USER23> You can't win against people's insecurities.

They went to school, they where not bashed in the head with hammers.

</comment></comment></comment></comment></comment><comment><USER24> This is great (to see something I know about on HN). As an undergrad at UMass (where Emery Berger teaches), I remember the exact paper they are talking about, and how it was presented at UMass (this was part of a lunch and learn with the faculty, grad, and undergrad students and the author of the original paper).

I remember Emery being quite confused at the methodology in the paper, and he was very confused with one aspect of it, which was how they came to conclude that C was more bug prone (something about void * being able to cast to everything? It was a while ago...)

Glad to see he wrote a rebuttal, a little awkward watching a professor debate with the paper's author :)

<comment><USER25> I knew Emery at UT Austin; he's a good researcher, but I'd imagine "awkward" is an understatement.

</comment></comment><comment><USER26> One of the simplest but more important conclusions that affects me all the time... it's easy to search for things, but hard to know whether you've got all the answers you want and hard to know if all the answers you got are answers you want.

6.3 Grep considered harmful

Simple analysis techniques may be too blunt to provide useful answers. This problem was compounded by the fact that the search for keywords did not look for words and instead captured substrings wholly unrelated to software defects. When the accuracy of classification is as low as 36%, it becomes difficult to argue that results with small effect sizes are meaningful as they may be indistinguishable from noise. If such classification techniques are to be employed, then a careful post hoc validation by hand should be conducted by domain experts.

<comment><USER10> _One of the simplest but more important conclusions that affects me all the time... it's easy to search for things, but hard to know whether you've got all the answers you want and hard to know if all the answers you got are answers you want._

Smalltalk was wonderful in this regard. If you wanted to search for how something was used, you just right-click search for "senders." If you wanted to find implementors, the same.

This big difference occurred with chains of senders. In other languages, where there's 2 or 3 ways to get to something or call something, you have this O(2^n) or O(2.5^n) blowup in the work you have to do to properly follow chains of senders. With Smalltalk, it's just O(n).

On top of that, there were tools that could let you compose really sophisticated SQL like queries of the code base, dynamically, then pop that up in a browser.

</comment></comment><comment><USER17> It looks like the key takeaways are:

Overall language effects do not appear to be a dominant factor in software quality. Manual memory management is error prone. Functional languages appear to produce better results than OO/imperaive ones. Static typing does not appear to play a measurable role. In fact, Clojure and Erlang were in a category of their own, beating out statically typed counterparts.

<comment><USER27> > Clojure and Erlang were in a category of their own

I wonder how they controlled for developer skill?

<comment><USER17> It's likely that Clojure and Erlang communities have a higher ratio of experienced developers than mainstream languages. However, this would be true for Scala and Haskell communities as well presumably. Meanwhile, the fact that experienced developers choosing these languages appear to produce better code is an interesting data point of itself.

</comment></comment></comment><comment><USER28> The language is what makes me apply to work at your company with 15 years experience but paid 20% less than I would be if I had to do OO. That's the driver.

Is the code quality better? Well maybe. Probably. But dollar for dollar you'll do better with a good language because you'll get much better people for your dollar.

</comment><comment><USER29> I wonder if this lack of significant link is because number_of_bugs = time_spent_programming / time_fixing_bugs

So choice of language does affect the number of potential bugs. But this ratio of effort a programmer gives to bugs vs features is almost completely independent. Actual bugs making it past the programmer depend on how much effort the programmer cares to expend

So a safer language doesn't reduce bugs. It's like farmers with back pain from driving tractors. Giving them comfier rides doesn't reduce their pain; it just means they drive faster upto the same pain limit

If this is true, then bugs can be reduced by making bugs more painful for the programmer

But also a safer language will let the programmer drive at a higher speed, releasing a greater percentage of safe code (even if the total number of bugs is the same)

</comment><comment><USER30> Good to see better statistics being applied.

However, the base methodology appears to be really weak.

The presence of fixes doesn't necessarily reflect the presence of underlying bugs: highly conscientious projects make many "fixes" that improve the software quality against an abstract ideal without directly fixing any defect, while highly unconscientious projects don't bother fixing anything.

There are also many confounders. For example, I've seen project institute restrictions on refactoring changes in response to the huge amount of brownian-code-motion popular projects can receive, only to then have some contributors start misleading describing their commits, "by splitting this function up, we avoid the risk that someone would later introduce an overflow!".

Considering how important software quality is to contemporary engineering, including life safety critical systems, it's disappointing that we don't see more randomize studies. E.g. take a pool of developers randomly assign them to teams using different tools each to accomplish the same task, then compare the results against each other and a hidden test suite.

</comment><comment><USER31> Of note is that these are all associations. It's possible the associations are all due to selection effects (or even that the "better" language are actually worse but their effects are reversed by selecting for programmers who are better).

In the early days of Python, some employers used it as a way to filter for candidates who were ahead of the curve. I believe Paul Graham mentioned Lisp being good for attracting better programmers, although I can't find the reference anymore [1]. If there's any value in this kind of filter, the effects will show up in the programmers' output.

1\. I'm having a hard time finding references for these assertions; the best I've found is some Reddit posts and Joel Spolsky's post on finding great developers: [https://www.joelonsoftware.com/2006/09/06/finding-great- deve...](https://www.joelonsoftware.com/2006/09/06/finding-great- developers-2/)

<comment><USER32> In an infamous rant, Linus Torvalds also hints at using a language as a filter for programmers[1]:

>Quite frankly, even if the choice of C were to do _nothing_ but keep the C++ programmers out, that in itself would be a huge reason to use C

[1] [http://harmful.cat-v.org/software/c++/linus](http://harmful.cat-v.org/software/c++/linus)

<comment><USER33> Considering the astonishing density of defects in Linux we can treat its author's advice on software development as anti-advice.

<comment><USER25> What is the density of defects in Linux? Any published comparisons?

<comment><USER34> According to Coverity, the "defect density" of the Linux kernel is around 0.5 errors per 1000 lines of code, while the average of the analyzed open source projects is around 0.7. Best among the analyzed projects is Python (the language/stdlib I guess) with an error rate of 0.08.

</comment></comment></comment></comment></comment><comment><USER35> Casual observation: adding a framework to any language seems to improve the overall code quality. It adds and teaches structure, patterns and good practices that developers usually follow.

I've seen terrible codebases written in vanilla PHP, JavaScript, Python (probably the worst ones). But I've seen very good looking, easy to understand, easy to maintain codebases written in Symfony, React and Django.

(React is an interesting case because it's not actually a framework but a view library, which doesn't force you to follow any structure to your project. But its declarative, component-based paradigm seem to help developers structuring their projects and writing simple, reusable and composable components in a good way).

<comment><USER36> I agree. Our framework, libraries, and/or interfaces can and should make a bigger difference than programming language.

If you have to use the "weird parts" of a language to get typical work done, you are doing something wrong. And if you are not using the weird parts, then programming languages look and do pretty much the same thing.

Braggings such as, "look! My language can do double recursive lambda backflips while blindfolded and chewing gum!" are mostly just 1950's car racing done in cubicles. We buy cars to get to work and shops as cheaply and conveniently as possible, not beat Fonzy.

<comment><USER37> I think it really depends on how you use the "weird parts". Some of those let you write code much more concisely and effectively. Used in the wrong context, it's a unnecessary distraction. It also depends on if you want to write "typical code" or code that the competition can't match.

See Paul Graham's essay on the Blub Paradox [0], which discusses why some languages seem to have "weird parts" from the perspective of someone who knows a less-powerful language.

[0] [http://www.paulgraham.com/avg.html](http://www.paulgraham.com/avg.html)

<comment><USER36> You make it hard to hire if you limit the field to those who know the esoteric techniques. Programming itself is mostly a dead-end career; you either move into management or quasi-management, or face ageism on average. There is thus not a lot of incentive to "perfect the art".

</comment></comment></comment></comment><comment><USER38> I've read a lot of code as a consultant. The best codebase I've read had almost no comments and was written in erlang. Besides that every codebase I've read in Golang were super clear and of excellent quality for the exception of one that was written by java developers.

I can say I hated reading C because of maccros and different build systems. I hated C++ codebases because people abused generics. And I hated Java the most because of the verbosity and the directory structure and all the layers of abstractions and all the factories and all the singletons and all the...

<comment><USER39> That is always a risk if a team decides to pick up a new language but does not make the effort to learn the language properly. At work we are going through a similar Java - Go transition, so I know :(

<comment><USER40> It's always a problem when people shoe-horn a non-idiomatic approach from one language into another.

It makes me wish the language creators wrote a single none-trivial 'this is how we intended it to look' project.

When learning a new language I find as many big projects written in it as I can and spend time exploring them.

It helps but there is often no guarantee those projects are doing it idiomatically either.

<comment><USER41> Looking through the Python standard library or Go standard library should be a clue not to use Java idioms, but yes I realize those habits are hard to break. I have seen Java-in-Python and it is indeed painful.

<comment><USER40> The problem with reading framework and library code is that it's very coupled to what it is, so while it's interesting and valuable to read it's not really the type of code you'd see in a business app or whatever.

<comment><USER5> Yeah I've tried this several times and the code written for the std library is so different from LoB code(because the domains are so different) that you can only learn a small % of possible idioms from them.

</comment></comment></comment></comment></comment></comment><comment><USER42> Unfortunately, it's the original paper that will keep getting quoted at me forever.

My favorite line from this paper is: "Correlation is not causality, but it is tempting to confuse them." I think most people believe "correlation is not causality, but most of the time it is", when in reality it is, "correlation is not causality, and almost never is." There was a great analysis of this in a book or paper I read years ago that I haven't been able to find, but the tldr is that if you have a set of events, if causality were truly common, the events would for a seized up network of causality.

</comment><comment><USER43> ...deleted

I skimmed the paper. I misunderstood the results.

<comment><USER44> Your quote was the conclusion of the original work by Ray et al., not the one from the reproduction paper linked here. That one in short is:

"Unfortunately, our work has identified numerous problems in the FSE study that invalidated its key result."

</comment></comment><comment><USER45> Testing Objective-C is sort of pointless, they should have picked Swift.

<comment><USER3> I disagree. If anything, they should have tested Obj-C _and_ Swift. I would also have liked to see Scheme, Common Lisp, or something else lisp-y besides Clojure. Kotlin would have been interesting. R or Mathematica would have been fun, too.

I guess it just comes down to needing a sufficiently large corpus of code and commits and having to eventually publish.

</comment></comment><comment><USER46> Maybe off topic, but isn't the language in the abstract a bit aggressive?

I mean, this type of study is somewhat open to interpretation. It's not like everyone should arrive to the exact same numbers..

<comment><USER47> Which part? This kind of direct language is both standard and encouraged in academia.

The idea is to take a clear position, which can be attacked if wrong.

</comment></comment><comment><USER48> Interesting! Excepting typescript, the "safer" languages also happen to be the ones I gravitate towards on a daily basis and actually enjoy writing programs in, while the others...

It'd be interesting to see whether programmers' preferences uphold the division posited by the study, or whether they are widely variable—eg is it likely that if you prefer ruby you'll also prefer typescript over JavaScript, if you prefer Haskell you'd choose clojure over c++ etc.

<comment><USER2> I think you're confusing the conclusions from the original paper with the conclusions from this paper. This paper is a reproduction of the original study, and for the most part, it is _not_ able to reproduce the findings.

<comment><USER48> How right you are. That's what I get for skimming news piecemeal way too quickly in the mornings!

</comment></comment></comment><comment><USER49> (Edited-- I was reading the original paper, which showed good results for TypeScript; the new paper linked above refutes that result. My mistake. Thanks to the posters who corrected me!)

The winners in this paper are Clojure, Haskell, Scala.

I look forward to seeing Rust added. The authors go into substantial detail about what they consider errors, and in my personal experience Rust solves many of them. See e.g. "Some defect type like memory error, concurrency errors also depend on language primitives."

<comment><USER50> Scala will really start to shine only after Scala Native[1][2] is ready.

[1] [http://www.scala-native.org](http://www.scala-native.org)

[2] [https://github.com/scala-native/scala-native](https://github.com/scala- native/scala-native)

<comment><USER51> What features of Scala Native do you think will improve Scala code quality?</comment></comment></comment>


How to set up Xilinx Vivado for source control - <AUTHOR> https://github.com/jhallen/vivado_setup <comment><USER2> Use fusesoc. [https://github.com/olofk/fusesoc](https://github.com/olofk/fusesoc)

Use your own editor and source control tools outside of Xilinx's 1990s straightjacket. It creates Vivado projects and invokes it to do synthesis. You can open the generated projects in Vivado if you really need their GUI.

</comment><comment><USER3> FPGA Pro here. I checked out the README.md to see if I could pick up any tips. It is a good guide for a first time through, but I recommend also reviewing the Xilix documentation on this.

There's Xilinx App Note 1165 [Circa 2013] which is getting long in the tooth but still valid: [https://www.xilinx.com/support/documentation/application_not...](https://www.xilinx.com/support/documentation/application_notes/xapp1165.pdf)

And, Chapter 5 in Xilinx User Guide 892 is "Source Management and Revision Control Recommendations" [https://www.xilinx.com/support/documentation/sw_manuals/xili...](https://www.xilinx.com/support/documentation/sw_manuals/xilinx2019_1/ug892-vivado- design-flows-overview.pdf)

There is also a .gitignore example which can be helpful but is not geared towards a minimal file set without alot of tweaking: [https://www.xilinx.com/support/answers/61232.html](https://www.xilinx.com/support/answers/61232.html)

A few words of warning here: The documentation recommends using the write_project_tcl and write_bd_tcl scripts. I have experienced problems with both of these not faithfully recreating the .xpr and .bd files so exercise caution with them. A better approach is to avoid .xpr files and to use a non- project or scripted flow. If you have to use a Vivado project for some reason (I can think of a couple) then create and maintain tcl script to generate the project by hand. One can use the write_project_tcl to get started and then update it by copying the tcl generated by Vivado after each GUI operation out of the Vivado tcl console into the project generation script when making changes to the project one wants to keep.

I have had the most problems with write_bd_tcl so I am now experimenting with just checking in the .bd file and setting the .bd extension to "binary" and various merge strategies in the .gitattributes file after several projects worth of frustration with the write_xx_tcl nonsense.

Finally, take all other Xilinx recommendation of source files to check in with a grain of salt. The documentation recommends checking in way too much. I recommend sticking with the "Minimum Set of Source Files to Manage" with archival backups of all output products for critical tags (eg. releases) somewhere outside the VCS.

</comment><comment><USER4> They made a nice effort in dressing it up but you can just see the shitty Eclipse scream at you, it's deafening. The biggest tell is when they invariably copy the abominable Eclipse "wizard" flows.

<comment><USER5> I'm told Eclipse is actually good for Java, but there are so many shitty adaptations of Eclipse to a hardware-vendor's toolchain that it's really tarnished the brand image for me.

</comment></comment><comment><USER6> You mean the multi tens of thousand dollar FPGA set up that Xilinx hawks doesn't have source control?

<comment><USER7> I understand there is some validity with this criticism. Xilinx has always been slow to adopt standard software development practices. But really, Xilinx tools have never cost 'multi-tens of thousand dollar's. The most expensive tools are several thousand dollars. There are also free tools for smaller devices / certain flows. Source control is done with tcl scripting (simple text files) and standard source control tools. It's not as bad as it was in the past. Cheers.

<comment><USER8> Microsemi Libero is a joke and is probably the greatest hindrance to getting actual work done. I wish Xilinx bought them out instead of Microchip so there could actually be some improvement to the tools. You can throw every bit of computing resource at it's dinosaur PnR tool and it will just happily chug along at 1% CPU usage. They just came out with some update that made a 20% improvement to PnR, literally hours of time gained back from watching a wheel spin. What is it doing? Who knows, it will probably fail and not tell you why. Zero source control, almost zero documentation for scripting, and a design tool that seems nearly crash everything just to tell you there are IP core updates available.

The only parts that actually work reliably are whatever ancient Actel-branded tools are hidden in the suite.

</comment></comment></comment><comment><USER9> Whilst I applaud the effort, could someone explain why this is preferable to the scripting flow?

I agree you need to do pin-planning and possibly play with constraints, but all of that is possible from a post-synthesis design checkpoint. The advantage of OOC flow is it's scriptable, reproducible, you can parallelise different place and route strategies if you're really stuck. This advice about IP in out of context mode is good though - you need that whether you're scripting or using the UI.

The only thing that really grinds my gears about source control is that checkpoints are 50-100MB, so it's not great if you want to incrementally place and route (which is often a nice time saver)

</comment><comment><USER10> There are several open source tools that can generate a Vivado project from a high level description that can be version controlled. One example is [https://gitlab.com/truestream/tsfpga](https://gitlab.com/truestream/tsfpga)

<comment><USER2> fusesoc is another one.

</comment></comment><comment><USER11> I have been through a similar process myself a couple years back, and just wanted to say that this is a really good effort in trying to tame a beast that doesn't really want to be tamed. Lots of experimenting around with write_project_tcl and figuring out what settings are needed to coerce the tool into making version control/CI friendly decisions. Nice work!

</comment><comment><USER12> Why they would use tcl? Why not something more cleaner?

<comment><USER13> Because that's what Vivado uses for scripting?

</comment></comment><comment><USER14> Off topic: Is this a good time to buy Xilinx shares? I seem to hear their name, and talk about synthesis every week on here now.

<comment><USER15> Chip stocks are soaring, so no. They're coming due for a market correction.

There's also a lot of volatility these days since all chip stocks rise and fall with trade news related to China. If you know or have faith that the trade tensions between the West and China are going to be resolved in the near future, buy. If you don't, stay away.</comment></comment>


Google to announce new App Engine runtime for "very popular language" at I/O - <AUTHOR> https://plus.google.com/103859497630711080569/posts/4T9FUCPsewA

<comment><USER2> Speaking of PHP in the clouds... fun fact: you can push PHP files to Heroku and they'll "just work".

Do it in 30 seconds:

        mkdir ~/testypoo && cd ~/testypoo
        echo "<?php phpinfo(); ?>" > index.php
        git init
        git add .
        git commit -m "woohoo php in the cloud!"
        heroku create
        git push heroku master

Now enjoy your insanely simple + free PHP hosting. I was pretty excited and surprised when I discovered this.

<comment><USER3> > Now enjoy your insanely simple + free PHP hosting.

"Simple" and "free", sure, but "enjoy"?

<comment><USER4> As much as I dislike PHP as a language I am still insanely productive in it for dynamic websites. I enjoy being productive more then I enjoy using the latest languages/frameworks.

So yes. I enjoy using PHP for all its faults.

<comment><USER3> I feel a bit bad for taking that cheap shot at PHP, to be honest. We're all adults, and you should use whatever makes you more productive. A good programmer can write maintainable code in any language.

However, "productive" and "latest frameworks/languages" is a bit of a false dichotomy.

<comment><USER4> I agree. But I have seen many programmers claim they will be more productive in language/framework X because its new.

As for cheap shots at PHP, I see PHP like the USA. Easy to take cheap shots at because its so large and runs so much. For all its faults/flaws its still pretty productive though.

I am an Aussie for the record.

<comment><USER5> > I agree. But I have seen many programmers claim they will be more productive > in language/framework X because its new.

I've never seen that. I've seen many programmers claim that they will be more productive in new language/framework X because it includes a combination of features A, B, and C that aren't found together in other languages/framewors, but never simply because the language/framework is new.

The closest I've seen to the "because its new" thing is "because it doesn't have the accumulated cruft of framework Z", but while that may be _related to_ newness, its still about features, rather than newness alone.

<comment><USER4> Sorry that's actually what I meant. "I will be more productive with X because it has Y feature". They still tend to underestimate though.

Don't get me wrong, i'm all for new technology but bleeding edge on new projects can be a recipe for failure most of the time.

<comment><USER5> > Don't get me wrong, i'm all for new technology but bleeding edge on new > projects can be a recipe for failure most of the time.

That's a fairly good reason for bleeding edge to be used as one track of a dual- (or multi-) track project which includes a short-turn-around, low-risk, low-reward track and one (or more) higher-risk, high-reward, longer-turnaround track.

This is equally true regardless of whether the project is "new".

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER6> _The pre-release of the python SDK released yesterday contains a PHP runtime_

[https://groups.google.com/forum/?fromgroups=#!topic/google-a...](https://groups.google.com/forum/?fromgroups=#!topic/google- appengine/0M3fYkN8y0c)

</comment><comment><USER7> Is it OCaml? I bet it's OCaml.

<comment><USER8> No way, gotta be something more mainstream: Haskell.

<comment><USER9> Nope. Erlang.

<comment><USER10> Erlang!

<comment><USER11> Erlang?

<comment><USER12> Well, I see you've fixed the bug then.

</comment></comment></comment></comment></comment></comment><comment><USER13> Woah, desperate much?

Headline roughly translates to "we're willing to pay the perpetual maintenance cost of a new runtime because our existing runtimes aren't attracting enough users to justify the product", and the reasons for that cannot be fixed by adding yet another layer of lipstick to a pig.

Having worked on 7k+ reqs/sec sites on App Engine I can expand on this in great depth, but please google my comment history before making me write another essay!

<comment><USER5> > Woah, desperate much?

I doubt that desperation is an issue.

> Headline roughly translates to "we're willing to pay the perpetual > maintenance cost of a new runtime because our existing runtimes aren't > attracting enough users to justify the product"

No, it doesn't. You may interpret it that way, but that's not a translation, that's your unsupported ascription of a motive.

It would be at least as justifiable an interpretation to say that this is a sign that the AppEngine platform has matured as a standalone product (rather than just a way to derive some incidental revenue at low cost from infrastructure Google has to have to support their core services) that they are getting around to supporting languages with heavy market demand but little internal traction in Google, rather than what is internally-useful to Google.

<comment><USER14> To this end, did anyone suggest Heroku was a dying platform when they announced Python support? I sure didn't hear anything like that.

</comment></comment></comment><comment><USER15> I hope people will put some effort in making WordPress compatible with App Engine. WordPress' reliance on local files is usually a big pain point.

<comment><USER16> There also seems to be a dearth of good FOSS CMS's for AppEngine, which would otherwise be a great platform for that.

A WordPress port might also make a strong full service option for SMB's self- hosting their public corporate site on Word Press but using Google Apps for email and corporate infrastructure. Now they can put it all on the same P/IaaS.

</comment></comment><comment><USER17> Here's hoping it's 6502 assembly.

<comment><USER18> You probably want its successor, the 65c816. Has a handy single instruction for getting a first pass of your web app running - MVP.

<comment><USER17> Mother of God.

Can you imagine how awesome it would be if they actually supported this on GAE?

<comment><USER18> Especially if they added some way to plug in your old SNES carts. Super Mario Web - not as capable as the semantic web but a lot more fun.

</comment></comment></comment></comment><comment><USER19> Well according to GitHub it's either JavaScript or Ruby (PHP is only 6th) <https://github.com/languages>

<comment><USER20> Github is a representative sample of published open source software, not of code being used in production.

<comment><USER19> Right and that's what I meant, by saying "according to GitHub".

</comment></comment></comment><comment><USER21> I am honestly surprised it took this long.

Can't say PHP is my favorite but I know lots people who use it every day.

Will it take 5 years before they have ruby on rails?

<comment><USER5> JRuby and Rails, AFAIK, have been able to run on the Java runtime for quite some time.

</comment></comment><comment><USER22> Sweet, been wanting PHP support on App Engine for a long time.

</comment><comment><USER23> just throwing this in the hat, C# and .NET. It's possible...

<comment><USER24> I was thinking C# (mono) as well. My second guess would be Javascript. Looking in existing runtimes for hints is cheating.)

</comment></comment><comment><USER25> PHP or Ruby probably

</comment><comment><USER26> Javascript

</comment><comment><USER27> I was hoping for node or dart, but it looks like PHP instead?

<comment><USER28> Dart doesn't come close to qualifying as a "very popular" language.

<comment><USER21> >Dart doesn't come close to qualifying as a "very popular" language.

Dart doesn't come close to qualifying as a "popular" language.

Fixed. :)

</comment></comment></comment><comment><USER29> Let me guess, "Go" ? :-)

<comment><USER5> Go was the _previous_ language added to App Engine.

</comment></comment><comment><USER14> or "How I learned to stop worrying and love ruby."

</comment><comment><USER30> asp.net!</comment>


Tesla will build battery 'Gigafactory' in Nevada - <AUTHOR> http://www.usatoday.com/story/money/cars/2014/09/03/tesla-gigafactory-nevada-carson/15029233/

<comment><USER2> I live up in Tahoe, and I've always wondered why Reno doesn't attract more high tech enterprises. It has a good business climate, and it sits right there at the foot of the Sierra Nevada, with skiing minutes away and endless other outdoor possibilities. SF and Silicon Valley are a hop and a skip away. Granted, some of the casinos are eyesores, but who doesn't have eyesores. Right now, Reno is also practically free of traffic congestion and stuff like that. Not sure what I should be wishing for...</comment>


Bing's search algorithm has been had - <AUTHOR> Was doing some work for a client. Looks like 90s webcrawler all over again.<p>https://www.bing.com/search?q=seattle%20personal%20injury%20attorney <comment><USER2> One nice thing about Bing is that it actually offers an API. I had a client who needed some scraping done -- basically, scrape a bunch (millions) of search terms and then intersect the results -- and I was able to use the Bing API to do it, without any need to beat Google CAPTCHA's or setup complex proxy systems.

</comment><comment><USER3> Looks like it pretty much works for "* personal injury attorney".

Slightly embarrassing.

<comment><AUTHOR> definitely did a quick look on whats going on, all redirects to one URL, here's there request:

HTTP/1.1 302 Found Date: Mon, 29 Jan 2018 22:12:45 GMT Content-Type: text/html; charset=utf-8 Connection: keep-alive Set-Cookie: __cfduid=d16c7107d2f0d7f82b98a8549260931421517263965; expires=Tue, 29-Jan-19 22:12:45 GMT; path=/; domain=.qpersonallawyer.com; HttpOnly Cache-Control: private Location: [http://google.com/?serverkw=Bellevue+Personal+Injury+Attorne...](http://google.com/?serverkw=Bellevue+Personal+Injury+Attorney&bingkw=&maindomain=qpersonallawyer.com) X-Powered-By: ASP.NET Server: cloudflare CF-RAY: 3e4f88e5e2925534-ORD</comment></comment>


More detail analysis of the Wuhan coronavirus - <AUTHOR> https://jameslyonsweiler.com/2020/01/30/on-the-origins-of-the-2019-ncov-virus-wuhan-china/ <comment><AUTHOR> May be accidental release when tying to find a defend against sars etc. Even got a patent for it. [https://patents.google.com/patent/CN1276777C/en?q=pshuttle-S...](https://patents.google.com/patent/CN1276777C/en?q=pshuttle- SN&oq=pshuttle-SN)

Less witch hunt this article but we need to know the case zero ...</comment>


FTC: Butterfly Labs Case Not Part of 'War on Bitcoin' - <AUTHOR> http://www.coindesk.com/ftc-butterfly-labs-war-bitcoin/

<comment><AUTHOR> Did anyone else notice that the BFL site is still configured to take orders for 10GH/s units, accepting bitcoin payments only? I thought that words like "shut down" and "closed" were pretty clearly reported from various sources. I can't imagine courts are going to look favorably on this action.</comment>


Ask HN: Performance optimizations for Geospatial applications - <AUTHOR> I am in the process of creating a mobile app that consumes geospatial data intensively. I am displaying a map of points of interest and upon user interaction (pinching, panning) with the map, I query the database for the new region. As you may infer this is very computationally expensive as I could potentially be making thousands of geospatial queries per minute. My current DB is RethinkDB, however as explained in Uber's tech stack article they use Redis for caching geospatial data. Does anyone have any insight into how to accomplish this? Are there any alternatives you recommend? Thanks <comment><USER2> I don't know exactly what kind of data you are using but here are a few things -

Often with geodata, people viewing a map of the whole country are interested in a different subset of the data than people viewing a small local area. For instance, when I view Texas I don't need the database to tell me where every street is - only the major rivers and highways. This is called layering. Consider 3-5 zoom levels and filter out the data that your user is going to care about at each, then in your indexing / storage scheme make it easy for the database to filter down to an appropriate dataset for the zoom level.

Also, fetch an area 4 times too big from the server and cache it so as they pan around in the local area you don't have to keep querying.

If you are rendering maps on the server side, and hand rolling that, consider using WMTS rather than WMS to serve your raster maps. WMTS tiles can be cached much more effectively than WMS tiles.

Just because something can be a spatial query doesn't mean it has to be. Spatial queries are relatively heavy. If your users are mostly operating inside one country, feel free to segment your data by country and only query the database for data for the countries on the screen - much lighter than applying a bounding box to a bunch of polygons.

<comment><AUTHOR> Well I have a simple GeoJSON point object with lat/long coordinates. The document also stores a score of sorts and what I plan to do is limit the results to a certain number say 20 (although still not quite sure) and then sort by the score. This way people will only view the most interesting locations no matter if they are looking at a street level view or on a national level.

The way rethinkDB advises is to query by intersections of circles. So on the client I calculate the center of the map, and then the radius based on the edges of the screen. Then I send that to construct the circle and get all points within the circle. I am just unsure how I can organize these results and cache them within Redis (or a better alternative) for ease of retrieval.

<comment><USER2> Okay, so presumably you are rendering this geojson in something like a google maps data layer, or some other kind of mapping library.

That means if you give it some GeoJSON which describes some points outside the normal screen bounding box you then that is okay - stuff on screen gets shown and stuff off screen doesn't get shown until you pan to it.

So far so good.

Now request and a circle 4 times too big and every time they move the screen, test if the ouside of the screen is outside that circle yet. Don't send another request till it is. Now you have a lot less requests for panning around.

But you want to cache, and all these very unique circles are hard to cache for right?

So instead of fetching a custom circle, divide up the world into a bunch of mathmatically calculated static squares [1]. When they view an area decide what square they are inside and query that. Like the 4xbig circle if you are feching some area outside the current view then it's around for when they pan. But critically - you can cache the result for a query for a square!

Hope this helps?

I haven't done this with rethinkdb.

[1] [http://www.ra.ethz.ch/cdstore/www6/technical/paper130/pyrami...](http://www.ra.ethz.ch/cdstore/www6/technical/paper130/pyramid.jpeg)</comment></comment></comment>


Sound in a Nutshell: Granular Synthesis - <AUTHOR> https://www.granularsynthesis.com/hthesis/hthesis.html <comment><AUTHOR> This book provides an approachable view of the history and practice of granular synthesis.</comment>