Schneier on UAE to Ban BlackBerrys - <AUTHOR> http://www.schneier.com/blog/archives/2010/08/uae_to_ban_blac.html

<comment><USER2> Bonus feature: "For the record, I have absolutely no idea what this quote of mine from the Reuters story really means".

<comment><USER3> It means the person listening to Bruce had absolutely no idea what he was saying so when s/he paraphrased it, they just took words out.

<comment><USER4> And they complain that journalism is a dying profession.

</comment></comment></comment><comment><USER5> Related: In 2009, Etisalat prompted its UAE BlackBerry users to install a surveillance application disguised as a performance update[1]. The update resulted in crashes and lowered battery life resulting in RIM to issue its own update to remove it.

[1]: <http://news.bbc.co.uk/2/hi/8161190.stm>

</comment><comment><USER6> Schneier and WSJ seem to put an emphasis on the concept of government interest in monitoring its citizens (or subjects in the U.A.E. I guess). The internal motivations for this action may be different. For example, maybe the U.A.E. sees BB as a bit of critical infrastructure that they don't want other countries to be able to monitor.

First article: "The U.A.E. acted after RIM refused to set up a proxy server in the country as required by its 2007 contract with telecom provider Emirates Telecommunications Corp., a majority of which is owned by the government, according to the person familiar with the situation."

Second article: "The U.A.E. wanted RIM to locate servers in the country, where it had legal jurisdiction over them; RIM had offered access to the data of 3,000 clients instead, the person said."

<comment><USER7> It can also have other legal implications. We (a non-US company) just got informed by legal that we shouldn't email copies of our patents internally because our email supplier is in the US - and any of our patents could be regarded as US property.

So a contract sent on a Blackberry between two UAE parties - could come under Canadian law.

</comment></comment><comment><USER8> _> RIM makes a big deal about how secure its users' data is, but I don't know how much of that to believe:_

It sounds like RIM is describing normal public key encryption. I'm not sure why Schneier thinks they have the plaintext, though admittedly "customer data" could refer to anything.

<comment><USER9> Since you're presumably entering the data (i.e., email text) using a BlackBerry device, running an RIM-developed operating system, device drivers and so on, RIM most likely "have" your data.

At least that was how I interpreted it, and it makes sense to me.

<comment><USER10> Especially considering on the other end your email comes out as plain text (it's not a requirement to send to other BB devices). Perhaps their messager service works completely encrypted, but as far as emails go that's surely not the case.

</comment></comment></comment><comment><USER11> He makes an excellent point about that nonsense 'even we at RIM don't see the unencrypted data' which RIM seems to think convinces people. How can makers of the software doing the encryption not know the plaintext?

<comment><AUTHOR> By not having control over the endpoints where the data is encrypted and decrypted, and being trustworthy.

Microsoft don't have the plaintext of Windows user's SSL encrypted web browsing, but they could if they changed their software to send them the plaintext too.

</comment></comment><comment><USER12> How would a startup go about selling monitoring services to the UAE government?

<comment> brown9-2 Considering that the traffic is encrypted between the devices and RIM's servers, you'd have to try to 1) break the encryption or 2) gain access to RIM's internal network, and 3) check your morals at the door. Good luck.

<comment><USER12> I wasn't asking specifically about this situation. I was considering niche markets like P2P. I know the government blocks torrents but I have seen many clients on the Gnutella network that are from the UAE.

</comment></comment></comment><comment><USER13> RIM should sit tight and do nothing, IMO. Those 500,000 users are likely to be the most important movers and sheik'ers in the Saudi kingdom. When their Blackberry service goes dark, the government absolutely will be held accountable.

</comment><comment><USER14> To be completely honest, I think this is a ploy by RIM to make them seem insanely secure. So secure that paranoid countries want to ban them because they can't evesdrop on their people.</comment>


Toba catastrophe theory - <AUTHOR> http://en.wikipedia.org/wiki/Toba_catastrophe_theory <comment><USER2> Is this apropos of some discussion I missed, or just a cool "Today I Learned" link?

I actually read this particular article just a week ago (Baader-Meinhof, etc.) when following links for another cataclysmic event: <http://en.wikipedia.org/wiki/Manicouagan_impact_crater>

It still amazes me just what an incredible resource Wikipedia is.

<comment><USER3> It lacks some paleoalignment pictures to illustrate the facts.

See [http://ars.els- cdn.com/content/image/1-s2.0-S092054460800003...](http://ars.els- cdn.com/content/image/1-s2.0-S0920544608000034-gr14.jpg) for the end carnian impacts - perfect alignment between Manitoba, Quebec, France and Azerbaijan craters

</comment></comment><comment><USER4> I find the bottleneck theory fascinating - for example it seems there is one gene now identified that in the six cases where it is missing the people simply cannot talk. Now was that mutation Pre or post bottleneck? If Pre, what was spread of talking beforehand - was there a family advantage - or did it take a whole talking species to have an advantage?

How on earth you can answer those questions is beyond me but what makes us human is such a fascinating study

(and on the "no eugenics here front" what really makes us human is our _humanity_ )

<comment><USER5> Are you talking about FOXP2? If so, absence of it foremost affects the motor control of speech organs. There also seems to be some effect on the actual brain functions that are usually associated with speech, but it is hard to say if this is really caused by the absence of the gene or by the developmental damage caused by its effects. It always seems tricky to me to pinpoint something as complex as language (and by extension speech) onto a single gene given the multitude of functions that are involved.

</comment></comment><comment><USER6> > _The last eruption had an estimated Volcanic Explosivity Index of 8 > (described as "mega-colossal")_

I'm not going to lie - this made me giggle.

Assuming this theory holds - then at one point in time all our futures depended on the actions of less than 1000 people - which makes me wonder about our future generations. Will they say the same thing about us living on planet earth?

<comment><USER7> I assume "1000 breeding pairs" means at least 2000 people. Elsewhere the article mentions an estimate of "3000 to 10000" survivors.

Either way, if true, it's an fascinating picture. Most of us will have more people within a few miles radius than once lived over all the Earth.

I wonder what sort of traits might have been passed on had the predicted disaster not occurred.

<comment><USER8> With some googling and clicking around I couldn't find what the estimated population was before the disaster.

Anyone know?

</comment></comment></comment><comment><USER9> Are we prepared for such an eruption today, and what can we do to prevent/fight consequences?

<comment><USER10> Well we did make it through last time with much fewer resources...

<comment><USER11> Sure but the thing about already living in the stone age is that being knocked back to the stone age isn't so much a catastrophe as it is Tuesday.

<comment><USER10> I dunno... Sometimes I miss the good 'ole days.

</comment></comment></comment></comment><comment><USER12> I've been there 2 years ago and the lake is so immensely huge. Difficult to imagine how powerful the eruption that made it.

</comment><comment><USER13> Zoy</comment>


Show HN: A Color Picker I Made - <AUTHOR> https://colorsupplyyy.com/app <comment><USER2> This looks awesome! Congrats on launching it.

First: Don't get bogged down by random HN commenters' feature requests. Second: I have a feature request. I'd love a native version for Mac OS with a magnifying glass thing that allows me to select a color somewhere else on my screen, and then suggest complimentary colors. I'd gladly pay for that!

<comment><USER3> If you'll accept the step of copying the values into the tool that figures out the complementary colors for you, macOS comes with Digital Color Meter, which will tell you the color of anything on your screen.

<comment><USER4> (It's hiding in the Utilities folder if you can't see it in Applications.)

<comment><USER5> Create a shortcut for it.

I have it set to CMD + Shift + C. Great to have it easily accessible

<comment><USER6> Hey, thanks to this comment, I just discovered that if you hit Cmd+Shift+C in Chrome it'll let you inspect any element by clicking on it. Cheers!

<comment><USER7> Also in Safari

<comment><USER8> and firefox

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> I have to say I like this - great design, easy to operate, etc.

I think something needs to be done to better indicate "other wheel selections" (ie - to move to "square" or "analogous", etc) - while I discovered it fairly quickly, it wasn't as intuitive as I think it could have been.

Beyond that it's a great tool, and the pricing for the more advanced version is decent. That said, it wouldn't take much for someone to build something like this into say, a VSCode plugin or whatnot, so I'm curious what your plans are to stay ahead of that possibility?

<comment><AUTHOR> There are other picker tools that are similar to mine and each of us has a unique take on the problem. It doesn't worry me. If someone wants to make their own version that's cool.

Thanks for the feedback!

<comment><USER10> Yeah, I didn't realize this too until I read the first comment.

I would have put the arrows down where "complementary" and "analogous" and made them more visible rather than elongated and thin.

</comment></comment></comment><comment><USER11> It's gorgeous and easy to use. I especially appreciate inclusion of demo images and hex codes for easy copying. I'll probably refer to it from now on instead of googling "complementary colors" as I've been doing. Well done!

<comment><USER12> FWIW, I've been using the one in DuckDuckGo's instant answers (search for "color picker" there), and it's been working great!

This one is nicer-looking for palettes, though, and has more functionalities :)

</comment></comment><comment><USER13> Hi, great work, quick suggestions red<>green is the "ugliest" combination of complimentary colors, which creates quite a disturbance in the viewers eyes (you could do some research on Van Gogh "The Night Cafe" where he used this for effect). So maybe don't use this as default/start color.

<comment><USER14> To be honest I don't think any of the complimentary colours suggested by this are complimentary.

