Hepatitis C kills more Americans than all other infectious diseases combined - <AUTHOR> https://scopeblog.stanford.edu/2019/09/03/hepatitis-c-all-adults-in-u-s-under-80-should-be-tested/ <comment><USER2> I'm working on direct-to-consumer STD testing in JasonHealth.com . Some thoughts on Hep C testing:

Hep C Antibody is a very inexpensive test. We charge $25 for it.

It takes a long time for the body to produce the antibodies after infection. This test is only 90% sensitive after 12 weeks ( [https://www.hepatitisc.uw.edu/go/screening- diagnosis/acute-d...](https://www.hepatitisc.uw.edu/go/screening- diagnosis/acute-diagnosis/core-concept/all) ). Testing shortly after possible infection with this test is not effective.

The best early detection test is Hepatitis C Viral RNA, Quantitative, Real- Time PCR. It's able to detect infection 2 weeks after.

The absolute best testing protocol after suspected infection is what doctors use for needle-stick. Test the person who may be spreading the infection immediately using the RNA test. If RNA is detectable start the short course of Hep C drugs on the person who might be infected. This will avoid acute Hep C infection altogether.

Hep C testing is very popular direct-to-consumer. For us, patients usually get it as part of full STD screening ( [https://www.jasonhealth.com/l/std- testing](https://www.jasonhealth.com/l/std-testing) ). About 80% of Hep C tests are ordered as part of that.

Anecdotally, it's not usually ordered by MDs as part of STD screening. Hopefully, these new guidelines will change that.

<comment><USER3> > It takes a long time for the body to produce the antibodies after infection. > This test is only 90% sensitive after 12 weeks

That's not much of a problem except for people worried about infection after a single known exposure (e.g. needlestick in a medical setting).

About a third of patients spontaneously clear the acute infection within six months. On top of that, some countries (such as Germany) refuse to treat acute infections with antivirals - so patients have to wait 6 months for the infection to develop into a chronic infection before they can take the medicine which cures it.

<comment><USER4>
      That's not much of a problem

It certainly _is_ a problem if they can infect others during that interval.

<comment><USER3> > It certainly is a problem if they can infect others during that interval.

Tell that to Europe! The NHS, as well as private insurers in Germany and the Netherlands, _refuse_ to treat patients until they've been infected for at least six months. In the US, insurers don't make this distinction.

</comment></comment></comment></comment><comment><USER5> Using a throwaway for obvious reasons.

Like many of you, I'm a young and healthy guy. I haven't taken a sick day in years. Since I'm young and healthy, I didn't see the need to take an annual physical exam. Scheduling doctor's appointments is such a hassle. I'm sure many of you feel the same.

So when I was diagnosed with Hepatitis C, it came as a complete shock to me. The shock was due to two reasons:

1\. I wasn't involved in any of the "high risk" activities associated with Hepatitis C, which are intravenous drug use and tattoos.

2\. I regularly went to the doctor's when I was a child, so there was at least 20 blood tests done back then. None of tests caught the Hepatitis C back then.

Since Hepatitis C is a chronic condition for most people, if I didn't catch mine early, it would have been found much later in life when all of the damaged has been done. I only caught my Hepatitis C because I wanted to an elective cosmetic medical procedure. It was my own vanity, plus pure luck, that caught it.

When I was a child, I was covered under the government's and my parents' health care plans. When I entered college, I was enrolled under the mandatory student health care plan. After I entered the work force, I was covered under my employer's health care plan. All this health care was fully paid for, either through tax dollars, or my parent's contributions, or my own contributions, and I stupidly chose not to utilize it, because I was young and healthy.

If you don't want to end up like me, then please heed my advice: all of you are under-utilizing the medical services that you have already paid for. You should research what kind of screening and preventive care is included in the health care plan that you purchased and then take full advantage of them. It's better for you since you live longer. It's better for your insurance company since screening and preventive care is much cheaper than paying for treatments down the road. It's better for your government since they get to collect more tax dollars over your longer lifespan. And it's better for me since I make a living using the software and services that you guys provide.

I can stick around and do a AMA if you guys have any questions for me.

<comment><USER6> Did you ever figure out why you got HepC? Did you conclude that you had it from birth, or did you remember that you stepped on a nail while traveling in Vietnam?

<comment><USER5> Yes, I got it from a blood transfusion when I was a child. The Hepatitis C virus wasn't identified until 1989, and blood bank wasn't wide spread until early 1990s, so anyone who received a blood transfusion before then is at risk.

<comment><USER7> For those reading, you're not going to believe this but ...

From the 70's to the 80's the medical community thought it was a good idea to mix blood from hundreds of donors and then use in transfusions.

That ended up killing nearly all of the hemophiliacs of that era, plus a good percentage of moms giving birth. Add in Hep C, and hospitals were basically butcher shops.

I followed the AIDS and hemophilia crisis in the press in real-time from the first one-column-inch Kapsoi Sarcoma stories. Boy, it wasn't pretty how the medical community reacted in slow motion.

There's an utterly horrifying Canadian movie about this.

<comment><USER8> Blood products are still pooled. They often have to be since one single donation doesn't give enough blood product for a single patient.

</comment></comment></comment></comment></comment><comment><USER9> Here's the crux point...

""" ...clinicians are now able to successfully cure at least 95% of patients with the chronic condition with oral medications that have little or no side effects.

"With such an effective means for cure, it only makes sense to universally screen patients," Cheung said. "Implementation of universal screening will also decrease the likelihood of primary care physicians forgetting who does or does not need screening -- and it avoids the sometimes uncomfortable discussion with the patient about why they have been labeled as high risk and needing further screening." """

I think the fact that high risk populations rock the medical boat so globally already makes medicine awkward regardless of avoiding uncomfortable discussions. All these blanket treatments and tests just paper over the fact that there are wide impacting subpopulations with poor health in our populous driving the need for these things in the first place. It's the next immediate question that gets raised when you evaluate 'why do I need another HIV test' or whatever other blood test it is that medicine pushes on you. Eventually it dawned on me that these blind blanket decisions are simply because these doctors don't know anything about a patient's personal life and what risky subpopulations they may or may not belong to. But from the patient who knows what virtue they live or don't live some of these tests just come off as absurd knowing your own life history and the absolute absence of risks you deliberately avoid in life. One step of indirection is not much to jump over for one who naturally asks the next immediate question.

<comment><USER10> This seems related to the political question of how much healthcare costs should be socialized, i.e. spread across a group rather than shouldered by individuals.

As someone who doesn't smoke, barely drinks alcohol, doesn't take illegal drugs, and (I hope) is in a lifelong-monogamous relationship, I hate having to cover healthcare costs specific to those problems.

On the other hand, as someone with chronic mild obesity, I'm grateful for government-funded research for treatments of hypertension, stroke, idiopathic cancer, etc. And to some extent I could, if motivated enough, keep my bodyweight down.

I guess there are two issues then. The politics of shared costs/benefits, and attending my personal struggles with only being empathetic to problems that I myself experience.

<comment><USER11> "This seems related to the political question of how much healthcare costs should be socialized, i.e. spread across a group rather than shouldered by individuals"

It's a moral question, not a political one. Food for thought: "Rough sleeper gives birth to twins outside wealthiest Cambridge college" \- [https://www.theguardian.com/society/2019/dec/26/rough- sleepe...](https://www.theguardian.com/society/2019/dec/26/rough-sleeper- gives-birth-to-twins-outside-cambridge-university)

<comment><USER12> But that story isn't about costs of healthcare - the NHS will treat her for free precisely because the costs are socialised. The social care system will also ramp up rapidly given she's a vulnerable new mother who has now been admitted to the local maternity hospital.

</comment></comment></comment></comment><comment><USER13> _Antiviral drugs for hepatitis C are very effective, but they come at a steep cost. Just one Sovaldi pill costs $1,000. A full 12-week course of treatment with this drug costs $84,000.

The price of other hepatitis C drugs is also high:

Harvoni costs $94,500 for a 12-week treatment Mavyret costs $39,600 for a 12-week treatment Zepatier costs $54,600 for a 12-week treatment Technivie costs $76,653 for a 12-week treatment_

[https://www.healthline.com/health/hepatitis-c/treatment- cost...](https://www.healthline.com/health/hepatitis-c/treatment-costs#2)

<comment><USER14> That is so depressing to read.

US pharma companies are completely out of control, there's absolutely no reason a 12 week treatment should cost around the mean annual US income. Can't imagine having to decide to risk my entire financial future to deal with Hep C.

<comment><USER15> What's the alternative? This gets tiresome asking because the typically argument is to say "This is crAzYyyy!!!! " without offering any real solution or input.

gilead the makers of Harvoni literally made a cure for a previously uncureable disease, You literally have no respect on a tech site of all places, for all the RnD that went into doing that.

<comment><USER16> _" gilead the makers of Harvoni literally made a cure for a previously uncureable disease"_

No, they acquired Pharmasset, the company that made the cure, for $11.2B. That was a pretty low-risk move. It was already an obvious money maker.

 _" for all the RnD that went into doing that"_

In the 18 months following Sovaldi's approval, Medicare alone spent $8.2 billion on the drugs...that doesn't include private insurance payments. I imagine the acquisition was paid off quite quickly. Pricing after that was just how much profit they wanted to make.

See these for more detail:

[https://www.finance.senate.gov/imo/media/doc/Wyden- Grassley%...](https://www.finance.senate.gov/imo/media/doc/Wyden- Grassley%20Document%20Request%20to%20Gilead%207-11-141.pdf)

[https://www.finance.senate.gov/ranking-members-news/wyden- gr...](https://www.finance.senate.gov/ranking-members-news/wyden-grassley- sovaldi-investigation-finds-revenue-driven-pricing-strategy- behind-84-000-hepatitis-drug)

<comment><USER17> > _No, they acquired Pharmasset, the company that made the cure, for $11.2B. > That was a pretty low-risk move. It was already an obvious money maker._

Before I was a software developer I was in equity research, and one of the companies that we covered was Pharmasset. The whole _point_ of these research companies is to find a winner and be acquired.

I get that it's low risk for the acquirer, but without that big payout the research and trials won't get done by the small companies, who won't be able to raise funding, etc.

<comment><USER16> I pointed it out because it brings some clarity to what the R&D actual costs are, and thus some clarity to whether gouging is happening.

<comment><USER18> Isn't this evidence in the other direction: if the drug already existed and was acquired for $11 billion, then that suggests that they expect the profit to be about $11 billion. Otherwise, wouldn't they bid up the price more?

<comment><USER16> In the 18 months following Sovaldi's approval, Medicare alone spent $8.2 billion on the drug.

I know that's revenue and not profit, but that doesn't even include private insurance, self pay, or sales outside the US.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> My dad passed away in August due to Hep C complications. Very true that anyone who has done anything that can put you at risk should be tested. The treatment is criminally expensive but it is curable with it. Sadly my dad, the a-typical medically procrastinating male, didn't start on Sovaldi until it was too late and he died before he could complete treatment.

</comment><comment><USER20> _> 70% to 90% of older injection-drug users are infected._

If you have the unique misfortune of being born to one of those older users, do get tested. I was asymptomatic when I tested positive a few years ago, at the age of 25. It was a surprise to the medical professionals involved, as I have no drug using history, no tattoos, in otherwise perfectly good health.

I did get the super expensive pills, and they cured me in eight weeks (and I'm extremely grateful my insurance at the time covered the cost).

My liver's doing OK, but who knows whether the disease contributed to my chronic depression. Still, I consider myself lucky to have caught it when I did.

</comment><comment><USER21> I get their point about stigma, but as someone who has never injected drugs, I'm having a hard time caring about getting screened for this.

How do they intend to actually roll out a massive testing operation (everyone under 80) when likely most people hear the details and respond with "meh, not me"?

<comment><USER22> From a public health perspective, recommendations and guidelines like this drive insurance company policies and government funding priorities. Or in other words, the things that actually move the needle when you're trying to get something done for an appreciable percentage of citizens.

There's no ability and need to test everyone today, but this is a sign that we should move to more regular screening of higher percentages of the population.

Honestly, I'm kind of curious from those involved in the field: What's the blocker to rolling out extremely broad, minimal-cost testing? Manual processes? Too few companies in the testing market? Requires expensive prep / reagents?

<comment><USER5> >There's no ability and need to test everyone today, but this is a sign that we should move to more regular screening of higher percentages of the population.

Signs of Hepatitis C, along with most liver diseases, can be caught with the standard liver enzyme tests that's available in pretty much every lab in the developed world.

To be specific, if you see your doctor and it's been more than 6 month since your last visit, then it's standard procedure to take a blood test. Your doctor will take out a pre-printed form that's commonly called "laboratory requisition form" or "assay requisition form", fill out the patient information and tick a few boxes. If they ticked the "ALT" box, then they have ordered the necessary liver enzyme tests. Quoting Wikipedia: "Significantly elevated levels of ALT (SGPT) often suggest the existence of other medical problems such as viral hepatitis, diabetes, congestive heart failure, liver damage, bile duct problems, infectious mononucleosis, or myopathy, so ALT is commonly used as a way of screening for liver problems."[1]

Here's a Kaiser Permanente laboratory requisition form[2] with the ALT checkbox. Here's a Quebec health provider that include ALT in their general profile test #1 through #4 [3].

Testing for Hepatitis C directly is also widely available. Since it's a public health hazard, most state and national governments in the developed world has setup free testing programs. For example, I Googled "california hep c testing" and this page[4] is the third result. They offer _free_ Hepatitis C tests with the results available in 20 minutes.

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

[2] [http://testinfo.kaiserpermanente.org/info_assets/cpp_ga/pdfs...](http://testinfo.kaiserpermanente.org/info_assets/cpp_ga/pdfs/Laboratory_Req_2016_Front.pdf)

[3] [https://www.dynacare.ca/DYN/media/DYN/Pdf/Print%20a%20Form/G...](https://www.dynacare.ca/DYN/media/DYN/Pdf/Print%20a%20Form/Generic- Dynacare-EN_V1_28NOV2018.pdf)

[4] [https://www.sfaf.org/services/sexual-health-and- testing/hiv-...](https://www.sfaf.org/services/sexual-health-and-testing/hiv- sti-testing/)

<comment><USER22> Forgive a non-bio major, but these tests can generally be segregated into cultured (pcr) / non-cultured, no? And I'm guessing as an enzyme test, this would fall into the later category?

</comment></comment></comment></comment><comment><USER23> It looks like the standard blood "Donor Battery" includes anti-HCV, so regular donors are already being screened.

Of course, you shouldn't donate blood for the purpose of getting tested for a disease.

<comment><USER24> There is a question on the blood donation form that asks if you are donating for the purposes of testing yourself.

If you answer yes, then your donation is discarded.

<comment><USER23> There's no one universal questionnaire. No such question exists at any blood center I've donated at.

If you answer any question in a way that would lead to the blood being unusable, they wouldn't go to the effort of taking a donation just to discard it. At least, my local blood center doesn't.

</comment></comment></comment><comment><USER25> WebMD ([https://www.webmd.com/hepatitis/digestive-diseases- hepatitis...](https://www.webmd.com/hepatitis/digestive-diseases-hepatitis-c)) says that 3.9 million people in the US have this disease, more than 1 in 100 of the population. And [https://hepatitisc.net/what- is/statistics/](https://hepatitisc.net/what-is/statistics/) says that worldwide abou 70 million, again roughly 1 per 100. This seems rather a lot. What is missing from the statistics I have been able to find is any breakdown by location, lifestyle, diet, etc. The only hint is that the majority of injection-drug users are infected and that poor blood screening in the past has contributed.

If this disease is so widespread it seems to me that public health measures that prevent or reduce the risk of infection must, in the long run at least, be necessary.

What measures might they be and is there anything that an individual can do to reduce their risk?

</comment><comment><USER26> The "reportable disease" qualifier must be an important distinction here. The article doesn't say how many Hep C deaths there are, but a search showed about 19,000 annually. That's a far cry from 50,000 estimated pneumonia deaths, and still just under the estimated 20,000 MRSA deaths.

</comment><comment><USER27> The article says nothing about the false positive and false negative rates of the test, and proceeds as if the screening is infallible.

Even given what was said in the article, one has to assume that the incidence of the infection in the general population is quite low—probably measured in basis points—which means that the false positive rate of the test would have to be very low to get a high positive predictive value. It may well be so, but we'd need to know that (and the costs of treating the uninfected) to understand whether universal testing is really warranted

<comment><USER28> The two key groups in western countries are baby-boomers (likely acquired the infection from dentists/doctors reusing needles), and intravenous drug users. The best bang for your buck is in testing and treating this last population, but you have to be careful and try to do followups to prevent reinfection. It's worthwhile to test the baby boomer population as many of them could require liver transplants soon if not detected

<comment><USER4>
       (likely acquired the infection from dentists / doctors reusing needles)

In _Western_ countries?!

<comment><USER29> My aunt is such a boomer. She got hvc in the military from a pneumatic vaccine injector. The DoD apparently discontinued this practice in the late 90s.

</comment></comment></comment></comment><comment><USER30> Hep C is a curable disease that doesn't have any symptoms. It also tends to infect the most vulnerable among us - heroin addicts.

So the root cause of this issue is not the disease itself but our society and health system. These victims are not receiving the testing and treatment they need because they choose not to or (more likely) can't afford to go to the doctor.

<comment><USER28> From a purely epidemic control point of view the most rational path is to test this population as often as possible (every 6 months or less) and treat them immediately if testing positive. If you find people that reinfect rather than a bad thing this means you are being able to reach a core at-risk group.

</comment></comment><comment><USER31> My mom is a physician who has treated hepc for years. But the problem these days is convincing insurance companies to pay for the treatment. Unfortunately having the disease isn't enough for them pay. :-/

</comment><comment><USER32> This is likely going to be an unpopular question and maybe I m just really naive, but is the protein really so complex to synthesize that a kit could not be made to make a small batch at home? I ask this because I have recently been studying what is required to produce non naturally occurring amino acids and while not trivial, it can be done. Are there not biohackers that figure these things out as a hobby? I know, totally unsafe, but if your only other option is death, then I think such discussions should be on the table. Derivative works so to speak.

<comment><USER5> I paid $1300 for a 12 weeks course of generic Harvoni from India. I paid using credit card and it arrived within a week. Normally I'm a law-abiding citizen, but as you said, if it comes down to choosing between violating intellectual property laws and death, it's an easy choice to make.

<comment><USER33> Considering even a 12 week vacation in India while you undergo treatment is cheaper than the alternative and also legal, the pricing of the US drugs is very... interesting.

There's probably plenty of other countries where you could get treatment for cheap too.

<comment><USER34> Hardly anyone with a regular job can just decide to take a 12 week vacation. You'd either have to convince your employer to let you take an unpaid medical leave (and you'd need to have enough savings to survive for 3 months), or you'd need to quit your job and hope to find another when you get back (not that easy for those outside the tech industry).

</comment></comment></comment></comment><comment><USER28> I worked for 5 years doing epidemic modeling for HCV, from right around when the first generation of the modern treatments became available (Sofosbuvir, etc). When I started working it was immediately clear that Sofosbuvir et al were a total game changer, and for a while my research was based on figuring out who to treat first: people very sick but that were not spreading the disease, or people with few symptoms that were actively spreading the disease

Here are a few interesting things (in my opinion) that are not so well known about HCV:

\- Prior to 2015 you could cure HCV, the standard of care was ribavirin with pegylated interferon. If you were lucky and had the right HCV genotype you would take a whole bunch of pills and injections for 48 weeks, with a 50% chance of cure. The side effects were pretty bad though, people I met that took it compared it to chemo.

\- Currently there are treatments available that will cure any HCV genotype, on people with advanced liver disease (cirrhotic), coinfected with HIV, with >95% success rate. One pill per day with basically no side effects.

\- In western countries there are a whole bunch of HCV positive baby boomers, in many cases unaware that they are infected. Epidemically they are not transmitting the disease, but they have been chronic for many years and are having liver issues

\- Again in western countries, the epidemic is being driven mostly by active intravenous drug users, typically young, and often with other co-morbidities (mental health issues, HIV, etc). Re-infection is possible, so HCV eradication will be tough

\- There is controversy as to whether you can transmit HCV sexually, at the least it is much harder than transmitting HIV. Conversely active intravenous drug users that share needles will almost certainly have HCV, with HIV being harder to transmit this way

\- In other countries the situation can be very different. Egypt in particular has around 20% HCV prevalence, the story goes that the UN funded a program to eliminate schistosomiasis in the 1980s via vaccination, but the campaign did a lot of shared needles

AMA I guess

</comment><comment><USER26> The HN headline should be changed to match the article. The current one does not encompass the content nearly as well.

</comment><comment><USER35> Why only in the US?

<comment><USER36> The recommendation was issued by the U.S. Preventive Services Task Force who is funded by the American government whose job it is to issue evidence based preventive medical recommendations for only the American population based on data relevant to the American population. The U.S. Preventive Services Task Force has neither the authority nor the funding to make Hep C testing recommendations for other countries.

Other countries may have similar issues and their medical task forces may issue similar recommendations, or Hep C might be extremely uncommon in other countries and their medical task force may make different recommendations.

</comment></comment><comment><USER37> Does anyone know what research is being done on creating the vaccine and what are the causes that prevented creating one?

<comment><USER38> Wikipedia has a brief summary, but it is a similar issue as we see with colds and HIV: a highly variable exterior shell for the virus. About six years back, scientists found one region that is mostly "conserved," the docking station that latches onto a particular receptor in liver cells.

Hepatitis C, like HIV, comes in different groups, and it has six to target.

<comment><USER37> Thanks a lot, that explains the struggle.</comment></comment></comment>


Mission to find never-contacted Amazon tribe to stop "catastrophic" jungle war - <AUTHOR> https://www.mirror.co.uk/news/world-news/mission-find-never-contacted-amazon-14106577 <comment><USER2> The dynamics of this situation are weird. Leave them uncontacted for however long out of principle, monitor them from above, commit to preserving their culture, but then intervene and try to manufacture a truce between tribes (thereby interfering with their culture) because _we_ want to keep them around.

"Hey guys, uh, you know, we were pretty happy to just let you do whatever, but we've been watching you for a while and you've started taking risks. We're not real fond of risks. Would you prefer not taking risks for us please? It would make us feel much better about letting you do whatever you like if you didn't take any risks."

<comment><USER3> The prime directive lover in me tends to agree with such logic (I am also a brazilian born/raised in the Amazon) but try to extrapolate that scenario to some extraterrestrial "overlords" telling us the same thing in a pre-nuclear winter situation. I would rather stick to their plan than risk my own ass. Of course, I know, that's a reductio ad absurdum type of argument but still...

<comment><USER2> Ironically, I wouldn't mind if aliens came down and told us we were being stupid some time soon...

We would still have to listen, however.

<comment><USER4> Would we?

If we're foolish enough to get to the point of self-destruction in the first place...

</comment></comment></comment></comment><comment><USER2> Which nation should they belong to? They likely consider themselves to be their own 'nation', and have for a long time. Simply because Brazil is now a thing, does not necessarily mean that Brazil should own these people and that these people should consider themselves to be a part of Brazil and be subject to its laws. There are arguments either way.

You assume that these people have no 'law' of their own. Though I cannot say either, it is entirely possible that distinguish between the ways a person is killed and they are punished accordingly. Simply because it is not _your_ law doesn't mean they don't have their own.

The article states these tribes are rivals. They may consider themselves at war. Soldiers are not tried for killing other soldiers (within reason) in wartime, so why should rival tribesmen be tried for killing other tribesmen when they are at war?

<comment><USER5> Well the logic is that just choosing not to be part of a country is insufficient. Otherwise separatist movements would be extremely successful.

<comment><USER6> I can draw a map and say this is my country. But, if I don't ever mention it to the people living there then de facto that land is not part of my country.

<comment><USER7> You also need to convince an army to agree with you.

</comment></comment></comment></comment><comment><USER8> If you find this story intriguing, the book "Spirit of the Rainforest: A Yanomamo Shaman's Story" is an amazing journey into a similar culture of cyclical violence between neighboring tribes.

</comment><comment><USER9> This is a horribly cynical interpretation but the new Brazilian President has said he wants to open the Amazon to logging and he doesn't care much about the indigenous people[0]

Of course if he tries anything the international community etc will protest, but if this 'rescue mission' (read: death squad with plausible deniability) can't stop the 'catastrophic jungle war' in time then the tribes kill each other off, there's no outcry and the logging begins.

[0][https://www.theguardian.com/commentisfree/2018/dec/31/tribes...](https://www.theguardian.com/commentisfree/2018/dec/31/tribes- brazil-genocide-jair-bolsonaro)

<comment><USER10> These tribes of dozens of individuals are not what prevents logging for happening. The mission will use boats and an helicopter on a long trip just to reach the place. What would be the economic viability to estabilish a commercial operation there?

The indigenous people that prevents some of the logging in some places are much larger ones with total contact with the rest of society for centuries that live in much more accessible areas

<comment><USER9> It's not without historical precedent. Look at the Congo under King Leopold for one example. Everyone is in the accessible areas, not as many in the harder to reach places that makes it extremely economically viable for them to set up shop there.

Like I said it's a cynical interpretation and I hope I'm wrong, but this is literally history repeating itself.

</comment></comment></comment><comment><USER11> Shake hands. Kill tribe with common cold.

<comment><USER12> The article states the government tries exactly to prevent this from happening since the isolated tribe is about to have contact with a non-isolate tribe:

> Anthropologists now fear that, as well as the prospect of both tribes > launching deadly attacks on each other, the potential of contact between the > Matis and the other, as yet still isolated Korubo tribe, as well as the > desire expressed by the breakaway tribe to reestablish contact with their > relatives, could lead to a breakout of disease which could bring the ancient > tribe to extinction.</comment></comment>


Scrabble Is First Paid Game App for Kindle - <AUTHOR> http://www.wired.com/gadgetlab/2010/09/scrabble-is-first-paid-gameapp-for-kindle/

<comment><USER2> If I was Amazon I'd be slinging Marco SDKs, hardware, whatever, to get a version of Instapaper running on the Kindle. Killer app.

<comment><USER3> Instapaper is pure liquid gold for the Kindle. Marco has definitely made the right choice to create a start-up based on it.

Right now I've got probably about a hundred articles on Instapaper, collected over the month or so I'm using it, but I haven't read any of them yet. My Kindle should arrive Monday and the first thing I'll do is read those articles on it.

</comment></comment><comment><USER4> For those curious, I was able to find KDK documentation:

<http://kdk-javadocs.s3.amazonaws.com/index.html>

</comment><comment><USER5> Does anyone know what CPU/clock speed the kindle 3 has? Can't seem to find it with google. Thanks!

I'm interested in the possibility of programming on the unit itself. The low- power consumption makes you less dependent on mains power.

 _EDIT_ according to <http://www.mobileread.com/forums/showthread.php?t=95968>, it's an iMX35 (ARM11-based) [http://www.freescale.com/webapp/sps/site/overview.jsp?code=I...](http://www.freescale.com/webapp/sps/site/overview.jsp?code=IMX35_FAMILY) (probably iMX353 or iMX357: max speed... 532 MHz)

<comment><USER6> Yes, it's an iMX35, you can see a teardown of the WiFi+3G version here: [http://www.eevblog.com/2010/09/03/eevblog-109-amazon- kindle-...](http://www.eevblog.com/2010/09/03/eevblog-109-amazon- kindle-3-3ggsmwifi-6-teardown/)

</comment></comment><comment><USER7> It bothers me a little bit that they are not opening the KDK for all people at the same time. Nevertheless, I expect to experiment with Kindle apps in the future (if they ever let normal guys into the developer program).

<comment><USER8> I guess I can understand that they want to test the waters with a brand name app, but now that they've actually published something the continued stinginess with the sdk is off-putting. Maybe one consolation is that, by the time they open it up to regular folk, there might be much better Kindles to play with.

</comment></comment><comment><USER6> "Major drawback: Unlike Facebook's or other online iterations of the Scrabble game, there is no social dimension. You can't play with another Kindle user online; the best you can do is set up a two-player game where you pass the Kindle back and forth."

This seems to me a major step-back. Someone knows if is this a choice made by Electronic Arts or is something imposed by Amazon?

</comment><comment><USER9> It seems to be currently unavailable at <http://www.amazon.com/dp/B003P2QCE8/>

Not seeing in my Kindle 3's store search either.

</comment><comment><USER8> Was anyone here let into the developer's beta program?

<comment><USER10> Would really like to apply, but I want to build a reading application (expressly forbidden by their SDK agreement), because I've yet to see _anything_ efficiently use E-ink displays, and their UIs are uniformly nasty. To the point where I've wondered if they're doing it _deliberately_ , because it could mean relative-death to second-hand book sales.</comment></comment>


Home office desk of a YouTube gamer - <AUTHOR> http://deskhunt.com/liam-biggs <comment><USER2> I'd like to see more desk setups from people here!</comment>


Sublime Text 2 Web Inspector - <AUTHOR> http://sokolovstas.github.com/SublimeWebInspector/

<comment><USER2> That looks very interesting, but typing several lines of text rather than speaking them is painful to sit through. I would suggest turning off the music next time and just tell people what it is and how it works.

<comment><USER3> Or skip the screencast altogether and just write step-by-step instructions.

<comment><USER4> At least mention what the default hotkeys are, and what will/should happen when you hit them. On Linux, after hitting CTRL+SHIFT+R, I just get the option to launch Chrome. I come back and hit CTRL+SHIFT+R again, and it's the same option.

<comment><USER5> I am having the same issue, have you figured out how to solve it?

<comment><USER3> Have you tried shutting down chrome before launching it from this plugin?

</comment></comment></comment></comment></comment><comment><USER6> Not to take away from the package, but I'm somewhat surprised that someone who invested significant work into this is running an unregistered version of ST.

<comment><USER7> why are you surprised by this? we don't all have $70 lying around

<comment><USER8> $70 isn't a lot of money. Is it an hour of your time? Maybe two? If people don't want to pay that's fine, use one of the great open source editors. Saying you don't have the money doesn't make it ok to violate the license. rms works hard to give you emacs for free. The Sublime guys are trying to earn a living.

<comment><USER9> 70 US Dollar equals 643.45 South African Rand.

To put that in perspective: R650 is a basic grocery shop for my small family for a week.

I have a day job, a baby under a year old, another kid reaching teenagerdom and a bootstrapped startup. My wife works part time.

I wish more startups and even more mature companies would build in some sort of currency sensitive sliding scale for their pricing models. I know what a ball ache pricing is and how much time we tend to spend on it already but I'd love to be able to support and often times the reality is that I simply cannot afford to... Because of the exchange rate.

I take issue with your suggestion that people like myself piss off and use OSS though and I take issue with it for one simple reason: I personally use the 'nag screen version' of Sublime. I'm crazy about the product and when I have a row of developers working on a product that's paying the bills then rest assured - I'll be buying those licenses. In the mean time people see me using it, I evangelize the app fairly regularly, etc.

I know the Sublime guys are trying to earn a living, we all are, and I think that having more users of any kind will ultimately lead to more users of the paying kind.

<comment><USER10> People will always justify this sort of thing - hopefully your startup won't be abused in a similar manner.

<comment><USER11> Justify what sort of thing? Using the nag version, which is his full and total right? And being from a place of relative poorness, where the asking price is equivalent to $400 dollars?

Where exactly did you bought your moral high-standing? Was it cheap?

</comment></comment></comment></comment></comment></comment><comment><USER12> I just recently found that if you put

      debugger;

in JS, it will trigger a breakpoint. Very handy

</comment><comment><USER13> This is pretty damn cool, but I can't help but notice that the UI seems to be severely limited by Sublime's API.

<comment><USER14> This is why I tried creating my own simple "text editor" within my experimenta live IDE, so that I would not be limited by anyone's API or closed source and could create something more unusual.

Is it a better approach? It's really hard to say, and definitely not obvious. I had to re-create a lot of existing functionality just so that I could more easily modify it. And clearly I cannot compete with the advanced functionality of a dedicated modern text editor.

So far it hasn't led to me anything beyond what one could've probably achieved by hooking things up to an existing API, as demonstrated by this project (perhaps aside from live editing on a type-a-character level rather than on- save level), but I'm keeping my eyes open. Perhaps I'll get lucky and come up with something that wouldn't have been possible otherwise. That was my motivation.

<comment><USER15> Have you thought of building on top of a library like CodeMirror (which Light Table is built on)?'

edit: ST2 -> Light Table

<comment><USER16> Where on earth did you read that ST2 is build on CodeMirror?

<comment><USER15> My mistake, I meant Light Table.

</comment></comment></comment></comment></comment><comment><USER17> It looks like a great start. I don't think it will yet pull me away from a dual monitor with ST2 + Chrome Inspector + Live Reload, but if it is further polished I think it could.

<comment><USER18> Live Reload appears to be OSX only, and this looks much more simple to setup than Guard-livereload.

<comment><USER17> There are many different incarnations of "live reload"; it is definitely not OSX only. The concept is simple - refresh the front-end / back-end when and edit or save occurs.

</comment></comment></comment><comment><USER19> Just the other day, I spent a good couple hours looking for good Linux web development tools. Something that mocked Brackets - this is exactly that. Only thing missing is a quick edit CSS feature, that would drop down the styling for a selected tag.

</comment><comment><USER20> This is incredible. I was particularly happy when I noticed Chrome filepaths for Mac, Linux, and _Windows_ \- some of the more powerful Sublime plugins (looking at you, LiveReload and that really powerful Markdown plugin) were developed by Mac guys who didn't bother porting them to Windows.

Not that I'm angry at the aforementioned Mac guys (it's not like they're getting paid to make me free stuff) but it's nice to see someone go the extra mile.

<comment><USER18> The linux path is the same as the Mac one, which is pretty lol. It's /usr/bin/google-chrome on most systems I think.

</comment></comment><comment><USER21> Looks like a very cool tool. Live reload alone should speed up development quite a bit, or at least remove some of the annoying wait between changing code and seeing the result.

Unrelated: Ah, Sublime Linter, you are always making ST unresponsible. Clicking away the message has almost become part of my workflow. I should probably just disable the warning, though.

</comment><comment><USER22> The good stuff starts around 3:20.

<comment><USER23> Thanks, came here looking for this.

I know some people are camera shy on the web, but it would be nice if the video was zoomed to the mouse or cursor just so we could actually make out what was going on.

</comment></comment><comment><USER24> I hope this also works for Chrome Remote debugging

[https://developers.google.com/chrome-developer- tools/docs/re...](https://developers.google.com/chrome-developer- tools/docs/remote-debugging)

</comment><comment><USER25> I think this is brilliant. This could change the way I work. Great work, thanks!

</comment><comment><USER26> This looks rather nifty, anyone know if there's anything comparable for Emacs?

<comment><USER27> Kite, though it's not ready for production yet:

<https://github.com/jscheid/kite>

</comment></comment><comment><USER28> I've been wanting such a feature for many years. SB2 is turning out into next big editor. I wonder when will they put command line navigation like ViM and Emacs into it.

</comment><comment><USER29> Sublime Text 2 has been really slow for me on Ubuntu for a few months. I haven't been able to fix it or even google anything about it. So sad.

</comment><comment><USER30> I was hoping for ST3 support, but since the author is running ST2 Unregistered, that's not going to happen soon. Oh well.

<comment><USER31> Yap :) just donate me some bucks for my work. I will buy ST3 when it will be released.

</comment></comment><comment><USER32> This is pretty nice, but the live reload package and existing browser debugging tools appear to still be more productive.

</comment><comment><USER33> I'm totally fine with debugging on browser, with live edits, I don't see a need for sublime text inspector.

<comment><USER34> agreed</comment></comment>


Braid Particle System Revision (part 1) - <AUTHOR> http://number-none.com/blow/blog/programming/2016/07/07/braid_particles_1.html <comment><USER2> Jonathan Blow always has interesting things to say. I love watching his YouTube channel about his programming language too</comment>


Twitter is down - <AUTHOR> https://twitter.com/ <comment><USER2> I miss the failwhale, this silly robot is just... silly [https://abs.twimg.com/errors/robot.png](https://abs.twimg.com/errors/robot.png)

</comment><comment><USER3> Perhaps related: Slack seems down, too [https://news.ycombinator.com/item?id=10911980](https://news.ycombinator.com/item?id=10911980)

</comment><comment><USER4> Nothing as yet on [http://status.twitter.com/](http://status.twitter.com/) but its also down for me.

</comment><comment><AUTHOR> API was not affected, so apps were still working (although tweetdeck was also unreachable).

It seems to be back up again.

</comment><comment><USER5> Wouldn't surprise me if AMSIX is having issues</comment>


How Python does Unicode - <AUTHOR> http://www.b-list.org/weblog/2017/sep/05/how-python-does-unicode/ <comment><USER3> UCS-4 is essentially never the right choice. It wastes space and thus messes up your cache. UCS-2 can be the right choice if the language you're encoding uses a lot of non-Latin glyphs (i.e. East Asian languages) but suffers from the same problem as UCS-2. UTF-8 is a good default: for most strings it's very compact, and for strings with a lot of multibyte codepoints it doesn't compare too unfavorably with UTF-16.

Python 3 tried to have its cake and eat it too by choosing the most compact encoding depending on the string, but in practice this wastes a lot of space. You'll double (or heaven forbid __quadruple __) your string size because of a single codepoint, and these codepoints are almost always a small percentage of the string. That 's actually why UTF-16 and UTF-8 exist.

It would have been better for strings to default to UTF-8, and to add an optional encoding so the programmer can specify what kind of encoding to use. As it is now, in order to use (for example) UTF-16 strings in Python you have to keep them around as bytes, decode them to a string, perform string operations, and reencode them to bytes again. Any benefit you get from using UTF-16 vanishes the moment you need to operate on it like a string, in other words.

I get that the idea was to maintain indexing via codepoint, but (again) in practice that's not great: usually you want to index via grapheme -- if you want to index at all.

A better solution is to allow programmers to specify string encoding and default it to UTF-8. From that, there's a clear path to everything you'd want to do.

<comment><USER4> > I get that the idea was to maintain indexing via codepoint, but (again) in > practice that's not great: usually you want to index via grapheme -- if you > want to index at all.

I definitely need indexes, and I don't really care about graphemes. I actually have only a vague idea what that is.

I write parsers typically by using a global string and lots of indices. The important thing for me is to be able to extract characters and slices at given positions, and to be able to say "parse error at line X character Y" where X and Y are helpful to the user most of the time.

I would be absolutely fine with working in UTF-8 bytes only (and that would be faster I guess), but there would be a more pressing need to recompute character positions (as a code point or grapheme index) from byte offsets at times.

There are more abstract parsing methods where parser subroutines are implemented in a position agnostic way, but I'm very happy with my simple method.

If everything works on graphemes instead of code points (as I think does Perl6) I will be happy to use that, but it's not so important from a practical standpoint.

<comment><USER5> > I definitely need indexes

No you don't. You need iterators, which behave like pointers. Let's say you're hundreds or thousands of characters into a string at the start of some token. Now you want to scan from that position to the end of the token.

With indexes it works fast only if it's by codepoint. in a language that properly supports graphemes this would mean it would have to scan from the beginning to get to that index.

With iterators it can start scanning from that position directly. Same speed no matter where you are in the string. With indexes the larger your input the slower your parse gets, and not in a linear way.

It's also super easy to get a slice using a start and end iterator. As for line x character y messages, you can't get that directly from an index as it depends on how many new lines you parsed so indexing doesn't help there.

<comment><USER4> Well, I could roll my own iterator which encapsulates a string and some position information, but then I'd have to wrap a lot of different operations, like advance, advance by n, compare two iterators by position, test for end position, extract character, extract slice, etc.

And the code would get a lot noiser, while the only advantage I see is graphemes support, which I have never needed so far. (And I hope graphemes are actually designed with a similar sensibility for technical concerns as is UTF-8, where I can simply parse with indexes at the byte level, looking only for ASCII characters, without headaches and with maximum performance.)

As for getting line/character from a byte or codepoint offset, that's no problem if I do the calculation only in case of an error. The alternative would be to do it on each advance, which again means ADT wrapping, thus line noise and slower performance.

<comment><USER5> I'm not advocating that the programmer needs to implement the iterators but that the language/runtime have built in support for them.

As for searching for ASCII, which is prevalent in parsing, the iterator function to find the next specified character can do a low level and fast byte search. That's one of the benefits of UTF-8, searching for ASCII characters is super fast.

You wouldn't have to do the character position on each advance. Just have a beginning of line iterator that's updated every time you see a newline character and on error you do call a function that gives you how many characters between the current position iterator and the start of line iterator.

Working with iterators is no more coplex than working with indexes. But it's the language that needs to provide them.

</comment></comment></comment></comment></comment><comment><USER6> My favorite story about Python's handling of Unicode was when one of my coworkers did a hotfix for our Python website, wrote tests, confirmed everything worked as expected... but right before committing and pushing to production wrote a comment like:

# Apparently we expect the field to be in this format ¯\\_(ツ)_/¯

Right above the code he'd just fixed.

Of course, the moment we pushed the update it brought production down, because the Python interpreter doesn't understand Unicode in source files unless you specify which encoding you are using.

After that, "¯\\_(ツ)_/¯" became a synonym for his name on our HipChat server, heh.

<comment><USER7> This would be the case in Python 2, where source code files are assumed to be ASCII-encoded unless there's an encoding comment at the top of the file.

In Python 3, source code files are assumed to be UTF-8.

<comment><USER8> Interesting that Python 2 couldn't fix that in a hotfix/point release... UTF-8 is backwards compatible with ASCII so it shouldn't break anything if source started being interpreted as UTF8. I'd be curious to see what their reasoning is.

<comment><USER6> I would imagine Python's approach to introducing new language features had a lot to do with it. Having to go through the PEP system takes some time, and changes like these tend to be reserved for minor-version releases. All in all, I love the PEP system, it's such an open concept and I've been surprised by the amount of quality proposals that get implemented. Wish Go had something like it.

</comment></comment></comment></comment><comment><USER9> This was a pretty gutsy move on Python's part. The presence of a single emoji in an English string will blow up memory usage for the whole string by 4x. And because graphemes aren't 1:1 to code points, the O(1) indexing and length operations you bought with that trade-off will _still_ confuse people who don't understand Unicode.

<comment><USER7> As I said in the article, I think the overhead of adding yet more weirdness in the form of quirks of the internal encoding (which could vary according to how the Python interpreter was compiled!) is a bad thing to do on top of how much people seem to struggle mentally just to get Unicode all on its own.

Though I also think the struggle is mostly due to people being stuck in an everything-is-like-ASCII mindset, and though I didn't get into that, it's one big reason why I think UTF-8 is generally the _wrong_ way to expose Unicode to a programmer, since it lets them think they can keep that cherished "one byte == one character" assumption right up until something breaks at 2AM on a weekend.

Personally I'd like everyone to just actually learn at least the things about Unicode that I went into here (such as why "one code point == one character" is a wrong assumption), and I think that'd alleviate a lot of the pain. I also avoided talking much about normalization, because too many people hear about it and decide they can just normalize to NFKC and go back to assuming code point/character equivalence post-normalization.

<comment><USER10> > it's one big reason why I think UTF-8 is generally the wrong way to expose > Unicode to a programmer, since it lets them think they can keep that > cherished "one byte == one character" assumption right up until something > breaks at 2AM on a weekend.

Unfortunately, as long as you believe that you can index into a Unicode string, your code is going to break. The only question is how soon.

I actually like UTF-8 because it will break _very_ quickly, and force the programmer to do the right thing. The first time you hit é or € or an emoji, you'll have a multibyte character, and you'll need to deal with it.

All the other options will _also_ break, but later on:

\- If you use UTF-16, then é and € will work, but emoji will still result in surrogate pairs.

\- If you use a 4-byte representation, then you'll be able to treat most emoji as single characters. But then somebody will build é from two separate code points as "e + U+0301 COMBINING ACUTE ACCENT", or you'll run into a flag or skin color emoji, and once again, you're back at square zero.

You _can 't_ really index Unicode characters like ASCII strings. Written language is just too weird for that. But if you use UTF-8 (with a good API), then you'll be forced to accept that "str[3]" is hopeless very quickly. It helps a lot if your language has separate types for "byte" and "Unicode codepoint", however, so you can't accidentally treat a single byte as a character.

<comment><USER11> I get the variable byte encodings. And I know that Unicode has things like U+0301 as you say, and so code points are not the same as characters/glyphs. But I don't understand why it was designed that way. Why is Unicode not simply an enumeration of characters.

<comment><USER5> One reason is because it would take a lot more code points to describe all the possible combinations.

Take the country flag emoji. They're actually two seperate code points. The 26 code points used are just special country code letters A to Z. The pair of letters is the country code and shows up as a flag. So just 26 codes to make all the flags in the world. Plus new ones can be added easily without having to add more code points.

Another example is the new skin tone emoji. The new codes are just the colour and are put in front of the existing emoji codes. Existing software just shows the normal coloured emoji but you may see a square box or question mark symbol in front of it.

<comment><USER12> > _The pair of letters is the country code and shows up as a flag. So just 26 > codes to make all the flags in the world. Plus new ones can be added easily > without having to add more code points. Another example is the new skin tone > emoji._

Still not answering the question though.

For one, when the unicode standard was originally designed it didn't have emoji in it.

Second, if it was limitations to the arbitrary addition of thousands of BS symbols like emoji that necessitate such a design, we could rather do without emojis in unicode at all (or klingon or whatever).

So, the question is rather: why not a design that doesn't need "normalization" and runes, code points, and all that...

Using less memory (like utf-8 allows) I guess is a valid concern.

<comment><USER5> It didn't have emoji but it did have other combining characters. While some langages it's feasable to normalize them to single code points but other langagues it would not be.

Plus the fact that some visible characters are made up of many graphemes the number of single code points would be huge.

As to your second point it seems to me to be a little close minded. The whole point of a universal character set was that languages can be added to it whether they be textual, symbolic or pictographic.

<comment><USER12> > _As to your second point it seems to me to be a little close minded. The > whole point of a universal character set was that languages can be added to > it whether they be textual, symbolic or pictographic._

Representing all languages is ok as a goal -- adding klingon and BS emojis not so much (from a sanity perspective, if adding them meddled with having a logical and simple representation of characters).

So, it comes to "the fact that some visible characters are made up of many graphemes the number of single code points would be huge" and "while some languages it's feasable to normalize them to single code points but other langagues it would not be".

Wouldn't 32 bits be enough for all possible valid combinations? I see e.g. that: "The largest corpus of modern Chinese words is as listed in the Chinese Hanyucidian (汉语辞典), with 370,000 words derived from 23,000 characters".

And how many combinations are there of stuff like Hangul? I see that's 11,172. Accents in languages like Russian, Hungarian, Greek should be even easier.

Now, having each accented character as a separate might take some lookup tables -- but we already require tons of complicated lookup tables for string manipulation in UTF-8 implementations IIRC.

<comment><USER5> You might be correct and 32 bits could have been enough but Unicode has restricted code points to 21 bits. Why? Because of stupid UTF-16 and surrogate pairs.

I'm curious why you think that UTF-8 requires complicated lookup tables.

<comment><USER12> > _I 'm curious why you think that UTF-8 requires complicated lookup tables._

Because in the end it's still a Unicode encoding, and still has to deal with BS like "equivalence", right?

Which is not mechanically encoded in the err, encoding (e.g. all characters with the same bit pattern there are equivalent) but needs external tables for that.

<comment><USER5> But that's the same for UTF-16 and UTF-32. That's why I was wondering why you singled UTF-8 out, implying it needed extra handling.

<comment><USER12> Nah, didn't single it out, I asked why we don't have a 32-bit fixed-size code points, non-surrogate-pair-bs etc encoding.

And I added that while this might need some lookup tables, we already have those in UTF-8 too anyway (a non fixed width encoding).

So the reason I didn't mention UTF-16 and UTF-32 is because those are already fixed-size to begin with (and increasingly less used nowadays except in platforms stuck with them for legacy reasons) -- so the "competitor" encoding would be UTF-8, not them.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> Python took the obvious approach - they already had UTF-16 and UTF-32 builds, so this was just making that mechanism dynamic.

Go and Rust expose UTF-8 at the byte level. This is something of a headache and may result in invalid string slices. It basically punts the problem back to the user.

Here's an alternative: Use UTF-8 as the internal representation, but don't expose it to the user.

If you're iterating over a string one rune or one grapheme at a time, the UTF-8 substructure is hidden from the user. Only if the user uses an explicit numeric subscript do you need to know a rune's position in string. When a request by subscript comes in, scan the string and build an index of rune subscript->byte position. This is expensive, but no worse than UTF-32 in space usage or expansion to UTF-32 in time.

Optimizations:

\- Requests for s[0] to s[N], and s[-1] to s[-N], for small N, should be handled by working forwards or backwards through the UTF-8. (Yes, you can back up by rune in UTF-8. That's one of the neat features of the representation.)

\- Lookup functions such as "index" should return an opaque type which represents the position into that string. If such an object is used as a subscript, there's no need to build the index by rune. If you coerce this opaque type into an integer, the index table has to be built. Adding or subtracting small integers from this opaque type should be supported by working backwards or forwards in the string.

\- Regular expression processing has to be UTF-8 aware. It shouldn't need an index by rune.

This would maintain Python's existing semantics while reducing memory consumption.

Some performance measurement tool that finds all the places where an index by rune has to be built is useful. It's rare that you really need this, but sometimes you do.

<comment><USER14> > Go and Rust expose UTF-8 at the byte level. This is something of a headache > and may result in invalid string slices. It basically punts the problem back > to the user.

In Go, yes. In Rust, no. UTF-8 in Go is garbage in, garbage out. Rust, however, won't let you materialize an invalid &str without "unsafe".

<comment><USER15> > Go and Rust expose UTF-8 at the byte level.

Or you can take the C++/C approach and have a character 1 byte, 2 bytes, or a multi-byte. It's a pain in the ass to constantly in C/C++ having to interface between two libraries that one decided to use char and another w_char!

<comment><USER14> The way the C and C++ committees approach Unicode is even worse than Python breaking away from UTF-16 in the wrong direction (UTF-32 being the wrong direction and UTF-8 being the right direction).

The first rule of reasonably happy C and C++ Unicode programming is not to use wchar_t for any purpose other than immediate interaction with the Win32 API.

The second rule of reasonably happy C and C++ Unicode programming is not to use the standard library facilities (which depend on the execution environment) for text processing but using some other library where the UTF-* interpretation of inputs and outputs doesn't shift depending on the execution environment or compilation environment.

<comment><USER15> This is where we run into a little bit of a problem. You have a char pointer that can be either a multiple byte encoded (depending on the code page window is using). It also can be UTF-8 encoded. Then when you move onto windows wchar_t that is originally defined as (UCS-2) then was later renamed to UTF-16, due to surrogate pair's.

So in the windows world with COM/DCOM you're basically nugged into using UTF-16 wchar_t or it becomes a hell of a lot of pain. So it is easier just simply to accept to use UTF-16 and do all the conversion from UTF-8, UTF-32, code pages to a single encoding standard.

<comment><USER16> You could just wrap that pointer in a class that describes what it is - ideally at the type level (Utf8String, etc). Each string class knows how to convert from other string types, and any library calls get wrapped in a method that is either templated on the string input type(s) or takes a BaseString* and calls virtual conversion functions. Or force a manual call to convert each time so that your fellow developers know when slow conversions are happening for sure.

It is a crappy situation though. Pick where you want your pain point to be.

</comment></comment></comment></comment></comment></comment><comment><USER5> I'm not a fan of how Python 3 stores Unicode strings internally. In my opinion they should have went with UTF-8. The extra scanning and conversion puts more preassure on the processor and caches under load.

I agree that Python 2's Unicode handling is broken. That's why I just stored UTF-8 in a normal string and avoided the whole mess. The only thing I have to do is validate any input from the outside world is really UTF-8.

<comment><USER7> Since the high-level API is supposed to let you treat a string as a sequence of code points, a correct implementation (which Python didn't have until 3.3!) would've imposed the overhead of conversion to something resembling a fixed- width encoding whenever a programmer invoked certain operations.

And the vast majority of strings in real-world Python contain only code points also present in latin-1, which means they can be stored in one byte per code point with this approach. And for strings which can't be stored in one byte per code point, you were similarly going to pay the price sooner or later.

<comment><USER5> > Since the high-level API is supposed to let you treat a string as a sequence > of code points,

I disagree with that premise. It should operate on grapheme clusters. Operating on code points falls into the same trap as operating on bytes.

> a correct implementation (which Python didn't have until 3.3!) would've > imposed the overhead of conversion to something resembling a fixed-width > encoding whenever a programmer invoked certain operations.

Those operations should have been removed. Indexing is the big one that needs fixed width internal representation for speed. Code could have been rewritten to not require indexing. But mechanical translation from Python 2 to 3 was a goal and because of that they couldn't radically change the unicode API for the better.

> And the vast majority of strings in real-world Python contain only code > points also present in latin-1, which means they can be stored in one byte > per code point with this approach. And for strings which can't be stored in > one byte per code point, you were similarly going to pay the price sooner or > later.

You're going to pay the price for 4 byte per codepoint strings quite often. A single emoji will blow up a latin-1 string to 4 times the size.

</comment></comment></comment><comment><USER17> [http://bit.ly/unipain](http://bit.ly/unipain) is my go-to reference whenever i get tripped up on what's going on with unicode in python.

it is significantly more sane in python 3.3+.

</comment><comment> mark-r I've always been curious on how this change in 3.3 impacts the C/C++ interface. I don't really know where to look it up, and since I haven't yet had to code a C++ library for Python I've had no burning need to answer the question.

<comment><USER7> The Python C API grew some new functions and constants which are aware of what's going on and can tell you what encoding a particular Unicode object is using, read from/write to it, etc. The pre-3.3 APIs have a lot of deprecations in favor of the new API. If you want to use new API on a Unicode string created via old API, you have to use the new PyUnicode_READY() on it first.

</comment></comment><comment><USER18> Question: if you read a file is there an algorithm that will make sure it is parsing the right encoding?

<comment><USER19> Not reliably, no. You can detect if it's an _invalid_ string according to the encoding you're currently using (value > 127 for ASCII, invalid surrogate pair for UTF-16) but there are lots of byte sequences that produce valid (but semantically meaningless) output in multiple encodings. To choose between them programmatically requires your algorithm to _understand_ the meaning of the string as well as be able to decode it, which might be possible in limited domains, but is a very hard problem in general.

</comment></comment><comment><USER20> If this was phrased as a question it would be a trick one.

<comment><USER21> "How Python does Unicode: Poorly."

<comment><USER22> Python 2 maybe. Python 3 does Unicode wonderfully well; I miss it whenever I'm working with other languages.

<comment><USER5> All Python 3 did was put a hard barrier between bytes and strings. That's it.

Mising is all the grapheme handling that languages that do Unicode strings right have.

</comment></comment></comment></comment><comment><USER23> Unicode is a horrible scam, the worst thing to happen to digital language representation. This is all just so much _turd polishing_.

(Also, that explanation of UTF-8 is crap. UTF-8 is _beautiful_ quite apart from its utility, but you'd hardly know it from the article.)

I've said it before: Unicode is a conflation of a good idea and an impossible idea. The good idea is a standard mapping from numbers to little pictures. That's all ASCII was. The impossible idea is a digital code for _every way humans write_. It's a form of digital cultural imperialism.

Unicode Consortium et. al. are absurdly arrogant.

<comment><USER24> Critical rants that don't suggest a better alternative, or describe what a better alternative might look like even in outline, are rarely informative or persuasive.

<comment><USER23> Step One: Admit there's a problem.

I heard, "Tell me more about what you think would be better." Here goes:

For written languages that are well-served by a simple sequence of symbols (English, etc.) there is no problem: a catalog of the mappings from numbers to pictures is fine is all that is required. Put them in a sequence (anoint UTF-8 as the One True Encoding) and you're good-to-go.

For languages that are NOT well-served by this simple abstraction the first thing to do (assuming you have the requisite breadth and depth of linguistic knowledge) is to figure out _simple formal systems_ that _do_ abstract the languages in question. Then determine equivalence classes and standardize the formal systems.

Let the structure of the language abstraction be a "first-class" entity that has reference implementations. Instead of adding weird modifiers and other _dynamic behavior_ to the code, let them be actual simple DSLs whose output is the proper graphics.

Human languages are like a superset of what computers can represent.

Here's the Unicode Standard[1] on Arabic:

> The basic set of Arabic letters is well defined. Each letter receives only > one Unicode character value in the basic Arabic block, no matter how many > different contextual appearances it may exhibit in text. Each Arabic letter > in the Unicode Standard may be said to represent the inherent semantic > identity of the letter. A word is spelled as a sequence of these letters. > The representative glyph shown in the Unicode character chart for an Arabic > letter is usually the form of the letter when standing by itself. It is > simply used to distinguish and identify the character in the code charts and > does not restrict the glyphs used to represent it.

They baldly admit that Unicode is not good for drawing Arabic. I find the phrase "the inherent semantic identity of the letter" to be particularly rich. It's nearly mysticism.

If it is inconvenient to try to represent a language in terms of a sequence of symbols, then let's represent it as a (simple) program that renders the language correctly, which allows us to shoehorn non-linear behavior into a sequence of symbols.

If you think about it, _this is already what Unicode is doing_ with modifiers and such. If you read further in the Unicode Standard doc I quoted above you'll see that they basically _do_ create a kind of DSL for dealing with Arabic.

I'm saying: make it explicit.

Don't try to pretend that Unicode is one big standard for human languages. Admit that the "space" of writing systems is way bigger and more involved than Latin et. al. Study the problem of representing writing in a computer as a first-class issue. Publish reference implementations of code that can handle each kind of writing system _along with_ the catalog of numbered pictures.

From the Unicode Standard again:

> The Arabic script is cursive, even in its printed form. As a result, the > same letter may be written in different forms depending on how it joins with > its neighbors. Vow-els and various other marks may be written as combining > marks called tashkil, which are applied to consonantal base letters. In > normal writing, however, these marks are omitted.

Computer systems that are adapted to English are not going to work for Arabic. I'd love to use a language _simpler than PostScript_ to draw Arabic! Unicode strings are _not_ that language.

Consider the "Base-4 fractions in Telugu" [https://blog.plover.com/math/telugu.html](https://blog.plover.com/math/telugu.html)

The fact that we have a way to represent the graphics ౦౼౽౾౸౹౺౻ is _great_! But any software that wants to _use them properly_ will require some code to translate to and from numbers in the computer to Telugu sequences of those graphics.

Let that be part of "Unicode" and I'll shut up. In the meantime, I feel like it's a huge scam and a kind of cultural imperialism from us hacker types to the folks who are late to the party and for whom ASCII++ isn't going to really cut it.

To sum up: I think the thing that replaces Unicode for dealing with human languages in digital form should:

A.) Be created by linguists with help from computer folks, not by computer folks with some nagging from linguists (apologies to the linguist/computer folk who actually did the stuff.)

B.) We should clearly state the _problems_ first: What are the ways that human language are written down?

C.) Write specific DSLs for each _kind_ of writing. Publish reference implementations.

I think that's it. Are you informed? Persuaded even? Entertained at least? ;-)

[1] [http://www.unicode.org/versions/Unicode9.0.0/ch09.pdf](http://www.unicode.org/versions/Unicode9.0.0/ch09.pdf)

<comment><USER24> That's a really good explanation of your position and reasons for it, thanks you.

>They baldly admit that Unicode is not good for drawing Arabic.....I'd love to use a language simpler than PostScript to draw Arabic! Unicode strings are not that language.

Unicode isn't good for drawing anything. Unicode is not intended to, or try to encode how a text should be displayed. At all, even slightly. This is the root of my disagreement with your post. You're claiming it can't accurately render the appearance of text, but that simply isn't it's purpose. It is purely and only about encoding the graphemes. Glyphs are what fonts and display technologies like PostScript are for, not Unicode.

You could argue that it should do that, perhapse Unicode should be a vector drawing language or something, but it's hard to see how that would make it useful for text processing that does concern itself with graphemes and grapheme like units. Unless the display oriented system you want contained within it a grapheme encoding system like Unicode to facilitate that - <USER2> then why not work the other way around and use Unicode for that and build a display system on top of Unicode to address your concerns?

I think trying to have your cake and eat it with a family of distinct DSLs would be problematic. Text processing is bad enough, but how would you process the content of a string that is actually a DSL? With Unicode it's possible to write a library that can process text in any script, even ones not in the standard yet, but if text could consist of computer code in any one of thousands of different domain specific languages, how would you ever be able to write one piece of code to work with all of them and all possible future permutations? Finally if your DSL is producing display output, how does that work with fonts? What if you want to vary the appearance of the output, how do you apply that to the encoding output? It just seems that this approach produces an enormous monolithic super-complex rabbit hole with no bottom in sight.

<comment><USER23> > That's a really good explanation of your position and reasons for it, thanks > you.

Cheers, I've had time to think and some sleep. I apologize to you and the people I've offended with my cranky trollish manner.

> Unicode is not intended to, or try to encode how a text should be displayed.

This made realize "text" traditionally is exactly language that is displayed somehow. The whole concept of storing writing as digital bits is metaphysical. Barely so for e.g. English, but quite a lot for e.g. Arabic.

> [Unicode] is purely and only about encoding the graphemes.

If it's just a catalog mapping numbers to little pictures (technically to collections, or families, of glyphs, or even to non-specific heuristics for deciding if a graphical structure counts as a glyph for a grapheme [1]) then I'll shut up. But what about the modifiers and stuff?

Maybe I _am_ being unfair to Unicode. I don't want to deny or denigrate the cool and useful things it actually does do. As I said I think it's a combination of a good idea (encoding graphemes) with an impossible idea (encoding written human languages). If Unicode _isn 't_ the latter then I've been shouting at the wrong cloud!

\- - - -

Here's what I'm trying to say: Imagine a conceptual "space" with ASCII on one side and PostScript on the other. In between there's a countably infinite set of formalisms that can describe _and render_ human languages. From this point of view, the Unicode standard is a small part of that domain but it is absorbing (in my opinion) so much of the available time and attention that other potentially more-useful regions of the domain are completely neglected.

\- - - -

So, yeah, I think we should study languages and writing systems and computerize them carefully with native speakers and writers and linguistic experts in the room. And I think we would need what are in effect DSLs for each kind of writing system. (Not every language, but rather every _kind_ of way that languages are written down.)

> how would you process the content of a string that is actually a DSL

Parse it to a data-structure, the simplest that will suffice for the language's structure. Work with it using defined functions (API). This is what we do already but the fact that English could be represented as array<char> reasonably well tends to obscure it.

string_value.split()

Or better yet:

        >>> s = "What is the type of text?"
        >>> s.title()
        'What Is The Type Of Text?'

> With Unicode it's possible to write a library that can process text in any > script

That seems like it's true but I don't think it is true in practice. In your reply to mjevans elsewhere in this thread,

> You can't determine [the correct way of connecting the characters] purely > from Unicode, you have to also know the conventions used in writing Arabic > script. However Unicode is not intended to encode such conventions.

And you point out that Unicode won't help you properly support cut-and-paste for Arabic. So you can't process text using Unicode if that text is Arabic. In fact, there may not _be_ "text" in Arabic the way there is in English! There is written Arabic but not textual Arabic. In other words, Unicode may well be engaged in _creating_ the textual form of Arabic (and other languages.)

> any one of thousands of different domain specific languages

I think there would be less than a hundred distinct formalisms that together could capture the ways we have come up with to write, perhaps less than a dozen, but I wouldn't want to bet on it.

> how would you ever be able to write one piece of code to work with all of > them and all possible future permutations?

 _Maybe you can 't._

But if it's possible it will be by figuring out the _type_ of text, which means exactly to figure out the set of functions that make sense on text. At which point your code can use those functions (the API of the TextType) to abstract over text. Like the str.title() method. Does that even makes sense in Chinese or Arabic?

The comment by int_19h in this thread speaks to this point really well:

> It's not about encodings at all, actually. It's about the API that is > presented to the programmer.

> And the way you take it all into account is by refusing to accept any > defaults. So, for example, a string type should not have a "length" > operation at all. It should have "length in code points", "length in > graphemes" etc operations. And maybe, if you do decide to expose UTF-8 > (which I think is a bad idea) - "length in bytes". But every time someone > talks about the length, they should be forced to specify what they want (and > hence think about why they actually need it).

> Similarly, strings shouldn't support simple indexing - at all. They should > support operations like "nth codepoint", "nth grapheme" etc. Again, forcing > the programmer to decide every time, and to think about the implications of > those decisions.

> It wouldn't solve all problems, of course. But I bet it would reduce them > significantly, because wrong assumptions about strings are the most common > source of problems.

What you're asking for is the base type for "text" for all languages, the _ur- basestring_ , if you will. (It may not exist.)

> Finally if your DSL is producing display output, how does that work with > fonts? What if you want to vary the appearance of the output, how do you > apply that to the encoding output? It just seems that this approach produces > an enormous monolithic super-complex rabbit hole with no bottom in sight.

Well again, computerized text is a new thing under the sun, different from writing, which has been happening all over the world for thousands of years (cf. Rongorongo[2]) Separating the "text" from the written form of the text (the display) is a new and metaphysical thing to do. For languages like English we get pretty far with encoding the Alphabet and some punctuation marks and putting them in a row. We completely bunted on capitalization though, we pretend that 'a' and 'A' are two different things. Typefaces can be abstracted from the stream of encoded byte/characters and treated as metadata. If you want to include it in a digital document you immediately have to define a DSL (Rich Text Format for example) to shoehorn the metadata back into the byte stream. Complications ensue.

For some languages (e.g. Arabic) _it may not make sense to abstract the display of the text from the text_. (Again, writing is exactly _display_. It is literally (no pun intended) the act of displaying language.) You _have_ to include metadata in addition to the graphemes in order to recreate the correct display of the text, so you _have_ to have some kind of DSL for the task.

As I said above, I don't think there are more than one or two dozen truly different ways of writing. A set of DSLs (perhaps not dissimilar to the generative L-Systems that can produce myriad realistic plant-like images from a small set of operations) could presumably model those ways of writing.

Unicode was a start on computerization of written languages. I think an approach that treats each kind of writing system as a first-class object of study in its own right will give us standard models for dealing with text in each kind in digital form. We should strive for computerized writing systems that are "as simple as possible, but no simpler." And, yes, it seems to me that some of them will have to include producing display output.

[1] DuckDuckGo image search for "letter A" [https://duckduckgo.com/?q=letter+a&t=ffsb&atb=v60-2_b&iax=1&...](https://duckduckgo.com/?q=letter+a&t=ffsb&atb=v60-2_b&iax=1&ia=images)

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

\- - - -

Here's my "Cartoon History of Unicode":

        1. ASCII exists
        2. Europe does too!  Extend ASCII with the funky umlauts or whatever.
        3. Oh shit! Japan! Mojibake!
        4. I know! Let's use *sixteen* bits!  That'll solve everything.
        5. What do you mean Chinese is different from Japanese?
        6. WTF Arabic!?
        7. Boy there sure are a lot of graphemes.  Gotta collect 'em all.
        8. PIZZA SLICE
        9. POOP

At which point we reach "peak internet" and Doge appears to say "wow".</comment></comment></comment></comment></comment>


Show HN: TrueSeller – Who Is Selling on Amazon - <AUTHOR> https://www.trueseller.co/ <comment><USER2> Interesting, but would need some disclosure and explanation.

All the links are affiliate links.

In several instances although Amazon would display "by <vendor>" the website returns "Sold By: 3rd Party", and an affiliate link. ex. [B0814GF8MW]

It did show 1 out of 10 times where the vendor may have multiple names. [B0178HOTOU]

<comment><AUTHOR> Good point! We will add text to the site that we use affiliate links.

</comment></comment><comment><USER3> Does this work only for .com?</comment>


Anyone interested in meeting up in the Palo Alto area? - <AUTHOR>

<comment><USER2> Absolutely. I was also thinking of setting something up as soon as we received word on admittance. I would love to meet the YC News community. Maybe even grab a drink afterward. Talk startup. :)

</comment><comment><USER3> I was going to put out something also whenever Startup School invitations go out.

Then again, maybe they have and I'm out of luck. :)

</comment><comment><AUTHOR> FYI, I made this post aside from Startup School -- I was originally hoping to meet up with other YC News peeps in the Palo Alto area (maybe those thinking of applying for Summer Founders?).

Regardless, observing this thread's progression, I'd also love to be able to meet as many of you as possible (put faces to those comments!) whether you live around Palo Alto or will be in town during Startup School.

<comment><USER4> Arranging this over week-end would really help a lot.

<comment><AUTHOR> Well, what I mean to say is that the number of meetups is simply dependent on those interested. YC News gatherings shouldn't ultimately be restricted to Startup School weekend.

I figured that it would be great if YC News goers in the Palo Alto area get together since we're probably sitting in the same neighborhood.

Ideally, it would be awesome if YC News communities got together with peers in their immediate locales. Know what I mean?

</comment></comment></comment><comment><USER5> I'm going to be in the area the weekend of StartupSchool (March 24th). Anyone up for coffee then?

<comment><USER5> Hey guys,

I just set up a wiki to discuss getting together: http://startup_weekend.bluwiki.com/go/Startup_Weekend/Events

I was thinking we could grab coffee at 8, and then walk over to the auditorium together. Who's in?

</comment></comment><comment><AUTHOR> It would be awesome to get together with fellow YC News community folks who are around the area.

</comment><comment><USER6> Guys I missed the deadline for application. If anyone got approved but can't attend, please, I'd be very thankful to you for sharing your invite with me, I can even consider buying it! Thanks! Please drop me a few words to firstname.lastname@example.com

</comment><comment><USER4> Count me in as well. Can someone please post the location and time details? I could not see info on how to get invitation to "Palo Alto OpenCoffee Club" when I clicked that link. I get message "That venue is private".

<comment><USER7> "weekly Palo Alto OpenCoffee Club on Tuesday between 830-100 at Deuce France in the Town & Country Village close to the intersection of El Camino Real & Embarcadero."

It's open to anyone (hence opencoffee) so no need for invitation. You just turn up and enjoy. The first one in London drew 120 people during the 2 hours, completely overunning the starbucks where it took place. I hope Palo Alto will be the same.

<comment><USER4> Thanks. I assume 830-100 means 8:30 AM to 10 AM then. Wish it was over weekend,

</comment></comment></comment><comment><USER2> Startup school replies just came in. Let's go ahead and decide that meeting place in Palo Alto.

The school ends at 5:30, so we should all meet at 6 and discuss what we've learned.

</comment><comment><USER8> Are you all planning on flying out there are or you from the area? I'll try to fly out (and most definitely meet up) if I am accepted and if it's within my budget.

</comment><comment><USER7> Parhaps you could all meet at the new Palo Alto OpenCoffee club. Details at http://localglobe.blogspot.com/2007/03/palo-altos-opencoffee-club.html

<comment><USER9> This seems like a good suggestion. If I get an invite to the Startup School, I'll be there.

<comment><AUTHOR> It seems that the crowd at OpenCoffee is mostly comprised of visiting international folk.

I'm going to stop by next week and check it out.

I'll let you guys know how things go.

</comment></comment></comment><comment><USER10> How about Chicago? Anyone interested in meeting up in the Chicagoland area? Talk tech, talk startup, over joes or en grosse bier.

</comment><comment><USER11> Is anyone else from Los Angeles interested in something similar? uWink would be a pretty sweet meetup spot.

<comment><USER12> Hey bgold, the BarCamp monthly dinners are a pretty good venue for that kind of meetup. I went to one in January - it was pretty cool and I'm planning on being at the next one. Unfortunately, BarCamp LA itself is the same weekend as Startup School. But the monthly dinner is the Tuesday before:

http://barcamp.org/BarCampLosAngeles

</comment></comment><comment><USER13> Someone make a post about how it went, I may be able to join in on a later date (like April)

</comment><comment><USER14> Count me in too - as soon as I get an invitation to Startup School :)

</comment><comment><USER15> Count me in, just make sure to announce the time and place here :)

</comment><comment><USER16> Anyone in NYC interested in something similar?

<comment><USER17> yes, we should do an east coast meetup. Count me in. Say, next week some time?

</comment></comment><comment><USER18> If only I weren't in school on the East coast.

<comment><USER19> where on the east coast are you?

<comment><USER18> North Carolina. University of North Carolina at Chapel Hill to be exact. Yourself?

</comment></comment></comment><comment><USER20> Definitely - count me in.</comment>


Ask YC: Any readers from Switzerland/Geneva? - <AUTHOR>

If so, I'll organize a meetup! Just respond here or drop me a line - shafqat at newscred.com <comment><USER2> I am from switzerland, I live near Yverdon and work in Fribourg area.</comment>


Fukushima robot operator publishes tell-all diaries and videos, now offline - <AUTHOR> http://boingboing.net/2011/08/23/japan-fukushima-robot-operator-publishes-whistleblower-diaries-on-blog-which-promptly-disappears.html

<comment><USER2> I read the IEEE version this morning, which was much more detailed:

[http://spectrum.ieee.org/automaton/robotics/industrial- robot...](http://spectrum.ieee.org/automaton/robotics/industrial- robots/fukushima-robot-operator-diaries)

It also contains human-translated and edited text of the blog, as well as training videos.

The BoingBoing post has two glaring errors:

First, the author is not a whistleblower. Google defines a whistleblower as an informant who exposes wrongdoing within an organization in the hope of stopping it. It wasn't all praise, but there were no reports of ethical violations.

Second, the IEEE summaries are not the complete text of the articles. The description reads: _Below are portions excerpted from nearly 50 robot-related posts ... Some sections (marked with [...]) were omitted for clarity or space._

Edit: I've submitted the IEEE version at <http://news.ycombinator.com/item?id=2921215></comment>


How Your Screen Knows to Spin - <AUTHOR> https://www.nytimes.com/2018/08/07/technology/personaltech/screen-rotate-isnt-working.html <comment><USER2> Low hanging fruit article or what?</comment>


Staying Away from Sex and Masturbation Helped Me Become a Millionaire - <AUTHOR> https://www.vice.com/en_in/article/n7w47q/no-sex-masturbation-success-millionaire <comment><USER2> [https://en.wikipedia.org/wiki/The_Contest](https://en.wikipedia.org/wiki/The_Contest)

</comment><comment><USER3> I love yoga, despite the weirdness and science skepticism that pervades it. It truly is a liberating and empowering experience, but so is every other good workout. And none of them claim to cure diseases.

<comment><USER4> [https://www.deccanherald.com/content/238699/yoga-can-cure- ev...](https://www.deccanherald.com/content/238699/yoga-can-cure-every- disease.html)

Just pointing out that some of them claim they can cure diseases.

<comment><USER3> That's true. Yoga is most famous for it but as you pointed out not the only one.

</comment></comment></comment><comment><USER5> for those curious about the source:

this adherence to sexual continence is known as brahmacharya and is one of the five yamas in traditional yogic philosophy.</comment>


Less is exponentially more: Rob Pike on designing Go - <AUTHOR> http://commandcenter.blogspot.co.uk/2012/06/less-is-exponentially-more.html

<comment><USER2> <http://news.ycombinator.com/item?id=4158865>

<comment><AUTHOR> Cool - thanks - useful discussion I missed first time round.</comment></comment>