Skepticism about beautiful people having more daughters. - <AUTHOR> http://www.stat.columbia.edu/~cook/movabletype/archives/2007/07/how_should_unpr.html

<comment><USER2> It's great to have what effectively amounts to a rebuttal on the front page at the same time as the article it disputes.

<comment><USER3> I find it great that on HN, new links are often relevant to recently, previously discussed links. You can almost see the collective mind digesting new information and putting out new conjectures.

Still, I wonder if there would be a good system for showing two stories are related, because although I frequently check HN, I don't always keep up and some stories really need the context of the previous story.

<comment><USER4> _I wonder if there would be a good system for showing two stories are related_

I believe that is called a hyperlink, as here.

<http://news.ycombinator.com/item?id=726421>

Hyperlinks generalize to showing that three or more stories are related, and allow annotations (by accompanying text) to show the nature of the relationship. Here, I can make clear that the thread to which I post this reply links out to an article that refutes the article linked out to in the link

<http://news.ycombinator.com/item?id=726421>

I have just provided to another HN discussion thread.

Hypertext is wonderful.

<comment><USER4> All right, I see the downvotes, so let me ask a question: what other technical means do people have in mind? Today's existing technology allows any of us to show relatedness of any URL to any other URL by posting the link and accompanying that link with explanatory text. What other technology would require less human thought about how to show that two (or more) recent threads here on HN are related?

As an example, could I ask for a demonstration of relatedness between my post above and any part of the HN guidelines?

<comment><USER2> You were a bit sarcastic and cheeky, which doesn't play well, but your point is well taken so I have upvoted you a bit.

Perhaps the submission form could use a "related stories" field if you're submitting a response to a previous story or something?

<comment><USER4> _Perhaps the submission form could use a "related stories" field if you're submitting a response to a previous story or something?_

Thanks for the specific suggestion. Along those lines, on this and other forums I've often wondered how technically feasible it is to mine the database as a submission is received, so that the user submitting a new article obtains a notification like "This submission looks very much like . . . " showing links to previously submitted articles that by titles (or keywords in full text) seem to be about the same subject. That would allow the user to

a) decline to submit the new link altogether,

b) indicate which previous links are related (as you suggest)

c) merge into one or another existing thread,

or

d) perhaps some other action that doesn't immediately come to mind.

But that still requires human thought by the programmer of the forum, at least, and most likely by the submitter as well. Sorry about the snarkiness above, but that's where the snarkiness came from--technical solutions fail if users don't have the commitment to make use of them.

</comment></comment></comment></comment></comment></comment><comment><USER5> This letter:

[http://www.stat.columbia.edu/~gelman/research/published/kana...](http://www.stat.columbia.edu/~gelman/research/published/kanazawa.pdf)

effectively shows that the original paper ignored endogeneity, mis-interpreted coefficient estimates and data-mined.

</comment><comment><USER6> I think most people try a variety of things in their life, eventually hit on something that yields good returns, and then milk it for all it's worth. So that "beautiful daughters" guy has found a gold mine. Who cares about science - tell people what they want to hear, and what they can use to chat on parties, and you can make lots of money. (Not only selling books, but also getting grants and invitations to universities, no doubt).

With that thesis the author can get famous, where is his incentive to be honest about it?

I am waiting for the corresponding articles to appear in all major magazines in my country (presented as established fact, of course). It just makes for too good a story to pass on it.

<comment><USER7> _With that thesis the author can get famous, where is his incentive to be honest about it?_

Well, this article is about a scientist, or statistician, alleging that the results are "speculation". She is being polite of course and in the scientific lingo she is probably saying that he is a fraud. So that is his incentive, he can be honest and find a "true" goldmine, or gamble and either go to the top or sink to the bottom.</comment></comment>


How to read Hacker News – what mistake I made for 2 years - <AUTHOR>

I am reading Hacker News for the last 2 years. It's been a really good source of information relevant to tech and startups, which I am interested. Recently I became a member to ask a question. Not much feedback came back except from some kind advice from PG.
My next submission involved an analysis about the future of YC, which got only one feedback.
>> Who are you?
Quite a way to handle an opinion expressed.
Now I noticed one thing.  I was doing something wrong for the past 2 years. I would only read the pages that are listed in the "Hacker News" tabs.  Quite a mistake I think.  Over time I would check the  pages again and see the same posts, because they were "rated" high. I don't know who and how rates the articles (of course I read that if you want to make it to the top you call your buddies clicking your article), but it clearly does not provide a real good sense of the articles submitted.
Now I believe a lot of people provide really valuable input and I have to browse through to see what's interesting. From now on I am going to check the "New" tab just beside the bold "Hacker News".  I counted roughly 300 posts published in a day, which I can skim through in 10 min and select the postings I found relevant. <comment><USER2> The listing of new articles is what I always read. It's what I check the most. I'll skim over the top articles once a day, or so.

<comment><USER3> I'm doing this more and more too. It's easier than on a lot of larger sites such as Reddit as the signal to noise ratio is much more in our favour, and I do find interesting stories that never make it near the front page.

</comment></comment><comment><USER4> I've said something similar (ie that I think it's a mistake to spend too much time on the "home" page, basically) a couple of times or so, like here: <http://news.ycombinator.com/item?id=2047397>

<comment><AUTHOR> Maybe it would be a good thing for Hacker News to explain this little detail to new readers of the list. I had to post an article first, to really check how post ranking works.

I am not saying that some articles do not deserve to have a better chance of reading, relevant to popularity. Instead I believe it would be valuable to Hacker News to have more informed readers. Otherwise there is a big chance that the "popularity" ranking can be mishandled for a number reasons, from people trying to have a "top" posting.</comment></comment>


Text Messages - <AUTHOR> http://www.theparisreview.org/blog/2015/06/24/text-messages/

<comment><USER2> This article pointed me down the path of the "Black Knight satellite." I've never heard of this before and this is the first time I've seen a plausible description/photograph of something truly extraterrestrial. That's crazy... [https://en.wikipedia.org/wiki/Black_Knight_satellite](https://en.wikipedia.org/wiki/Black_Knight_satellite)

</comment><comment><USER3> "We've learned to fly the air like birds, we've learned to swim the seas like fish, and yet we haven't learned to walk the Earth as brothers and sisters..." - MLK

</comment><comment><USER4> These remind me of Toynbee tiles:

[https://en.wikipedia.org/wiki/Toynbee_tiles](https://en.wikipedia.org/wiki/Toynbee_tiles)</comment>


Typelevel Scala and the future of the Scala ecosystem - <AUTHOR> http://typelevel.org/blog/2014/09/02/typelevel-scala.html <comment><USER2> Background: I saw Miles' tweet on this last week but didn't follow the apparent brouhaha that followed. All I know of him was his (hilarious) talk at Scala Days in June.

As someone who uses Scala daily, I don't think this is a good thing. I fall squarely into the Typesafe side of the camp—we don't use Scalaz or Shapeless or much of anything from the Typelevel project but Akka and Play are core technologies for us. We don't have a Typesafe subscription, we just use Akka and Play, a lot.

> As I observed earlier, there are already several variants of the language in > existence and it has been clear for a long time that different sections of > the community have different interests.

I don't think the author's examples really hold water. Nobody is using the Dotty compiler commercially, Scala.js is still in its infancy and while I know large organizations have at times run on minor Scala forks (I think Twitter used to but is now on 2.10.4), I'm not sure I believe that this is a major constituency. The official Scala is _the_ Scala.

If this fork gains steam, it's going to be a huge opportunity for FUD around Scala and will hurt its adoptability, especially if existing Scala teams now have to choose sides.

That said, if the Haskell side of Scalaland wants to hang out somewhere else, that might be good too. Too many Scala questions on SO are answered (and upvoted) with obscure Scalaz solutions that make no sense to someone coming in from Ruby or Java.

I _like_ functional programming. I _like_ how monads can simplify things. But I also have to write code that someone without a lot of Scala (or Haskell) experience can maintain.

<comment><USER3> > I like functional programming. I like how monads can simplify things. But I > also have to write code that someone without a lot of Scala (or Haskell) > experience can maintain.

I agree with this, but I think a same replacement for the type lambda syntax goes a long way towards making those scalaz solutions maintainable.

</comment></comment><comment><USER4> To people worried about fragmentation, retaining binary compatibility means it really doesn't matter. Scalaz can be written in the Typelevel fork and you can use it without issue from code compiled with the standard Scala compiler.

Also, from the announcement:

"As a conservative fork, our aim is to be merge compatible from the Typesafe Scala compiler, and a key objective is to feed pull requests (many of which will resolve long standing Scala bugs or feature requests) back to the Typesafe Scala compiler."

So we aren't looking at radical changes, and hopefully these changes will get into Typesafe's compiler.

So basically it's an opt-in better Scala compiler with no effect on compatibility. What's not to like?

</comment><comment><USER5> So the elitist community component of Scala that is constantly trying to turn it into Haskell has decided they need an island of their own. Great, they can have it. Now I'll know where to go when I need monadic and monoidal libraries for serving HTTP requests using nothing but type level hacks.

In all seriousness though I don't really know what this is going to accomplish. The article mentions the academic and non-academic components of Scala and it is clear the author falls on the academic side but if that's the case then why not just go and hack on something like Haskell (or Coq), a perfectly unapologetic academic language that has tried to avoid success at all costs. If push comes to shove I'm with team Odersky.

<comment><USER6> >Now I'll know where to go when I need monadic and monoidal libraries for serving HTTP requests using nothing but type level hacks.

Monadic libraries with classes like Option, Future, and List? Used in elitist features like for comprehensions? Anyone who writes Scala on a regular basis deals with monads constantly. Why not take 15 minutes and learn how they work?

<comment><USER5> Oh no that is all a little too pedestrian for me. I've moved my sights much higher now. These days I use template haskell and applicatives to generate HTML forms: [https://github.com/yesodweb/yesod/wiki/Multi-select-field- po...](https://github.com/yesodweb/yesod/wiki/Multi-select-field-populated- from-database-%28using-esqueleto%29).

I'm all for applying theory to enrich the practice of programming but lets be reasonable here. Lists and Options existed way before anyone added monadic sugar on top of it as did mapping and filtering collections. I like category theory as much as the next guy but lets just pull back a little bit. Not everything needs to be point-free, functorial, and shapeless.

<comment><USER6> >I'm all for applying theory to enrich the practice of programming but lets be reasonable here. Lists and Options existed way before anyone added monadic sugar on top of it. I like category theory as much as the next guy but lets just pull back a little bit. Not having needs to be point-free and functorial.

I agree that Spire/Shapeless/Scalaz tend to go far beyond anything I would use in a production app, but Options/Futures/etc are barely usable without for comprehensions, which are just syntactic sugar for flatMap. I see the ability to write

      for {
        x <- f1() // returns Option[T1]
        y <- f2(x) // returns Option[T2]
        z <- f3(y, x) // returns Option[T3]
      } yield foo(x, y, z)  // for expression returns Option[T4]

as a huge part of Scala's success

<comment><USER5> Sure that's nice and so is LINQ but there are thousands of programmers using LINQ without worrying about monads. It's like I said, I really don't have any issues with applying theory to enrich the practice of programming and the new crop of languages that are more fully grounded in theory is really a breath of fresh air. The problem I have with some people that enjoy these type level hacks is that they are not in it to build things that thousands of programmers can use to make their lives easier. They're usually in it to build monuments to their own egos. Forking the language is just another instance of that hubris. They're basically saying what Odersky and friends are doing is not good enough even though Odersky and friends have poured thousands of hours into making it something that in my opinion is actually something good.

If this was something that was driven by anything other than ego then they'd look at library popularity and contribute fixes to the most used and valuable libraries. Instead, they've decided to fork the language because 3 libraries, one of which is the author's own, don't have enough syntactic sugar to express certain type level constraints. Does that sound reasonable to you?

<comment><USER7> I think it is misguided to call this an act of ego, like Miles says in the announcement Typesafe has different goals, and milestones that don't necessarily serve the whole community. There are actually tons of nice small changes that haven't been implemented for various reasons, and I see this as an incubator where people can try out experimental extensions of the language and reasonably package them together, ideally porting them (if they are good) back to scalac itself. This isn't much different than people reimplementing Python or Ruby, or adding experimental extensions to Haskell (go look at how many different Haskell compilers there are). Personally I'm always interested to see what directions people can push software in when not motivated by money, or publications.

I think it is also important to remember that these people work on stuff for free in their free time because they enjoy it. They are free to pick designs and approaches they like, and have zero obligation to contribute to popular libraries, regardless of their supposed merit.

<comment><USER5> How many people write anything in Python or Ruby that is not compatible with CPython and MRI Ruby? The lowest common denominators in those communities are still the reference implementations and any production grade library conforms to that lowest common denominator. As for the Haskell compilers, I'd like to hear from someone that uses anything other than GHC in production.

I agree they can work on whatever they want but this is a bit less benign than writing another library that no one is going to care about. Language forks have never been successful. Please show me one example where a language fork has succeeded and I'll concede. This is a whole lot of drama that is going to turn more people away from Scala which in my opinion is one of the better languages that runs on the JVM.

<comment><USER8> Haskell's actually got a pretty great (if informal) standard which has been used to write a number of different compliant Haskell compilers. GHC is obviously the most popular open source one, but Standard Chartered Bank has its own Haskell compiler it uses a great deal of in production, for instance.

<comment><USER5> What is the point of a proprietary, in-house, custom compiler?

<comment><USER9> The Excel backend of course.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> My biggest frustration with Scala is the exact opposite of their frustration with Typesafe's Scala: it moves too fast. Scala's backwards compatibility problems are obnoxious for the people who don't feel the need to reinvent everything. I can find a version of Foo that works with 2.11 but the only version of Bar I can use only has artifacts for <=2.10.

The play framework exemplifies these problems. Documentation doesn't keep up with releases, blog posts and tutorials don't either. Sometimes I'm looking for example code for some plugin or library, and the code only works with some other version of another dependency that I can't use. I totally understand that people prefer Agile development, but you can't combine Agile development with non-Agile documentation, unless you want to create a framework that only experts can use.

<comment><USER11> Yeah I've wasted so much time dealing with code for the wrong version of Play. It's horrendously organised: case in point, the JSON parsing (WTF?)

<comment><USER12> The documentation for JSON parsing in Play is hilarious.

You read the "The Play JSON library Basics" document, it looks like a lot of code for something that should be simple, but you go ahead and implement as explained. After a while, the verbosity starts bugging you, so you read the "JSON Reads/Writes/Format Combinators", followed by "JSON transformers" and finally the "JSON Macro Inception" pages.

The punchline in the last section can be summarized as "forget all that other stuff, just do "implicit val personFmt = Json.format[Person]". I was happy to be able to delete hundreds of lines of code from my project after learning this, but couldn't you just have told me this upfront since it probably covers 99% of all cases? The documentation also has an aura of "Isn't this all very clever?" feeling to it. It's also quite hard to search for anything, as outdated versions of the docs keep popping up in Google as the first results.

<comment><USER13> Look at this one: [http://stackoverflow.com/questions/1722726/is-the- scala-2-8-...](http://stackoverflow.com/questions/1722726/is-the- scala-2-8-collections-library-a-case-of-the-longest-suicide-note-in-hist)

Scala has a lot of really clever stuff and the "isn't this all really clever" attitude is definitely there.

EDIT: Come on. I meant clever in a good way as well. I'm just a bit ambivalent, is all.

<comment><USER3> I think if anything that example shows the cleverness is a good thing. It's from almost 5 years ago, since when Scala has gone from strength to strength, so the collections rewrite turned out quite well, and fears that it would stop new people coming to Scala, or that companies would stay on 2.7 and the community would schism, were definitely unfounded. The "use case" simplification of the documentation has been implemented and has shown itself to work well, suggesting that this kind of complexity can be managed. And a few years later I've seen Chris use equally complex techniques in his own code (check out his "practical scalaz" talk).

</comment></comment></comment></comment></comment><comment><USER6> I'm conflicted. Type constructor partial application would be great (the current type lambda syntax is just awful), but I really don't want to see Scala fragmented.

<comment><USER14> Agreed on conflicted-ness.

The thing that concerns me the most is that from observation it feels like many of the high muckity mucks of the Scala world would probably be heading in this direction. There's nothing inherently wrong with that, but IMO that increases the chance of serious fragmentation.

</comment></comment><comment><USER15> I'm worried about this fork. Scala is far away from being a wildly used industry language. Yes, there are some well known companies using Scala, but how many of them develop a really big part of their software with Scala? Not so much. If you look around you'll see Java, C#, C, C++ (depending on the business) and actually not so much Scala. The ones who think forking Scala does help the community are in a reality distortion field.

Take a look and Linux desktops to see that diversity is not always good, especially if you're in a niche.

<comment><USER16> I think there is a lot of Scala usage you perhaps don't see. As an example from the corporate world, at least six major international banks (probably more) are doing a significant amount of their development in Scala, some with teams in the hundreds. That's a solid market for Typesafe right there, which isn't going to go away overnight, and won't be stirred by the existence of the Typelevel fork of Scala. Furthermore, they should benefit from its existence because it represents a means for more people to be able to contribute to and enhance the language, without negatively impacting the stable, reliable releases from Typesafe.

</comment></comment><comment><USER17> What's the history behind this fork and what is it likely to mean in terms of fragmentation? In particular what are the irreconcilable beliefs on each side that have led to this?

I haven't tried Scala yet, but my gut reaction is I should stick with Clojure until the dust settles. A fragmented community around a relatively niche language is never good.

<comment><USER18> As someone who's been using Scala for the better part of a couple years:

This seems more like a more ambitious version of the Shapeless and ScalaZ libraries (with some of the same crowd/authors).

I (and I suspect most people who program in Scala for a living) don't use those libraries. Not because they're in any way bad. But there are trade-offs using them IME. The biggest being compile-time. So I get by fine without.

I think this is probably generally good news. In the same way that (I believe) JRuby pushed MRI forward and popularized the case for a multi-threading VM, more advanced type features in this fork probably benefit the Scala community as a whole.

I certainly don't see how it could be harmful. Typesafe isn't going away. The vast majority of businesses will still use their compiler. If you didn't use the advanced-type-based-libraries before, this news probably isn't going to impact you anyway.

So from where I'm standing, having made a late 2.9 to 2.10 transition, and now having made several 2.10 to 2.11 transitions, Scala seems a very mature language/platform to me. Libraries are generally upgraded fairly quickly, and source wise, those releases broke _very_ little (2.11 being the biggest culprit just because of the modularization effort, but that's pretty trivial to resolve).

I dunno. It's not Java. But it's not Ruby either. It's gotten new features since 2.9, but it's broken or changed very little. I find working with it, even working through upgrades, very stable and mostly frustration free.

<comment><USER19> As someone involved in the scala community (and scalaz) community, I'd say about 60% of the companies I talk to at the various meetups use at the very least #scalaz. I was pleasantly surprised.

<comment><USER14> Could this be a biased sample though? Not saying this _is_ the case but it seems logical that the people at the scala meetups are cut from a cloth that would make them more likely to be using things such as scalaz.

I know that my local scala meetup seems to be more heavily oriented towards the functional end of things than the bulk of the scala developers I interact with. OTOH, perhaps the bias is with _my_ sample.

</comment></comment></comment></comment><comment><USER20> When I see all the various Scala compilers out there (Typesafe Scala compiler, LAMP/EPFL Dotty compiler, Scala.js, Scala Virtualized compiler, Scala.Meta system, and several research and private variants of the Scala compiler, IDEs own Scala variants) compared to the lone version of the Groovy one, I realize just how detrimental to the Groovy ecosystem was Codehaus Groovy's practise of ignoring creator James Strachan's JSR-241 standardization effort and redefining "Groovy" to mean the org.codehaus.groovy implementation only. At times it seemed they were scuttling others attempts to build a variant compiler, and even cannabalizing the annotation-based addon market like when they duplicated the Groovy++ static compilation "speed booster".

</comment><comment><USER21> I'm somewhat surprised that everybody missed the fact that Scala 2.12 has more to it than just Java 8 compatibility and stability.

We're working on replacing the whole backend in scalac. We'll ship faster and easier to maintain optimizer that fixes lots of long-standing bugs in scalac. In fact, it will allows us to fix the second most voted issue ever: [https://issues.scala- lang.org/browse/SI-4633?jql=project%20%...](https://issues.scala- lang.org/browse/SI-4633?jql=project%20%3D%20SI%20AND%20status%20%3D%20Open%20ORDER%20BY%20votes%20DESC)

More details: [http://magarciaepfl.github.io/scala/](http://magarciaepfl.github.io/scala/)

\-- Grzegorz, member of Scala team at Typesafe

</comment><comment><USER22> I don't understand what features they want to add beyond type lambda's, singleton types, and literals for bytes / shorts.

1\. I understand if you spend all day making shapeless / scalaz the lack of sugar for type lambda's is annoying. Why not make a SIP to add some sugar there?

2\. Singleton types would have use in ScalaJs as well for encoding. There is already a SIP for this.

3\. Byte / Short literals, seem like again, a SIP could be made for the next release.

So all this boils down to getting SIPs into the language faster. So I think the real feature is not having to wait 3+ years for language improvements that significantly improve the QOL of some library writers.

That is a feature I would like as well. I really miss being able to open the mailing list and scan for exciting new features, Instead I know even if someone has a great idea, it'll be years before it sees the light of day. This sucks and I've moved onto to getting my neat idea -> wow I can use this in my language fix to ScalaJS[1].

I think (thought?) about Scala as ycombinator for language features. I see this enterprise mindset coming in now trying to tie down what Scala is and ultimately I fear that it will kill all the things that has made Scala popular in the first place. Pushing to a more infrequent release model _might_ help enterprise customers but it absolutely crushes library developers in the vanguard working to make the Scala of tomorrow by fighting to get the language features of today. They need turn around on the improvements listed above and can't wait 4+ years to get them.

So does Scala take all the strength it has built up from acting as a feature incubator for the last 10 years and switch and lock down what works, it is in a prime position to do so? It has a virtual monopoly on it's space.

Or does Scala continue to act as a language feature incubator giving its coders early access to cutting edge CS idioms in a mainstream language. There are a lot of CS ideas waiting to get their shot.

Some people would see this situation and say Scala is facing a mutually exclusive set of outcomes, it must decide now. Nonsense I say! When confronted with tough choices I think of the famous Yogi Berra quote "When you see a fork in the road, take it."

I ask myself is there some way we can have our cake and eat it too? Can we go on trying out new features while still oferring stability to those willing to wait for it?

What if we moved to model of more frequently releases + less frequent releases? A controlled fork within the ecosystem, similar to what Ubuntu / Fedora does.

Publish 2 major short term releases a year that cutting edge library writers can target and build their libraries against. Vend these are properly tagged releases in maven central. Stick any old SIP in there, the enterprise overlords don't have to know about it. Rapid iteration, with rapid fall-off in support, a fun Scala for those of us that love using new features, bugs and all, for us the language is about growth.

Then have an LTS version released every other year that picks up the features that worked and everyone seems to love and that will be supported for years into the future. Relatively slow iteration with slow fall off in support, vend this Scala to enterprise users with a coherent multi-year support policy that just oozes with that 'this is rock solid and will work for eons to come' professional vibe that makes them happy.

1: I am using ScalaJS and man it feels great, it's like Scala of 6 years ago, I love opening the mailing list to see if there is a new release with some awesome new features / improvements. There is a lot of green territory over there because it's targeting a new platform and that will settle with time, but already it beats the socks off all the other competitors in the statically typed compiles to JS camp, just no one knows it yet.

<comment><USER23> +1 on ScalaJS. It's pretty amazing piece of technology (Thank's team!) using it in combination with David Barri's bindings for ReactJS[1] and Li Haoyi's uPickle[2]. It makes for elegant solutions with a shared codebase.

[1] [https://github.com/japgolly/scalajs- react](https://github.com/japgolly/scalajs-react)

[2] [https://github.com/lihaoyi/upickle](https://github.com/lihaoyi/upickle)

<comment><USER24> do you know of any large apps using scalajs-react in production?

</comment></comment></comment><comment><USER25> Regardless of the outcome of this initiative (which has little chance of succeeding, but best luck to them), this is pretty bad for the Scala ecosystem overall. There's a general lack of confidence from the community toward Scala and Typesafe and this certainly contributes greatly to the general uncertainty about Scala's chances of success.

<comment><USER9> I guess it was only a matter of time until the "Scala will surely die!!! Really!!! This time it will go down!!!" crowd would show up ...</comment></comment>


I shared my toddler's hospital bill on Twitter - <AUTHOR> https://www.vox.com/first-person/2017/7/7/15934752/health-insurance-heterotaxy-twitter <comment><USER2> Am i missing something in here or are the costs in that bill really this high? $22,526 for room boarding for 2 weeks? Over here in India my grandma's bypass surgery costed somewhat about $10,000. That included everything including the stent, medicines and boarding, that too at a renowned, premiere private hospital.

Is this a special case or are healthcare costs generally this high in America?

<comment><USER3> > are healthcare costs generally this high in America

Yes they are ridiculously high, even after factoring in cost of living / currency rates or as a %age of monthly salary, if you are comparing it to costs in a different country. 1 month after coming here (to America) from India (1999) I had to get wax from my left ear cleaned as it was blocking my hearing.

They squirted some liquid in my ear and got the wax out. 2 weeks later, I got the insurance Statement. It cost $ 800. I was astonished. In India a year before, I'd paid a Doc 100 Rupees (at that time, $2 equivalent in USD) for the same exact thing.

A month later, I had a chest x-ray taken, and some weird quirk in insurance it wasn't covered. So I had to boot the bill. $ 576 for 1 single chest x-ray. My take home at that time as a software engineer was about 2500 / month after tax and deductions, so this was 23% of my paycheck!

Health Insurance coverage is too closely tied to employment. In order to get continued coverage, you are more or less working "for the man" till you die.

<comment><USER4> If you or on high deductible plan, consider hsa :)

<comment><USER5> Depending on his tax rate with HSA a $1000 bill would still be $750 after the tex savings. Hardly an improvement.

</comment></comment></comment></comment><comment><USER6> _> It was eye-opening to see just how low our discourse has sunk, to be forced to acknowledge that what passes for debate in the age of the internet is often nothing more than spewing venom at the other side. How are we ever supposed to find a solution that's better than either Trumpcare or Obamacare if we can't even shut up long enough to recognize the humanity in the people on the other side of the debate?_

So people on one side of the fence are not happy about the very high medical costs required to keep a child alive. They do not understand the humanity behind the numbers.

On the other side of the fence are parents who are not happy that some people think their child is an excessive burden on the system. They (understandably) do not understand (or at the least, are looking away from) the numbers behind making their child viable.

The author correctly identifies one side's shortcoming wrt balanced discourse, but does not see the blindness of her own implied position -- that no cost is too high to save a life. Nowhere in this piece does she broach the subject of numbers and real cost [1].

Finding balance is very difficult in any area, especially in areas where you only have _one shot_ (an example is your child's education, where many parents feel that no amount of investment is enough, and more is always better). But since the system does not have infinite resources, it's a necessary conversation to have (which the author could have brought up, but failed to do so -- understandably, since this article is a strategic opinion piece meant to further the author's self-interest, which I completely respect).

A billion dollars to save a child's life, we would likely agree, is too much. $1,000, we would likely agree, is entirely justified. Where we draw the line, why, and how we get there (of urgent need is our relationship with end of life care and treatments) is an important conversation that we are failing to have, and those of us on both sides of the fence are equally culpable for this shortcoming.

[1] The large 6 figure bill and post insurance $500 bill is only used qualitatively in the introduction.

<comment><USER7> Who sets the numbers and why, though? How much is profit, how much should be profit, when it comes to human health and rehabilitation whether mental or physical assistance is required? Or, ignoring profit, why take away public funding to programs for poor people just to provide tax breaks to rich folks? How much is a dollar worth to each individual, relatively-speaking? There are few easy answers, except (almost) everybody wants to see costs lower to the levels they are in other countries. Setting price or profit caps and limits is one method, ensuring the system can't ask for inflated amounts from insurers is another. This could affect quality of service, but then again, it might not. All stores might charge the same price for some brand name item but not all stores offer equal customer service or trained staff... The same is surely true of medical facilities.

<comment><USER8> > Just to provide tax breaks to rich folks

Your statement illustrates one of two competing views. The following statements are extremes of the two positions.

1) The government by default owns all your money, and any money you get to keep after taxes is just a tax break.

2) You own your money by default, and the government should not take your money except to provide things that the market is unable to (some examples of which are law enforcement, military).

Those who espouse one of these views, tend to see people who espouse the other as morally wrong and evil.

<comment><USER7> I've found most nations settle on: if you're not making much, keep it. It means more to you. In fact, here's a few hundred more for sales taxes you might have paid. If you're making enough to "get by," we'll skim off the top and give you tax breaks as incentives. From there it's a sliding scale up to some cut off. For example: If you're making more than 3-5x the "getting by," rate mentioned above, we'll split it – you keep half, we'll take half. And again, that's only on top of other tax breaks, so 50% is an asymptotic upper bound for most people.

I may not like it come tax time, but it makes sense to me. I consider the half I don't keep another sort of contribution to society. And of course look for ways to minimize it–money doesn't save itself. But I don't fight over the concept– I rely on services paid directly from taxpayer money each day. The one thing I would hope for is efficiency– but I don't think starving and cutting systems inherently improves them. It's just a shell game.

</comment></comment></comment></comment><comment><USER9> It's depressing to me to think that people hate others so much that they would go to such great lengths to keep others from getting healthcare and ensure their demise. These same people would have no problem accepting healthcare from others if it was their lives that were in danger. I truly cannot fathom the hypocrisy, hate, and cruelty that must exist in these people's hearts towards their fellow citizens.

<comment><USER10> In what way does wanting to keep what I earn mean I "hate others"? I feel sad when I walk by homeless people, but I don't stop and give them everything I can afford until I'm impoverished. Do you? If not, why do you hate others so much that you want to "keep them from getting housing"?

Hopefully you see why your argument is disingenuous. If you're really so hard on hypocrisy, you should go out right now and give every last penny to someone else's medical expenses. Or are you only generous enough to spend other people's money?

<comment><USER11> Maybe you didn't read the story but people were sending her death threats.

<comment><USER12> who cares about reading the whole story w hen you're a libertarian (not you) who thinks every penny he makes is due to his own merit and he is entitled to this no matter the life of others though :/

<comment><USER10> Ah, I see you're of the much more enlightened opinion that everything you earn is due to and owned by the government, and anything they let you have is due to their own benevolence and good grace.

</comment></comment></comment></comment></comment><comment><USER13> Part of why healthcare is so expensive today, is we're capable of saving so many more lives than before. As little as a generation ago, many more would have died, people who now go on to live fruitful productive lives.

<comment><USER14> America spends more per capita than any other first world country for worse outcomes [1]. Healthcare is expensive because of the profit motive. Single payer isn't implemented for (mostly) the same reason.

60% of Americans want single payer [2].

"A majority of Americans say it is the federal government's responsibility to make sure all Americans have health care coverage. And a growing share now supports a "single payer" approach to health insurance, according to a new national survey by Pew Research Center.

Currently, 60% say the federal government is responsible for ensuring health care coverage for all Americans, while 39% say this is not the government's responsibility. These views are unchanged from January, but the share saying health coverage is a government responsibility remains at its highest level in nearly a decade.

Among those who see a government responsibility to provide health coverage for all, more now say it should be provided through a single health insurance system run by the government, rather than through a mix of private companies and government programs. Overall, 33% of the public now favors such a "single payer" approach to health insurance, up 5 percentage points since January and 12 points since 2014. Democrats – especially liberal Democrats – are much more supportive of this approach than they were even at the start of this year.

 _Even among those who say the federal government is not responsible for ensuring Americans have health care coverage, there is little public appetite for government withdrawing entirely from involvement in health care coverage. Among the public, 33% say that health care coverage is not the government's responsibility, but that programs like Medicare and Medicaid should be continued; just 5% of Americans say the government should not be involved at all in providing health insurance._ "

Emphasis mine.

[1] [http://www.npr.org/sections/goatsandsoda/2017/04/20/52477419...](http://www.npr.org/sections/goatsandsoda/2017/04/20/524774195/what- country-spends-the-most-and-least-on-health-care-per-person)

[2] [http://www.pewresearch.org/fact-tank/2017/06/23/public- suppo...](http://www.pewresearch.org/fact-tank/2017/06/23/public-support-for- single-payer-health-coverage-grows-driven-by-democrats/)

<comment><USER15> I used to be for single part until I listened to a recent episode of econtalk ([http://www.econtalk.org/archives/2017/06/christy_ford_ch.htm...](http://www.econtalk.org/archives/2017/06/christy_ford_ch.html)). Christy Ford described how the current medical system evolved and how the American Medical Association made the current, insurance based system happen. Before this we used to for example multi-disciplineray offices of doctors that you could directly buy health care coverage from. That was made illegal. What we currently have is the worst of any world. It's a artificially constrained market that's practically devoid of competition. On top of that we have insurance which is clearly the wrong model for something you know you are going to need. And it's employer provided on top of it. How could this market possibly be less functional? Let's try to fix the market before we pour out the baby with the bath water.

<comment><USER14> I have to respectfully disagree. It's time to burn down the current system and go straight to single payer.

Collect premiums via payroll taxes->fund healthcare providers. That greatly simplifies it, but there are many other first world models we can pick from. This is not hard.

<comment><USER16> > Collect premiums via payroll taxes->fund healthcare providers. That greatly > simplifies it, but there are many other first world models we can pick from. > This is not hard.

I entirely agree with you on that and your assessment on how the finance/tax part of it is not as scary as some would think, it might even perhaps not be the hardest part of the problem.

My personal belief in single-payer is that it is the only way to create a leverage to either create a public offer of healthcare goods and service, or radically modify the power imbalance and drive the prices of goods and services way down. The thing that worries me is that in both cases, what I understand as being a total healthcare bubble, which I am sure is a well organized lobby, won't exactly be thrilled at letting things happen without a fight :)

</comment></comment></comment></comment></comment><comment><USER17> Bots and unthinking cyberdisinhibited people competively flame and troll whomever is the current punching-bag for brownie points, schadenfreude and negative attention seeking behavior.

</comment><comment><USER18> This is one of the reasons I love my country (France) : because I do not even have a bill to tweet. Literally : there is no obvious financial trace of serious medical items.

Sure, when I go to the emergency with my child and his swollen ankle, I get charged 28€ (IIRC), which later get reinbursed. This is the highest medical bill I can think of (except dental and optical). A 100,000€ bill would not appear anywhere.

</comment><comment><USER19> The are children, orphans, families, whole societies that live worse than even the poorest of americans. Sickening.

</comment><comment><USER20> In my country somewhere in europe you pay ridiculous taxes and you cannot opt out. The healthcare is shit, corrupt and if you want good care when they do not treat you like shit you need to go private and pay extra. Beware americans with your mentality you end up paying more ans getting less with programs like obamacare.

<comment><USER21> [citation needed]

</comment></comment><comment><USER8> Based on the background of the mother, she would have been able to have had insurance even without Obamacare, and would have still been able to have insurance no matter what the Republican Congress passes. In this situation, no matter what the government did, her child would still have been able to get the necessary surgery.

In addition, Boston Children's Hospital is one of the premier hospitals in the world. Given the specialized nature of the problem and the fact that heterotaxy cases are pretty rare, even without insurance, the chances are high that the child would still have been treated and the hospital would have eaten the cost.

Thus, pre/post/no Obamacare, the child still would have had the treatment. Thus, you cannot derive a political position from this case.

<comment><USER6> I am assuming that your statements are correct.

However, if we examine the author's motives, she seeks a society where any child who shares her son's ailment (or other life threatening but treatable -- albeit expensively -- diseases) can receive treatment, whether or not they share her fortunate circumstances or not.

In that light her rhetorical strategy remains reasonable.</comment></comment>


Orbital, Sierra Nevada, SpaceX Win NASA Commercial Cargo Contracts - <AUTHOR> http://spacenews.com/orbital-sierra-nevada-spacex-win-nasa-commercial-cargo-contracts/ <comment><AUTHOR> This is pretty exciting news -- Sierra Nevada's "Dream Chaser" cargo version lands on a runway, and may lead to a future human-carrying version. Until now it looked like Sierra Nevada had no customers.

Orbital and SpaceX are incumbents for the previous contract.</comment>


Statistics Refresher? - <AUTHOR> I'm doing a bunch of split testing and multivariate testing, but have forgotten a lot of the associated statistics and probability. Do any of you know a good refresher I can go over? <comment><USER2> <http://news.ycombinator.com/item?id=529673>

<http://news.ycombinator.com/item?id=201913>

</comment><comment><USER3> The Little Handbook of Statistical Practice: <http://www.tufts.edu/~gdallal/LHSP.HTM>

It's the best stats resource I've come across, particularly for the stats behind split testing and multivariate testing. I've used it as a reference while building an A/B testing system in the past.

For considerations in building a system to perform split testing and using such a system, the folks working on Microsoft's Experimentation Platform published an incredibly helpful paper: <http://exp-platform.com/hippo.aspx></comment>


A.D. 2035: Rich people will be thousands of times smarter than poor people - <AUTHOR> http://venturebeat.com/2016/08/02/a-d-2035-rich-people-will-be-thousands-of-times-smarter-than-poor-people/ <comment><USER2> I don't buy it.

Something I learned in grad school is that there is a continent of linear problems surrounded by exactly solvable islands in a vast unsolvable sea.

For instance, you can solve quadratic equations easily with a closed form formula, and do cubics and quartics with just a little more work, but there is no closed form for quintics and higher and no amount of "intelligence" is going to change that.

Similarly, without the right experimental results, no amount of "intelligence" is going to lead to a fundamental breakthrough in theoretical physics.

You might be able to throw more speed, more computing units, a larger memory, etc. at a problem but that doesn't mean you're going to get proportionally better results.

<comment><USER3> I think you are assuming that the "cloud brains" will just be number crunchers like today's computers. Human intelligence and computer intelligence are fundamentally different. Sure, plugging directly into a massive calculator is useful, but does have it limits. However, this article is more about running simulated copies of our neural patterns. The human brain is limited to only a handful of simultaneous ideas. Imagine if you could synthesis an idea with 100 inputs instead of just 5. Or if you go with the spontaneous theory of creativity, you can parallelize the creative process, and just have a higher chance of having a good idea by increasing the number of ideas had. This is fundamentally different from raw calculation. Both are likely to be useful, but both will serve different purposes.

<comment><USER2> I think the outcome for that is even more pessimistic.

If you generate 100x more ideas most of them are going to be rehashings of the same old ideas, not that much better than what you had before. You probably get some more value, but not 100x. Whether value goes up logarithmically or reaches an asymtope, the benefits of throwing more neurons on it will become uneconomic.

Also I think creativity is overvalued. Look at all the things Buckminister Fuller invented that went nowhere:

[https://bfi.org/about-fuller/big-ideas/dymaxion- world/dymaxi...](https://bfi.org/about-fuller/big-ideas/dymaxion- world/dymaxion-bathroom)

</comment></comment></comment><comment><AUTHOR> The concept itself is pretty amazing to think about, but I wouldn't expect the long-term implications of intelligence to play out nearly as dramatically as the author implies. While coming from means AND having high intelligence would confer benefits to be sure, there has to be a law of diminishing returns on increasing intelligence. For sure, the short-term inequalities would be difficult to keep in check. But if the entire world has increased intelligence then those benefits will quickly deteriorate.</comment>


Ask HN: Why would you use a cloud IDE? - <AUTHOR>

This question is genuinely asked. Over the last few years various companies have started work on cloud IDEs, with admittedly impressive results in many cases. But personally, I've never been able to really identify a motivation for me to use one. Perhaps this is because I'm not very web-centric in terms of the code I write.<p>I feel like I must be missing something significant if people are putting a lot of effort in to something, so how do other people feel? Is the cloud IDE approach scratching a real itch, or is it being done because it can be? (My admittedly slightly pejorative initial reaction a few years back). <comment><USER2> I see two reasons to use a cloud IDE:

1) Device independent. If you want to start writing code on your work computer, work on it on your laptop when you get home, and debug it while at your mother-in-law's house, using a cloud IDE makes this much easier than having to sync files and have programs installed on all computers

2) Mobile. If you think of a breakthrough in your code when you only have your smartphone or tablet on you, being able to access it and work on it on devices that may not even support native development could be really useful.

<comment><USER3> #1 was a huge deal for me. I only use a cloud IDE for web development, and the ability to edit something no matter where I am or what computer I'm using in an environment I'm used to is simply awesome. It's had such an impact on me that I'm moving everything I do to cloud services; the value of not just having my data everywhere but the tools I'm used to everywhere is very significant.

</comment></comment><comment><USER4> My main reason would be not having to set up my computer for development. When you're new to an ecosystem it can be super painful to get set up.

Example: I use Python a lot, but had never used it with MySQL until yesterday. I had MAMP installed and I just wanted a Python package to run queries. I tried to install MySQL-Python, but it couldn't find mysql_config. So I find it and update my PATH. Then it can't find some files. I google it and it turns out MAMP MySQL doesn't include some parts and I need to install another version of MySQL to make it work. It works now, but the MySQL Workbench export/import feature isn't happy with the MySQL version number.

Especially since many open source projects are compiled from source and have many dependencies I'd love an environment that just works.</comment>


How we built a hardware startup with two engineers and some free time - <AUTHOR> http://techcrunch.com/2016/04/01/hardware-is-hard-how-we-built-a-hardware-startup-with-two-engineers-and-some-free-time/ <comment><USER2> Fascinating. I used to do decades ago with my ears what their devices do now: Listen to machinery while walking around the plant I worked in to see if I could pick up on a trouble spot, because I learned over time that mechanical equipment that was heading for failure sounded a bit different then the equipment that was still running smoothly. Belts, bearings, rollers and plates would wear and I would know to pay more attention to them more often, rather than just react when something happened. People thought I was nuts when I told them I could hear that something didn't sound right through all the noise, which was considerable (you had to wear hearing protection all day).

<comment><USER3> Some of the more fancy machines these days have embedded microphones to tell if a bearing is going to fail soon. They make a distinctive noise based on shaft rpm and bearing diameter when they start to fail, so you know which one to order before you spend a day tearing the machine appart to get at the faulty bearing.

<comment><USER4> Bearings also tend to start running quite hot when they are at the end of their lives. Bearings on trains often have smoke bombs on them that go off at a specific temperature.

</comment></comment></comment><comment><USER5> As a hardware startup founder, I would like to note that the lean model only really works for hardware when you not creating something complex (ex lots of mechanical parts or lots of integrated electronic systems). In cases like that, the lean method completely falls apart because of the cost, and it becomes really important to make sure your calculations and simulations are correct.

<comment><USER6> I'm sure it's true and I don't mean to diminish your comment but.. Isn't that kind of true for anything? Start small and build up.

You're not going to be a contender of, say, Apple in a year or even 10, but there are several companies in the pipeline already at more advanced stages

<comment><USER7> In some complex and mature markets if you start too small you will never be able to compete with existent players. "Starting up in a garage" works mostly on new and undeveloped markets.

<comment><USER8> Depends on what you can leverage. You can start a car comapny by modifying existing cars, go up market, build a business and use the same suppliers as the other car company's. Give it 40 years and you really can start a major car company from scratch. Granted this generally takes long enough that most people fail or get bought out.

<comment><USER9> As an extreme example, before starting Tesla, Eberhard took an existing electric car [A], which was itself built on an existing kit car [B], and had a different battery technology installed [C]. And then used it as a proof of concept to start Tesla.

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

[B] [http://www.funcar.com/sportech/](http://www.funcar.com/sportech/)

[C] [https://en.wikipedia.org/wiki/AC_Propulsion_tzero#Lithium- io...](https://en.wikipedia.org/wiki/AC_Propulsion_tzero#Lithium- ion_battery_conversion)

</comment></comment></comment></comment></comment><comment><USER10> Inspiring. I've been walking around with the idea to build an amplifier of sorts, but have not talked to any customers.

Plans range from guitar headphone amps, to valve amps, to DAC things, to other crazy things.

</comment><comment><USER11> It would be nice if they actually talked about their experience and creation, rather than just the methodology...

</comment><comment><USER12> Why would they build on Android then launch on iphone? ? I also can't find ruguscope

<comment><USER13> I too searched Ruguscope but then realized it's Auguscope.</comment></comment>


Facebook has a coronavirus problem. It's WhatsApp - <AUTHOR> https://www.cnn.com/2020/03/18/tech/whatsapp-coronavirus-misinformation/index.html <comment><USER2> I'm not sure I get how the problem is related to WhatsApp.

WhatsApp is a platform for (largely) private messaging among individuals or small groups. It's a SMS/Call replacement/enhancement. I wouldn't want health officials, or anyone else for that matter, to be monitoring what gets exchanged over WhatsApp to detect misinformation. This is not a platform problem, this is a "there's disinformation out there and individuals are spreading it problem", I think.

This is different in my mind from semi-public/public platforms a-la Facebook, Twitter, etc.

</comment><comment><USER3> Goverments have a problem. People can exchange information without oversight.

This is frightening, to say the least.

</comment><comment><USER4> Facebook has a Facebook (or Instagram) problem. Most misinformation originates from there before being spread further through private platforms such as WhatsApp.

However I am not sure if this is a _real_ problem for them. After all, it keeps engagement levels high on the platform; if anything, idiots and crazies who crave misinformation are _more_ likely to click on ads.</comment>


F# enters Tiobe top 20 index for the first time - <AUTHOR> http://www.tiobe.com/index.php/paperinfo/tpci/F_.html

<comment><USER2> Some F# to ponder:

        type LogicGate =
            | ON
            | OFF
            | NAND of LogicGate * LogicGate
            | NOT  of LogicGate
            | AND  of LogicGate * LogicGate
            | OR   of LogicGate * LogicGate
            | NOR  of LogicGate * LogicGate
            | XOR  of LogicGate * LogicGate
            | XNOR of LogicGate * LogicGate

        let rec evaluate input =
            match input with
            | ON         -> true
            | OFF        -> false
            | NAND(a, b) -> not ((evaluate a) && (evaluate b))
            | NOT(a)     -> (evaluate (NAND(a, a)))
            | AND(a, b)  -> (evaluate (NOT(NAND(a, b))))
            | OR(a, b)   -> (evaluate (NAND(NOT(a), NOT(b))))
            | NOR(a, b)  -> (evaluate (NOT(OR(a, b))))
            | XOR(a, b)  -> (evaluate (AND(NAND(a, b), OR(a, b))))
            | XNOR(a, b) -> (evaluate (NOT(XOR(a, b))))

        [
            NAND(OFF, OFF);
            NAND(OFF, ON);
            NAND(ON,  OFF);
            NAND(ON,  ON)
        ] |> List.map (fun x -> printfn (evaluate x))

<comment><USER3> Curious: is this also valid ocaml?

<comment><USER4> Almost, |> isn't an operator in OCaml (although I think Batteries has something like |- that does the same thing) and printfn isn't in OCaml. Printf.printf is, but wouldn't work in this case (you'd need a format string). Also, List.map returns a new list, in OCaml you would probably want to do List.iter.

<comment><USER5> the |> operator is very very simple. ocaml implementation would look something like:

      let (|>) a b = b a ;;

</comment></comment></comment></comment><comment><USER6> From the full article:

 _The confidence of the SuperCollider programming language has been set to 80%. The reason for this is quite funny. In order to prove that the TIOBE index can be manipulated easily, Adam Kennedy created an empty Perl library called Acme-SuperCollider-Programming. This was to boost the unknown programming language SuperCollider by adding it to Perl's popular library archive CPAN. Now 20% of all +"SuperCollider programming" come from this artificial library._

Yes, quite funny indeed, but not for the reasons they think. Just to show that Tiobe methodology is a joke. I don't understand how people take this seriously.

<comment><USER7> Who has a better methodology? Is there even a good one?

<comment><USER8> If that was a serious question, places that do developer tools and programming languages for a living (at least MSFT, I assume others as well) pay ridiculous amounts of money to independent third-party companies that specialize in gathering this kind of data. The raw data was then kept fairly private (marketing + upper mgmt only), but the rank and file would see some of it occasionally when things such as trends on the number of VBA or VB5 or VC++ programmers appeared in slide decks talking about the direction for upcoming versions of the product.

Having working with the raw data, it was pretty fantastic. Segemented by industry/business size, handled issues with multiple programming languages or companies where one section used one language and another used other ones, etc. We even knew which tools and add-ons were used for which languages and which compiler on each platform (i.e. how many commercial shops using C++ targeting linux are using gcc vs. icc?).

But that data was also stunningly expensive. My marketing friends tell me that accurate market data always is.

<comment><USER7> Interesting. It's a tautology but the Internet sees only the Internet - there's a huge swathe of programming work that just isn't advertised online, so is invisible to TIOBE.

</comment></comment></comment></comment><comment> T-zex Go was a winner of 2009, RPG (OS/400) is more popular than Haskell or Erlang. Sure this is a joke.

<comment><AUTHOR> Actually the award Go won was "the highest rise in ratings in a year". That said, I do agree their methodology is pretty suspect. The thing is, a lot of developers look to Tiobe to decide what language to learn next, so it's interesting to follow even if the data is flawed.

</comment></comment><comment><AUTHOR> The full article is at [http://www.tiobe.com/index.php/content/paperinfo/tpci/index....](http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html)

I couldn't put it in the submission because of HN's dupe detection.

</comment><comment><USER9> I also look at the number of people in related Meetup and Linkedin groups. I'm in NYC and there are a lot of local people in various groups.

</comment><comment><USER10> Scala ate their lunch.</comment>


RubyOnRails significantly under-performs frameworks in common concurrency...why? - <AUTHOR> http://www.techempower.com/benchmarks/#section=data-r8&hw=i7&test=query

<comment><USER2> I don't trust those benchmarks: what configuration are they using? rails in development or production mode? behind web server or pure application server? if yes, socket or port? which database? socket or port? which drivers? there are too many combinations in my opinion to trust a single benchmark

<comment><AUTHOR> You can hit the Github repo and investigate the source --> [https://github.com/TechEmpower/FrameworkBenchmarks/tree/mast...](https://github.com/TechEmpower/FrameworkBenchmarks/tree/master/rails)</comment></comment>


Job posting from 1994 Jeff Bezos for a 'well-capitalized Seattle startup'  - <AUTHOR> http://startlife.hangwith.me/early-job-posting-by-jeff-bezos-seeking-a-pro

<comment><USER2> I wonder who was the guy that got the job and how well he is doing now with that equity

<comment><AUTHOR> I was wondering the same thing!

</comment></comment><comment><USER3> I love artifacts like these. This, Mark Zuckerberg's /. profile, Sergey Brin & Larry Page's Stanford course page, and the like. Digital archaeology.

</comment><comment><USER4> <http://news.ycombinator.com/item?id=2044945>

<comment><AUTHOR> Genuinely did not see the RWW post. I found this randomly elsewhere.

</comment></comment><comment><USER5> cool</comment>


Another Over Paid Google Exec: $4 Million - <AUTHOR> http://www.webguild.org/2008/06/google-new-cfo-starts-job-at-4-million.php

<comment><USER2> He makes $4 million/year. Google's net interest income was $167 million last _quarter_. So if he's able to increase their interest income by more than about .7%, he's worth the $4 million/year for that alone.

If you were 1% better than your predecessor at just one aspect of your job, would it be worth your entire annual compensation to your employer? I doubt it. With a company that huge, a tiny improvement in their financial policies can make a massive difference -- and the people who can effect such changes are worth a premium.

</comment><comment><USER3> Google has incredibly complex finances. An incompetent or corrupt CFO could easily cost Google tens or hundreds of millions, or knock billions off its market cap in the event of a scandal.

There's no evidence or reasoning here to justify the headline's judgment that this executive is "Over Paid". It's just unthinking populist resentment.

</comment><comment><USER4> to demonstrate overpaid you must compare actual pay to actual value. so provide an estimate of his value, or you have no grounds to call him overpaid.

</comment><comment><AUTHOR> Why is there such a big salary difference between the executives and their engineers? Without us they wouldn't have a product to sell! Who feels under appreciated?

<comment><USER5> You need to have the right people at the top and when you find someone you do what it takes to get them.

There's a reason it took Google almost a year to find a new CFO.

If you think Google is undervaluing your work there's only three ways to do: one, convince Google to pay you more; two, go work for a company that will pay you what you think you're worth; and three, strike out on your own and let the market prove to everyone what you're worth.

Anything else is just whining.

<comment><USER6> Agreed. You get paid what the market will bear. There are fewer CFOs with experience managing the finances of $Billion+ companies than there are engineers who have developed high performance apps. Given this scarcity, and that the CFO (and CEO) are ultimately responsible for the finances of the company, and that they report to the board and shareholders, it's not surprising that Google pays its CFO more than it pays its top engineers.

<comment><USER7> I think the article inadvertantly points out another reason why CFOs get paid a lot - make a mistake and you can end up in prison for a decade.</comment></comment></comment></comment>


Coverage Is Not Strongly Correlated with Test Suite Effectiveness (2014) - <AUTHOR> http://www.linozemtseva.com/research/2014/icse/coverage/ <comment><USER2> Notice the result is a bit more nuanced if reading the paper, i.e.

> Our results suggest that, for large Java programs, the correlation between > coverage and effectiveness drops when suite size is controlled for.

and

> While coverage measures are useful for identifying under-tested parts of a > program, and low coverage may indicate that a test suite is inadequate, high > coverage does not indicate that a test suite is effective.

They also propose an alternative as a "quality goal" for test suites:

> Of course, developers still want to measure the quality of their test > suites, meaning they need a metric that does correlate with fault detection > ability. While this is still an open problem, we currently feel that > mutation score may be a good substitute for coverage in this context.

<comment><USER3> I wasn't familiar with mutation testing. This is also from the article:

>We used the open source tool PIT [35] to generate faulty versions of our programs. To describe PIT's operation, we must first give a brief description of mutation testing.

>A mutant is a new version of a program that is created by making a small syntactic change to the original program. For example, a mutant could be created by modifying a constant, negating a branch condition, or removing a method call. The resulting mutant may produce the same output as the original program, in which case it is called an equivalent mutant. For example, if the equality test in the code snippet in Figure 1 were changed to if (index >= 10), the new program would be an equivalent mutant.

Sounds like a resource intensive way to test -- # tests * loc * mutation options. However, if you need the fault tolerance it could be worth it. You can probably spot check to get similar quality with lower resources. Very interesting.

<comment><USER4> pitest has a few tricks up its sleeve to keep overhead reasonable. For example (from [http://pitest.org/faq/](http://pitest.org/faq/)):

> Per test case line coverage information is first gathered and all tests that > do not exercise the mutated line of code are disguarded.

I've used pitest in real life and while it is quite a bit heavier than straightforward testing, it's definitely usable. I'm now using it on all Java projects, I wish there was something comparable for JavaScript!

<comment><USER5> I don't think it is quite as complete, but this looks usable [https://github.com/jimivdw/grunt-mutation- testing](https://github.com/jimivdw/grunt-mutation-testing). That's just from google, no experience with it.

</comment></comment></comment></comment><comment><USER6> I am not surprised by the findings of the study - not at all.

In discussions about software metrics, I'm always trying to make the point that you can _only_ use most metrics from within a team to gain insights, not as an external measure about how good/bad the code (or the team) is. In other words, if a team thinks they have a problem, they can use metrics to gain insights and explore possible solutions. But as soon as someone says "[foo metric] needs to be at least [value]", you have already lost - the cheating and gaming begins. Even if the agreement on [value] comes from within the team.

Back to the topic :) I am not surprised by the findings - Higher test coverage does not mean that everything is fine. But very low test coverage indicates that there might be hidden problems here or there. This is how I like to use test coverage and how I try to teach it.

But it is great that we have now empirical data here: From now on, I can point others to this study when we are discussing whether the build server should reject commits with less than [value] coverage.

<comment><USER7> A brief skim of the study shows that the headline is a bit misleading. The correlation between coverage and bug yield is weak _when suite size is controlled for_.

Another way of looking at this is that large suites improve bug yield. They tend to have high coverage as a _by-product_ , because a large test suite will hammer each unit from various directions.

My suspicion is that scoring coverage for _every_ pass over an LOC or a pathway would change the result substantially.

Nothing in this paper is an argument that test coverage is useless; rather, it should be seen as a secondary metric that rapidly loses indicative value as it approaches 100%.

 _Number of test cases_ seems to be the independent variable here.

<comment><USER8> Paper author here. Scoring coverage for every pass is an interesting idea and something I'd like to look into. I'm not sure it would change the result as much as you think, though. The basic finding of the paper is that coverage is a complicated way of measuring the size of the suite. Counting the number of times each line is hit will have the same problem, I think: writing more tests increases that score but also increases the number of bugs found, causing a spurious correlation.

My hunch is that the quality of the oracle matters more than the coverage score. You can write tests that cover all the code without actually checking anything; the tests will only catch bugs if you're carefully comparing expected and actual results. Maybe a simple metric like "number of asserts" would be useful -- except, of course, that will also be correlated with the size of the suite... It's a tough problem.

The point about the title is fair. I erred on the side of clickbait when I wrote the paper and regret it a bit. On the other hand, it worked. :)

<comment><USER7> I see your point about coverage volume being a better-fitted proxy for suite size. It'd also be a proxy for path coverage. Still, it'd be fun to count the horse's teeth anyhow.

Would you say that coverage's worth as a _negative_ metric still seems meaningful, at least as a heuristic? I imagine that's covered in other literature.

Where I work we don't really fuss too much about coverage. We TDD, so in practice our coverage hovers around the high 90s as a matter of course. When I am writing a test I often manually mutate the code and test once it goes green as a quick validation that the test does what I think it does.

One last question -- did you classify tests? Feature, integration and unit tests should show quite different curves. Especially heavily mockist style unit tests.

<comment><USER8> I'd definitely say that the absence of coverage is a problem. My view is that coverage is necessary but not sufficient for good testing.

We talked a bit about classifying tests but didn't do it in the end because it's surprisingly hard to do. I do know of one paper that looked at different kinds of tests, called "The Effect of Code Coverage on Fault Detection under Different Testing Profiles": [http://goo.gl/nnxgwE](http://goo.gl/nnxgwE). The authors found differences between tests for error cases vs. tests for normal operation and between functional tests vs. random tests. IIRC, they had undergrads do a term project that had to pass 1200 tests before the final submission, and the professors themselves wrote the tests, so categorization was a bit easier.

<comment><USER7> As a rough way to automatically classify tests, you can look for tools like capybara, selenium or htmlunit for feature and mocking libraries for unit.

Mind you, there's as many taxonomies for tests as there are tests. To be honest I expect one way to classify them is by working backwards from coverage -- feature tests should have low volume but wide distribution across a codebase (perhaps that's another metric -- density?). Unit tests would be narrow but deep on a particular module.

<comment><USER8> Those are good ideas, thanks!

<comment><USER7> Throw me on as the tenth or eleventh coauthor and I'll buy beer to sweeten the deal.

If you need a corpus of code from a highly doctrinaire TDD shop, or if you think we can help, let me know: firstname.lastname@example.com.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Another case of conflating a phenomenon and its measure.

Rather than write good tests, people have gotten side-tracked by chasing magical number that may or may not reflect the phenomenon of interest.

Heuristics are sometimes wrong, but always fast and not fundamentally bad. Writing unit tests for high-risk code is a good heuristic, god dammit. Chasing after 100% test-coverage is pedantic, and -- I honestly think -- evidence of a development team that favors form over function.

I'll continue writing unit tests that actually test critical boundary conditions, and I will continue not to care if only 10% of my code is covered. If that 10% represents 80% of my bugs, I've won.

<comment><USER10> What about the other 20% of your bugs? They don't matter?

<comment><USER9> Huh?

Preemptively testing a subset of my code doesn't prevent me from fixing other bugs, or from writing regression tests.

From the tone of your question, you'd think that 100% test coverage would fix the remaining 20%, when it clearly doesn't. I mean no disrespect, but this is what I meant when I said that unit-test coverage is a pedantic subject (which, I must again insist, is _not_ meant to imply that you are a pedant).

The bugs get fixed, they just don't get discovered/resolved with up-front unit tests alone. It ends up being more effective and more efficient to hunt them down by other means.

</comment></comment></comment><comment><USER11> No kidding. This has been known for a long time but it's good to see empirical evidence. The empirical evidence of 70's-90's showed the best ways to reduce defects were the following:

1\. Unambiguous specifications of what the system will do.

2\. Implementation in safe languages or subsets with plenty of interface checks.

3\. _Human review_ of design, implementation, and configuration looking for errors. Best results were here.

4\. Usage-based testing to eliminate most errors user will experience in practice.

5\. Thorough functional and unit testing.

(Later on...)

6\. Fuzz testing.

7\. Static analysis.

Practices 1-4 were used in Cleanroom, some major commercial projects, and high assurance security work. Every time, they produced results in preventing serious defects from entering the system that often might have slipped by testing. So, those are where the majority of our verification work should go in. Supporting evidence is from those that do a subset of that from OpenBSD team to Microsoft's SDL along with substantial defect reduction that followed.

Note: 6 and 7 showed their value later on. No 7 should definitely be done where possible with 6 done to a degree. I haven't researched 6 enough to give advice on most efficient approach, though.

So, internal testing and coverage are the weakest forms of verification. They have many benefits for sure but people put way too much effort and expectations into them where it pays off more elsewhere. Do enough testing for its key benefits then just cut it off from there. And don't even do most of that until you've done code reviews, etc which pay off more.

<comment><USER12> I'm not going to dispute that #7 earns a place lower down the chain than the features you mentioned in practical terms of identifying bugs. That said, it's only overly feasible when run from early on in design.

If a project currently produces clean output, and I make a commit that causes clang's analyser to complain, it's easy enough to fix, whether it's a "legitimate" error or not.

I've tried throwing static analyzers at long established projects like OpenSSL and.. there's just no point. Noone is going to review a few thousand errors and make hundreds of commits that don't actually fix anything just to get perfectly clean static analysis output. It's more likely I would break something than help.

It's really not that hard to implement a "no commit unless it passes static analysis" rule from the start, and even if the bugs removed are low, I usually argue they are non-zero.

<comment><USER11> I did it in chronological order of discovery and significant application. I agree it should be used as early as possible. Plenty of benefit to that. Further, the Orange Book era systems discovered a heuristic that supports your theory about old codebases: things must be designed for such verification or security from Day 1. Usually impossible to retrofit such properties into an existing codebase whose methods were quite different.

</comment></comment></comment><comment><USER13> I find it strange that so much time is spent trying to convince people that some aspect of testing (coverage / tdd) is not a panacea and so little around improving how to test.

As a student / recent grad I remember thinking that testing was maybe some thing you maybe had to do for super hardcore projects. Now I see it as one of the first things to think about on a serious project and something that is going to take ~30 - 50% of the cost / effort.

<comment><USER14> IMO testing's biggest strength is in allowing you to delegate remembering all the use cases of an API to some code, instead of having to look them up in a checklist, or worse, having to remember them all.

Even if the tests are covering mundane, easy functions and execution paths, the benefit of not worrying if you broke something far outweighs the time to write tests.

<comment><USER15> Isn't "remembering use cases" something that should be done with comments or documentation ?

<comment><USER7> Comments and documentation become stale because they require deliberate human intervention to maintain their truthfulness. They also rely on the author of the documentation or comments correctly mentally executing the code being marked up.

Tests are compared with the API every time they're run, as seen by the computer's model of execution, giving immediate feedback on detected discrepancies.

(I believe that Pythonistas have clever docs that can encode snippets of testing into documentation, which splits the difference a bit, but is no substitute for a robust test suite).

</comment></comment></comment></comment><comment><USER16> Coverage is pretty awesome feedback for reminding you that "oh yeah, I should probably test that case too." And if you start out with this kind of feedback early it can help influence your design to increase its testability.

If X% coverage is a goal measured by non-technical team members, it likely loses much of its value.

<comment><USER17> I've been getting into shooting for 100% coverage in critical [1] code lately, and while that may not be to everyone's taste, what I've noticed is that I _always_ learn things from at least _looking_ at the coverage. "Oh, I thought I had that covered... that's interesting, I thought I had that error simulated but it didn't happen after all... oh, look, there's no possible way to ever enter those 125 lines of nasty-looking code _plink_."

Might I also add that I discover errors in the error-handling surprisingly often. Coverage testing goes a long way towards reminding you to check those too. What your code does in error cases is part of the spec.

Shooting for 100% may not always be the best use of time, but if you are writing unit tests you should at least look at the line-by-line coverage results. You've already done the hard work of writing the test suite, be sure to reap _all_ the benefits you can.

[1]: "critical" is, ahem, a _critical_ word here. I don't shoot for 100% on everything, but every even halfway sanely-designed system has a "core". Total coverage on the core has the dual benefits of assuring the core really does work as intended, and making it possible to refactor the core. It is a very common antipattern for the core to metastasize because without a test suite, all ability to modify it, even to fix bugs, is lost.

</comment></comment><comment><USER18> Coverage does not guarantee effectiveness. Lack of coverage guarantees the behavior of uncovered code is not checked.

Use the tool for what it is good at. It's not a substitute for code review or writing convincing tests. Granted even convincing tests are going to miss important stuff, but they will miss less and after the initial bout of bugs will become quite good (because you write regression tests for EVERY bug right?).

</comment><comment><USER19> I have a few objections to the evidence presented.

Keeping in mind that I don't disagree with the statement. Test coverage is an objective metric, and test Effectiveness is a... what is it again? How many bugs you'll find with it? Obviously the two are separate concepts.

This is my first objection: The paper seems to say that Mutation Testing is test effectiveness, but Mutation testing is merely another metric. They cite other papers, but papers that attempt to demonstrate that this metric is correlated with test "effectiveness".

Metric against metric, is that meaningful?

She presents graphs of results that seem to demonstrate linear correlation between test suite size/test suite coverage/and mutation testing (called "effectiveness") This is addressed later, "isn't this what we would expect?" yah! And the explanation for why it's unexpected sailed fully over my head. (I admit it! I'm dumb.)

finally, many test suites are generated on the presumption of achieving code coverage, is this test valid without also having test suites that were made without that goal in mind? Could such a suite exist?

so summary of my objections

* is mutation testing a meaningful measure of effectiveness?

* can you measure one metric against another another, get a linear relationship, and conclude any meaningful differences?

* does the presence of code coverage as a target spoil the conclusion?

I'd love to hear input on this.

<comment><USER8> Paper author here. We measured "effectiveness" as the mutation score. We showed in a separate paper that the mutation score is a good way to measure a test suite's ability to detect real faults. Of course, using the mutation score instead of the real fault detection rate does add a layer of indirection, but it's a lot more practical for a large empirical study (i.e., can be automated), so there's a bit of a tradeoff there. (The other paper is also on my website if you want to read it: [http://www.linozemtseva.com/research/2014/fse/mutant_validit...](http://www.linozemtseva.com/research/2014/fse/mutant_validity/))

What the graphs show is that effectiveness rises with suite size, which is expected: more tests catch more bugs. We also see that effectiveness rises with coverage, which seems intuitive: you can't catch bugs in code you never run. But when you graph effectiveness against coverage for suites that are all the _same_ size, the correlation drops significantly, in some cases to 0. Here's an analogy: the number of PhD students that graduate in the US is highly correlated with the amount of profit generated by arcades in the US, but there's no causal relationship between them. They probably both depend on the size of the population. Similarly, coverage and effectiveness are correlated because they both depend on the size of the suite, but we can't say that there's a causal relationship. In other words, saying that a suite will catch a lot of bugs because it has high coverage is like saying that a lot of PhD students will graduate because arcades turned a good profit this year.

Your third point is a really good question. It's true that developers don't write tests randomly, so our method of making new suites by picking random test cases isn't quite realistic. What impact that would have on the results, I'm not sure. That's something I'd like to look into in the future.

<comment><USER19> Thank you very much for the response! This paper is pretty interesting for sure.

It's just it doesn't have what I would consider good evidence that coverage isn't correlated with effectiveness. (or... I don't understand the section that explains it <:( )

What I would consider good evidence would be to demonstrate that _different_ test suites of the _same size_ and _different coverage_ achieve the same effectiveness.

* test suite A has a size of 300 sloc, and a coverage of 5%, effectiveness of ~8%

* test suite B has a size of 300 sloc, and a coverage of 12%, effectiveness of ~8%

That to me would be evidence of the stated conclusion, but I don't see where this is demonstrated (or where this is demonstrated, I don't understand). I do see where it is stated! Though... now that I have read through the paper a bit more thoroughly.

On the subject of normalized effectiveness.

      Suppose
      we are comparing suite A, with 50% coverage, to suite B, with
      60% coverage. Suite B will almost certainly have a higher
      raw effectiveness measurement, since it covers more code and
      will therefore almost certainly kill more mutants. However,
      if suite A kills 80% of the mutants that it covers, while suite
      B kills only 70% of the mutants that it covers, suite A is
      in some sense a better suite."

I don't believe a majority of people would agree with this. To me, this says coverage is positively correlated with effectiveness, and that suite B is doing more with less. Maybe that's a philosophical stand point? By normalizing, have you eliminated the premise?

Anyway, thank you for your time and work!

<comment><USER8> What you're looking for is in Figure 3 (admittedly a bit hard to read because I had to squish it into the paper). Each panel in that figure shows the results for test suites of a fixed size. For example, the top left panel shows the results for suites with three test cases for Apache POI. If you draw a horizontal line through the graph, all of the test suites that fall on that line have the same effectiveness score even though they have different coverage levels. I gave a talk about this paper at GTAC this year and Google posts all the videos on YouTube, so if you have time and you're still curious the explanation in the talk might help (and the graphs are much easier to read). [https://www.youtube.com/watch?v=sAfROROGujU](https://www.youtube.com/watch?v=sAfROROGujU)

The normalization was a point of contention with the peer reviewers as well, so in the end I tried both the normalized and unnormalized metrics and found similar results with both. The other tables and figures are available on my site if you want to look at them.

I'm not sure I understand what you mean when you say suite B is doing more with less, though. In the example, I was trying to say that suite B covers more code, so it will kill more mutants. Maybe suite A kills 20 mutants and suite B kills 25 mutants, just to have some numbers to talk about. But if B covers 50 mutants, and is only killing 25 of them, while A covers 25 mutants and kills 20 of the 25, it seems like suite A is doing a better job of testing the code it covers. Or to put it another way, suite B is broad but shallow while suite A is focused but deep. B isn't necessarily a bad suite, but I wouldn't say it's doing more with less, just that it has a different focus. Maybe I'm misunderstanding your point, though.

Another way of thinking about it is that the raw mutation score measures breadth: B is better than A because 25 > 20\. The normalized score measures depth: A is better than B because 80% (20/25) > 50% (25/50).

</comment></comment></comment></comment><comment><USER20> I'm biased (it's my research field, in part) but I'd suggest that studies on coverage are all over the place, with this one showing lack of correlation, and other studies showing good correlation between coverage and... some kind of effectiveness (the ICSE paper mentioned above, also from 2014, and a TOSEM paper coming out this year, as well as a variety of publications over the years).

[http://www.cs.cmu.edu/~agroce/onwardessays14.pdf](http://www.cs.cmu.edu/~agroce/onwardessays14.pdf) covers the Inozemtseva et al. paper as well as some other recent work, and nothing in the time since we wrote that has modified my view that the jury is still out on coverage, depending on the situation in which you want to use it. Saying "coverage is not useful" is pretty clearly wrong, and saying "coverage is highly effective for measuring all suites in all situations" is also clearly wrong. Beyond that, it's hard to make solidly supported claims that don't depend greatly on details of what you are measuring and how.

I suspect Laura generally agrees, though probably our guesses on what eventual answers might be differ.

</comment><comment><USER20> The SPLASH Onward! 2014 essay concludes with this advice to practitioners:

In some cases where coverage is currently used, there is little real substitute for it; test suite size alone is not a very helpful measure of testing effort, since it is even more easily abused or misunderstood than coverage. Other testing efforts already have ways of determining when to stop that don't rely on coverage (ranging from "we're out of time or money" to "we see clearly diminishing returns in terms of bugs found per dollar spent testing, and predict few residual defects based on past projects"). When coverage levels are required by company or government policy, conscientious testers should strive to produce good suites that, additionally, achieve the required level of coverage rather than aiming very directly at coverage itself [56]. "Testing to the test" by writing a suite that gets "enough" coverage and expecting this to guarantee good fault detection is very likely a bad idea — even in the best-case scenario where coverage is well correlated with fault detection. Stay tuned to the research community for news on whether coverage can be used more aggressively, with confidence, in the future.

</comment><comment><USER21> While I think it's well-agreed upon in this community that code coverage is not all that big a deal, I think we also should consider the methods used in this study before we all pat ourselves on the back for having 'proof' of what we know.

> we generated 31,000 test suites for five systems consisting of up to 724,000 > lines of source code

You auto-generated unit tests suites, and you're surprised they weren't very good at finding bugs? Well, no kidding, they were auto-generated! Would you trust your unit tests to be generated by a computer? Of course not.

Do a study of real-world software, and compare the unit test coverage to the Test Suite effectiveness. Then I'll be interested.

<comment><USER22> The unit tests are written by the programmers on each project, not generated by a computer. The test suites are generated by selecting a subset of the project's real-world test suite.

</comment></comment><comment><USER23> Maybe we need to write tests to cover the test suites? Why not? They are code too. Then they'll improve.

<comment><USER10> Yes, these are mutation tests. Riddler or some such for java. It modifies a part of your code and then if your tests that cover that code still pass, that's a clue that the test is not effective</comment></comment>