<comment><USER15> It's _complementary_ , which is a different word and has a very specific meaning when it comes to colour theory (a colour's complement is the colour directly opposite it on a colour wheel) [https://en.wikipedia.org/wiki/Complementary_colors](https://en.wikipedia.org/wiki/Complementary_colors)

<comment><USER16> They don't appear to be complementary either. The complement to #ee4035 is in the cyan range (~5cf7fa). You can get this by hand.

Convert #ee4035 to rgb(234, 64, 53). Subtract those values from max RGB domain (255) and take square root of difference of squares. i.e sqrt(255^2 - 238^2) etc.

You end up with rgb(92, 247, 250), or the cyan color mentioned above. You can also check this in several other complementary calculators.

I could be missing something.

<comment><USER17> that's the rgb compliment[1], this app uses the traditional colour wheel[2]

1: [https://en.wikipedia.org/wiki/Complementary_colors#Colors_pr...](https://en.wikipedia.org/wiki/Complementary_colors#Colors_produced_by_light) 2: [https://en.wikipedia.org/wiki/Color_wheel](https://en.wikipedia.org/wiki/Color_wheel)

<comment><USER16> TIL. I shouldn't have skipped art class. Thanks for the sources.

</comment></comment></comment></comment></comment></comment><comment><USER18> This is suprisingly helpful. I've seen all these color systems before, but this site demonstrates the design possibilities they create much better than any color guide I've used before.

</comment><comment><USER19> The great thing this color picker provides that others don't is live-updating icons utilizing the colors. Awesome job!

</comment><comment><AUTHOR> Thanks for the feedback everyone! If anyone is looking for a senior visual/product designer here's my portfolio: [http://masongentry.com](http://masongentry.com)

</comment><comment><USER20> looks nice! unfortunately when I try to select a color from the wheel, the line switches to a horizontal position (dark blue o----o bright orange) and gets stuck there :(

[Android 7.1.2, Chrome 73]

<comment><AUTHOR> Ahh thx, the color picker was initially built for desktop only so its super wonky on mobile. I need to fix that!

</comment></comment><comment><USER21> I like many things about it, but I think having it default to a red-green complimentary combo is a little iffy. Those of us who are colorblind (and we're 12% of the male population, and 0.5% of the female!) will have a lot of trouble seeing it clearly. Maybe just have it start on square instead? Or maybe have the line start out horizontally between blue and orange instead of vertically between red and green?

<comment><USER22> Offtopic, but why is there such a disparity in the percentage of colour blind people between the male and the female population?

<comment><USER23> "It is sex-linked: genetic red-green color blindness affects males much more often than females, because the genes for the red and green color receptors are located on the X chromosome, of which males have only one and females have two. Females (XX) are red-green color blind only if both their X chromosomes are defective with a similar deficiency, whereas males (XY) are color blind if their single X chromosome is defective.[12]"

via

[https://en.wikipedia.org/wiki/Color_blindness#Red- green_colo...](https://en.wikipedia.org/wiki/Color_blindness#Red- green_color_blindness)

<comment><USER24> Interesting. Because one of the X-chromosomes is inactivated in female cells (which have XX). Otherwise it would lead to over expression of X-chromosome Genes (well most anyway).[1]

[1][https://ghr.nlm.nih.gov/chromosome/X](https://ghr.nlm.nih.gov/chromosome/X)

(There are some genetic disorders where an organism have 3 of one chromosome. Trisomy its called.)

Which X is inactive is somewhat random however so it seems that it reduces the instance of color blindness.

</comment></comment></comment></comment><comment><USER25> This feels like astroturfing since more than half the comments are "cool"...

<comment><AUTHOR> If only I had the money and the ability to plan...

</comment></comment><comment><USER26> Looks awesome! Bookmarked.

As someone who loves hacking together projects at times, I can see myself using this to take out the initial headache of picking color schemes.

</comment><comment><USER27> I like the usability with the arrow keys and the instantly changing examples, but the results do not convince me. You might want to take a look at the adobe color picker [1] to get some inspiration for other modes.

[1] [https://color.adobe.com](https://color.adobe.com)

</comment><comment><USER28> Just a heads up...on your homepage when hovering over the artist's name "Anastasiia Andriichuk" the highlight seems to add padding on each side which makes the line break in between their first and last name and the page gets jumpy. This is using chrome on my laptop.

</comment><comment><USER29> I think this is a really attractive and useful tool. Great work!

I'm not really the target market, I don't think. But my first thought as I was playing with it was "can I upload my own images/logos and have the colors displayed on my stuff?"

So, like the top comment said--don't get bogged down with random suggestions. But, here's mine:

If a premium user could upload their own SVG (or multiple) that adhere's to some kind of standard that lets you style it up with the colors like you're doing with the preset ones, that might be useful for visualizing the colors on their brand.

</comment><comment><USER30> I like the concept of how this works. Do you have a mailing list. I think I want to wait for a couple more color wheels.

In any case:

> "Ability to bookmark your favorite colors for later."

Is this read-only? Can I share such links with clients (i.e., people who aren't using the paid version)?

What that said, some sort of web font integration would be a nice touch. Begin able to show a less design-minded clients a "rough draft" of colors and fonts would be helpful.

If not, if anyone can suggest anything for doing a simple, rough draft-y "style guide", that would be helpful.

Thanks again. Nice work.

</comment><comment><USER31> Beautiful! Congrats on shipping it. And you're right about the Square/Complementary/Analogous/etc. selection mechanism. Your target audience is smart enough to figure it out in seconds.

</comment><comment><USER32> From a few days ago, this is also excellent for exploring colours with accessible contrast from each other:

[https://color.review/](https://color.review/)

</comment><comment><USER33> This is perfect, thank you!

I would add HSL colors and ability to download color scheme.

</comment><comment><USER34> Quite nice. So far I've been using [http://paletton.com/](http://paletton.com/) \- not identical, but similar functionality.

<comment><USER35> I was about to comment, Paletton is far nicer with the amount of color choice (every color!), but it lacks the examples for simple icons and gradients. The best combination would be to use both together.

</comment></comment><comment><USER36> This is really great. I mostly do front-end web dev but I'm terrible with colours. Until now I've used adobe's color wheel thing even though I hate it's buggy guts. This looks like it will be a drop-in replacement for me.

Bonus points for making a good responsive layout. I haven't fully evaluated it, but it seems functional from my phone so you beat adobe küler or whatever it is called.

Edit: spoke too soon. First colorpicker broke on 2nd interaction. Brave on android.

</comment><comment><USER37> This is really neat.

One suggestion, make the two circles in the color wheel that you can drag slightly different (at least). Maybe just line thickness, shape, filled/open something to note that dragging one will produce the opposite results from the other. Maybe make only one of them draggable?

I know it doesn't really work this way, but I only figured out by accident that dragging to the orange/blue vs blue/orange produced totally different results.

</comment><comment><USER38> This is fantastic, and gets a lot of little things right. Just piling on at this point, but you can never have too many compliments. I really like the little added touches like keyboard navigation and the quick, bouncy animations. Makes it feel really friendly. Super cool! I'm bookmarking this.

In the future would there be a way to enter a hex code and have the system work off that? That's the only thing it's missing (for me).

</comment><comment><USER39> Why does "check out premium" go to a memoir of their design career - with a call to action basically hidden at the bottom - instead of straight to the subscription page?

I read the first two sentences, then scrolled a little faster trying to figure out if they were going to post a patreon link for basically donations, and then scrolled faster like what even is this, all to find a normal expected subscriptions page. WTF?

</comment><comment><USER40> Looks cool, doesn't work.

At least on my mobile Chrome on Android.

I can only set a color once, then the black selectors just wiggle around in place whenever I choose a color.

</comment><comment><USER41> I'd suggest adding some sort of message for people with JavaScript disabled. Currently it just looks weird when JS is disabled.

</comment><comment><USER42> Including the example images was GENIUS. Love it.

</comment><comment><USER43> Wonderful design. Example images are an awesome touch, quite useful!

Feedback for mobile safari - it would be helpful if the wheel was fixed to the top of the window (position:sticky?). Not the end of the world to scroll, but there's quite a bit of back and forth as-is.

</comment><comment><USER44> Cool tool! I really like the idea of showing some actual pictures with the colors chosen. Definitely a case of something I never knew I desperately wanted.

As a tip, maybe try to not include your entire life story on the "upgrade" page ;)

</comment><comment><USER45> I like it. I noticed that when changing pattern type, it doesn't remember which color I had selected. It would be nice if it remembered that, so one could quickly cycle through all the patterns for a selection.

</comment><comment><USER46> Very interesting design!

I have too focused on solving the problem for finding color schemes specifically in web design.

Tell me what do you think - [https://csscolors.io](https://csscolors.io)

<comment><USER47> This looks great thanks! I really appreciate the color blindness functionality. As a color blind web dev i really have issues with coming up with good color palettes and this looks like something i can use.

Great job!

</comment></comment><comment><USER48> Love this, I'm always digging around on the usual suspect website trying to find good themes for my apps. I'll definitely be using this in the future. Thank you for sharing!

</comment><comment><USER49> Awesome! What a great tool, not only to find the right color, but also to find inspiration when starting a new project.

</comment><comment><USER50> Neat. What's the deal with the Blue Dot? Seems to indicate that somebody authored that palette. Why are some authored and others algorithmic?

</comment><comment><USER51> I think you should charge more for Premium, especially for the top two plans.

Also -- really sell it. I had to dig for a while to find the upgrade plans and what they get me.

</comment><comment><USER52> Amazing work. Thank you for sharing! I've been looking for a color palette generator like this for the past week and this is exactly what I needed.

</comment><comment><USER53> I've been on it for ~35 seconds and I've already learnt: square, complementary, split complement, triad and analogous colors. Wonderful!

</comment><comment><USER54> This is amazing! A boon for people who cannot visualise colors in the head (people like me =)) Thanks for this and congrats.

</comment><comment><USER55> Are the examples images supposed to change with the color picker? They seem fixed on red/green, otherwise looks awesome

<comment><USER55> Works in edge, but not in chrome for me.

<comment><USER56> Working in Chrome 71.0.3578.98 for me.

</comment></comment></comment><comment><USER57> Great job! This is the first time I'm able to find a nice color pattern so easily. The sample images are very helpful.

</comment><comment><USER58> There are a lot of color pickers out there. This one is pretty cool.

I wish I could feed it a color and get options from there.

</comment><comment><USER59> great color picker, really love the preview images. the only thing missing for me is to have the possibility to specify a specific color in hex as a starting point: most of the time when I'm looking for additional colors for a project, the main color is already pretty much set.

</comment><comment><USER60> Nice app mate, I particularly like the elements that show the colors used with a practical example.

</comment><comment><USER61> This is design porn at its finest. Absolutely beautiful! What tools did you use to build this?

<comment><AUTHOR> Thanks! It's messy under the hood. The first version was all js, this latest version is Rails & js.

</comment></comment><comment><USER62> Very nice. Good idea on the example images. I may actually buy premium for some projects.

</comment><comment><USER63> Love it :-) Having the colour applied to things right away is really helpful, great idea!

</comment><comment><USER64> Awesome, just put together a movie poster using the orange / blue combo.

</comment><comment><USER65> Very nice work!

[whispers] colorsupplyyy.app and colorsupply.app is available for purchase :)

</comment><comment><USER66> Really cool! I will definitely use it when making new website.

</comment><comment><USER67> Beautiful, original work. Thanks for sharing.

</comment><comment><USER68> Appears to have collapsed under the load :(

</comment><comment><USER69> Very nice and useful. Thanks for sharing.

</comment><comment><USER70> Thank you. This is very pleasant to use.

</comment><comment><USER71> Fails when cookies are turned off.

</comment><comment><USER72> It's beautiful, really cool!

</comment><comment><USER73> this is such great work - good job and thank you

</comment><comment><USER74> so simple to use and love how u have an example

</comment><comment><USER75> Good job and Good luck.

Thanks!

</comment><comment><USER76> This is the most practical colour picker that I've seen. Puting the sample icons using the colours we select makes all the difference. Great work!

</comment><comment><USER77> this is awesome!!! nice work!!

</comment><comment><USER78> Great

</comment><comment><USER79> Very nice!

</comment><comment><USER80> deep linking would be great

</comment><comment><USER81> awesome!</comment>


The troubling age of algorithmic entertainment - <AUTHOR> https://theweek.com/articles/875017/troubling-age-algorithmic-entertainment <comment><USER2> Troubling? The quality of nearly all television in the 80's and 90's was troubling. The outrageous amount of unskippable commercials was troubling. The fact that people would have to be home at a certain time on certain days to watch a show they liked was troubling. And the fact that all of this was tightly controlled by a small number of gatekeepers was particularly troubling.

Media today is better in every way. The delivery methods, the diversity of perspectives, the reduction of advertising, even just the overall quality of content is far beyond what most of us grew up with.

There's of course nothing wrong with critiquing the many ways content has changed over the last couple decades. But let's not pretend for a moment that television before the internet was anything other than anti-consumer garbage.

<comment><USER3> This is a grandiose statement to say the least.

In the old days advertisers paid to insert ads before, during, and after the content. Now advertisers pay to know your consumption habits and demographic and push their content to the top of your recommendations, radio, next-up, and whatever else. My personal feeling is that I'd rather pay with my time by watching ads anonymously than pay with my personal data.

Also, nowadays there are numerous ways to virtually purchase content. This is super convenient, but at the same time access to this content can be revoked with no notice, no reasoning and no refund. Content can also be changed without warning or continued access to the previous version.

Things are not unquestionably better today than yesterday. There have been tradeoffs, particularly in the areas of privacy, ownership and convenience.

<comment><USER4> I still don't fully understand the mechanism behind it, but it blew my mind when I found out that you now get personalised advertising through live satellite TV in the UK.

[https://www.sky.com/help/articles/tailored-advertising- with-...](https://www.sky.com/help/articles/tailored-advertising-with-sky- adsmart)

</comment></comment></comment><comment><USER5> We had a preview of what was to come in the early 90's right before the Internet went mainstream (though I'll argue the Internet was not truly mainstream until a little after 2000 when broadband connections were widely available).

At least where I lived at the time, it seemed like the number of channels on cable TV quadrupled, and the number of radio stations catering to different genres also increased. So people's attention was already being chopped up and "bubbled". I feel the "fractioning" effect of streaming whereby everyone is in their own personal bubble is simply a later stage of a trend that was underway in the early 90's.

Regarding an algorithm picking what is visible to you, it's not very much different than a TV or radio broadcaster selecting programs that he/she will think will sell advertisements. It's simply faster, more efficient, and outside some legal liabilities because it's done by software and not human beings.

It's a shame that so much is going into making the Internet obey the one- direction broadcast-and-corporate-controlled TV model, though. The Internet was supposed to be for end-user freedom and control.

But Facebook and Twitter, for example, shows that when you give a bit of that capability to large numbers of people, you don't get fantastic results (but the owners will make a lot of money). Most people seem content to take a mostly passive relationship with their screens, participating in their tribes' regularly scheduled outrages, regardless of the size or technology behind them.

I don't think things will ever change too much for most people. Same town, pay taxes to a different king. It's mostly about companies figuring out how to sidestep existing companies and regulations.

<comment><USER6> But I can change curation bubbles when they are explicit. I can change channels or listen to a different radio show.

When the algorithm is customized for "me" and opaque, I don't have that option.

This has deep implications.

<comment><USER7> Yes absolutely. It's destructive to curiosity too imo. If you do go and search for something outside the algorithmic expectation it can break things hard (oh, you looked at a thing about shoes? Let me give you nothing but that). Which makes me hesitant about search terms on some platforms.

Potentially this can be fixable in the long term, but I think humans will almost always(?) be superior curators. Mostly because they're approaching it from "this is what I like" and not "this is what I know you're going to like."

<comment><USER8> > Potentially this can be fixable in the long term, but I think humans will > almost always(?) be superior curators. Mostly because they're approaching it > from "this is what I like" and not "this is what I know you're going to > like."

This is why I like that youtube actually recommends music channels, mixes and compilations that are curated and uploaded by humans. It'll be a sad day when totalitarian copyright enforcement makes this a thing of the past.

</comment></comment></comment></comment><comment><USER9> A little bit offtopic, but are people really going ballistic over Netflix speed up feature? Has no one ever noticed Youtube has supported this since forever? Or that most video players have this feature? I also seem to remember plain DVD players having the ability to alter speed.

<comment><USER10> I turn it on myself in the web console, which works on Amazon as well:

        document.getElementsByTagName("video")[0].playbackRate = 1.5

<comment><USER11> There are browser plugins for Chrome and Firefox that enable video speed controls on all HTML5 video elements.

My second favorite plugin of all time, right behind uBlock.

</comment></comment></comment><comment><USER12> When the alternatives to streaming platforms look like Clear Channel, then I think it's ridiculous to complain about algorithmic curation of content. Clear Channel and its ilk used the most dumbed down, mass market research driven curation imaginable and the 90s media landscaped suffered accordingly.

On a side note, as a consumer I don't care at all what the intentions of the creator are. Hence post-modernism. If I want to watch Netflix at 2X speed in reverse while I stand on my head, then so be it.

Once you create something, it should be free to use as people see fit. I think there are actually some corollaries to this with the recent conversation around politics and software (c.f. GitHub's ICE issue) but that's beyond the scope of this comment.

</comment><comment><USER13> > The complaint is pretty straightforward: film and other forms of art and > entertainment are made by creators to be experienced in a certain way; > technology that allows end users to modify that experience ruins the purity > of that vision.

It seems like the creators want to have it both ways: the control of being a private artist combined with the money of being a commercial artist. If you want to completely control the art experience, invite people to your home for an in person performance or showing. Otherwise accept, that people have the ability and right to change your art in ways that works for them.

</comment><comment><USER14> Random past blaster from 1985

[1] [https://en.wikipedia.org/wiki/Max_Headroom_(character)](https://en.wikipedia.org/wiki/Max_Headroom_\(character\))

wherein some artificial news anchor rendered like a showroom dummy does... hrrm can't remember anymore...things...

<comment><USER15> "What's that?"

"It's a book."

"What's that, then?"

"A non-volatile storage medium. It's very rare, you should have one."

</comment></comment><comment><USER16> The main problem is they don't really have algorithms. Its just "hey here is a low budget garbage version of the show you were watching." That's not an algorithm. That is just crappy category matching that companies want to pretend is AI.

</comment><comment><USER17> >But it also suggests that tech platforms don't just deliver content, but that they shape it too

The medium is the message. Every medium shapes content. This is the whine of incumbents who want their power back.

</comment><comment><USER18> While algorithms do affect how shows are surfaced, produced, promoted and discovered on streaming platforms, I'm unconvinced that television is more formulaic, unoriginal, and uninteresting now with dozens of online streaming sources and literally millions of channels (e.g. youtube) vs. cable (local monopoly streamer, hundreds of channels) or broadcast television (local oligopoly, tens of channels dominated by three national broadcasters.)

Most importantly, the barriers to creating and distributing video are lower than ever: we carry high-quality video cameras built into our smartphones, we can easily edit those videos using inexpensive (or free) and widely available apps or web services, and we can easily and cheaply make that video available to about half the people who live on the planet.

It seems to me that we are in a golden age of television in terms of quality, quantity, and variety. Regarding quality, it seems that many of the best writers and actors are working in television; moreover, streaming supports watching an entire series from the beginning, which can support longer story arcs without necessarily having to recap everything each episode. Compared to a 2 or 3-hour movie, a series watched from beginning to end can potentially tell a longer and possibly more interesting story with a larger main cast and deeper character development. Regarding quantity and variety, streaming supports a larger number of niche shows with smaller audiences, while wider geographic distribution means that we have access to shows that we would never have had the opportunity to view in the cable and broadcast eras.

</comment><comment><USER19> Netflix's nefarious end goal is clear: feature parity with early-2000s VLC Media Player. They must be stopped.

</comment><comment><USER20> And there you are, with a chum-box at the bottom of your article...

</comment><comment><USER21> I find it pretty boring once the pattern becomes obvious.</comment>


CERN: physicists report the discovery of unique new particle - <AUTHOR> https://theconversation.com/cern-physicists-report-the-discovery-of-unique-new-particle-142315 <comment><USER2> > The paper by more than 800 authors is yet to be evaluated by other > scientists in a process called "peer review"

"'Peer review'? Hey Professor Einstein go easy on the technical terms. We're only human here!"

<comment><USER3> That was a very strange sentence to read. Is that really how little they assume the reader knows? I almost took it as a comment on the expected quality of the peer review.

<comment><USER4> It's also worth noting that for a paper from the collaboration to have to got to the preprint stage it will have gone through a very strict internal review process with several layers.

Source: I working in the LHCb collaboration for several years.

</comment></comment></comment><comment><USER5> tl;dr: It's a tetraquark, not a fundamental particle. We've seen tetraquarks before, just not one made out of four charmed particles. And it's not 100% clear that it's actually a tetraquark rather than two mesons.

Better link: [https://home.cern/news/news/physics/lhcb-discovers-new- type-...](https://home.cern/news/news/physics/lhcb-discovers-new-type- tetraquark-cern)

</comment><comment><USER6> 2019: CERN Pentaquark found (7.3 sigma)

[https://home.cern/news/news/physics/lhcb-experiment- discover...](https://home.cern/news/news/physics/lhcb-experiment-discovers- new-pentaquark)

[https://theconversation.com/exotic-particles-containing- five...](https://theconversation.com/exotic-particles-containing-five-quarks- discovered-at-the-large-hadron-collider-114211)

How many particles can be made of other particles? Stay tuned!</comment>


Slack's Drafts ("Where did that channel go?") feature, misses the mark - <AUTHOR> https://spencerdailey.com/2019/11/21/slacks-drafts-where-did-that-channel-go-feature-misses-the-mark-for-some/ <comment><AUTHOR> I decided to expand on this comment. [https://news.ycombinator.com/item?id=21590920](https://news.ycombinator.com/item?id=21590920)

Its responses:

> I use Slack very often, and I also get annoyed that Drafts features often > tugs a frequently-used channel to a different spot in sidebar. "Where did > that channel go?" -/jmccaf

> First time that happened I had no idea where it went. Still don't and it's > happened a few times. They killed my flow. I hate this "feature". - > /markdog12

> I am so glad you said this! It drives me mad. I think of the lists of > users/channels in slack alphabetically so even now that I'm aware of the > "drafts" change I still go through this shock every.damn.time. - > /libraryatnight</comment>


Is there any software out there to manage alpha/beta invites and emails? - <AUTHOR>

Is there any software out there to manage alpha/beta invites and emails? <comment><USER2> I've been using Prefinery to put up teaser pages and manage a 'wait' list for my app. The free account should be enough for this.

How ever you can use their API to build something to suit your requirements maybe.

<comment><AUTHOR> nice, I'm going to check them out.

</comment></comment><comment><AUTHOR> is there any open source software that I can throw up on my server?

<comment><USER3> You could probably whip up a quick Django app to catch your potential user's email addresses... or some other framework.</comment></comment>


Your developers aren't slow, your process is - <AUTHOR> http://thenextweb.com/dd/2014/11/25/developers-arent-slow/

<comment><AUTHOR> Our data at Codealike ([https://codealike.com](https://codealike.com)) supports the conclusions. When we cross-reference other sources of data like ALM data in our field studies we find that the ratio between actual coding vs. perceptual time (the time we think it took to solve an issue) there is at least a 1.5x multiplier, no matter the team size or the team skills.

Beware though, the multiplier will change based on team size and skill, but will always be higher :)</comment>


Don't Use Markdown for Documentation - <AUTHOR> http://ericholscher.com/blog/2016/mar/15/dont-use-markdown-for-technical-docs/ <comment><USER2> After having written a fairly popular 400+ page book, and dozens of documentation sets in Markdown (and having worked on a few in other languages), I have to say—Markdown is _good enough_.

The other syntaxes mentioned will not be mainstream enough to gain critical mass for some time, if at all. Markdown, for many projects, is literally plain text with some added frills for headings, lists, and code blocks.

Yes, adding a code snippet inside a table cell inside a list can be a pain- inducing experience (especially until CommonMark settles things down a bit)... but that's about .05% of anything I've ever written, and for those particular instances, I fall back to HTML, which is completely compliant and much less ambiguous.

For myself, and for most of the projects I've worked with and maintained, you need documentation to be dead simple in syntax, and requiring a syntax with even less adoption than Markdown is an easy way to cause users who would've otherwise contributed doc fixes and updates behind.

<comment><USER3> I wrote a 400+ man page in troff!

[http://nongnu.org/txr/txr-manpage.pdf](http://nongnu.org/txr/txr-manpage.pdf)

Welcome to the BDSM club.

Big Document in Shitty Markup.

:)

<comment><USER4> How was your experience? What tools did you use, editor? Was it troff, Plan9 roff, neatroff?

<comment><USER3> I use GNU troff (Groff) for maintaining this.

And by the way, this is actually installed as a man page on target systems.

Most of my struggles were in the area of halfway decent HTML conversion. To that end, I started with a very hacky C program calld man2html, which actually contains a mini-troff implementation, and improved it quite a bit. I cloned that program here:

[http://www.kylheku.com/cgit/man/log/](http://www.kylheku.com/cgit/man/log/)

This had numerous issues, among the main ones being not handling loops and conditionals and so on for complex macros.

I still do quite a bit of post-processing on the output of this program, still, to do things like re-arrange its order, add internal hyper-links, and create a Java-scripted table of contents:

[http://www.nongnu.org/txr/txr-manpage.html](http://www.nongnu.org/txr/txr- manpage.html)

(Almost the same URL as before, s/pdf/html/).

That post-processing is done by:

[http://www.kylheku.com/cgit/txr/tree/genman.txr](http://www.kylheku.com/cgit/txr/tree/genman.txr)

I don't like the approaches you have to take in troff for defining multiple ways of doing the same thing, based on whether it is juxtaposed to something else or followed by whitespace. This is fundamentally broken.

For instance if you want foobar such that foo is italic, but bar is regular, you have to use .IR foo bar, rather than the .I macro. I'm sorry, but a markup language should have the scoping/delimiting wherewithal not to have to do stupid things like this.

I have a more or less fixed (non-growing) set of such redundant macros in the document and so it doesn't bother me that much any more.

<comment><USER5> mandoc works great for producing HTML and PDF output from man(7) and mdoc(7): [http://mdocml.bsd.lv/](http://mdocml.bsd.lv/)

> I'm sorry, but a markup language should have the scoping/delimiting > wherewithal not to have to do stupid things like this.

(btw, mdoc has this and is widely supported, having been around for about 2 decades... having discovered it, I'll never write a manpage in man again)

<comment><USER3> This "mandoc" naming of a project that was previously called "mdocml" is terribly confusing.

"mandoc" is the name of a newer troff/nroff macro package for writing man pages which replaced one called "man". (nroff -man versus nroff -mandoc).

The renamed "mandoc" project provides a processor which understands a "mdoc" language, a set of macros used on BSD Unixes. It's not a full processor for the roff language. The mdoc language has macros that resemble mandoc, like .SH, .TH and others.

In the TXR man-page-like reference manual, I'm using real roff macros (some of which output mandoc macros as their target, in the original sense of mandoc).

I don't think these macros could run in under the mandoc system, where you have to use a canned repertoire of macros.

For instance, I have a macro like this.

       .coNP Functions @, boundp @, fboundp and @ mboundp

This parses its arguments. Any word preceded by @, is typeset in a typewriter font, immediately followed by a comma. A word preceded by @ is typeset typewriter, not followed by a comma. Other material is in the regular font.

Another complicated thing:

       .mets (replace-list < list < item-sequence >> [ from <> [ to ]])

IN this syntax "< word" means typeset word as a meta-identifier. "<< word1 word2" means, typeset word as a meta-identifier, immediately juxtaposed with word2 (no whitespace) which is ordinary. >> word1 word2 reverses the relationship, and <> w1 w2 w3 means w1 and w2 are ordinary , surrounding meta- syntax w2 without space.

When you render this with a man reader, the macro puts out angle-bracket notation, exactly like this:

       (replace-list <list> <item-sequence> [<from> [<to>]])

in the paragraphs which describe this, this notation is consistently used. In HTML and PDF output, these angle-bracket notation is replaced by italics.

<comment><USER5> Ah, I didn't realize you were making full use of roff. I don't think mandoc (mdocml) supports that; you're correct in saying that it's a canned version of man/mdoc.

It has served me well, though :)

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> Markdown has a lot of faults, but it solves the one single biggest problem in writing documentation that basically overrides every single other consideration: _getting people to actually write it_. Basically nothing else matters except this.

And I disagree about the portability. Write Pandoc-compatible markdown and you can convert it to just about any format under the planet. I love that I can write in Markdown, then quickly create a word document to send around the office for comments - whatever anybody says about Word, the track changes and review functions both useful and defacto standards in most offices.

<comment><USER7> Markdown has always seemed to me less like a file format or a formal document syntax and more like a set of strategies for upsampling plain text into such a structured format by looking for the sorts of informal conventions people naturally use when they're writing plain-text documents.

Or - I should say, it infers structure from the sorts of things people did as a matter of course back when we had a network culture based on sending each other blobs of text via email or Usenet. I'm sure the original author of Markdown.pl was not intending to design a new structured document language at all, and simply wanted to pretty-up some plain text files for display on the Web. The structure was already there, the conventions were already in common use, and Markdown.pl was just one strategy for doing something useful with them.

I think it's easy to get people to use Markdown because it doesn't feel like writing in code, and it doesn't feel like writing in code because it's basically just the sort of thing we all did all the time before the web took over.

Ironically, then, I think it actually will make Markdown _less_ useful to build it up as a rigidly specified uniform document protocol offering sophisticated formatting features. There's certainly value in having the various makers of tools doing this job work together toward a common understanding of the patterns people like to use, but it's far less important whether someone uses triple-tickmarks for quoting or four-space-indentation for quoting or whatever, so long as the tool can recognize that they are doing _something_ , take a reasonable guess at what that might be, and then offer a simple way to correct that guess later if the user is particularly concerned about the way the text is being rendered.

<comment><USER8> this is an astute comment. (because marssaxman.)

but the problems arise because different markdown flavors recognize different types of "common understanding of the patterns people like to use", so misunderstanding happens.

</comment></comment></comment><comment><USER9> Markdown is wildly popular because Markdown is easy to write and read unprocessed. At a basic level, it's little more a few conventions for writing text.

RST, used by Sphinx, isn't quite as easy to write or to read. There are plenty of gotchas. RST adds friction.

Using Sphinx also requires you to setup and configure Sphinx for your project - even more friction early on.

The world is far better for having Markdown, and it's the right choice for most projects.

However, there is indeed a place for more complicated projects to take on the workload of a more complicated documentation system so that they can help user and developers better. Django's amazing documentation is an example of this, and a major reason for the success of the project.

<comment><USER10> > RST, used by Sphinx, isn't quite as easy to write or to read. There are > plenty of gotchas. RST adds friction.

What gotchas are you thinking about?

> Using Sphinx also requires you to setup and configure Sphinx for your > project - even more friction early on.

You can perfectly well RST without Sphinx, it depends what you want to use it for. Obviously, if you want to use for Sphinx, you need Sphinx. But otherwise, you can perfectly well use rst2pdf or rst2html with a standard RST document.

<comment><USER9> The format for code blocks in Markdown is to indent by four or more spaces.

The format for RST/Sphinx code blocks is to type two periods, a space, the word "code-block", then two colons, then exactly two new lines, and at last you can write your code. Indented with four spaces. Also, you have to make sure there is a blank line between that "code-block" magic line and your preceding text. In practice, I usually manage to screw some part of this up.

The extra complexity and cognitive load makes it much harder for a developer to just write thoughts.

<comment><USER11> You can do code blocks::

       like this

:)

<comment><USER9> Yeah - this always trips me up too, since it's two colons, not the holy Python single colon, and it's "magic" on the preceding paragraph, not the code itself. Django docs written in RST avoid doing this style.

You can do anything you need to in RST, but there's just more friction involved.

<comment><USER12> It's not a Python thing, though. It's a reStructuredText thing. I don't see how this syntax is more "magic" than, say, using # in Markdown to indicate a heading.

The reason it's a double colon is because a single colon acts like a normal single colon (i.e., it's not interpreted in any way), which is sometimes what you want (i.e., not every indented block is a code block).

</comment></comment></comment></comment></comment></comment><comment><USER13> I wrote a six book, 1100 page series in Markdown (all on github). I write all my blog posts in Markdown.

I'm sorry but I just can't sympathize with any of the complaints leveled against Markdown. They are so minor and compared to the massive adoption of the common bits of Markdown, there's no chance I'd ever choose to write anything in any other markup than that just for those small annoyances.

I don't need custom extensibility when I can just add HTML. HTML is pretty good at markup, and it enhances the markdown in those rare occasions where what's provided seems too limited. The very last thing I'd want to do is literally write code as an extension to my markup language. The only code in my markdown is inside nice tidy code blocks for display purposes only.

I also use JSON for configuration, even though many have tried to convince the community that YAML or some other format is better. I pre-process my JSON to strip it of "non standard" comments, and I'm quite happy that I chose the by- far-defacto-standard there instead of going off the beaten path.

<comment><USER14> Markdown is fine for books, but not for technical docs.

Techdocs have lots of cross references and other similar elements, their implementation in all markdown "standards" is really bad.

ReStructured text is much, much better.

<comment><USER13> I didn't mention in my comment, but I also use Markdown for all my technical documentation (READMEs) on my dozens of github OSS projects. I have lots of cross-references and I use normal links to named section anchors (sometimes that I insert manually via HTML).

It's not perfect or even ideal, by any means, but the other benefits of Markdown are more than enough to make up for the slight annoyances here.

I don't know about ReStructured text, but I can say that none of the examples in the OP swayed me that I'm missing anything of any import.

</comment></comment></comment><comment><USER15> I love Markdown. I enjoy RST. I think, like programming, they have their own merits and use cases.

Markdown is a lot less verbose in my opinion than RST. It's not intentional, nor is it insurmountable, but little things like inline code, hyperlinks, defined subsection levels, and many more all add up to a bit of cognitive load that I don't need for all situations. When I'm writing quick notes for a meeting, or trying to jot down something, RST is a bit much. Which perhaps isn't what this article is really harping on.

But when my quick notes to myself about a project turn long-winded and become more of functional docs, it can be a pain to rewrite that into rst.

I do, however, tend to use RST when I sit down to write documentation for a project. I even tend to use it when documenting firmware and hardware portions of projects. This of course due to the so far poor handling of images in Markdown.

So like I said above, they are tools. One may be better suited to something than the other. But thus is the nature of tools. Use the right tool for the right job whenever possible.

<comment><USER16> When I was confronted with this dilemma for the first time I attacked it by using multiple passes. My original draft is markdown. I pandoc it to DocBook. Then I add frills and edits in DocBook.

I see the process as not being different from what's needed to do the writing - compiling notes and sketches and outlines into a coherent narrative.

<comment><USER17> I have a very similar process. I start of with an org document, do a couple of drafts and then pandoc to LaTeX, pull in the proper template and add the frills as you say.

</comment></comment></comment><comment><USER18> Ah. This reminds me of a great discussion that happened over at the Rust Internals forum about which markup language to use for documentation. [0]

tl;dr: Markdown won.

[0]: [https://internals.rust-lang.org/t/rustdoc- restructuredtext-v...](https://internals.rust-lang.org/t/rustdoc- restructuredtext-vs-markdown/356)

</comment><comment><USER19> The fundamental complaint seems to be that the portable subset of Markdown doesn't allow for extending with new types of blocks.

I find this an unconvincing argument against Markdown _per se_. It's an argument against writing in the portable subset of Markdown, but why would anyone _need_ to do that in their documentation? It isn't as if specific Markdown implementations are hard to come by, or that there is a context where it would be onerously hard to mandate a specific implementation.

Not to say that Markdown's fragmentation isn't a bad thing. It's annoying, especially when you do use different implementations in different pieces of software and you're trying to remember whether this version supports tables, say, and what the syntax might be.

> "Markdown" is the most commonly used markup language on the internet.

That'll be HTML. :) Not just being facetious. HTML is certainly an option for documentation, albeit not one I'd be totally happy with.

> You also can't migrate Markdown easily to another markup language (Asciidoc > or RST), because Pandoc and other conversion tools won't support your > flavor's extensions.

Unless those flavours are Markdown Extra or Github or CommonMark, which pandoc does support. Pandoc also supports adding specific syntax extensions ad-hoc, as noted in its fine documentation. Although, I'd question why this would be an issue in practical terms.

</comment><comment><USER20> Personally I love how in Elixir, documentation comments are markdown. The Elixir runtime even comes with a nice tool that generates awesome HTML from it.

For example, this:

[https://github.com/parroty/extwitter/blob/master/lib/extwitt...](https://github.com/parroty/extwitter/blob/master/lib/extwitter.ex#L742)

Becomes this:

[https://hexdocs.pm/extwitter/ExTwitter.html#follow/1](https://hexdocs.pm/extwitter/ExTwitter.html#follow/1)

</comment><comment><USER21> > "Markdown" is the most commonly used markup language on the internet.

Wouldn't that be HTML? :)

</comment><comment><USER22> If you're using Github and/or Pandoc for things, you can pretty much drop org- mode in as a replacement. It doesn't even require emacs :-)

In general, I find org-mode about as easy as Markdown, but with support for things like cross-references that are sadly lacking in standard Markdown.

</comment><comment><USER5> I don't have a particularly strong opinion about most markup, but I know for sure I'll never use something that uses xmlto/xsltproc as part of the toolchain (such as Docbook). As a maintainer of several packages for a Linux distribution, I've gotten far too many headaches dealing with packages that rely on Docbook for generating their manpages or other documentation. The user's xsltproc setup has to be _just right_ for the packages to build. Anything off in the XML catalog will break the whole build. Supporting it has been the opposite of fun.

For manpages, I write mdoc directly. It's not hard. There are several great mdoc resources on [http://bsd.lv](http://bsd.lv)

For reference material, I stick with either Pandoc or I use LaTeX (along with tex2page for generating HTML). Anything fairly small tends to get the Markdown treatment. If it's something I foresee will need to be split into multiple documents, I reach for LaTeX. Scribble is pretty nice, too, if you're dealing with Racket or Scheme.

</comment><comment><USER23> Yep, I tend to agree with the author. For software documentation with complex APIs, something more robust than markdown is necessary. For the same reason that writing extensive in-line HTML+CSS markup is bad, relying too heavily on HTML as the "fallback" for styling and structuring things that markdown cannot handle is just not efficient.

Here's a quick cheat sheet... for the "why" of semantic styling your docs with something like .rst with directives makes for better overall integration.

[https://github.com/indie/sphinx- deco/blob/master/sphinx_deco...](https://github.com/indie/sphinx- deco/blob/master/sphinx_deco.rst)

</comment><comment><USER24> Getting developers to write documentation is hard enough already.

Raising the barrier to entry to include learning complicated markup languages will chase them off completely.

I agree, it's far from perfect. But some documentation is better than none.

</comment><comment><USER25> TIL that Read The Docs is a product and not just a condescendingly-named website with mirrors of python docs. :)

</comment><comment><USER26> I feel like this drive to use a document description language that is "natural to read in ascii" but also works as a real markup language ends up fulfilling neither in practice. I prefer LaTeX than any of these half-assed markup languages that never quite works as you want.

<comment><USER15> As a former physicist and LaTeX user, I find it hilarious that you refer to any others as "half-assed markup languages that never quite works as you want". I've found myself spending way too much time recompiling my LaTeX documents to get just the look I want. And I much prefer writing my first draft in Markdown, then pandoc it to LaTeX and finish. Takes much less time in my opinion.

<comment><USER27> Using pandoc markdown with inline latex works pretty well.

</comment></comment></comment><comment><USER28> I really tried to write in ReST but there is nothing intuitive about the syntax and I kept forgetting how to do things, it also makes the plain text unnecessarily verbose and does not support simple things like combining styles (i.e. good luck if you want something be monospaced AND bold without terrible kludges).

In the end I converted to Asciidoc, it does all I need, is readable and is not as python-centric as docutils (I use the python implementation but asciidoctor is ruby and there's even a chrome extension for live preview in the browser).

</comment><comment><USER29> I think most the arguments made in the piece don't matter but the argument for Lack of Semantic Meaning is interesting in how Markdown solves it. First off the argument is bad because Markdown can have semantic meaning, it is just defined with HTML. So the real argument is semantic meaning in HTML sucks. In his example, I would generally agree. However, what if you just used <warning>Warn Me</warning>. I kind of like that a lot.

</comment><comment><USER30> I guess markdown is nice for unstructured text.

When you think you can learn a job (technical writer) by doing it bad rather than not doing it at all, you just take bad habits.

Serious technical documentation are structured. Pictures have captions, graphs have legends... It is cumbersome, it requires more data but that is the price to communicate (wait for it) INFORMATION to other humans.

Yes, writing structured documentation that can be easily used is part of what information technologies are. Structuring information from data.

Information is still analogic at the end and rst is just a typesetting chain designed for a domain specific kind of documents called technical documentation.

I am totally biased. I love readthedocs, I love POD, man pages, ISO documentations, IETF RFC, ASM papers, all kind of scientific papers, useful instructions that can help me do my job faster by following well known practices to be consistently readable without strain. And rst for this level of requirement is less a PITA than doing it conscientiously by hand or with markdown.

But I agree, I totally love the artistic freedom of markdown for writings too. But in a Museum, or as grafitis.

We talk about documentations right? Not art? So the title is accurate.

</comment><comment><USER31> Agreed. Better use docx for every type of documentation. Just embed it with base64 if thats what you need. Nothing more standard than a good ol' docx.

</comment><comment><USER32> And then there's CommonMark: [http://commonmark.org/](http://commonmark.org/)

They aim to standardize the "markdown-like" formats into a single unified one. It's not done yet but it's certainly better than everyone for themselves.

<comment><USER33> Does anyone remember Creole wiki markup? It was born in a time when each wiki created its own syntax. Creole should become the standard for wikis, but it never got traction. I fear that it will be the same with commonmark.

<comment><USER34> Probably would have worked better if they were allowed to call it "Standard Markdown" or had been able to get Gruber aboard.

</comment></comment></comment><comment><USER35> The primary limitation I've found with Markdown, and the one reason I revert to LaTeX for longer documents, is the lack of support for equations. I'd love to be able to just add LaTeX math between dollar signs.

<comment><USER36> Have you looked into RMarkdown?

[http://rmarkdown.rstudio.com/](http://rmarkdown.rstudio.com/)

Just like you said, you just use $ or $$ to add LaTeX.

I am not arguing you should write a 600 page book with RMarkdown + LaTeX (just use LaTeX in that case), but it has worked well for me for technical reports and presentation.

</comment></comment><comment><USER37> Rust uses markdown (with some extensions) for its documentation. This has some limitations, and there was a discussion [1] about changing this to RST a while ago, but it never happened.

[1]: [https://internals.rust-lang.org/t/rustdoc- restructuredtext-v...](https://internals.rust-lang.org/t/rustdoc- restructuredtext-vs-markdown/356)

<comment><USER38> The only real issue I have with it is manually creating links to other things, which is tedious and error-prone. I'm hoping to transition us to CommonMark, and with it, an extension that can do this.

</comment></comment><comment><USER39> "portable if you install all the custom extensions the document needs" is a fairly poor implementation of "portable". You might as well call the different flavors of Markdown "portable" (contra the article) since all you need to do to render them correctly is install the right parser...

</comment><comment><USER40> Don't blindly follow advice from articles with hard "yes/no" imperatives as titles.

</comment><comment><USER41> I have been expecting github markdown to become the defacto standard just as github itself has become the defacto standard for hosting.

This would be a good thing since any standard is better than the tower of babel we have now.

</comment><comment><USER42> Rst is a bit harder to write but more powerful and extensible. To alleviate some of the syntax annoyances I created some snippets in my editor.

</comment><comment><USER43> Is it [text](URL) or [URL](text) or (text)[URL] or...? It's impossible to remember, because this syntax is bizarre.

<comment><USER44> I too get them back to front, but to be frank I have no better suggestion. Markdown definitely isn't perfect, but it is "good enough." Now if Only HN supported Markdown :)

</comment></comment><comment><USER45> > This leads people to embed HTML directly in their Markdown

I don't find that too bad.

</comment><comment><USER46> that's like... your opinion, man

I have done just fine with md

</comment><comment><USER47> Wah wah. I disagree. I'm tired of seeing this in Enterprise:

* 100 page Word document. 200 page Word document. Take your pick.

* 99% of it is clearly cut and pasted from somewhere else and contains information absolutely incorrect and irrelevant to the task at hand because it was accidentally included from the last document they cut and paste from, but people are afraid to remove it.

* Someone has manually typed in a few lines into a table (oooh, so THAT'S the temporary IP address of the server which will almost certainly change at a later date!) As it's buried in the document there's no way to extract, verify, or update it. It will be listed with a bunch of other IP addresses from the prior cut and paste, and if you get a server name in there, it's probably wrong too.

* They've also handed off the effort to any Architect, probably one of the people I see sitting in Visio day in day out drawing those diagrams of how a computer connects to the network. In a VM data centre. Where it's meaningless and has no connection to reality. And where the moment it gets turned on someone will install software that connects to 20 other servers in ways that will never be described let alone in this document let alone in a diagram.

* Now, take that, cut and paste the whole thing keeping it 90% intact, call it a "Controlled Document", add in the names of some people at the front and last edit dates (where every document starts at version 0.1 and stays there for its entire lifetime), and now you've got a process manual! Hundreds of them! Thousands of them! Don't worry they were all based on whatever kind of template the business was branded with from year to year so you can kind of tell which decade they were first created.

* And they'll be dumped in shares because whatever multi-million dollar document management system was never used by users before being bought and never ever ever works. If you're lucky they might have version numbers or edit dates which don't correspond internally but get you 90% of the way to finding which one is current.

I get to see those holy manuals in Enterprise every day. You have no idea how bad it is.

Pick a third party format apart from Markdown? Are you fucking serious? Enterprise doesn't buy fucking third party software and everything is locked down so that you can't run your own. This is Windows for fuck's sake and there aren't even decent free Markdown editors for it anyway.

I write _MY_ personal documentation in Markdown and I do it in a plain text editor. If I ever need to draw a diagram or put in a picture then I know I've fucked up and to backtrack. It's just plain text. That's what Markdown is for. "Not portable" my arse. About the only thing I wish was easier is tables. And they'd probably be ASCII tables at that.

So yeah. The argument against Markdown is bullshit.

</comment><comment><USER48> Markdown is a virus. The virus shows you how you don't need markup at all.

</comment><comment><USER49> Markdown actually works great for documentation.

stick a certain version and do not change it.

the article is likely bias as writes states he works for read the docs.

</comment><comment><USER50> This is what I think of when reading this article: [https://xkcd.com/927/](https://xkcd.com/927/)

</comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>===

Situation: There are 14 competing standards

"14?! Ridiculous! We need to develop one universal standard that covers everyone's use cases.!"

"Yeah!"

Situation: There are 15 competing standards

</comment><comment></comment><comment></comment><comment></comment><comment>==

The argument is that there are too many variations markdowns. Their solution? Another markdown.</comment>


Things I Learned Building The Most Powerful Language Processing Engine - <AUTHOR> http://www.xyhd.tv/2013/04/industry-news/things-i-learned-building-the-most-powerful-language-processing-engine-on-the-planet/ <comment><USER2>
      Linguists don't know squat about grammar in modern times. Everything is a verb these days. I Google things. I FedEx things. My game gets nerfed.

That's a bit broad. Talk to the right kind of linguists, and yes, they do know these things.

Every problem he talks about is well-known. Not to say that they aren't still problems- they are problems, and hard ones, that linguists (computational and otherwise) don't have good standard solutions for. Thing is, most of the time, you can get away with not bothering to solve the real problem. Most of the time, you can pretend that white-space separates words and periods separated sentences and that 8 parts of speech is good enough, and it will be good _enough_. And thus the incentive to spend lots of time and research money on solving all of the big problems in natural language processing is reduced.

Except when it isn't _good enough_ , and we wonder "why the heck hasn't this been solved yet? Doesn't anybody realize that this library is totally broken?" But yeah, we know that it's broken, we know what the problems are, they're just really frickin' hard.

<comment><AUTHOR> You are right there are a select few. But it is very few. I linked to the quora as just one example. The challenge is that they focus on what is "right" not what is "common".

It is like swum. It is a real word, and I have swum many times in my pool, but it is not how humans write. More of practical linguistics is about how people use words, not how they are supposed to use words.

<comment><USER3> Linguists get descriptivism drilled into them from day one! If anyone who goes on about what is "right" I would highly doubt they were trained as a linguist.

You could perhaps instead mean "standard" instead of "right" - that they're describing a standard dialect, which doesn't meet reality. That could be true, I'm sure it is in places.

Btw, I'd be interested to know how many parts of speech the CGEL describes. Anyone got easy access?

</comment></comment></comment><comment><USER4> I've been looking at stremor.com to find some justification for your bold claims. I'm still looking; these are some ancillary points:

-The copy throughout the site does not inspire confidence. Your point that many texts are written poorly is valid. That does not require you to also write poorly. I've seen far too many sentence fragments on your site. You site also includes some embarrassing misuses of words, like "Some may believe using heuristic science in language analysis infers it is a learning system." These incidents discredit your claims about your technology.

-I am having difficulty finding specific information about how your technology works.

-The people responsible for your graphics, visual design, and the video about the summarization app should not have those responsibilities. Summly had nice a aesthetic; your aesthetic is jeopardizing your credibility.

I apologize if my comments sound hostile. When you make claims as bold as yours you should prepare for scrutiny. The problems you are addressing are interesting; I wish you good luck.

<comment><AUTHOR> You judge the technology based on the marketing? Summly had no tech and lots of marketing. SRI had no marketing and lots of tech. I'd rather be SRI than Summly. Take note as to which one got a Billion dollar valuation.

<comment><USER4> I don't judge your technology based on your marketing; as I mentioned, I looked for specific information about your technology but was not able to find any. The .pdf you linked is what I quoted above; I'm interested more in your papers or patents.

SRI is a respected brand with a great reputation and history. I wouldn't be so dismissive of marketing since, as you mention, you have recently exited stealth mode.

<comment><AUTHOR> We started 14 months ago. Papers and Patents take a bit longer than that to get through. We have two pending patents. Much of the "magic" is trade secret rather than patent because the changes in patent law are now requiring enough information for you to build the tech. We don't have the money for enforcement, so making that much IP public scares us, especially if someone like Google decided that the patent was "obvious". So we are balancing our portfolio of IP. Enough to be worth acquiring, not so much that you could dupe the work with the part that are in the public record.

<comment><USER4> I didn't realize that you had started so recently. I appreciate that patents and papers take time to produce.

I am trying to be helpful when I say that for a company that produces language processing technology, your customer-facing content shows a strange disregard for language. If your writing does not demonstrate that you have mastered English grammar, why should I believe that your software has?

<comment><AUTHOR> The challenge with the website is saying things in such a way that we don't scare off the non-technical, and still appeal to the technical.

All cards on the table, there is a lot of discussion internally about who we are writing for. The result is we get a mish-mash of copy from Engineering and Marketing.

The PDF I linked to is much better because those were targeted to Engineering managers. The website still doesn't know who it is targeting. <http://www.tldrstuff.com> knows its audience it sucks much less.

<comment><USER5> Simple, clear, and grammatically-correct writing will not intimidate non- technical users.

</comment></comment></comment></comment></comment></comment></comment><comment><USER6> "200,000 words. Ha! 400K words. I laugh. 3.2 Million words. I still know I am missing stuff. Single word nouns in just the singular form exceeds 150k. 40k verbs and conjugates. 37k adjectives. 10K adverbs. I know I am still missing things."

I was all set to hate this post, but I found I ended up largely agreeing with it, especially the quoted bit above. I remember working on a very focused NLP tool a few years ago and needed a comprehensive English Lexicon. No problem, I'll just scrape WordNet or similar, not even close. Then you start dealing with stemming and conjugations and such and realize that almost all of the algorithms for dealing with this kind of thing would barely even be hacks in software terms, yet there they sit, regurgitated in countless libraries, generating garbage stems all over the place. It ends up just being easier collecting all the stemmed forms as well and just building some smart in- memory indexes and data structures for searching millions of words.

Vector space models? Why do they work? Nobody really seems to know! Just jam all your words into some matrixes and run some simple calculations and voila you get something seems to kind of like it sorta works some of the time.

Sentence tokenization is stupid hard, but shouldn't be, parantheses have all kinds of different meanings, commas are a mess...English is stupid.

The worst bit though really is that most of the research->turned into software assumes astonishingly brittle models about the language which almost never seems to describe any _actual_ usage of the language which always means very frustrating _almost_ right results out of NLP systems. My previous sentence, for example, would cause most NLP software to blow a gasket.

<comment><AUTHOR> I ran it through our stuff we do fine with segmentation of your comments. We still have trouble with certain poorly formatted numbers, or if you do something like for get a space after a sentence that ends in a number. "I'll take 2.In case I need one later."

Typos are really hard for rules systems.

PS Glad you didn't hate it.

<comment><USER7> Aren't you arguing against prescriptivism and not linguists (as in people with a background in Linguistics)? My background is Linguistics, Computer Science and NLP. From what I was taught, and what seems to be the norm, is linguists tend to do descriptive linguistics. You learn from your data and change the rules and methods accordingly, not the other way around. Anyway, interesting read.

I am curious about one thing. Are you just handling white spaced words, or do you handle lexical items as well such like polywords (inside out), phrasal verbs (put up with, beat up), idioms, etc.?

<comment><AUTHOR> We handle polywords. We had to. Noun adjuncts being one of the worst in terms of how often they show up, and I'll be honest I don't even know what you call Gerunds as Adjectives like "Running shorts" but those are a pain too. But you can kind of find ways to get lists of those. Parts catalogs, shopping sites. People want to buy polyword nouns. There are fewer of the verbs but they are harder to find lists of.

Idioms we haven't addressed much. Fortunately in news they come up less than other things. Sarcasm we deal with in most cases, but not all. There are hints that things are sarcastic, but if they are written like "the Onion" and they don't change tone because they are really a parody rather than sarcasm we can't tell that.

I like to say that if your 5 year old would figure it out we will figure it out. If your 5 year old won't probably we won't either. But this is a huge leap forward since the competition is about the level where your dog would understand.

</comment></comment></comment></comment><comment><USER8> Interesting blog post, though I wish they would give us some meat rather than what's essentially a rant. I do find it a bit amusing that it doesn't perform well in their own system:

> _I am the CTO of Stremor, we make TLDR Reader. Sentence objects > Sentenceobjects represent information extracted from a single sentence > within a document. Attributes and methods available on Sentenceobjects: ∗ > text: The raw text of the sentence as a string. ∗ names: A list of all names > detected in the sentence._

Yeah, this is similar to picking at Google Translate not translating Google into the same text as they use on their other-language homepages. I'm honestly not complaining, I just found it funny :) To be fair, it does a significantly better job at other blocks of text I've thrown at it. Not great, but surprisingly good - I'll have to prod it more.

<comment><AUTHOR> As I mentioned in comments, I didn't mark up my "code paste" so it decided the documentation was more important than my comments.

The TLDR version is optimized for news at up to 5000 words. We have some other stuff for Fiction but it isn't public, and a version that is specific to politics.

<comment><USER8> I'll aim to feed it some 5k articles, thanks! Definitely interesting, but it's such a tease of an article :/

</comment></comment></comment><comment><USER9> One of the Stremor devs here. I'm helping to build Liquid Helium, and wrote the cited README. Never expected that it would make its way to a public blog post :-).

Yes, language processing is hard. There are two challenges here:

1) Understanding the ambiguities of language, when every word in the sentence can be 2+ parts of speech.

2) Making it fast, and making it fit within the relatively constrained RAM limits of App Engine instances.

We're wrestling with both while we greatly expand on what Liquid Helium can do. It's not easy, but some of the things we're able to do with it are pretty magical.

<comment><AUTHOR> To akavlie's Ram limit comment: We run on Google AppEngine. It gives us great scalability, but it limits us to about 512 Megs of ram.

We made this choice because with a small team it gave us the most freedom to focus on the code, rather than the scalability and the infrastructure. We don't manage servers, or routers, or load balancers.

<comment><USER10> I was going to ask about that, seemed strange to feel that a self imposed constraint was a challenge you had to work around.

There are other options outside of app engine that could help you achieve the same thing. I outsource most of my processing to picloud (specifically because I need more ram than I have).

I don't work in your field but I think it's a really interesting problem you're working on.

<comment><AUTHOR> If you are going to compete with Google you might as well step in to the arena running on the same hardware. :-)

Also the best targets for acquisition put Google high on the list so building things the way they would makes sense.

</comment></comment></comment></comment><comment><USER11> What precisely makes this particular engine 'the most powerful in the world'? Does it do domain independent named entity recognition with an F score better than 0.8? For what classes of entities? Is it at least adaptable without oodles of training data? Does it do syntactic parsing? With F scores of 0.9 or better? Faster than 200ms per sentence? Across domains? Does it do anything at all in languages other than English? If there is a page on that site where it answers these types of questions I couldn't find it..

<comment><AUTHOR> Install the TLDR plugin. Pick a web site. Or better yet go out to project gutenberg pick a book. Tom Sawyer. Push TLDR. Way faster than 200ms per sentence.

Yes it does most Germanic and Romance languages.

Yes it does domain independent named entities with a a higher score than anything else on the planet. ALL English classes. Medical, Dental, Animal. (that doesn't include Latin uses of animal names) Technical.

As I said we are just stepping out of stealth. I linked a PDF in the comments here.

<comment><USER11> Thanks, that's somewhat helpful. I am not particularly interested in the summarizer plugin itself (mostly because we have one, built in house), but I would love to talk about the underlying pipeline. If you have e.g. a named entity recognition library that performs as well as you say in Romance languages on standard data sets, you have material for at least one conference paper, and furthermore a product much more valuable than the summarizer itself.

My question about speed referred to syntactic parsing specifically. I am sure you can do entropy scoring faster than 200ms per sentence, but unless you have access to parses you are unlikely to be able to do more than purely extractive summarization. That's what Summly does, and every other summarizer on the planet as well. (Except perhaps Columbia's Newsblaster, but that's a bit of a different story).

<comment><AUTHOR> We do extractive summarization because we don't feel that changing the authors words is fair use. We could do rewriting. We actually have an in house demo that for lack of a better word build Wikipedia pages for animals. (animals have fixed traits so it is easier than if we were to try and do general people and the information on them changes much less frequently)

I don't have time to do conference papers.

Our pipeline requires almost every one of our capabilities in order to do TLDR.

We have to grab the page. We have to separate the content from the theme. We have to convert the HTML to a not HTML "thing" that lets us work on the text but maintain the HTML. Then we have to Disambiguate/Segment the sentences. Then we have to analyze the type of content to pick how we are going to summarize it, which requires all the noun, and stemming and keyword analysis, then we have to rank the sentences in importance based on concepts and causation, and readability, and emotion. Then we have to put all the HTML back, and present it to the user.

We set the goal that Tom Sawyer can't take more than 45 seconds to run.

<comment><USER11> Fair use or not, if you could do it I would buy it :) Fine, forget conference papers. If you can demonstrate fast NER in multiple languages, across domains, with competitive precision/recall metrics, I will buy it. The rest of it is not particularly interesting to me because it's frankly not that hard.

</comment></comment></comment></comment></comment><comment><USER12> Aside from the NLP-related aspects, which are pretty interesting by themselves, I was glad to see this:

> The biggest thing I learned. The thing I also hope my team has learned. > Everyone else has hit the limits of what they can do because they weren't > willing to burn it all to the ground and start over. We start over a lot. We > code for 3 days and then decide this won't work, and we do it over again. We > take the lessons we learned but little of the code. The second, or thrid > time we do it right based on what we now know.

I am a big fan of rewrites, and am sad to see how much of the software engineering world has centered around the Spolskyesque idea of rewriting being a horrible waste of time. Truth is, 99.9...% of software just sucks. The more and more infrastructure we build up around it, the more constrained we become. Just look at the most common languages/tools/technologies we use on a daily basis. C++/Java/JS/Python? These are just awful. Hell, I'm even like Python compared to most languages, but there's still so much historical cruft, and it's ridiculously slow to boot.

I think this is mostly because people just suck at writing software in general. Rewriting in the industry usually doesn't buy you anything since it's the same people writing it, and they're still constrained by all the other software that they interact with. But if everyone was more willing to rewrite, focusing on code quality, I believe our tools would be less intertwined, we could achieve much faster rates of progress, and the life of a software engineer would be a lot more tolerable.

<comment><AUTHOR> I fixed my misspelling of third...

I think for us the biggest thing is that often we don't know what approach will work best until we try, and often we have to balance more than just readability or performance. Memory usage issues meant that we prototyped one way for getting all the words in to memory, proved that we had enough information about the words for 99% of what we were going to do, and that we could get the other 1% later, and then re-wrote with a different "loader" and different information about the words loaded.

I like functional programming but it made sense to make parts of the code object oriented not just for readability or ease of programming, but because it was more performant.

So our rewrites are partly for performance, partly because the end goal moved slightly, and partly for maintainability. As we stack on new features often the way we should do things changes drastically.

<comment><USER12> > I think for us the biggest thing is that often we don't know what approach > will work best until we try

Absolutely--and I think pretty much all software is like this. Engineering/optimization is, in a vague sense, all about how much shit you can throw at a wall and how well you can tell what sticks. The faster/easier/more accurately you can do this, the better. If you're going to be bound to the first pile of shit you throw due to business constraints or whatever, you're not likely to end up with something very nice.

</comment></comment></comment><comment><USER13> When smart people get cocky about the hard work they've done, it gives me great confidence in their claims. Cockiness for smart people is reserved for only such occasions when the problem has been solved and tested, born into a growth state, ready to evolve. I am following this story with great interest because I'm rooting for the creative geniuses at Stremor and for the technological advances they are producing.

</comment><comment><USER14> "I am sure I will have a lot of mistakes for the grammar Nazi's to point out in this post."

I'm hoping this was a subtle and brilliant joke and not just a typo.

<comment><AUTHOR> In a VC pitch you always include a small easy to fix, minor issue. One you know the answer to. That way they point it out, you tell them how smart they were for mentioning it, and then the solution. They feel like they proved you aren't perfect, and you avoid them poking hard enough to find your real issues.

</comment></comment><comment><USER15> It would be cool to be able to download an SDK and build experiments with this without having to email sales and engage in a licensing agreement for the software first. I've always appreciated the fact that SaaS products like parse.com, twilio.com, and stripe.com have a low barrier to experiementation and probably lends to the reason why so many solutions today use their technology.

<comment><AUTHOR> We are working on getting it in to the Azure Data Market place with a free monthly tier of a certain number of API calls. Microsoft is being slow (more than 5 weeks). We are looking at Mashape but we have not heard good things about their uptime, and their accuracy in billing.

As a developer I feel your pain. Balancing our building, business concerns, and support for an API is hard. We are a small company and are doing our best. But if you do email sales we will make sure to get you access to the API as soon as it is available.

</comment></comment><comment><AUTHOR> We were mostly flying under the radar. But with two companies doing summarization being bought for $30M in the past month we are becoming less stealth.

I know it sounds like a bold statement, but I believe it to be true. Doing things right required we build our own tools, and not rely on libraries from third parties. I think we benefitted a lot from that philosophy.

</comment><comment><USER16> I installed the Chrome plugin with interest, but it only seems to work on the stremor.com page. However, for all I know it's in alpha/beta stage.

Like the general approach, which looks very promising.

<comment><AUTHOR> Did you restart Chrome after? It should work everywhere.

<comment><USER16> And now it does, I'm happy to say.

</comment></comment></comment><comment><USER17> I can't be the only person who wanted to write this:

tl;dr

<comment><AUTHOR> We have an app for that. <http://www.tldrstuff.com>

The "short" 25% view is pretty good on this. The summary doesn't read as well because it picks up the ReadMe because I didn't mark it as code snippet because I'm sucky at WordPress editing.

</comment></comment><comment><USER5> I am supposed to buy tools for analyzing writing from people who cannot write?

<comment><AUTHOR> People become editors at book companies not because they can write, but because they know how others should.

I'm confident few of the Engineers for F1 racing are spectacular drivers.

I know my PE teacher couldn't touch his toes.

<comment><USER5> If you can determine whether someone else's writing is good, it follows that you can determine whether your own writing is good.

Engineering race cars well is distinct from driving race cars well.

If your PE teacher were capable of touching his toes, he would discredit himself by choosing not to.

</comment></comment></comment><comment><USER18> Any chance this project will ever be open-sourced?

<comment><AUTHOR> Parts of it maybe. But as a whole not likely. Much like SRI we are hoping that we will license the tech to companies. We could build full products, but we think that the way this can be best applied is as enhancements to other products. Search, Technical and Customer Support, Content Authoring, News Aggregation.

We also have tech that could vastly improve book and movie reccomendations based on the content and themes of books, not just "did someone like you like this" kinds of systems.

<comment><USER19> So I guess whatever scientific insights you've gained that make you claim that linguists know nothing about modern English will remain unknown. At least the linguists publish.

It is too bad because apparently we wouldn't need to study language and cognition any more if we had access to your work. I mean, why bother with neurolinguistics or anything having the stink of biology or psychology? Brain mapping projects and experimentation have nothing to tell us now that we know that there are 3.2 million words in English. That has been the burning question after all.

You've made some progress working on the most widely and deeply studied language in the world with a richness of written data available that is unprecedented. But the linguist working to record, preserve and study a small Amazonian language that works nothing like English is probably just an idiot because they haven't figured out how language works yet.

Do you even know what linguists are?

<comment><AUTHOR> I can rephrase. Google releases their billions of NGrams. They did so because they knew that it would scare anyone from competing. Not because they thought it would help. They aren't that nice.

Will I ever share? Possibly. But like Google it will likely be when I have a competitive advantage. I don't not share because I'm mean. I keep things close because as someone on the thread mentioned that they are competing if I published all the information you mention, then Google would build what I have built and we'd be out of business.

Those brain mapping projects aren't done purely for the good of mankind they are trying to make money and get funding. My goals are the same.

<comment><USER19> I wasn't implying that there was anything wrong with making money, just that if you're claiming that you're leaving the scientific study of language in the dust and insulting the people working in that field, it seems a little strange at the same time to not publish your insights. If you're competing with scientists, you kind of have to produce science, right? You made great software but why insult people working toward the understanding of language? Be more specific with what particular linguists you're talking about if you have a beef with someone. Why insult an entire discipline if you aren't even taking part in the discussion by publishing?</comment></comment></comment></comment></comment>


Ask HN: How much do you pay software engineering interns? - <AUTHOR>

I am curious to know the general salary a decent intern would expect to make. I know some SF startups offer up to $7000 a month for interns, but other places don't go more than $3000. I am looking for companies both in the US and Canada. <comment><USER2> I'm getting paid $24/hour at a startup in Ontario, Canada.

<comment><USER3> Of which a large % is being subsidized by the government, most likely. Seems rather high for an intern.

</comment></comment><comment><USER4> From the intern side, when I have been paid (I had a three-year unpaid internship because it was the best job opportunity around), it's been between $8 and $25 an hour. The $8/hr was for other jobs in which I was also asked to do work that included software development. The $25/hr was way outside standard deviation; from reading the want ads and talking to other CS students, intern programmers usually make in the $14-$18 range. A real, non- intern job in IT paid me $16-$17/hr.

<comment><USER5> My first internship (not CS) paid around $14 an hour, with full benefits. My IT internship paid from $15.xx/hr and no benefits, with a standard raise every semester you worked. I know the software interns got paid the same $15.xx starting off, but their raise was variable. I think at the top end they were making $25 an hour. This was in Georgia, so figure COLA adjustments and all that.</comment></comment>


Show HN: Barnett, a design proposal for an extensible EHR system, and my thesis - <AUTHOR> http://barnett.surge.sh/ <comment><AUTHOR> So for my masters in design, I explored healthcare software, particularly the type which deals with patient medical records.

Healthcare software is a paradox to me, because it's so important to our society, but it's just kinda .... shit. After doing interviews and surveys, I can safely say that doctors and medical professionals feel the same. The software my GP uses was literally first put in place when I was born, and it hasn't changed since then.

There are many factors why healthcare software is bad, but one thing is for sure - most health IT systems are huge, complicated, monoliths. Most medical practices have a single system which does literally everything. This makes it super hard to swap out parts of the system to make improvements - you can't just improve say, the appointment management system without touching anything else - you have to do it all at once.

This makes 'upgrading' your healthcare software, stupidly hard, and stupidly expensive. The reality is that a doctor with the worlds best software, and a doctor with the worst will probably see the same amount of patients in a week - it's hard to justify when the cost can literally be in the [billions]([http://barnett.surge.sh/welcome/intro.html](http://barnett.surge.sh/welcome/intro.html))

So what's the future? I think there's three options.

1\. Nothing changes, we keeping doing as we have for the last 30 years or so.

2\. We break up the complexity of these systems, allowing for faster, iterative improvement. This is where my design proposal aims to sit.

3\. A leap frog technology comes along, which either has huge value, or is super easy to implement. Machine learning and modern AI could be this, but it's a long shot, and cultural challenge.

So yeah, this is my thesis, hope you find it as interesting as I did.</comment>