Joint Pain, from the Gut (2015) - <AUTHOR> http://www.theatlantic.com/health/archive/2015/01/joint-pain-from-the-gut/383772/?single_page=true <comment><USER2> Helicobacter pylori is blamed for increasing the risk of stomach cancer. My gastroenterologist treated me to get rid of it for this reason.

That being said, since 50% of the world's population have this in their gut, I'm starting to get the feeling that modern medicine doesn't have the entire picture with relation to the microbiome and their are making drastic decisions based on half that story.

It seems increasingly likely that the delicate balance of bacteria inside the gut, or more specifically its imbalance, is closely linked to a variety of autoimmune diseases.

The long term consequences of antibiotics, highly processed foods and sugars, alongside the corn phenomenon is not understood and could well be changing is for the worse.

<comment><USER3> The man who first made this connection with H. Pylori, Martin J. Blaser, thinks the same thing: [https://en.wikipedia.org/wiki/Martin_J._Blaser#Research](https://en.wikipedia.org/wiki/Martin_J._Blaser#Research)

He has a book on it too, "Missing Microbes". It's sad how much dogma there is in the medical community.

<comment><USER2> Interesting. Thanks for sharing that.

</comment></comment></comment><comment><USER4> "Finnish researchers found that a vegan diet changed the gut microbiome, and that this change was linked to an improvement in arthritis symptoms."

I had a suspicion when I started reading this article that the simplest solution would be to cut meat out of the diet.

It's astounding how many problems are solved medically, environmentally, economically, and of course ethically if we simply stop consuming meat, or at least stop consuming it at such extreme levels!

<comment><USER5> The question I wonder about -- and I speak as a non meat-eater -- is whether it is, indeed, the meat itself that is at fault, or the payload of antibiotics, growth hormones, colourants, preservatives, etc. that are the product of contemporary factory-style production of meat.

<comment><USER6> Those things are no doubt playing a huge role, but as a person increases their consumption of meat they may also be crowding out fiber. Fiber is substrate for the microbiome. Listen to what Dr. Justin Sonnenburg out of the department of microbiology & immunology at Stanford has to say about the importance of fiber... [https://youtu.be/gOZcbNw7sng?t=6m19s](https://youtu.be/gOZcbNw7sng?t=6m19s)

</comment></comment></comment><comment><USER7> There was a fascinating RadioLab episode on similar not too long ago.

There are indications, too, that these microbes may affect/control things like depression, bipolar, etc.

We may see some amazing medical breakthroughs in this area in the coming years

</comment><comment><USER8> FTA: "In another study published in October, Scher found that patients with psoriatic arthritis, another kind of autoimmune joint disease, had significantly lower levels of other types of intestinal bacteria."

But what if the bacteria were destroyed by the body first, after being targeted by the body's own immune defenses?

</comment><comment><USER9> I found this article very interesting. I suffer from RA and I can tell you that it sucks. It attacks more than just your joints. Things like minor coughs and colds will hang on for forever and make you vulnerable as you age. Scary stuff. Its good to know that there are possible treatments on the horizon.</comment>


Apple scraps €850m Irish data centre after planning delays - <AUTHOR> https://www.theguardian.com/technology/2018/may/10/apple-scraps-850m-irish-data-centre-after-planning-delays-ireland <comment><USER2> Couldn't have anything to do with Apple losing their tax dodge now could it?</comment>


New test of the gravitational 1/r2 law at separations down to 52μm - <AUTHOR> https://journals.aps.org/prl/abstract/10.1103/PhysRevLett.124.101101 <comment><USER2> A couple of us from the Eot-Wash group are active on HN. Happy to answer questions.

Hopefully the lead author (an HN-lurker, as far as I know) will jump in to bask in the limelight and answer your questions :).

<comment><USER3> This seems like the key result:

> We find that any gravitational-strength Yukawa interaction must have λ < > 38.6 μm. This implies that the dilaton or heavy graviton mass and the radion > unification mass must be greater than 5.1 meV and 7.1 TeV, respectively, and > that the largest extra dimension must have a toroidal radius less than 30 > μm. These are the tightest existing lab constraints on "string inspired" new > gravitational phenomena.

But the key words in it mean ~nothing to me :(

So do they do anything more than constrain parameters?

<comment><USER2> The first sentence above is, for a physicist, the key result. It says that, for the most common way one could modify gravity to incorporate a new force- mediator, the new interaction has to turn on at distances shorter than 39 microns.

At distances longer than that, these measurements show that gravity acts, and in a way that roughly follows the inverse-square law. (at distances of ~100 microns it very-much follows the ISL, and at distances longer than that, it _really_ follows the ISL).

The easy way to think about this result: we are on the cusp of showing that gravity acts over distances shorter than the width of a human hair. Only the finest human hairs are smaller in diameter.

For many years, my goal in life (see HN handle) was to push this limit below 10-microns. Turns out that is really hard to do :).

<comment><USER3> Thanks.

> ... and at distances longer than [100 microns], it really follows the ISL

But at cosmic distances, there's also evidence that gravity doesn't follow ISL, right?

Are there any implications of this work for hypothesized dark matter and dark energy?

<comment><USER4> You are probably thinking of galaxy rotation curves which do not agree with theoretical predictions that assume only visible matter exists.

Gravity not following the ISL at large scales would indeed be a possible explanation for this. However, most alternative theories of gravity clash with other observations, such as the motion of binary pulsars or gravitational waves, whereas (unmodified) General Relativity is in excellent agreement. This is one of the reasons why the existence of dark matter is considered to be a much better explanation for the deviation of the rotation curves.

<comment><USER3> Yes, I was.

But I know so little physics that the distinction between dark matter and extra terms in gravitation is unclear.

<comment><USER5> It's pretty simple. You can use the known laws of gravitation and the visible distribution of matter in a galaxy to predict how fast stars at the edge of the galaxy should move. But when we do this we find that the stars are moving much faster than expected. So EITHER the formula for gravity is wrong OR there is extra matter there which we can't see, i.e. dark matter. Dark matter is currently the preferred explanation because it also explains a bunch of other, unrelated, phonenomena, but it has as yet never been directly detected or measured.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> Ars Technica article about this: [https://arstechnica.com/science/2020/04/gravitys-inverse- squ...](https://arstechnica.com/science/2020/04/gravitys-inverse-square-law- tested-at-scale-of-a-human-hair-and-passes/)

</comment><comment><USER7> For those of us who don't have APS access, there's the preprint: [https://arxiv.org/abs/2002.11761](https://arxiv.org/abs/2002.11761)

</comment><comment><USER3> [https://sci-hub.si/https://doi.org/10.1103/PhysRevLett.124.1...](https://sci- hub.si/https://doi.org/10.1103/PhysRevLett.124.101101)

Also FYI: [https://sci-hub.now.sh/](https://sci-hub.now.sh/)

</comment><comment><USER8> First of all - very interesting work. I am gonna use the opportunity to ask question to authors directly. Keep in mind that I don't know a lot about gravity ;)

As far as I understand speed of gravity interaction is limited by speed of light. So my understanding is that the 1/r^2 law is only approximately true since real interactions are retarded. Is that correct? If yes then at what level (what order of magnitude) those corrections affect your result (I understand that at such short distances it's very minor but I suppose it can be an somehow is estimated)?

</comment><comment><USER9> Relevant to this: Quantized Inertia - [https://www.youtube.com/watch?v=1itasiXNUPg](https://www.youtube.com/watch?v=1itasiXNUPg)

<comment><USER10> Very interesting, in that it is falsifiable, it makes testable predictions, and it appears to fit a number of observations.

So is this just quackery or could there be something there?

<comment><USER9> I believe the author of this theory is working with some groups to run tests. Let's re-visit in five years?

</comment></comment></comment><comment><USER11> I wonder what scales string theories would expect? As in — is this getting uncomfortably close for string theory to manage or still orders of a magnitude away?

</comment><comment><USER12> Is it the new concern not when it is within 1/3 galaxy width but exceed that the law may change?

<comment><USER13> "New" a hundred years ago, yes. No one has been happy with our model of gravity since Newton's time, and people were only happy with it then because they didn't know any better.

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

</comment></comment><comment><USER14> Sounds like a really clever experimental setup. I hope there's a website that shows it off.

</comment><comment><USER15> I have a hard time believing how gravity could be measured at such a small scale. Is it possible to video record the experiment? Maybe with some layman explanation.

I would like to make my own gravity experimentation. Is this something I could do at home?

<comment><AUTHOR> >I would like to make my own gravity experimentation. Is this something I could do at home?

Best EVER definition of an optimist.

<comment><USER16> Many gravity experiments can be done at home

For example, drop an apple on their head

<comment><AUTHOR> Good point</comment></comment></comment></comment>


ATOM: 1 Year Open Source - <AUTHOR> http://blog.atom.io/2015/05/06/one-year-open-source.html

<comment><USER2> My experience of Atom after having been using it exclusively for the past 6 months or so: Awesome editor, even though the experience is definitely better on the powerful computer I have at work than on my personal 4-year old laptop. I like the plugins, I like the themes, how customizable everything is. The only aspect where I've found Atom to be dramatically inefficient is search/replace. Feed it a big enough file (and it doesn't even have to be THAT big) and the whole editor can freeze for minutes.

I am not sure I understand why that is, but I sure wish this is an area the community will help make better in the future.

A community that I would like to thank heartfully for their efforts and dedication, Atom has turned into a fine editor.

</comment><comment><USER3> Github's insight, that an easily hackable editor will get a vibrant ecosystem around it, has paid off a lot. Two large companies (Facebook and Microsoft) have adopted the underlying platforms and created powerful editors themselves (Facebook's Nuclide and Microsoft's VS Code).

Sure, with MS, their editor is their own component, but it's quite amazing that you can see two such products come out in just a year.</comment>


Does ad blocking herald the end of the free internet? - <AUTHOR> http://www.bbc.co.uk/news/business-34268416 <comment><USER2> Not even going to read this. Assumes websites exist sold for profit. Internet originally existed as a non-commercial medium. Sad that we forget so soon.</comment>


Ask HN: What has been the best career advice someone has ever given you? - <AUTHOR> Lets share, shall we? <comment><USER2> Don't be afraid to quit every few years. It's the most reliable way to get more interesting work and higher pay.

Whilst I expect this to plateau at some stage, it's worked out very well for the first decade-plus.

</comment><comment><USER3> This was told to me in my first year in school. When in doubt ask seniors and not sophomores.

<comment><USER4> That makes me smile. Love it.

</comment></comment><comment><USER5> Although I did not quite agree with it completely: look out for #1 because that is what everyone else is doing. It explains a lot of behavior in a corporate environment.

</comment><comment><USER6> ~'A good CEO never forgets how to clean the dishes.'

</comment><comment><USER7> If you get handed a turd, it's your job to polish it up and make it the shiniest turd out there.

</comment><comment><USER8> Emulate success, and modify it after you achieve your own success.

</comment><comment><USER9> "Plastics."

<comment><USER10> "Sunscreen"

</comment></comment><comment><USER11> Follow your passion.

<comment><USER12> Along those same lines...find a space you love and dive in. The idea and business model will change 50+ times, so if it's a space you're passionate about you'll figure out the win.</comment></comment>


High School Students Are Reading Books At 5th-Grade Levels - <AUTHOR> http://www.huffingtonpost.com/2012/03/22/top-reading_n_1373680.html

<comment><AUTHOR> There are lies, damned lies, and statistics.

I think this report is incredibly misleading. It may be a fact that the avg. reading level of the top 40 high school books is 5.3, but that doesn't really mean much. The most important sentence in the article is glazed over:

"While readability formulas can't say much for the depth of literary aspects within a text, they offer objective measures of vocabulary and sentence complexity."

So, in other words, the less "readable" a book is, the higher the competency of the person reading it. Doesn't make much sense.

As a big reader myself, I think it's this kind of cargo-cult thinking (higher readability level > better readers) that leads people, and teenagers in particular, to dislike reading. I know that was the case with me when I went to school. Now I read all the time, but hate books with complicated writing (aka high readibility scores).

<comment><USER2> Agreed! "Of Mice and Men" is ranked as a grade 4.5 book? "To Kill a Mockingbird" is grade 5.6. "Lord of the Flies" is grade 5.0. These are not books at an elementary school letter. The method used is simply inappropriate, which means the article was published with publicity strongly at the forefront. A real analysis would have shown the change in reading level over time. I and my wife read those books while in our respective high schools in the 1980s/1990s, and a quick search says that non-US high schools do the same.

</comment></comment><comment><USER3> I'm assuming they're talking both leisure and assigned reading? (I can't imagine schools assigning The Hunger Games, and I don't imagine many students leisurely reading Of Mice and Men.)

Maybe the solution is to push to popularize better books for older audiences? People read The Hunger Games and Harry Potter because they enjoyed them. Lots of early 20s people I know loved the Girl with the Dragon Tattoo, and while I don't know how complex of a rating it would get, I understand it's considered an "adult novel", and is thought of as smart.

So all we need is popular, smart written, books.

</comment><comment><USER4> Interesting. I was reading at a high school level when I was in 5th grade. I also read "The hunger games". I've been out of high school for 10+ years.

Is it well below my level? Yes, but it was a good story.</comment>


Amazon's Project Zero will let brands remove fake product listings - <AUTHOR> https://www.theverge.com/2019/2/28/18244603/amazon-project-zero-counterfeit-listing-remove-products <comment><USER2> Please make SanDisk one of the initial brands. Fake sd cards are the bane of my Amazon exisrance.

<comment><USER3> I just bought a bunch of these; how can you tell?

<comment><USER4> brew install f3

<comment><USER5> [https://github.com/AltraMayor/f3#installation](https://github.com/AltraMayor/f3#installation) \- for non mac users

</comment></comment></comment></comment><comment><USER6> How would it help to combat counterfeit items that end up in the sold by amazon category trough their supply chain?

Also I'm not entirely stoked about a DMCA claim like system for physical products, I have a feeling that it will be abused by some manufacturers of expensive crap to combat just as good cheap crap that don't necessarily fall under counterfeit.

<comment><USER7> Then those that are selling just as good cheap crap can make their own brands and do better. I've been burned every time I get a fake product, either the shirt doesn't fit, SD card doesn't work, the quality of the fabric is crap, etc.

</comment></comment><comment><USER8> Manufacturers need an easier way to sell and ship directly to the end customer, without Amazon in-between. That, combined with an unbiased 'directory' site that has legitimate customer reviews will be the end of Amazon and counterfeiting.

</comment><comment><USER9> Seems a bit late. Counterfeits have been rampant since 2015 at least.

<comment><USER10> Better to be late at addressing problems, than never. Though, it remains to be seen whether or not the problem is worse than the cure. Co-mingling of inventory from multiple suppliers is a huge threat to the security of the supply chain, and I don't see how permitting vendors to remove listings without going through an existing oversight process will address that.

<comment><USER11> > Better to be late at addressing problems, than never.

This doesn't actually address the FBA commingling counterfeit problem, so it is both late and misdirected.

</comment></comment></comment><comment><USER12> This doesn't solve the co-mingling problem which would immediately solve a lot of issues...

<comment><USER13> >Additionally, Amazon is offering an optional product serialization service for companies that would have them put a unique, Amazon serial code on their products during manufacturing that will then allow Amazon to scan and confirm that a given products is authentic before it ever leaves a warehouse.

If the manufacturer opts in to this serialization, as a customer, co-mingling wouldn't be an issue. If a co-mingled counterfeit item gets picked, it wouldn't leave the warehouse. The Amazon worker would then put the counterfeit item to the side and find a genuine one.

For the manufacturer/Amazon, it would still be difficult to find who shipped the fake item.

<comment><USER14> ... because it's impossible to just copy the serial code, too?

<comment><USER15> Maybe it's a use-once uuid-like code like things like gift cards use?</comment></comment></comment></comment>


Ask HN: If you are a postdoc, please read this. - <AUTHOR>

Hi HNers. In the past few weeks the web promoted a bunch of very interesting discussions about academic career paths and academic job market. Some of them were discussed further on these pages too.
I realized there is no data about what postdocs really want of their life and how prepare they feel they are and this make the discussions a bit less savvy. So I made a survey and I am inviting all of you who are postdocs, to fill it (it will take no more than 2 minutes).
You'll find it at http://thepostdoctrap.gilest.ro
Please share the form as much as you can if you have friends or colleagues who may be interested in the matter. Thanks a bunch! <comment><AUTHOR> Clickable link: <http://thepostdoctrap.gilest.ro></comment>


Google Spending Millions to Find the Next Google - <AUTHOR> http://www.nytimes.com/2011/07/20/technology/google-spending-millions-to-find-the-next-google.html?_r=1&partner=rss&emc=rss

<comment><USER2> Google can do this because they have too much cash on their balance sheet and the market demands a return on that cash. They need novel areas to invest for them to grow. But there is an alternative. I would prefer to see Google return cash to shareholders via a stock buyback and focus on their core: organizing the world's information.

This is not because I hold GOOG stock, just because I believe in that mission, think they still have a long way to go, and don't yet have the resources to tackle that problem myself.

I think as a smaller company revenue-wise and, ideally, as a private one they could have more long-term focus.

</comment><comment><USER3> _Google says the algorithms have taught it valuable lessons...(start-ups located far from the venture capitalist's office are more likely to be successful, probably because the firm has to go out of its way to finance the start-up.)_

Disagree.

Try this: Google's analysis of the venture capital industry shows that companies do better when it's difficult for their investors to meddle in their business on a day to day basis.

</comment><comment><USER4> Taking a look at Google's data set would sure settle a lot of arguments:

1\. Does age matter?

2\. How important it is to be in Silicon Valley?

3\. Are biz devs really important?

4\. Are cofounders really important?

<comment><USER5> The next Google is an outlier, you can't infer them from rules that give you few winners.

<comment><USER6> I wonder about this. Was Google itself an outlier? I don't think so. Indeed I'd say you probably could have discovered Google using similar metrics the article claims they are using, such as scholarly trends (but possibly not founder history).

<comment><USER5> Google was not an outlier, they were from Stanford, etc, etc. But it doesn't imply anything about the possibility to catch outliers, they can't catch them with those rules.

Even for non outliers, how can you catch Microsoft in front of casual opportunities (DOS) that gives them an amazing opportunity. Chance and Rules collides.

</comment></comment></comment></comment><comment><USER7> Google Ventures, like 500 Startups, is one of those funds that you have to be invited to pitch for?

<comment><USER8> I don't think you have to be invited. Though it's probably hard to get a meeting, just like it is with any VC.

Google Ventures is fairly similar to traditional venture capital, but with more support provided to portfolio companies. Andreessen-Horowitz is another VC that follows this model. Besides providing traditional VC help (money, intros, executive recruiting, advice), GV and A16Z have operating folks on staff that can help portfolio companies with things like HR, Bizdev, engineering recruiting, UX, etc.

</comment></comment><comment><USER9> It's mostly a journalistic device, but the notion of the next ______ (Google, Scorcese, insert popular thing) is flawed. There won't be a next ______, and that is okay.

</comment><comment><USER10> spend millions to save billions.. sounds about right

</comment><comment><USER11> the problem isn't finding "next" Google per.se. The main problem for a corporation at the life stage Google is at is to not allow the "old" (very successful, thus having a lot of clout, inertia and generally looking back instead of forward) Google to kill the "next" one when it is brought in.

</comment><comment><USER12> Not surprising that Google would be on the hunt for the next hit among startups. We've seen them do it within their own products, ala GMail, Google Maps, Google Voice, etc. Tech companies don't tend to stick around unless they move with the times, and of all companies I'd bet Google knows it.

</comment><comment><USER13> The next Google is "IBM's Watson" patched in through your smart phone so someone can punch in a natural language question and get back a reasonable natural language response from a simulated person with IQ of 5000.

If you can build even a primitive version of this deployed well, it would be the Google-killer. Have it answer everything from 'how do you make a for loop in php' to 'what cinemas near 32807 are playing Cars 2'? I don't want pages of links, I want concise understandable objective correct answers.

<comment><USER14> Did you mean Wolfram Alpha?

<comment><USER15> PowerSet.

<comment><USER16> Which got bought by Bing...

</comment></comment></comment></comment><comment><USER17> At Google's revenue aren't losses kinda a good thing? (tax right off) I mean as good as losses can be. Does this give them an advantage against other VC's? and if so any idea on how much?</comment>


Our Logo Looks Like Underpants: A Case Study in Internationalization (2013) - <AUTHOR> https://blog.rjmetrics.com/2013/10/09/our-logo-looks-like-underpants-a-case-study-in-internationalization/ <comment><USER2> This is why I think anyone doing a rebrand, logo change, etc... should forego regular focus group testing and such, and instead get a group of teenage boys.

They will immediately see if your logo is a dick/butt/boobs/swastika/etc... or if your company name can be taken in a "more vulgar manner"

<comment><USER3> My mom is a strong believer that every expecting parent should poll other kids about names for their baby. She asked her young nephews about potential names when she was pregnant and immediately threw out the ones they made fun of.

<comment><USER4> Having previously been a teenage boy, I'm not sure there's really any benefit to discarding names that might get made fun of. Having your name mocked is a pretty inconsequential thing, and probably better than being mocked glfor your physical appearance or mannerisms.

If kids want to make fun of somebody, they'll find a way. There's always something.

<comment><USER5> Right, but a name is one of those things that can actually be decided ahead- of-time; no sense in giving the little shits _more_ ammo with which they could mock your kids.

That is, unless your goal is to "toughen them up" via the "boy named Sue" strategy.

</comment></comment></comment></comment><comment><USER6> Good, entertaining read.

>It appears that y-fronts are a uniquely British phenomenon whose popularity doesn't extend far past their borders.

I don't think you can make that statement after sending a survey only to people in USA and UK. I'm Australian and I definitely see Y-fronts in the original logo.

Edit: I thought I'd add an interesting point. In medicine we include "Y-fronts" in the mnemonic to help us remember the order and direction of structures in the femoral triangle.

[https://radiopaedia.org/articles/femoral-triangle- contents-m...](https://radiopaedia.org/articles/femoral-triangle-contents- mnemonic)

<comment><USER7> Ha amazing, maybe this guy shouldn't be writing to non-US audiences. Or maybe his next article can be "A Case Study in responding to A Case Study in Internationalization (2013)"

There are more than 2 countries out there, and more than 2 countries that speak english.

</comment></comment><comment><USER8> I once tried to sell a software library as a product. Bad timing, concept, and execution, so it flopped. The thing I remember most is putting the phrase "slam dunk" in my initial product announcement. I took a lot of flack about that from non-Americans. That wasn't so bad, but I let that very temporary error distract and derail my marketing efforts, and _that_ was a mistake. Personally, I'd have stuck with the underwear logo and put that energy elsewhere.

</comment><comment><USER9> I have three letters for you if you think this can't happen within your own borders: OGC

<comment><USER10> Link for reference: [https://www.telegraph.co.uk/news/1901656/OGC-unveils-new- log...](https://www.telegraph.co.uk/news/1901656/OGC-unveils-new-logo-to-red- faces.html)

Including this gem:

>A spokesman for OGC said: "It is true that it caused a few titters among some staff when viewed on its side, but on consideration we concluded that the effect was generic to the particular combination of the letters OGC - and it is not inappropriate to an organisation that's looking to have a firm grip on Government spend."

<comment><USER11> Can't beat British humor.

</comment></comment></comment><comment><USER12> Discussed in 2015: [https://news.ycombinator.com/item?id=10499578](https://news.ycombinator.com/item?id=10499578)

And in 2013: [https://news.ycombinator.com/item?id=6521138](https://news.ycombinator.com/item?id=6521138)

<comment><USER13> From their website, looks like they eventually went back to something close to the original design (and which, really, looks even more like underpants now):

[https://rjmetrics.com/](https://rjmetrics.com/)

<comment><USER14> they should run a survey in france and be surprised how respondents answer "slip kangourou"

<comment><USER15> That's pretty close to a codpiece ;)

</comment></comment></comment></comment><comment><USER16> The punny section headers are a treat:

"A Brief Problem"

"Getting to the Bottom of This"

"But Y?"

<comment><USER17> More inside the article (not sure if the last 2 were intended):

"it's a bit of a stretch"

"lingering question"

"laundry list"

</comment></comment><comment><USER18> While from my cultural bias, I cannot see any "Y pants" in the dodecahedron, the logo of Magento BI (next to "Magento" at the upper left corner of

> [https://rjmetrics.com/](https://rjmetrics.com/)

and also the logo shown in the tweet) looks like - how should I express it - "a hanging male reproductive organ" to me. The four sides of the hexagon surround the region of pubic hair.

<comment><USER19> And funny enough their updated main logo on the top left with the extra accents looks exactly like stylized football/soccerball.

<comment><USER18> > And funny enough their updated main logo on the top left with the extra > accents looks exactly like stylized football/soccerball.

Perhaps I studied too much mathematics that I cannot see a truncated icosahedron

> > [https://en.wikipedia.org/w/index.php?title=Truncated_icosahe...](https://en.wikipedia.org/w/index.php?title=Truncated_icosahedron&oldid=848140851)

which is the typical pattern of a soccer ball

> > [https://commons.wikimedia.org/wiki/File:Football_Pallo_valmi...](https://commons.wikimedia.org/wiki/File:Football_Pallo_valmiina- > cropped.jpg)

in a docecahedron:

> > [https://en.wikipedia.org/w/index.php?title=Regular_dodecahed...](https://en.wikipedia.org/w/index.php?title=Regular_dodecahedron&oldid=851508454)

:-)

</comment></comment></comment><comment><USER20> My personal favorite was the 5 1/4 inch floppy disk brand name: Janus

The first time I saw one of these laying on my desk with the first letter "J" covered up...well, I could never unsee it.

<comment><USER21> One previous employer, an analytics company, had their website's title set to "<Company Name> Analytics". It just so happened that at my browser's default tab width, this title showed up as "<Company Name> Anal..."

</comment></comment><comment><USER22> Could be much worse:

[https://www.boredpanda.com/worst-logo-fails- ever/](https://www.boredpanda.com/worst-logo-fails-ever/)

<comment><USER23> I'm pretty sure at least a couple of those were intentional.

</comment></comment><comment><USER24> Ummm... it's not just Internationalization you need to worry about. Sometimes you should look at the logo from all angles. Literally, in the Office of Government Control's case...

[https://www.telegraph.co.uk/news/1901656/OGC-unveils-new- log...](https://www.telegraph.co.uk/news/1901656/OGC-unveils-new-logo-to-red- faces.html)

</comment><comment><USER25> Story reminds me of Yandex.Browser logo, which looked for many like a woman thongs on a ball: [https://hsto.org/getpro/geektimes/post_images/11e/fe1/9bb/11...](https://hsto.org/getpro/geektimes/post_images/11e/fe1/9bb/11efe19bbb12e3d088ac3767fa251fe8.png)

</comment><comment><USER26> Based on the title alone I assumed this was gonna be about Daewoo. Their logo is regularly compared to a pair of tighty whities (TIL they are also known as y-fronts).

[http://www.carlogos.org/Car-Logos/Daewoo- logo.html](http://www.carlogos.org/Car-Logos/Daewoo-logo.html)

</comment><comment><USER27> I grew up in the UK and have never heard of this y front term before, I wonder if it's regional. I have heard of briefs and tight whiteys. Based on my experience people in the U.K. will take the mickey/piss out of things like this more in general regardless of what it is.

<comment> cup-of-tea I grew up in the UK and we just called them "pants". Pants are far superior to boxer shorts but totally unfashionable for some reason. Now people wear "boxer briefs" which are like more fashionable pants that look a bit like boxers.

<comment><USER27> That's what we called them.

</comment></comment></comment><comment><USER28> Wait.

"UK schoolchildren sometimes tease each other with insults like "I bet you wear y-fronts.""

Why is it an insult? I'm wearing it now, and I'm sure it's quite common here (not UK/US).

<comment><USER29> Because there's an implication of childishness (yes, amongst children), that one might be mollycoddled by one's parents who do not let them move on to more seemingly "adult" underwear such as boxer shorts.

</comment></comment><comment><USER30> Not exactly a logo, but check out the "Hitler kettle", which was disturbing and funny at the same time.

[https://www.telegraph.co.uk/news/worldnews/northamerica/usa/...](https://www.telegraph.co.uk/news/worldnews/northamerica/usa/10084348/Kettle- that-looks-like-Hitler-brews-trouble-for-JCPenney.html)

<comment><USER31> I had a similar reaction the first time I was stuck driving behind a Megabus: [https://i.imgur.com/Xpm7vN2.jpg](https://i.imgur.com/Xpm7vN2.jpg)

<comment><USER32> There's a UK comedian who created a show around trying to get people to view the moustache as Chaplin's instead of Hitler's [0].

[0]: [https://www.independent.co.uk/arts- entertainment/comedy/revi...](https://www.independent.co.uk/arts- entertainment/comedy/reviews/richard-herring-hitler-moustache-underbelly- edinburgh-1773849.html)

</comment></comment></comment><comment><USER33> it looks more like sport bra than underpants

</comment><comment><USER34> hahahaah, man you're hilarious! You should consider writing comedy blogs! I was chuckling all through out the article

"I bet you wear y-fronts" hahahaha - it is something that I heard a lot growing up in the UK (and for the record, yes..no, I didn't wear them)</comment>


Clojure.spec – Rationale and Overview - <AUTHOR> http://clojure.org/about/spec <comment><USER3> This is an important move for the Clojure language. As with all dynamic languages, and exarcerberated by the fact that it encourages relying on data first - as opposed to say, classes in other languages - Clojure puts the onus on the developer to catch errors in data.

The clojure community as a whole embraced prismatic's schema as a way to provide occurence typing for data. Since library authors often tend to reduce their dependency surface, most libraries do not ship with it though.

With the inclusion of this in clojure core, it will now be possible to provide occurence typing at the edge of functions instead of tracking malformed input deep inside apps.

The racket-type contract notation is also a very welcome change from other similar approaches in my opinion.

[1]: [https://github.com/plumatic/schema](https://github.com/plumatic/schema)

<comment><USER4> Agreed that this is a big step, but what is being included in core is very distinct from Prismatic Schema. For example the way keysets vs values are handled is intentionally different from schema.

The rationale is a good read.

<comment><USER5> > The rationale is a good read.

Hickey's design choices consistently appear to be exceptionally well reasoned.

<comment><USER6> It's because of the hammock time.

</comment></comment></comment></comment><comment><USER7> Luckily Common Lisp already has ways to do that:

Functions have defined keyword argument lists and can have type declarations which for example a compiler like SBCL can partially check at compile-time.

Common Lisp uses for anything more complex than lists of keyword value combinations CLOS classes, which form a multiple inheritance hierarchy and types for slots.

That way I can look into a debugger at runtime and see what functions are actually supposed to receive and what these collects of keyword/value maps actually mean (since they are CLOS classes).

Having simple lists as maps was popular with assoc lists in the 70s - basically the same as hash tables, but slower. Then lots of dynamic object systems were developed which were in essence dynamic key/value sets. Later various object systems appeard, with CLOS as a local maximum.

Where Rich Hickey points to RDF, there is a lot prior art in Lisp as well -> Frame systems / description logics / ....

[http://wilbur-rdf.sourceforge.net/docs/ivanhoe.html](http://wilbur- rdf.sourceforge.net/docs/ivanhoe.html)

[http://franz.com/agraph/racer/krss- spec.pdf](http://franz.com/agraph/racer/krss-spec.pdf) and zillion others

CLIM, the Common Lisp interface manager, uses 'presentation types' to specify user level data structures...

</comment><comment><USER8> Clojure, with its dabbling in schemas and rule systems / logic programming (as a substitute for conditional statements) and thanks to its great tools (like figwheel or devcards), could really be establishing a cheaper, "as-good" alternative to static typing and full formal verification.

Instead of encoding constraints as type signatures, the Clojure folks (true to character) encode them in data. In my eyes a very interesting, pragmatic trade-off between expressiveness and automatic verifiability.

<comment><USER9> > dabbling in schemas and rule systems / logic programming (as a substitute > for conditional statements

That sounds interesting. Could you elaborate or post a link?

<comment><USER8> As a side note in his talk "Simple Made Easy" ([https://www.infoq.com/presentations/Simple-Made- Easy](https://www.infoq.com/presentations/Simple-Made-Easy), around minute 42) Rich Hickey mentions, that conditional statements are complex, because they spread (business-)logic throughout the program.

As a simpler (in the Hickey-sense) alternative, he lists rule systems and logic programming. For example, keeping parts of the business logic ("What do we consider an 'active' user?", "When do we notify a user?", etc...) as datalog expressions, maybe even storing them in a database, specifies them all in a single place. This helps to ensure consistency throughout the program. One could even give access to these specifications to a client, who can then customise the application directly in logic, instead of chasing throughout the whole code base.

Basically everyone involved agrees on a common language of predicates explicitly, instead of informally in database queries, UI, application code, etc...

But Hickey also notes that this thinking is pretty "cutting-edge" and probably not yet terribly practical.

<comment><USER10> It can work. My current company uses a rule system to represent most of our business logic since it is so dynamic. The downside is that we have to rebuild the entire graph into memory (times the number of threads, times the number of app servers) every time anything changes (which is constant).

Facebook wrote about rebuilding a similar system in Haskell that only changes memory incrementally, so it's definitely possible to do better.

<comment><USER8> Interesting note, thank you. Are you referring to "Sigma" [https://code.facebook.com/posts/745068642270222/fighting- spa...](https://code.facebook.com/posts/745068642270222/fighting-spam-with- haskell/) ?

<comment><USER10> That's the one.

</comment></comment></comment></comment></comment></comment><comment><USER11> > spec has been designed from the ground up to directly support generative > testing via test.check. When you use spec you get generative tests for free.

Great, I've been holding out on digging into the test.check generator syntax... looks like my laziness paid off!

<comment><USER12> It's still worth digging in! There are times when you will want to write your own generators.

</comment></comment><comment><USER13> It's unfortunate that Rich Hickey (assume he's the author) can't write this without trolling about type systems. It's pretty clear to anyone who's read the literature, or has thought for a few moments, that contract systems provide different guarantees to type systems, so no need to poke at type systems throughout the Guidelines.

<comment><USER14> It's quite annoying, but he definitely has a tendency to do this, though I wouldn't go so far as to call it 'trolling' per se. I think he's more sort of speaking to the 'in-group' and that can often be quite off-putting for people who are not members of that group because all the "but..." caveats are missing.

Btw, remember 'transducers'? He did the exact same thing there and claimed (in so many words) that it couldn't really be done in a typed language until people showed that, yes, it really could be done in a typed language such as Haskell. I suspect it's because he just doesn't know enough Haskell and couldn't get the type signatures to work. However, it's a big leap from "I cannot figure out how to do it" to "It cannot be done" and it requires a wee bit of (probably 'well-earned') arrogance to make that leap. :)

<comment><USER12> Rich provided the Haskell translation at [https://www.reddit.com/r/haskell/comments/2cv6l4/clojures_tr...](https://www.reddit.com/r/haskell/comments/2cv6l4/clojures_transducers_are_perverse_lenses/cjjyay7). His point was that some aspects of transducers were not possible to capture well in a type signature.

<comment><USER15> Some aspects, as in: not possible to describe state machines by types.

This is a well known problem, an active subject of research actually. Add asynchrony in the equation and you're out of luck. And transducers can also have asynchronous behavior.

<comment><USER14> > Some aspects, as in: not possible to describe state machines by types.

I _really_ don't understand this, I mean:

        data TrafficLight = Red Int
                          | Green Int
                          | Yellow

(let's assume that you have a flexible traffic control system which permits chaning the duration of Red/Green due to live traffic data, but Yellow _must_ always be, say, 5 seconds because the safety requirements say so.)

Add a function

        nextState :: Input -> State -> State
        nextState = ...

and you're done. Am I missing something?

 _EDIT_ : Oh, I think I see what you're saying. This doesn't provide _that_ many guarantees at the _type_ level about state _transitions_ , but I'd counter that: a) You have other options than "Int", so you could manage valid states more strictly, and b) There's such a thing as Dependently-Typed languages, say Idris, so you can go even further. Then, perhaps Dependently- Types languages was what you meant by "active subject of research". I'd probably agree on that :)

> Add asynchrony in the equation and you're out of luck.

Not sure how that's to be interpreted? Are you talking about asynchronous updates to state, or...?

> And transducers can also have asynchronous behavior.

Is there a formal description of what semantics they have in that scenario? Or are we just going by implementation details?

EDIT: I should say: I'm not being faceitous or going for any kind of 'gotcha' type thing here. I'm really curious; maybe I'm just misunderstanding your post.

<comment><USER16> I'm as clueless as you are about that asynchrony business, but would like to point out that you are not fully describing your state machine within the type system unless the typechecker prohibits you from defining (nextState Yellow == Green).

<comment><USER14> That would be an invalid definition since you _must_ provide an (integer) parameter to Green. Effectively you must "magic" a default value for what happens when Yellow goes to Green.

(Obviously in my sketched scenario the value would really come from Input.)

<comment><USER16> That's true. My point was just that your type definition does not tell the compiler/typechecker that the light, if it is currently yellow, must become red before it can become green.

That's a rule of the state machine and, if the compiler doesn't stop you from writing a function that breaks that rule then your state machine has not been modeled fully within the type system.

I'm pretty sure this is what Hickey et al mean when they say that Haskell's type system is not powerful enough to describe a state machine.

<comment><USER14> > That's true. My point was just that your type definition does not tell the > compiler/typechecker that the light, if it is currently yellow, must become > red before it can become green.

Ah, yes, I understand what you mean now, but you _can_ actually encode that if you _really_ want to. (If we assume Haskell, there's very limited DT programming which will probably let you state which transitions are legal. I must admit I'm not very up-to-speed on it, but see the next paragraph.)

The thing is that people usually don't want to go that far. Whether you're working in a typed scenario or not. In the unityped scenario, you _can 't_ go that far without reinventing a (run-time?) type-checker.

> That's a rule of the state machine and, if the compiler doesn't stop you > from writing a function that breaks that rule then your state machine has > not been modeled fully within the type system.

> I'm pretty sure this is what Hickey et al mean when they say that Haskell's > type system is not powerful enough to describe a state machine.

Certainly this is true, but if you're in an entirely unityped setting... do you have _any_ guarantees?

(To which the answer is, of course, "no".)

Foregoing _all_ guarantees just because you can't guarantee _everything_ seems... rash. (I believe this is the position that Hickey takes, for better or worse.)

Obviously, that's why _I_ , personally, prefer languages with multiple types.

Note: I _do_ think there are geniune scenarios where unityped may win out, e.g. "generic data transformation without knowing anything about the structure", but there's even "typed" answers for that, e.g. lenses. For my money -- and I'm obviously semi-joking -- ekmett >> hickey :)

<comment><USER17> > Certainly this is true, but if you're in an entirely unityped setting... do > you have any guarantees?

This is what clojure.spec is all about. The answer is not, of course, "no". They are "reinventing a run-time type checker" and _prefer_ it that way because it allows increased expressive power at the cost of delayed verification.

> Ah, yes, I understand what you mean now, but you can actually encode that if > you really want to. (If we assume Haskell, there's very limited DT > programming which will probably let you state which transitions are legal. I > must admit I'm not very up-to-speed on it, but see the next paragraph.)

So you don't actually know how to do it, but assume that you can. This a little strange. Are you sure that "people usually don't want to go that far"? Because the real answer is probably "it's too hard to do".

By the way, you probably want linear types in order to encode state machines in the type system in a natural way, which Haskell does not have.

<comment><USER18> > reinventing a run-time type checker

It's not a runtime _type_ checker, but a spec (not a type[1]!) that tools can use to check in different ways.

\</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment></comment><comment>

[1]: A spec is a proposition; a type is a judgment (that corresponds to a proposition). E.g., you can have a type: `data A = 1 | 2 | 3`, and `data B = 3 | 4 | 5`, but then testing `a < b` (assuming `a:A b:B`) may not be straightforward (depending on the language), while a spec of `A = {1, 2, 3}, B = {1, 2, 3}, a ∈ A, b ∈ B` does let you test `a < b`.

<comment><USER14> Types _are_ propositions. See Curry-Howard.

<comment><USER18> Types _encode_ propositions (see Curry-Howard) but are logical _judgments_ in the language's logic. The expression `a:A` does not have a boolean truth value (like a logical proposition), but is rather a judgment. In my example above, the value of the expression `a ∈ B` is true iff a = 3 and false otherwise, but the expression `a:B` is just not a well-formed expression. In other words, you could create a type that corresponds to a proposition, but type assignment is distinct from a proposition (e.g. the proposition `b1 < b2`, assuming `b1,b2:B`) in the language.

More precisely, you could say that types encode propositions at the type level (even if the language allows the same data-level syntax in type definitions, as in Idris), while propositions at the data level are distinct, while specs are data level propositions.

<comment><USER19> `x:T` is a _typing judgment_. A typing judgment is not a type, even if one of its constituent parts (`T`) is a type.

What you call "data-level propositions" is really just "data-level abstract syntax representation of propositions". Propositions _really_ are types. (Though, of course, there are types that are not propositions.)

And your example is simply not valid Haskell.

<comment><USER18> > A typing judgment is not a type

You are absolutely right. `x` is a proof object of `T` in the logic induced by the language, but I didn't want to get to that level of technicality, just to show the difference between data-level propositions and type-level ones. That's why I added the second paragraph, but in the process confused matters; sorry.

> Propositions really are types.

Types have a syntactic meaning that determines the well-formedness of an expression. Once you talk about types, you must talk about a language; a type cannot exist without a language because it is a syntactic construct, but a proposition can: it is a set (of programs, or Turing machines if you like; people in the verification community may say it's a set of states in a Kripke structure). Now, you could say that given the proposition (or the set) _P_ , you can construct type P in language L that expresses it, but P would still not be a data-level expression in L. You can then argue about whether or not this matters, but you can't deny that the two expressions of proposition, i.e., the dynamic `x < 10` and `T`, are distinct and "live" in two separate worlds. When data-level propositions are concerned, this is not the case. E.g., in TLA+, an untyped logic (TLA+ZFC), the program and the propositions are the very same objects and not at all just a "data-level abstract syntax representation of propositions".

> And your example is simply not valid Haskell.

It wasn't meant to be (I haven't written a Haskell program in over 15 years). Sadly, unlike standard logic and set notation, there isn't a standard notation for typed LC with data types, or any typed logic for that matter (not one that I'm familiar with), so you have to use something with a meaning people would understand or define a syntax every time.

<comment><USER19> > but a proposition can: it is a set

Set theories are normally built _on top_ of the apparatus of logic, so a proposition can't be a set.

> (of programs, or Turing machines if you like; people in the verification > community may say it's a set of states in a Kripke structure)

Ah, I see. You aren't talking about general propositions. You're talking about assertions about program states that can be checked dynamically, but want to verify statically. You can't represent an arbitrary proposition as a data structure, but it's of course a-whole-nother matter if you can decide the proposition's truth value by evaluating a Java expression of type `boolean`. The `boolean` expression itself is still not a proposition, though.

> but you can't deny that the two expressions of proposition, i.e., the > dynamic `x < 10` and `T`, are distinct and "live" in two separate worlds.

Most programming languages don't have propositions at all, for a very good reason: a proposition is the type of a programmer-supplied proof that has no runtime computational relevance, and how to integrate proofs into programming is still a research question whose answer language designers can't wait for. In Java, "the dynamic `x < 10`" is just a `boolean` expression - not a proposition!

> E.g., in TLA+, an untyped logic (TLA+ZFC), the program and the propositions > are the very same objects and not at all just a "data-level abstract syntax > representation of propositions".

In TLA+, or any other external program logic, the program itself is just a syntactic object. And by extension so is any `boolean` expression the program might contain. OTOH, if Java had propositions, you could carry out your reasoning internally, side-stepping the need to encode propositions as abstract syntax for a metalanguage to see.

<comment><USER18> > Set theories are normally built on top of the apparatus of logic, so a > proposition can't be a set.

You don't need a set theory. P is a "naive" set. It's well defined no matter what, because TMs are a recursive set, and P is just a RE subset. You're not in danger of running into any sharp edges.

> The `boolean` expression itself is still not a proposition, though.

I'm not sure what you mean by that, but I think we're talking past each other. That boolean expression is not a proposition _about the program_ \-- that is correct -- but the distinction may be artificial. You may be used to languages where there's a clear distinction between program properties and program code, but if you think about it, that distinction is artificial. For example, the expression `IF x > 0 THEN x ELSE -x` can be understood to be a program description taking the absolute value, but it can also be a proposition, or a description of the set of programs returning the absolute value of their input. Your language may use the same expression in both cases, yet still make a distinction about its meaning based on where it is used. Another language (like TLA+) has no such distinction.

> a proposition is the type of a programmer-supplied proof that has no runtime > computational relevance

That's _your_ definition. For me, a proposition about code is a set of TMs with a property (in particular, safety properties are a closed set of TMs, and liveness properties are dense etc. etc.). Its truth value is whether your program is in this set or not. To be more precise, a proposition to me is a sentence in any logic denoting that set.

I think my definition is both more encompassing and more precise than yours. It is more encompassing because every proposition by your definition is a proposition by my definition; it is more precise because the converse may not be true (although, again, I'm not certain about what your definition really means, its ties to a specific language, or whether or not it applies only to denotational semantics of programs).

> has no runtime computational relevance

I'm not sure what you mean by that. Does the proposition "the program returns a list containing exactly the same elements in its input, each appearing the same number of times, only in sorted order" has a runtime computational relevance or not?

> In TLA+, or any other external program logic, the program itself is just a > syntactic object.

TLA+ is not an external program logic, but a complete logic -- i.e. a TLA+ expression can describe any unique and arbitrary TM, or a set of them -- and there is no difference between a program and a proposition about a program in TLA+. The program is certainly not a syntactic element in TLA+ (certainly no more than any proposition is a syntactic element). Conceptually, in TLA+ you can describe the set of all programs that perform quicksort (it can be more than one; TLA+ allows nondeterminism) and then ask whether quicksort implies sorting, or, in other words, whether the set of quicksort programs is a subset of all programs that sort their input. Both the program and the proposition are logical expressions (describing a set of TMs, if you will), and you may then try to prove that one implies the other (or any logical combination of the two):

 _In a quest for minimality and orthogonality of concepts, TLA+ does not formally distinguish between specifications and properties: both are written as logical formulas, and concepts such as refinement, composition of systems or hiding of internal state are expressed using logical connectives of implication, conjunction, and quantification. Despite its expressiveness, TLA+ is supported by tools such as model checkers and theorem provers to aid a designer carry out formal developments._ [1]

[1]: [http://www.loria.fr/~merz/papers/tla+logic2008.pdf](http://www.loria.fr/~merz/papers/tla+logic2008.pdf)

<comment><USER18> P.S.

If you think about it, the conjunction of all true propositions about your program _is_ the program (modulo the equality semantics of your logic). This is true whether or not your program is deterministic, or, in the case of LC, is a collection of state machines, depending on the evaluation strategy). Conceptually, then, there is no difference between a program and the true propositions about it. Some languages make a syntactic distinction between the two (Haskell), some languages use similar syntax but different semantics (Idris), and some make no syntactic or semantic distinction (TLA+): your program _is_ a logical sentence (a conjunction of axioms, if you will), from which all true propositions about it can be derived (and, obviously, only those). A program _is_ the complete axiomatization of all true propositions about it[1].

[1]: This may get more tricky if intuitionistic logic is used, where the program is actually the proof object of all true propositions, but I think that even in intuitionistic logic, the distinction may be artificial: a proof may be no more than a hidden proposition.

<comment><USER19> There's so much that's wrong with this comment. You're either ignorant of formal logic, or deliberately trolling. If the former: being ignorant isn't a crime, but pretending you know what you don't know is uncivilized. If the latter: of course trolling is uncivilized. Let's keep things civilized, okay?

> If you think about it, the conjunction of all true propositions about your > program is the program (modulo the equality semantics of your logic).

This doesn't even make sense. A program can be run. What does it mean to "run a proposition"? Even if I charitably interpret that as "decide its truth value", well, not all propositions are decidable!

> your program is a logical sentence (a conjunction of axioms, if you will),

What you can treat as a bunch of axioms is the semantics of your programming language of choice. But a program isn't the same thing as the language it's written in.

> the distinction may be artificial: a proof may be no more than a hidden > proposition.

This isn't true in either classical or intuitionistic logic. A proposition has a truth value - a proof does not.

<comment><USER18> > Let's keep things civilized, okay?

Formal verification of large, very complex real-world systems is what I do all day every day. If you don't understand what it is that I'm saying (and that's my fault -- I'm probably not clear enough) you can just ask. I'm a practitioner, not a theoretician, so I may make mistakes, but I think that in this particular case you are too attached to the typed LC to consider other reasoning systems (which, BTW, happen to be far more prevalent in the verification community).

> This doesn't even make sense. A program can be run. What does it mean to > "run a proposition"?

Let's step back and consider the theory and then get to the specifics. Consider the set of all TMs (perhaps TMs isn't the best name because it may imply a specific programming model, but that is not my intent; I'm using the term here interchangeably with an abstract state machine, or a program). Each and every one of them is "runnable", right? Each and every subset of that set also consists of TMs, which are also runnable, right? A proposition about a TM constitutes such a subset. Under certain conditions, you can incorporate all DTMs in the set corresponding to the proposition into a single NDTM, which can also be run. Hence, there is a direct correspondence between propositions about programs (e.g., the program returns its input sorted) and NDTMs. Hence, you can most certainly run a proposition about programs (though perhaps not all propositions).

The temporal logic of actions (TLA) is a _complete_ logic in the sense that for every NDTM (or a DTM as a special case) there exists a (non-unique) TLA expression, consisting of the simple logical connectives, the priming operator (an action) and possibly LTL operators (describing say, fairness, properties) that describes that particular TM. But, of course, a TLA expression can be less precise, and describe a whole set of TMs -- a proposition. Therefore in TLA, propositions and programs are the same object. Here's Lamport in the opening paragraph introducing TLA in the 1993 paper[1]:

 _Correctness of [an] algorithm means that the program satisfies a desired property. We propose a simpler approach in which both the algorithm and the property are specified by formulas in a single logic. Correctness of the algorithm means that the formula specifying the algorithm implies the formula specifying the property, where implies is ordinary logical implication._

FYI, that paper has 2458 citations and is far from obscure. This theory is much better known in the software verification community than type theory (certainly when you consider it within the greater framework of temporal logics, of which TLA is one), and has had a greater impact -- both academic and real-world -- on formal methods, at least so far. Specifying programs as propositions in temporal logics was a modern theoretical turning point in CS, and has yielded two or three Turing awards (Pnueli in '96, Clarke et al. in '07, and Lamport -- at least partly for this -- in '13).

> Even if I charitably interpret that as "decide its truth value", well, not > all propositions are decidable!

This is where things are a bit tricky. For a complete treatment see the preliminaries section in this '88 paper by Abadi and Lamport[2].

> A proposition has a truth value - a proof does not.

Of course, but there's room for interpretation here (like I said, I'm not a type expert so I'm not 100% sure about it): `<x = 3, y = 5>` can be viewed as a proof object of the proposition `∃x,y ∈ 1..10 . x < y`, but it can also be viewed as the more precise proposition, `x = 3 ∧ y = 5`. Existential propositions (or types) can therefore be viewed as a set of multiple programs, while the proof object is a particular program, that could have been specified with a more precise proposition. That is what I meant when I said "hidden proposition".

If you step back from typed LC and consider the original proof objects, those objects are just a series (a tree, actually) of logical deductions. Each of those deductions is a proposition. A proof is, therefore, a series of true propositions, each derived from the previous one using one of the deduction rules. You can certainly say, then, that a proof is a collection of hidden (true) propositions.

[1]: [http://research.microsoft.com/pubs/64074/lamport- actions.pdf](http://research.microsoft.com/pubs/64074/lamport-actions.pdf)

[2]: [http://research.microsoft.com/pubs/64046/abadi- existence.pdf](http://research.microsoft.com/pubs/64046/abadi-existence.pdf)

<comment><USER19> > Consider the set of all TMs (...) Each and every one of them is "runnable", > right? Each and every subset of that set also consists of TMs, which are > also runnable, right?

This much makes sense.

> A proposition about a TM constitutes such a subset.

A unary _predicate_ whose argument ranges over TM may have such a subset as its _extension_. Two syntactically different predicates may have the same extension.

> If you step back from typed LC

At this point I'm not even talking about types. I'm talking about deductive systems in general.

> and consider the original proof objects, those objects are just a series (a > tree, actually) of logical deductions.

This part is correct.

> Each of those deductions is a proposition.

Propositions exist inside of a logic, deductions exist in the logic's metatheory. There oughtn't even be the possibility of conflating them.

> A proof is, therefore, a series of true propositions, each derived from the > previous one using one of the deduction rules.

A deduction is a series of _judgments_ related by rules of inference. But a judgment is _not_ a proposition!

<comment><USER18> > A unary predicate whose argument ranges over TM may have such a subset as > its extension.

Yes, but now we can talk about a specific logic/language, and now it matters exactly how the NDTM is expressed syntactically. E.g. in TLA (and LTL, or CTL for that matter) `[](x ∈ {1,2,3})` means "the variable x in the program is always in 1..3", or (semantically) "the set of all TMs where x is always in 1..3". x is a name given to a variable in an infinite set of variables defining the abstract machine's state (i.e. a state in TLA is defined to be an assignment to the infinite set to all possible variables), and the existence of the machine (or a Kripke structure, if you will) is implied. If you only supply a proposition on variable x, it means that all other (infinite set of) variables can take any value.

You can read about TLA/TLA+ in one of the links I provided to get the specifics (it's extremely easy to pick up, BTW). In any event, a proposition in TLA can be thought of as a predicate over a(n implicit) TM. You may also find this short note by Lamport about the history of TLA/\+ (and in particular the unification of temporal-logic propositions and programs) interesting[1].

> Two syntactically different predicates may have the same extension.

True, I didn't say the syntactic representation is unique. Also, in TLA it's no longer just a predicate but any proposition.

> There oughtn't even be the possibility of conflating them.

I am not conflating them, and I'm not saying a proof _is_ formally a proposition. I'm saying that in intuitionistic logic, a proof (especially of an existential quantification) may be also interpreted as a more precise/limited proposition. But this is just a vague notion, and it could be completely wrong (even if I were able to communicate it clearly), so I see no point in debating this.

[1]: [http://research.microsoft.com/en- us/um/people/lamport/pubs/c...](http://research.microsoft.com/en- us/um/people/lamport/pubs/commentary-web.pdf)

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> Could someone explain what the paragraphs under "Map specs should be of keysets only" are getting at?

I'm trying to map it onto my experience with Clojure and plumatic/schema, but nothing is clicking.

<comment><USER12> Generally in most of the existing libs like Schema you specify that a "person entity" is a map that has particular attributes that have particular properties and a "company entity" is a map that has other attributes (some of which might overlap).

In spec, you specify that a first-name attribute is a string and an email attribute matches some regex. Those are specifications about the attributes and can be used across many entity types. A person entity spec is then defined as a map that contains a set of required or optional attributes. A company entity spec is a different map with different attributes, some of which might be shared with a person (like email address).

This is in many ways a shift in perspective, allowing you to start defining and reusing attribute specs to a much greater degree.

The use of structural systems with mathematical properties (regular expressions for sequence structure and sets for map keys) turns out to have many useful effects in computing error sets, etc.

<comment><USER21> The division -- between predicates for attribute values vs. specs for maps/seqs -- is interesting because AFAICT Datomic schemas ~= the former, while leaving the latter to your app? (Although I guess :db.cardinality/many straddles that line.)

</comment></comment></comment><comment><USER22> Those regular expressions for sequences seem related to "Efficient dynamic type checking of heterogeneous sequences", or maybe some other prior work I don't know about.

See [https://github.com/jimka2001/regular-type- expression](https://github.com/jimka2001/regular-type-expression) and [http://www.lrde.epita.fr/dload/papers/newton.16.rte.report.p...](http://www.lrde.epita.fr/dload/papers/newton.16.rte.report.pdf)

</comment><comment><USER23> Incidentally, the source is here: [https://github.com/clojure/clojure/blob/master/src/clj/cloju...](https://github.com/clojure/clojure/blob/master/src/clj/clojure/spec.clj)

</comment><comment><USER24> I enjoy using racket and contracts make it quite enjoyable to use - <USER2> messages in particular are much improved by their presence. Looking forward to this!

</comment><comment><USER25> If you are new to using a snapshot of clojure (like me), you can find some helpful information here: [http://dev.clojure.org/display/community/Maven+Settings+and+...](http://dev.clojure.org/display/community/Maven+Settings+and+Repositories)

tl;dr

      In a Leiningen project.clj file:
      :repositories {"sonatype-oss-public" "https://oss.sonatype.org/content/groups/public/"}

      Also, in that lein project file, reference clojure as
      [org.clojure/clojure "1.9.0-master-SNAPSHOT"] (1.9.0 being the dev head right now)

<comment><USER26> This won't work with Cider btw. I had to change it to 1.9.0-SNAPSHOT in pom.xml before a mvn install.

      error in process filter: version-to-list: Invalid version syntax: '1.9.0-master-SNAPSHOT'
      error in process filter: Invalid version syntax: '1.9.0-master-SNAPSHOT'

<comment><USER25> Interesting. It works for me, but I'm using a dev snapshot of cider too.

Having -master- in there is pretty non standard, but I was poking in oss.sonatype.org and that's what the jar looked like in there. Maybe I goofed. There is a little bit of magic that happens with maven and snapshots (magic to me anyway).

</comment></comment></comment><comment><USER27> Excellent. This definitely looks to be an improvement over schema, which I use but don't particularly like. Though, I'm fairly new to Clojure (about a month or so), so it may just be my inexperience :)

</comment><comment><USER28> > Defining specifications of every subset/union/intersection, and then > redundantly stating the semantic of each key is both an antipattern and > unworkable in the most dynamic cases.

This is the reason I haven't jumped on the Schema bandwagon. Surprised to see I'm not the only one who had reservations about it.

> Finally, in all languages, dynamic or not, tests are essential to quality. > Too many critical properties are not captured by common type systems.

Glad to see some acknowledgement of the need for at least some tests from Rich, who previously critized TDD, saying that you don't keep a car on the road by banging into the guardrails, and advocated H(ammock)DD.

> But manual testing has a very low effectiveness/effort ratio. Property- > based, generative testing, as implemented for Clojure in test.check, has > proved to be far more powerful than manually written tests.

(Assuming by manual testing he means manually writing automated tests,) I can't help but wonder if he came to that conclusion by writing the _wrong_ tests and, naturally, finding them unhelpful.

> Enable and start a dialog about semantic change and compatibility

Okay, slightly rant-y tangent, but out of all the fluff phrases and buzzwords I've ever heard, "start a dialog" is probably the worst offender, and I wish it was wiped from the English language.

> I hope you find spec useful and powerful.

Looks useful so far. But where's the Github repo? Or is it coming in the next version of Clojure? Or, like, how/when can we use it?

<comment><USER29> Rich was never against testing, he was against TEST DRIVEN development, and thats what TDD stands for.

</comment></comment><comment><USER30> This is awesome. Is it available for clojurescript too ?

<comment><USER31> From Alex Miller via slack:

> will be in cljs as well, but not on first release

> most of the code should work as is, most of the tricky bits are around vars

</comment></comment><comment><USER32> >The basic idea is that specs are nothing more than a logical composition of predicates.

This reminds me of this technique:

[https://github.com/astoeckley/Eat-Static#going- further](https://github.com/astoeckley/Eat-Static#going-further)

</comment><comment><USER33> I'm confused what a function spec would look like using fdef (etc). Can someone write an example?

If in Haskell we have a type signature

f :: Type1 -> Type2

...what will a clojure function spec roughly look like?

<comment><USER12>
      (spec/fdef clojure.core/range
        :args (spec/alt
                :infinite (spec/cat)
                :range-0  (spec/cat :end number?)
                :range    (spec/cat :start number? :end number?)
                :step     (spec/cat :start number? :end number? :step number?))
        :ret #(instance? clojure.lang.Seqable %))```

<comment><USER33> Interesting. I don't know what to think. It's a lot to read. But in some ways adds more information than types (you can make reference to values). Maybe you could make it more concise with more definitions? For example:

        (def UnboundedInterval (spec/cat))
        (def PositiveUnboundedInterval (spec/cat :end number?))
        (def ClosedInterval (spec/cat :start number? :end number?))
        (def StepClosedInterval (spec/cat :start number? :end number? :step number?))
        (def SeqableInstance #(instance? clojure.lang.Seqable %))

And then:

        (spec/fdef clojure.core/range
            :args (spec/alt
                    :infinite UnboundedInterval
                    :range-0  PositiveUnboundedInterval
                    :range    ClosedInterval
                    :step     StepClosedInterval
            :ret SeqableInstance)

Perhaps this would be non-idiomatic, and perhaps I'm trying to make this into something that looks like a static type annotation when it _isn 't_.

<comment><USER19> > (you can make reference to values)

Dependent types let you do just that as well. While theoretical computer scientists for the most part focus on dependently typed systems capable of expressing and proving any mathematical proposition (which obviously results in increased complexity), there exist more pragmatic variants of dependent types aimed at solving the everyday needs of programmers, with a minimum of annotation burden, see: [http://hackage.haskell.org/package/liquidhaskell](http://hackage.haskell.org/package/liquidhaskell)

</comment></comment></comment></comment><comment><USER34> clojure.spec is available in 1.9.1/alpha1 via [org.clojure/clojure "1.9.0-alpha1"] in your project.clj.

There is an excellent guide available here: [http://clojure.org/guides/spec](http://clojure.org/guides/spec)

</comment><comment><USER33> Will there be performance hits to using this?

</comment><comment><USER35> This site could really benefit from a custom stylesheet for printing. Having to delete lots of nodes with devtools just to get a printable doc.

<comment><USER12> Noted. Won't get to it anytime soon though. [https://github.com/clojure/clojure- site/issues/99](https://github.com/clojure/clojure-site/issues/99)

</comment></comment><comment><USER36> I'm waiting for the day somebody with write a Clojure transpiler for a non- Lispy syntax! Although I love Lisp (I used to use it 20+ years ago daily), but the year is 2016!

<comment><USER15> Not sure what the year has to do with anything, but most things in computer science were invented in the sixties and the seventies or even earlier and since then we've only been refining them. In terms of programming languages, the theoretical breakthroughs have been in terms of static typing, even though note that even the Hindley-Milner type system has been first described in 1969.

In other words, strange thing to complain about a syntax that has stood the test of time. After all, most mainstream languages (C, C++, Simula, Pascal, Java, etc) are Algol-based, a language that first appeared in 1958. And no, you can't have LISP without its syntax, because that's what's giving it power. The " _code is data_ " mantra only works because Lisp is homoiconic, because it basically has no meaningful syntax other than syntax for describing its primitive data-structures, which makes its macros first class and its "eval" natural.

But in the LISP family Clojure is actually quite modern. It runs on both the JVM and Javascript engines. It does have extra syntax for describing sets and maps. Its data-structures are immutable and it encourages immutability to a far larger degree than other LISPs. But it also has very good interoperability with the underlying platform.

<comment><USER37> > And no, you can't have LISP without its syntax, because that's what's giving > it power. The "code is data" mantra only works because Lisp is homoiconic

No. Homoiconicity is nice for "code is data" and macros, bot not necessary. Being able to reify and generate ASTs is sufficient. See for example Dylan, Terra/Lua, Scala LMS, MetaML, or Julia's or Rust's macros.

<comment><USER15> Note sure what you're arguing against. I stand by my claim.

I'm actively working with Scala's macros and played with Scala LMS. In fact working with those convinced me of how much all LISP alternatives suck for expressing macros.

Do you know why? Because in these languages macros are not first class, hence (1) they tend to be an afterthought, (2) hard to use and (3) filled with bugs because, wouldn't you know, they are targeting "library authors" and not users.

Scala's macros for example are exposing the compiler's internals. And boy, I can tell you stories. Like how it wants an "untypecheck" call on the AST if you modify it, because those ASTs happen to be mutable (the horror), but then "untypecheck" has a bug in it, crashing the compiler if you have an implicit "unapply" in a pattern match, so you have to rewrite your AST first to get rid of implicit "unapply" calls to work around it. Behold Sincron, an otherwise simplistic library, for which it took me a whole month to achieve inlining Function0 literal arguments, with help from others and copy/pasted code, between cries that I crashed the compiler, again and again: [https://sincron.org](https://sincron.org) \- and btw, this rewrite for getting rid of unapply, this was the still-dangerous shortcut I took, because the general consensus at this point is that if you want to workaround the bugs of "untypecheck", you need to fix that AST manually.

You can't blame Scala too much really. This is definitely preferable to hacking your own compiler plugin or to forking the compiler. And eventually beautiful solutions can emerge from that.

The alternative to something like this is to expose a limited form of macros. For example F# quotations, or Rust's macros, since you mentioned those. The problem with these macro systems is that they are very limited, only applicable to a narrow set of use-cases. Sorry, but I personally think Rust's macros are next to useless as they needlessly complicate the language without that big of a gain. And the irony is that macros are basically used for error- handling in Rust. You know, if they added higher-kinded types, there wouldn't have been such strong demand for those macros in the first place.

LISP is the only language (family) exposing macros to users.

<comment><USER38> The standard library contains many macros that are not about error handling: [http://doc.rust-lang.org/stable/std/#macros](http://doc.rust- lang.org/stable/std/#macros) Only try! is, specifically. vec!, write!, panic!, and println! are also very popular.</comment></comment></comment></comment></comment>


Show HN: TweetFull – an automated Twitter marketing and branding tool - <AUTHOR> http://tweetfull.com

<comment><USER2> Just put in a test, will check back with comments in a few days.

</comment><comment><AUTHOR> Would love to hear if you guys have a feature request.</comment>


Is anyone else experiencing rapidly increasing health care costs? - <AUTHOR> If you're over 50, it seems the health insurance companies are raising rates every 2 or 3 months now. For 2 of us, we expect to pay $900 for a PPO plan soon, $800 now. <comment><USER2> Yes, never had so many collection notices in the mail for hospital visits, lab work, etc.. that I simply lost track of. I am extremely diligent when it comes to paying bills on time, but these just got out of hand.

Was paying $1200 a month for family of 4.

Why is this not discussed more?

</comment><comment> atom-x Only $900? My partner and I are both under the age of 50 had to pay over $1200/mo this year for a personal plan with BCBS without ridiculous deductibles. This was an increase from ~$1100/mo from just 6 mos ago.

</comment><comment><USER3> i've seen my health care plan go from $300 to $400 to $560 for the last 3 years. for this coming year, i'm seeing quotes for $700. These were platinum PPO's for single male in 30s.</comment>


Homoiconicity isn't the point - <AUTHOR> http://calculist.org/blog/2012/04/17/homoiconicity-isnt-the-point/ <comment><USER2> Here's a duplication of the comment I made on the site. I speak as if I'm speaking directly to the author.

\---

> it's possible to read it without parsing.

Yes, it's possible to perform lexical analysis without parsing too.

> the front end of every interpreter and compiler looks pretty much the same: > [diagram]

You forgot the step where lexical analysis occurs. This is akin to what Lisp's READ does. Except the output isn't a stream of tokens, it's a tree of tokens. So, actually, even superficially, Lisp and $OTHER_LANGUAGE front-ends are not all that different.

> it knows nothing about the contents of the expression. All it knows is the > macro definition of for.

This is because the `for`-statement is akin to a special form in Lisp. When Scheme encounters IF, and assuming it doesn't get transformed into a COND, then what does it do? It does not pass the arguments to some IF macro. IF is fundamental.

> What should the expander do when it sees: quux (mumble, flarg) [1, 2, 3] { > foo: 3 } grunch /wibble/i

It expands it. The expander should not see a stream of characters, as you show in that example, it should see a tree. The expander does not care what the original stream of characters was, nor should it.

READ isn't the point. READ is a way of turning a stream of characters into a data structure. The only time an expander cares about the stream is when it's a reader macro, like in Common Lisp. Otherwise, once the stream has been converted into some tree-like structure, syntax is gone. It just so happens we can convert the tree back into syntax in a standard way (most of the time, at least).

This is what makes Lisp/Scheme different from C. Macros in C operate on streams of characters, and do string insertion and deletion. This isn't true with Lisp, which does node insertion/deletion/manipulation on a tree. In other words, Lisp makes changes to structure/semantics, not syntax.

> If you've ever wondered why Lisp weirdos are so inexplicably attached to > their parentheses, this is what it's all about. Parentheses make it > unambiguous for the expander to understand what the arguments to a macro > are, because it's always clear where the arguments begin and end.

No, it's not that Lisp weirdos are attached to parentheses. They're attached to regularity. As said above, the expander doesn't give a single flying fsck about parentheses. An expander could expand DOTIMES[{x, 5}, SETQ[a, a+5]] just as well as it could (DOTIMES (X 5) (SETQ a (+ a 5)). In fact, Lisp started as this first syntax (to a degree), and it worked fine. See the book Anatomy of Lisp, which is written entirely using this syntax.

The field of lexical analysis and parsing is well developed. Lexers and parsers can amazingly be written in a way that things aren't ambiguities to the computer. Maybe to the human, but not the computer.

In conclusion, I do think homoiconicity is the point: that the language's representation as a data structure is accessible and transformable. The stream of characters used to represent this structure does not matter at all.

<comment><USER3> I replied in a comment on my post, but Disqus is having issues today and anyway I want to say a bit more.

>> What should the expander do when it sees:

        quux (mumble, flarg) [1, 2, 3] { foo: 3 } grunch /wibble/i

> It expands it. The expander should not see a stream of characters, as you > show in that example, it should see a tree.

This is the point: what tree? How many arguments does `quux` have? The answer isn't obvious, because `quux` isn't surrounded by any pair of delimiters. The net result: there isn't a clear way to write a JavaScript "lexer" that produces trees---i.e., a reader. JavaScript's syntax was not designed with this in mind, so there isn't a clear tree structure inherent in the syntax.

(And even if you solve that problem, there are aspects of the JS syntax that depend on knowing the parsing context, such as whether

        grunch /wibble/i

lexes as an identifier followed by a regexp literal or identifier-slash- identifier-slash-identifier. So the number of sub-nodes is not even clear until you expand enough to know what context that fragment appears in.)

These are all issues you'd have to sort out to figure out how to make JS amenable to macros. But what it amounts to is figuring out how to design a reader for JS. Or at least, if you wanted to design a Lisp-like macro system for JS, you would.

The point is, the fact that Lisp macros operate on trees (though syntactic trees, not "semantic" trees as you claim---that's a debate for another day) is directly enabled by being able to generate a tree rather than a stream of tokens from the reader. And that's only possible because the syntax was designed to support that. There's of course not just a single unique syntax that has this property, but Lispy languages have syntaxes that are designed to support a reader, and that's at the heart of what makes the Lisp approach to macros work.</comment></comment>


Walled Garden 2.0 - <AUTHOR>

Did Amazon, with the release of Kindle Fire, just raise the stakes for the requirements of a walled garden that Apple, Google and Facebook will try to match? "Machine Learning. Finally, Silk leverages the collaborative filtering techniques and machine learning algorithms Amazon has built over the last 15 years to power features such as "customers who bought this also bought…" As Silk serves up millions of page views every day, it learns more about the individual sites it renders and where users go next. By observing the aggregate traffic patterns on various web sites, it refines its heuristics, allowing for accurate predictions of the next page request. For example, Silk might observe that 85 percent of visitors to a leading news site next click on that site's top headline. With that knowledge, EC2 and Silk together make intelligent decisions about pre-pushing content to the Kindle Fire. As a result, the next page a Kindle Fire customer is likely to visit will already be available locally in the device cache, enabling instant rendering to the screen." <comment><USER2> For those who remember the original AOL fat client, AOL 2.0 would have worked as a title for this post too.

<comment><USER3> I'll wait for the Facebook laptop.</comment></comment>


Why Demand Generation Can Be So Challenging for Startups - <AUTHOR> https://www.linkedin.com/pulse/why-demand-generation-can-so-challenging-startups-tomasz-tunguz?trk=hp-feed-article-title-like <comment><USER2> So when you are an entrepreneur, generating demand for your product after the initial penetration to early adopters submarket is more an issue of understanding the sociology of your overall market and the risk aversive inclination of the later adopters. This is similar to "selling" a programming language or a library of useful functions. It seems some kind of analysis of historical behaviour by people is an essential part of successful demand generation. Is there a science of this?</comment>


Google App Engine 1.4.0 release will fix spin-up delay for JRuby. - <AUTHOR> http://jruby-appengine.blogspot.com/2010/11/app-engine-prerelease-sdk-140.html

<comment><AUTHOR> If you pay. Otherwise, a one-minute cron is still an effective solution.</comment>


Wit.ai (YC W14) raises $3M seed round from Andreessen Horowitz - <AUTHOR> https://wit.ai/blog/2014/10/15/wit-ai-raises-seed-round-from-andreessen-horowitz <comment><USER2> Congrats on the round!

I'm curious how you differentiate yourself from the built-in speech APIs on iOS and Android? [https://developer.apple.com/library/mac/documentation/Cocoa/...](https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Speech/Articles/RecognizeSpeech.html) [http://developer.android.com/reference/android/speech/Speech...](http://developer.android.com/reference/android/speech/SpeechRecognizer.html) [http://developer.android.com/reference/android/speech/Recogn...](http://developer.android.com/reference/android/speech/RecognizerIntent.html)

I'm a little biased (I used to work on the Google speech team), but it seems very hard for a startup to compete on the basis of accuracy, and for wearables like watches it's pretty clear both Google and Apple are putting third-party APIs for voice interfaces (including command-like syntaxes) front-and-center. A lot of earlier speech/NLP startups have struggled with this dynamic-- although an aggressive, well-executing team can get a year or so ahead of the platform, if you do something too close its core competency, eventually Google/Apple will build the same feature directly into the operating system, and then you're stuck competing with a team of 100+ PhDs with a 1000x distribution advantage. At least, that's what would give me hesitation about building a speech/NLP API startup in 2014.

I also noticed you're running a conference on voice interfaces ([http://listen.ai/](http://listen.ai/)). I'm not sure if you're well- connected to the speech folks at Google/Microsoft/Apple, but if you decide you want somebody from Google to speak, I'd be happy to ping some of my former colleagues on your behalf. Looking at the agenda, I think the areas where they could provide coverage is the core technology--acoustic modeling, deep learning, hotword detection, or embedded recognition.

<comment><AUTHOR> Thanks for these excellent remarks.

We differentiate ourselves from the Android Speech API in several ways:

1) As a developer, with Google you have no way to customize the speech engine by providing your language model. Wit.ai builds a specific, customized configuration for each app. If your app is specific and you cannot tell Google what kind of thing it should expect, accuracy will be bad especially in noisy environments. Wit.ai builds a specific language model for each app automatically and in real time (each time Wit.ai learns more examples about your app, it's updated), and queries several speech engines in parallel. To do that it uses not only your data, but also relevant data from the community. This is the core of our value proposition and not something Google does provide today.

2) Google keep their Natural Language Understanding layer (what translates text to structured, actionable data) for themselves. Developers cannot access this. They're left with free text, but they often need actionable data.

3) Wit.ai is cross-platform. We have SDKs for iOS, Android, Linux, etc. [1] or you can just stream raw audio to our API. Android Speech API is just available on Android (well, you could hack it and use it from elsewhere but you're not supposed to, and you can be shut down anytime). More and more wearables and smart devices will run Linux. For instance hundreds of developers use Wit.ai on Raspberry Pi.

As for the Apple doc you linked, it's Mac only (no iOS) + it just recognizes a few phrases you provide in advance. I think it's a very old API that's still here :)

Regarding listen.ai, yes please we would love to have Google (especially Now) there. We have the Siri founder, the top Cortana guy, the former CEO of Nuance... but nobody from Google yet.

[1] [https://wit.ai/docs](https://wit.ai/docs)

<comment><USER3> Any chance listen.ai will either be livestreamed or videos made available later (a la confreaks or similar)? I can't make it, but I'm super interested in ALL of this and really, really want to learn.

<comment><USER4> +1, also really interested.

</comment></comment></comment></comment><comment><USER5> A week ago Mark Suster wrote an interesting article about the definition of a "seed round":

> If it looks like an A-round, smells like an A-round & tastes like an A-round > … it's an A-round. My personal definition? It is less about actual money and > more about structure of your Cap Table. If you have raised $2-4 million from > a bunch of high-net-worth individuals I simply don't see it as an A-round. > If you raised $2 million from two small seed funds I probably don't either > (although in the past I would have). But if you raised $3-5 million from > well-known seed funds or from a VC and you're asking for $8-10 million in > your next round … that next round is a B-round no matter what we > collectively decide to call it when we VCs fund you.

<comment><AUTHOR> My personal definition of a seed round is a round where you don't give up any board seat or special power to investors. After a seed round you should basically work as usual (product, users, product, users, ... nothing else). By this definition, our round qualifies as seed. Managing a board takes time and energy and the more you can delay this, the better (from my experience).

That being said, this is a very subjective notion and everybody is free to have their own.

</comment></comment><comment><USER6> Congrats to the Wit.ai team! Not sure there are any other companies laser focused like this (NLP + IoT).

@ar7hur The pricing page[1] shows that the Community (free) plan allows unlimited queries, but the Starter plan is limited to 250 queries per day.

Did you mean that unlimited queries are still allowable to any open instances, while the query limit is only restricted to the three private Wit instances? If so, I recommend another footnote on your pricing page to clarify this distinction.

[1] [https://wit.ai/pricing](https://wit.ai/pricing)

<comment><AUTHOR> Yes open instances are free and unlimited. This is the cornerstone of our approach: we want developers to work together and share their training data. Natural Language is _very_ hard and we need to join forces to crack it.

Thanks for the feedback, we'll try to make this easier to understand on the pricing page (yeah, natural language generation is hard for humans, too!)

<comment><USER6> Awesome thanks! Also, the other ambiguity is whether the private instance query limits are per instance, or total aggregate across all private instances.

<comment><USER7> Great feedback again, the query limit is the total aggregate across all the private instances of a user

</comment></comment></comment></comment><comment><USER8> Fun fact: "Wit.ai" can be pronounced just like "Witaj" in Polish, which means "Welcome/Hello". Dunno if this is intentional or even acknowledged by founders. ;-)

<comment><USER9> One of the founders is named Laurent Landowski. Could this be a Polish name? Polish also looks to be in beta for them, which is one of only a handful of languages they support.

<comment><USER10> I've met him -- he and three other members of the team are French!

<comment><USER9> I guess the Laurent should have given that away, but I figured "Landowski" sounded a bit Polish.

</comment></comment></comment></comment><comment><USER11> Wow, congrats on the round! Looks like an amazing service. Will be trying it soon for a project I'm working on, Android speech APIs aren't quite cutting it.

Can this be run continuously from a Service on Android? Didn't see a mention of it in your docs, but I've yet to play with it.

</comment><comment><USER12> Nice! I have been telling everyone since I found out about Wit several months ago how awesome it is. Excited to see what they offer in the future!

</comment><comment><USER13> Amazing. Perfect example of when Peter Thiel says that the best investments are in companies not easily categorized. That test works here imo

</comment><comment><USER14> The guys at Wit are awesome and are a great group to work with. Definitely glad to see them raise that round. Congrats!

</comment><comment><USER15> Congrats! Great job!</comment>