Google Unveils Tools to Increase Subscriptions for Publishers - <AUTHOR> https://www.nytimes.com/2017/10/02/business/media/google-subscriptions-publishers.html <comment><USER2> Subscriptions are just the wrong model for news publishers. There's NO way I could possibly afford to subscribe to every news output I occasionally read news from, unless the subscriptions were so close to free as to be useless as a revenue source for the publisher. It's just not going to happen.

What we desperately need is a real, useful micro-payments model where you can pay per-article. I'd be happy to pay you a few cents, or a dollar, or whatever, for each of the 3 or 4 articles I read on your site per month. But I'm not buying a subscription just to read 3 or 4 articles. The economics just don't work.

<comment><USER3> > What we desperately need is a real, useful micro-payments model where you > can pay per-article.

Former news editor here. I have spent a loooong time thinking about how to help my beloved news industry find a payment model that works. I've become convinced that a "cable subscription" model has more promise than a micropayments model.

Here's what's wrong with a micropayments model. Each microtransaction is an additional cost incurred by the user, and in many models that cost can vary based on the website visited and other factors. And so every single time you choose to engage in a microtransaction, you have to do some brief mental gymnastics to determine whether the transaction is valuable enough to you to proceed. It may be only a few cents, so for many people it's not a big deliberation, but the decision is always there, every time.

The benefit of this approach is that there's very little economic waste involved; you pay only for what you buy. But it encourages stingy, penny- pinching behavior, and that's horrible for adoption. If you want broad, mass- market support, it's a big problem.

Under the cable subscription model, you pay a fixed monthly fee for access to a large number of "channels," and in return you can access those channels as much as you want. Under the hood, that subscription fee can be doled out to each channel based on how much it's accessed, or divided equally, or by some other method in between. But to the end user, it's an all-you-can-eat buffet, and they just don't need to think about it. Part of the fee they're paying is for content itself and part of it is for the convenience of not having to regulate usage.

The downside of this approach is that there's more economic waste involved; some light users won't get their money's worth and will end up subsidizing heavy users. But it discourages stingy behavior, and that's great for adoption.

Later on down the line, once the cable-subscription model has been widely adopted, the market will eventually demand more a la carte payment models (we see this happening right now in the fairly mature cable television industry).

But for right now, widespread adoption should be the primary focus of any online payment model. Ultimately, a good number of the major U.S. news publishers would need to get on board, and to date they have been relatively unwilling to cooperate (which may be due to regulatory hurdles). But I'm pretty sure that's what needs to happen. Less sure whether it will be enough to save the industry.

<comment><USER4> That's the model used by Flattr [1]. They started years ago. Not sure why adoption is taking so long.

> Flattr is a browser add-on that intelligently measures your interaction with > content on the websites you visit, and then automatically distributes the > right amount of funds to those sites you engage with the most.

[1] [https://flattr.com/](https://flattr.com/)

<comment><USER5> I have some tabs in my browser open that remain there for months (poor tab hygiene), how does it account for that?

</comment></comment></comment></comment><comment><USER6> I have no problem with this. But in return I should be able to opt out of results that I cannot view. A result for a news article that changes when I click on it to a "Please subscribe..." plea is _not_ the result that was returned that I clicked on.

Unfortunately, like the AMP fiasco, I doubt this is what will happen as Google doesn't exist to serve it's users.

<comment><USER7> > I doubt this is what will happen as Google doesn't exist to serve it's > users.

There intent is to serve users with quality, truthful information. If all the quality information goes out of business and gets replaced with "Fwd:Fwd:Fwd: Obama failed New Orleans during Katrina!!" then Google doesn't have any more quality information anymore.

Google and Facebook are becoming acutely aware of how easily dishonest propaganda can propagate through their systems and are trying to find a solution for that. One step is making sure that people who have to make a living finding the truth for us all have the means to get paid.

<comment><USER8> Also, it's a very small percent of users who dislike it (or even know AMP is a thing), and majority of them are developers who don't want their site cached. To claim that they don't serve their users is ridiculous.

</comment></comment></comment><comment><USER9> Not the best headline. Here's the gist of it:

> "Google's plans include doing away with the "first click free" policy, which > requires subscription-based news outlets to offer three free articles a day > through its search and news features, allowing users to skirt pay walls. A > new program, which Google plans to start this week and is calling "flexible > sampling," will allow those publishers to determine how many free clicks to > give Google's users."

So sites can still give access to Google visitors (which I bet many will), but they just have more say over the specifics.

</comment><comment><USER10> I happily pay for lots of services, but I just don't think many of these publishers are worth paying for.

I'm pretty tired of shitty clickbait headlines, and stories which cherry-pick a handful of twitter posts to make it seem like there's outrage over something.

Even worse, it seems like most publishers are dead set of trying to feed you their agenda. Why would I pay for misleading or intellectually dishonest articles?

<comment><USER11> These news paid sources are usually only valuable for local content. My local news paper' only redeeming value is it is local but it isn't $4 a week valuable.

<comment><USER12> I agree that $4*52 is expensive, but it could cost less if more people were subscribing. Unfortunately, even at a more reasonable price per month or week, I think papers wouldn't see a surge in subscribers in the current environment.

Short-term, I think people undervalue the value of local news. There are often a lot of info holes when it comes to local government and politics. I wonder if this has adverse affects that lead to less involvement in local politics except when a NIMBY issue appears, which doesn't seem like good governance.

Local news coverage, with the exception of major cities, tends to be sparse and often non-existent. Even for some major areas there can be a lot of holes in coverage.

This problem makes itself apparent to me when come election day I try to look up all of the candidates, and find no info for many of them that isn't from their own website (if it even exists).

<comment><USER11> It is going to bot created I am afraid to say. My city has good local coverage, a wee bit biased but it is local people in a School Board meetings and City Meetings at least.

Google is funding the creation of software that writes local news stories

[https://techcrunch.com/2017/07/08/google-is-funding-the- crea...](https://techcrunch.com/2017/07/08/google-is-funding-the-creation-of- software-that-writes-local-news-stories/)

</comment></comment></comment></comment><comment><USER13> Just change your web browser's User-Agent to the Google crawler?

<comment><USER14> That said, some publishers are smart and also check to see if your IP is in a Google range.

EDIT: That is, you can check the PTR record of an IP: [https://support.google.com/webmasters/answer/80553?hl=en](https://support.google.com/webmasters/answer/80553?hl=en)

<comment><USER15> You can set the PTR record of an IP to a domain you don't control. Most ISPs won't let you do that, though. Also, whatever host you set as the PTR record won't resolve back to your IP.

<comment><USER16> XS4ALL in the Netherlands lets you. I never knew I should be using it for that -- I just set it to match my email domain to end up in less spamboxes.

</comment></comment></comment></comment><comment><USER17> Cue massive drops in traffic (again) and news orgs whining about it (again) and blaming the next boogeyman, whatever that is. Probably something something "piracy" etc.

Paying/subscribing for general-purpose news is old news. It had its time, and that time is over. Much like music industry CD sales with the real rise of p2p, news orgs will have to figure out what their "ipod" equivalent is going to be.

</comment><comment><USER18> We should just go back to having newsies selling newspapers on the street corner for a nickle. Study has found that there is a direct correlation to musicals about newsies when they are a significant portion of the news ecosystem.

</comment><comment><USER19> Like others I think a well done micro-pavement or bundle of payments would be nice.

One thing I think that is missing from the discussion is metrics. If you do a nice job building the site, and let users give an indication whether they want to see more or less coverage on the topic, you can offer this metrics data back to the news outlets, which can give them far better direction than simply looking at website clicks (which encourages click-bait). This, along with a slice of micro-payments would be valuable to them.

</comment><comment><USER20> As a side note google gave me a free digital subscription to the nytimes for posting reviews on google maps. Is google or nytimes making money off of this?

</comment><comment> j-c-hewitt Maybe non-subscribers should get a lite reader's digest type abstract of the article instead of the truncated/cloaked stuff that currently gets served on sites like WSJ. Most articles can probably be described in 50-100 words or less. The automatic truncation is often less descriptive than a good meta description would be.

</comment><comment><USER11> Block the paid wall sources so you are not annoyed anymore.

I have CNET blocked due to their CBS and CES Fiasco and never unblocked them.

[https://news.google.com/news/u/0/settings/sources?hl=en](https://news.google.com/news/u/0/settings/sources?hl=en)

</comment><comment><USER21> Called it [0]

[0] [https://news.ycombinator.com/item?id=15383058](https://news.ycombinator.com/item?id=15383058)

</comment><comment><USER22> The O'Reilly Safari system is a great alternative to paywalls. You pay for Safari and it pays out royalties to the authors proportional to how many users read your book that month.

So an author of a book that had 200 readers would get roughly double the pay of one that has 100 readers.

I would gladly pay for a kind of all access pass that divided up my subscription money to the news sites I visited the most.

Of course, if someone goes to 200 different sites equally an individual publisher would get less from that customer but I think that's fair.

<comment><USER23> There's an older version of this principle used to compensate authors for library borrowing in the UK and other countries called Public Lending Right.

The government puts some tax money into a pot, and it's paid out to authors in proportion to the number of loans of their books. There's also a cap to stop the bulk of the money going to a handful of bestselling authors.

In some ways, this can be seen as croudsourcing decisions on government subsidy, which is an interesting model.

</comment></comment><comment><USER24> Publisher have one and mostly one way to be profitable. Shrink the overhead with 90%. If they cant do that most of them are simply not going to survive.

Subscription or no subscription.

</comment><comment><USER25> archive.is still captures text from most of these.

</comment><comment><USER26> Unfortunately there is no need to pay for news articles, there is a need to pay for RESEARCH and MEDICAL papers.

News? No.

</comment><comment><USER27> Paywalls are a dying gasp being uttered by the publishing industry.

Here's why they don't work:

\- If I respect a publication and feel that the content has value for me, I'll happily subscribe.

\- If I click on a clickbait headline only to arrive at a paywall, it's like a small and unpleasant electric shock, punishing me for clicking the link.

\- Paywall creators think that the combination of clickbait and paywalls is magical and gets people to subscribe, but it does not, it only creates negative emotion and irritation.

\- There is no such thing as a free lunch. If publishers want subscribers they need to consistently produce high quality content day after day, week after week. They also need to forego the sugar high of clickbait.

\- That means there can't be some sort of social virality genius telling the editor how to title articles and showing charts of all the clicks from Reddit, etc. Doing this may generate some incremental subscribers, but it does so at the cost of the publication's brand image.

\- The approach Salon used of showing the first third or half of the article is better than a "You obviously love great journalism" banner. Let the content stand on its own and earn the subscription.

\- I have not been able to bring myself to subscribe to the NYT or WaPo for one simple reason -- around half of the articles they publish are very low quality and many have clickbait headlines. The article headlines have the feel of being ads themselves that falsely represent the content of the article. In many cases the articles are pretty solid reporting, but the headlines oversell them as being the article that will bring down the Trump presidency.

If I were a journalist I'd be pretty outraged if I took the time to write a thoughtful article and then some virality genius retitled it something silly and tribe-oriented to get the shallowest of readers to thoughtlessly click it.

<comment><USER13> Agree. Also, the websites that try to get you to unblock ad blockers are equally irritating. Usually I just leave, and find another source of the same news. In many cases their ads are super annoying and CPU-intensive, which is the main reason I block them; it's not that I hate advertising itself. If they were just a simple <img> tag and a hyperlink without a huge pile of JavaScript bloat I would probably not bother blocking them.

<comment><USER27> Indeed. It's true, in a world where a major newspaper will decide to write a multi-page story about one of Trump's silly tweets and run it on the front page, it's not all that hard for a large number of news orgs to write a similarly informative story, and many make it available for free.

I agree about ads, but my least favorite are the ones that begin playing video in a tiny window that devours laptop battery life... It's strange to imagine the marketers who are designing these pages. They must imagine that all of us read only when watching TV is not an option, so they try to make the website as much like TV as possible, complete with a tiny screen that you can click on to simply shift into couch potato mode.

</comment></comment></comment><comment><USER28> GoFundMe?

Patreon?

Those who could find people to buy what they are producing, are already doing it on social funding platforms.

The models that are struggling are those who are not able to sell what they have to sell... a product that not only sold ad-space but infoticles, just like infomartials on TV or product placement in movies, there was paid bias in articles. In the days of Internet, no body wants to watch ads, not in the sidebar clearly labeled as an ad, or in the center of the page in terms of a info(ar)ticle.

I would rather pay to hear the bias of the person speaking, than letting a corporation tell that person what he or she can or can't write. There is banding together of like minded people to pool resources together to keep making progress on a cause, much better model than a corporation. Much efficient use of funds, time, energy. The only one to loose is the investor or influence seeker, who would have to do much more digging than just walking into an top floor office with a check in hands.

</comment><comment><USER29> To block news sources in Google News go to Settings > Sources and add the domain to the Block section.

Used to have to add the source, then slide the frequency slider down to 0. Looks like Google automatically moved them to blocked.

Better yet, just have a setting to automatically block all sites using paywalls. They have a right to deploy paywalls, we have a right to request never to see them in our feed.</comment>


Meatier – A Meteor alternative - <AUTHOR> https://github.com/mattkrick/meatier <comment><USER2> Wow, there's a ton of jerks here dissing the variety of javascript frameworks here.

Look, the web is a fast evolving platform. Similarly, the best way to understand the tradeoffs a framework makes is write your own own! You probably shouldn't use it in production, but it's a good exercise. And writingcode is so easy to do (just code for awhile!) that we're getting a proliferation of it. This is a good thing!

I just wrote a carousel widget in jquery. Yeah, I know there are 10million carousel widgets I could have downloaded, but I wanted to understand it better so I made it on my own. (And yeah, I know carousels suck, tell my company's marketers that.)

We don't hear complaints when people try building new game engines from scratch. Granted, maybe those aren't posted on HN often?

@minionslave, @untog, @sergiotapia, looking at you guys.

// edit: And looking at the github page, this isn't really a new framework anyway? It's like... the web-dev equivalent of a review paper. He looked at meteor's stack, and swapped a lot of the component pieces. And that's cool and informative.

<comment><USER3> Why directly mention people you disagree with? Will that accomplish something?

<comment><USER4> It might. There is no other good way to directly reply to multiple comments without duplicating the reply. Maybe it will encourage them to join this discussion. It also is less vague than leaving them off.

</comment></comment></comment><comment><USER5> As someone who works in JS day in day out, I'm becoming less and less sure the entire ecosystem isn't an elaborate parody.

Replacing one monolithic structure with another one because the component parts aren't right? Just skip the monolith part and use the components you want.

<comment><USER6> > use the components you want

That's what he did. Anybody is free to use it or not...

I'm starting to think a part of the javascript fatigue is caused by people complaining.

<comment><USER7> Bingo.

<comment><USER8> Monkey see, monkey be.

</comment></comment></comment></comment><comment><USER9> I made this. Neat!

For those that didnt read more than the title, it's database agnostic. It scales vertically and horizontally. It's not a framework, frameworks are dead. Its just a bunch of packages that fit together like Lego pieces.

If you don't need these things (or don't know what they are) don't complicate your life! Get off HN and build something :-)

<comment><USER10> JavaScript doesn't really scale vertically, not by standard usage. You can't double the CPU cores and RAM and I/O and double your throughput.

</comment></comment><comment><USER11> This is far closer to mainstream JS - with the benefits that offers, eg, wide user base, maintained version of node, etc - while offering the same 'change item in browser, DOM updates, DB replicates, other clients see changes' as Meteor did.

</comment><comment><USER12> I like the idea of this; it's really what Meteor should be but they'd provide support/hosting/etc.

One thing I'm concerned with in general with stacks like this is their use in mobile stuff - even React+React Router+Redux+redux-form adds a fair bit to a payload, even before you start developing an app. As nice as it is to use, for mobile I roll my own.

<comment><USER13> Very true, but there are some promising build tools like Rollup and React API- compatible alternative libraries with smaller sizes available for a payload- sensitive context.

</comment></comment><comment><USER14> Is this a parody? It must be right?

"Meteor is awesome! But after 3 years, it's starting to show it's age."

Edit: Reading more into it, this is just a starter kit and not a replacement for Meteor. You lose everything that made Meteor insanely popular, for what exactly? RethinkDB?

<comment><USER15> Makes a point of Meteor's age and then proceeds to say that they're using 0.10 node with a bit about not upgrading anytime soon. Seems legit.

<comment><USER16> He was complaining about meteor using node 0.10. This uses node 5.x

<comment><USER15> Oh I misread. That's a really good point and it's too late to edit my comment. Thank you.

</comment></comment></comment></comment><comment><USER17> RethinkDB + graphql is exactly what I missed from Meteor :) Meatier seems like a promising stack.

</comment><comment><USER18> Looks interesting - I only briefly tried Meteor, but it seemed like one of those very tightly-coupled frameworks - everything is all nice and sweet as long as you're using all of the official stuff, but try to switch out something, and you're in a world of pain. Sounds like this is trying to both switch out some of Meteor's choices that haven't aged so well and also make the whole package more modular.

</comment><comment><USER19> Nice project, but wouldn't call it yet Meteor alternative. It looks more like Meteor 0.x, but done with a few different tools.

Still it doesn't solve my main problem with Meteor adoption. Right now if you would like to use Meteor you need to start from scratch using specified database. That limit adoption a lot. I would love if Meteor could be adopted more incrementally by companies (e.g. write collaboration layer to your existing app).

</comment><comment><USER6> Looks like what Meteor team are planning to do...

Very interesting as a complete web app starter kit

<comment><USER20> True! Seems pretty much the direction meteor is taking & is an interesting web app starter kit :)

<comment><USER21> Except Meteor will not be using Webpack

<comment><USER22> Real shame, Webpack rocks!

</comment></comment></comment></comment><comment><USER23> JavaScript people have programming ADHD. "This system works fine, but we've been using it for too long, let's just rewrite it with the latest greatest" "Angular, let's rewrite that from scratch"

Imagine is Microsoft released a totally new version of C# every year, and stops supporting it.

<comment><USER11> > "This system works fine, but we've been using it for too long, let's just > rewrite it with the latest greatest"

You realise this is the opposite of that? Common, popular, existing tools, working together out of the box, replacing something that's generally regarded as weird and custom by the general JS community?

</comment></comment><comment><USER24> I just don't understand how anyone can make a "best" decision these days.

I'm not a frontend person. I'm backend and middleware and infrastructure, although I'm trying to figure out the front end stuff.

Maybe I just don't understand what people are trying to accomplish. In fact, I'm sure of that. I can't for the life of me figure out why you would want to have your front end so tightly coupled to you database.

Can someone explain to me in simple terms how and where I would use one of these JS frameworks in the context of a Python or Golang or Ruby/Rails app?

<comment><USER25> When I had to learn Python to do my job, I read a few pages on python.org, and one of the things it mentioned was that 'a python developer can do in a month what a C++ developer can do in a year".

Expressive, concise code is always a good thing.

Meteor is excellent for MVPs and POCs; there are a lot of people out there with big ideas, but limited budgets to test out those ideas.

In Meteor, you can access your collections from the client and the server; and the vast number of packages on atmosphere makes writing a webapp in Meteor feel more like assembling lego than anything.

The speed at which we can write software is tightly correlated with our ability to innovate quickly; test things out, keep what works and throw away what doesn't.

I've developed things for clients in Meteor, in a matter of weeks what others have failed to deliver in year

90% or so startups fail, not because your front and backend were too tightly coupled, but because of a whole variety of other reasons. Given that most of that code will end up in the bin anyway, might as well focus on quantity, and switch to something more robust when need be.

</comment></comment><comment><USER26> How does this do server side rendering but also uses local storage for storing auth token?

</comment><comment><USER27> This is the exact same stack and components i was thinking about for a while, nice job integrating everything together!

</comment><comment><USER28> You should capitalize the M in the title.

<comment><USER28> People downvoting me: the title was something completely different when I wrote this.

</comment></comment><comment><USER29> My main wish is that it was written in Go. Maybe I'll do that someday. Maybe.</comment>


INISMO - Manage your funding activities - <AUTHOR> https://inismo.com Online platform for investors & entrepreneurs to manage their entire funding activities like project collaboration, deal flow management, deal negotiations and project listing <comment><USER2> I really liked the environment to find new projects to invest and also the very good support for who is now beginning.

</comment><comment><AUTHOR> Great solution, good to get supported with the whole funding process.</comment>


Is TechCrunch doing sponsored posts now? - <AUTHOR> http://www.crunchgear.com/2010/09/09/the-chevy-volt-saved-gm/ <comment><USER2> Is this title ("Is TechCrunch doing sponsored posts now?") just a snarky way of commenting on a CrunchGear story that you think the reporter is in the bag for GM, or is there something in the story that is literally evidence GM paid for its placement?

If it's the former, please don't do that; it's against the site guidelines. Use an accurate title and put your editorial comments in a comment.

</comment><comment><USER3> No. Was there something specific about the article that made you wonder that, or is this merely one of the knee-jerk reactions we get every time we write a positive article about anything?</comment>


Consolidation in the Telecommunications Industry (infographic) - <AUTHOR> http://online.wsj.com/article/SB10001424052748704471904576229250860034510.html <comment><USER2> A small telco startup, launched back in the 1960's, played a critical role in breaking up the Bell monopoly. It's a great story if you're not familiar with it. They were using a new technology that would result in affordable long- distance calls for the masses. Later, they would also create the first commercial electronic mail service.

PBS recently aired a documentary on the story called "Long Distance Warrior". It's about MCI and its founder, Bill McGowan. Here's a preview: [http://chicagotonight.wttw.com/2011/09/21/long-distance- warr...](http://chicagotonight.wttw.com/2011/09/21/long-distance-warrior)

</comment><comment><USER3> Consolidation also happens with vendors, think nokia-siemens, alcatel-lucent, cisco bought 100 smallish companies, big companies "innovate" and remain cimpetitive by acquiring the competition</comment>


Code Like a Pythonista: Idiomatic Python - <AUTHOR> http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html <comment><USER2> One thing that has always bugged me about PEP8 is the advice about trying to keep line length to <80 characters. It seems a little dated.

I basically just completely ignore this part of the guidance, even though I know that in theory it makes it hard to edit code via a terminal. But this is not something we ever do in practice where I work - code on servers gets there only by being checked out of SVN.

I personally find it incredibly irritating when I see people who've split a function call over a couple of lines just to try and meet this criterion, e.g.:

      def __init__(self, first, second, third,
                 fourth, fifth, sixth):

Note that if you're creating functions with very long signatures you're probably doing something wrong.

About the only time I make any kind of concession to the line length guidance is when I initialise a big dictionary, e.g.:

      my_dict = {
          ham: eggs,
          bar: quux,
          # Snip 10 lines of code
          rhubarb: custard
      }

(There are often better ways to do this too, but sometimes it's necessary for clarity to build a dictionary all at once like this.)

I'm perfectly happy to initialise dictionaries with a small number of keys just like this:

      my_dict = { ham: eggs, bar: quux, rhubarb: custard }

<comment><USER3> It's easier to read something quickly if your eyes don't have to travel far. This is why newspapers (remember them?) are written in multiple columns across the page.

This may be less of an issue with code, due to its structure, but I still find it much easier to read 80 column code than code that stretches across the screen.

If I'm reading code in an 80 column terminal I prefer the line breaks to come from the human that wrote it, to show and reveal structure, rather than having it arbitrarily broken at 80 columns by the editor.

Another reason is that most of your code won't stretch across the screen, but you need your window sized for the small amount of code that does, losing a bunch of screen estate to empty space.

But I don't worry too much about it.

<comment><USER4> Code is not prose. The layout rules that apply to a written article do not (necessarily) apply.

I prefer code that can be quickly scanned, and hard wrapping at 80 columns (IMO) doesn't facilitate this.

If someone doesn't like it, they can turn on text wrap.

<comment><USER3> "I prefer code that can be quickly scanned, and hard wrapping at 80 columns (IMO) doesn't facilitate this."

Then you shouldn't hard wrap at 80. Subject to any agreements with your team members. :)

I'm just speculating on why some people recommend to break at 80, which was originally the length of a physical punch card and so has nothing much to do with readability in and of itself. Fundamentally, 80 is likely just the most likely common denominator (MLCD).

</comment></comment></comment></comment><comment><USER5> I have just skimmed this so far, but it looks very good.

A lot of the Python scripts that I see at work look like either C programs or glorified batch files. I'll definitely point people to this when they are ready and willing to move on to the next level.

Well done.

Suggestion: one thing I didn't see mentioned is switching from "if s.find(c) == -1: ..." to "if c in s: ...". I see people do that a lot.

<comment><USER6> _one thing I didn't see mentioned is switching from "if s.find(c) == -1: ..." to "if c in s: ...". I see people do that a lot._

I think this is covered implicitly by the two "Use in where possible" sections. Although as Tim Peter's The Zen of Python states, which is also quoted in the tutorial, "explicit is better than implicit." If people are doing that despite knowledge of the in keyword then I suppose that just proves Tim's point.

<comment><USER7> I don't know. I'd argue that

      if c not in s: ...

is more explicit (and readable) than

      if s.find(c) == -1: ...

</comment></comment></comment><comment><USER8> Read from the perspective of someone very much still learning to code, this was excellent. I particularly valued the idiomatic comparisons to 'naive' implementations (the kind I would initially reach for). One of the later sections on lazy generation also opened up some new doors for me, and gave me a nice solution to a problem I've been having with a piece of code.

</comment><comment><USER9> Is it really idiomatic to use intrinsic truth values (eg, using "if x" instead of "if x != 0")?

Here are my arguments against it:

\- "Explicit is better than implicit."

\- If there's need for a table as reference for what is intrinsically true and what is intrinsically false, then it's clearly not "elegant" enough for people to just understand from looking at the code.

\- Conventions vary across languages. You're basically forcing anyone who looks at your code who's not used tons of Python (and who would otherwise completely understand the code) to look up that table.

<comment><USER10> \- But readability counts. Having written a lot of Java and Obj-C lately, I honestly prefer the ability to write "if (foo && foo->bar && foo->bar->baz)" in the latter.

\- Frankly, it's not a very complicated table. "Zero, empty, or none" summarizes it pretty well. <http://docs.python.org/release/2.5.2/lib/truth.html>

\- Of course conventions vary across languages. If you're familiar with perl, awk, or ruby, some of these conventions will be familiar to you. If you're more familiar with Java, they'll feel odd and you'll feel an uncertainty using them.

</comment></comment><comment><USER11> In case there are Pythonistas here who will indulge a question: one thing I've never figured out how to do elegantly ("idiomatically", I suppose) is create a list of predetermined size initialized with a constant(usually zeros). I always end up with something kludgey like:

        x = [0 for i in xrange(0..100)]

which seems so roundabout it can't possibly be the right solution.

<comment><USER12>
        x = [0] * 100

<comment><USER13> This is much better than my own comment - I never even knew about that syntax!

Is it efficient though?

<comment><USER12> My guess is that it's optimized, but I don't know. Semantics-wise, it's consistent with list addition.

        >>> [0] + [0] + [0]
        [0, 0, 0]
        >>> [0] * 3
        [0, 0, 0]

<comment><USER13> I just read, that syntax is sugar for the list.extend() method so it's still making copies of the list - I wouldn't use it for a list containing complex objects; but that is very idiomatic for simple use cases (like this one?).

</comment></comment></comment></comment></comment><comment><USER12> Just a note: the optparse module is deprecated, in python 2.7+ argparse is preferred.

<comment><USER14> Doesn't really matter though because using argparse means an additional dependency on <2.7. In practice nobody really uses argparse atm.

<comment><USER12> It's worth knowing given the intent of the original post.

</comment></comment></comment><comment><USER15> He had me up until the part where he wrote an algorithm to specifically leave out the Oxford Comma. :)

Kidding aside, this was a great read.

<comment><USER16> As he remarks, he doesn't take in account the corner cases. Suprisingly, or maybe not, his concatenation statement is similar to what I regularly use:

      def commalist(f, endword="and"):
          "Concatenate a list of strings in the form of 'Red, Yellow, Green and Blue'."
          if len(f) == 0:
              return ""
          elif len(f) == 1:
              return f[0]
          else:
              return ", ".join(f[:-1]) + " " + endword + " " + f[-1]

</comment></comment><comment><USER17> This might be completely trivial, but can someone explain to me how one Python idiom is not to mix tabs and spaces, and another is to align arguments over several lines when needed like this:

      def __init__(self, first, second, third,
                   fourth, fifth, sixth):

I see similar examples elsewhere, and I don't see how you can achieve the alignment without mixing in spaces - at least in some cases. I, too, prefer to align arguments, but it looks bad in places like GitHub and Pastebin, when my Sublime Tex-written code gets uploaded.

Am I missing something here? The two just seem mutually exclusive in most cases (where the alignment position's required spaces % 4 != 0. Is the indentation done with just spaces then?

<comment><USER18> Yes, indentation is done just with spaces. Tabs are not used. Typically you set your text editor to have the tab key print 4 spaces.

<comment><USER17> Ah, there lies the rub. Thanks a bunch.

<comment><USER19> EDIT: Emacs is pretty intelligent when it comes to indenting Python code; it does not merely insert 4 spaces for a TAB, but it automatically aligns your code to the Python expression in your previous line!

I don't know which one is the "right" way, but I certainly prefer Emacs's default behaviour. Maybe I just didn't configure my Vim properly :-)

Example:

        In Emacs:
        def _five(one,two,
        ....,,,,..three,four):

        In Vim, with 4 space Tabs:
        def _five(one,two,
        ....,,,,|hree,four):

        | => cursor position when you press ENTER.

</comment></comment></comment></comment><comment><USER20> I really liked the part about for ... else statement, the body of else statement executes the code after the loop finishes but not if break statement was executed.

I know about this construct but whenever I have a problem that requires it, I always forget and use old:

        if counter -1 == len(obj):
            ...

ugh.

</comment><comment><USER16> I wrote an article about the same subject, albeit much shorter and from a slightly different perspective: <http://www.michielovertoom.com/python/ugly- python/>

</comment><comment><USER21> Can anyone suggest any other materials or resources in the same vein as this?

<comment><USER22> See [http://www.quora.com/How-can-I-learn-to-program-in- Python/an...](http://www.quora.com/How-can-I-learn-to-program-in- Python/answer/James-Thornton)

<comment><USER21> Thanks for the reply -- I should have been more specific. I'm after something that similarly contrasts naive and idiomatic styles.

<comment><USER22> You mean Python specifically or for other programming languages?

<comment><USER21> Python, specifically.

<comment><USER22>
      * Idioms and Anti-Idioms in Python (http://docs.python.org/howto/doanddont.html)
      * Python Idioms and Efficiency  (http://jaynes.colorado.edu/PythonIdioms.html)
      * Python Style Guide (http://www.python.org/dev/peps/pep-0008/)
      * Google Python Style Guide (http://google-styleguide.googlecode.com/svn/trunk/pyguide.html)
      * Pocoo Style Guide (http://www.pocoo.org/internal/styleguide/)

</comment></comment></comment></comment></comment></comment><comment><USER23> In the Java ecosystem, they call it best practices. But of course using the phrase "best practices" these days is considered taboo. Thus the use of the word "idiomatic"?

<comment><USER24> <http://dictionary.reference.com/browse/idiom>

An idiom is rather a _preferred_ practice.

If you take some time to read through some Python source, you'll notice that, although the code uses the exact same constructs that you are used to in Java, it does so in a manner you might find unfamiliar or unpredictable.

One example is the use of try/except instead of if/else (beg for forgiveness rather than ask permission). Another is Duck-typing rather than Interface (if it quacks like a duck...)

Coming from Java and looking at some Python code without forewarning or context, you might just be tempted to label the whole thing as really really bad practice, when in truth, it's just _Idiomatic Python_.

<comment><USER12> To be fair, though, some of the things on that list really do seem more like best practices, like advice not to use:

        from module import *</comment></comment></comment>


Ask HN: Has the bubble burst? - <AUTHOR> I'm seeing an decline on average salary for developers in my country, more startups dying and a decrease in acquisitions from the big tech. Has it begun? <comment><USER2> There is less acquisition and IPO from tech company this year compared to last year. I think more VC are more cautious on their money and taking less risk hence the flow of money has decreased, not necessary bursting the bubble. Just lesser startup without a profitable roadmap.

</comment><comment> the-dude No.</comment>


Show HN: Forecast popular times of public businesses and analytics - <AUTHOR> https://besttime.app/ <comment><AUTHOR> Similar to Google maps Popular times, but with more functionality

BestTime.app forecasts how busy public businesses will be. All you have to do is type the name and address of the public business. For each public business BestTime will try to forecast:

* how busy it will be per hour

* how busy it is now (live)

* list of the visitor peaks per day

* list of all busy hours

* list of all quiet hours

* at what time most people go and leave

* a week overview

* Dynamic data like (time remaining until next peak, or quiet hour)

* All data will be available through the Developers API

* create a dashboard overview with all analyses

Register for free to create a detailed dashboard for your favorite venue. Use the 'compare venues' demo without registration to compare the busyness of all your favorite places

You could use the tool to find popular bars for tonight , or see which gym   in your neighborhood is the quietest. During COVID-19 the tool is useful to see when the supermarkets in your neighborhood are not too busy.

Who else could use this? \- Marketing researchers \- Websites with curated lists of bars (e.g. Best bars in New York City)

Please let me know if you have any feedback or (partnership) ideas for tools I can build on top of this API.</comment>


What ruins can teach us about beauty and decay - <AUTHOR> https://www.washingtonpost.com/outlook/what-ruins-can-teach-us-about-beauty-and-decay/2020/02/06/1f26cb98-3e3b-11ea-8872-5df698785a4e_story.html <comment><USER2> An earlier book about the subject is "In Ruins" by Christopher Woodward.

I also liked this "Ruins and Futurity" article [http://www.sf- encyclopedia.com/entry/ruins_and_futurity](http://www.sf- encyclopedia.com/entry/ruins_and_futurity) about the use of ruins in science fiction.

</comment><comment><USER3> I was only able to read one paragraph due to the paywall. Do you have a workaround? Thanks.

<comment><USER4> [https://archive.is/Y60oM](https://archive.is/Y60oM)

(Generally, just pasting a paywalled article URL into archive.is works.)</comment></comment>


Amazon to offer Library Lending to Kindle through Overdrive - <AUTHOR> http://www.crunchgear.com/2011/04/20/amazon-partnering-with-overdrive-to-bring-kindle-library-lending-to-11000-libraries-across-the-us/ <comment><USER2> This is _huge_ for Amazon, because it eliminates the one competitive advantage the Nook (and others to a lesser extent) had over the Kindle -- compatibility with libraries.

As far as the potential for format fragmentation goes, it's still the wild west as far as the relationship between libraries, publishers and e-books go.

</comment><comment><USER3> We have this wonderful technology called "computers". It allows us to replicate information with a marginal cost approaching zero, and yet we continue to handicap its potential so that it could resemble the printing press of the 16th century.

<comment><USER4> Correct. The publishers are trying to enforce scarcity, so that they can make money.

Said money redirects - eventually - into the coffers of those who are the creators.

If there is no scarcity, then there is no incentive to give creators besides your personal ethics.

Supply/Demand/Price curve. If supply is infinite, then price goes towards zero.

If price goes towards zero, then no one gets paid except by sponsors/patrons[1]. Are you sure that's the world you want writers and musicians to live in?

\--- [1] Do you want those sponsors to control the ideology spoken by artists?

<comment><USER5> If your conclusion was correct, the music industry would have run out of money and died. That has not happened yet. How do you explain how your theory does not match observed reality?

<comment><USER4> Things take time to play out. Plus, physical CDs are still pretty popular it seems.

<comment><USER5> How long? We're 10 years after Metallica sued Napster and the music industry is still going strong.

</comment></comment></comment></comment></comment><comment><USER6> This is really awesome. I realize there will be limitations with the borrowing (despite the fact that they are digital books, there will be a limited number of "copies" available to be distributed at a given time), but that's totally understandable. I do hope, however, that you don't have to actually be at the library to download the books, that it can be done remotely.

If they throw a full functioning OS, like Android, on the next Kindle, keeping it at it's current size, I'm all there.

<comment><USER7> They have that already, but Amazon doesn't make it and it's called the Nook Color. I've got one and am using it more than my iPad.

</comment></comment><comment><USER8> Any idea if this will still subject participate libraries to publishers' rules surrounding e-books, like HarperCollins' idiotic 26-circulation limit?

<comment><USER9> My concern is that making ebooks easier for libraries to obtain will encourage them to reduce or eliminate the printed version.

More most reading I prefer having a book, and every so often I look for something in my local library and find they only have some electronic version.

</comment></comment><comment><USER10> If I live in one city, would I be able to access the library of another city? Do all libraries essentially converge into one big cloud based library?

<comment><USER11> It wouldn't be _that_ new if they did - we already have interlibrary loan, especially within states and throughout academia. Just go to worldcat.org, look up the book you want, and see if your library can do ILL with any of the libraries that come up.

</comment></comment><comment><USER4> Massively awesome.

I need to start showing up at my local library meetings.

edit:

For the purpose of working to bring e-books to our local library system.

</comment><comment><USER12> Yet another one of those times when I wish I lived in America. I don't want to move, so I'm going to start inventing the future right here damnit.

<comment><USER13> I'm an Australian living in America; I sometimes seriously cite the lack of an Australian Amazon (or real equivalent) as one reason not to move back. Other, more normal Australians don't disagree.</comment></comment>


The Song 'Oh Yeah' from 'Ferris Bueller's Day Off' is the Origin of a Fortune - <AUTHOR> http://www.wsj.com/articles/oh-yeah-the-song-from-ferris-buellers-day-off-is-catchy-irritating-and-the-origin-of-an-investing-fortune-1485531358 <comment><USER2> The whole album by Yello is fantastic. Not a bad track and has guest vocals by Shirley Bassey of Goldfinger fame.

</comment><comment><USER3> Hmm, well, part of the "origin of a fortune".

Dieter Meier of Yello was already very rich (son of a big-time Swedish (edit: Swiss) banker).

<comment><USER4> Swiss, not Swedish.

Switzerland - bankers, cuckoo clocks and chocolate

Sweden - IKEA, meatballs and Spotify.

<comment><USER3> Yes. Actually a typo, since I know where he is from and the differences between the two countries (e.g. not a "I want to visit Austria and see the kangaroos" mistake).

</comment></comment></comment><comment><USER5> I was in elementary school when i first saw Ferris Buellers. I used to wake up early, ride my bike to school and wait for school to start in the dark with a few other kids. We thought it was fun to be at school a few hours before anyone got there. That all changed once I saw the movie.

<comment><USER6> Oh no!

</comment></comment><comment><USER6> 'On March 23, 1994 between 3 and 4 in the afternoon, Dieter Meier will be standing on this plaque.'

[https://dialoguesentredeux.wordpress.com/tag/train- station/](https://dialoguesentredeux.wordpress.com/tag/train-station/)

</comment><comment><USER7> Mirror, or paywall workaround?

<comment><USER8> Click the "web" link under the title on HN.</comment></comment>


Sorry, Skittles, your prank offends me. I'm going to go buy me some Chuckles, stat. - <AUTHOR> http://technologizer.com/2009/03/02/hey-skittles-get-off-of-my-cloud/

<comment><USER2> Twitter is (among other things) a communication medium. To call an innovative use of a communication medium "co-opting" it seems unfair to me; if interesting memes didn't spread through it, it would be a failure. Evan Williams noted in his TED talk that new, unexpected uses of Twitter are exciting and welcome.

Do something remarkable, get remarked about. It seems an honest form of marketing to me.

<comment><USER3> Agree. What other things is twitter, however?

<comment><USER2> Apologies for the late reply, MoeDrippins; hopefully you'll see this if you check out your comments list.

I originally wrote that Twitter was a communications medium. But then I considered that people might be offended by Skittles on behalf of the Twitter community, or Twitter the company, and in those ways, Twitter is more than just a communication medium.

I think its importance as a communication medium is paramount.

</comment></comment></comment><comment><USER4> "Actually, almost none of the conversation about the stuff has to do with any of the things that make Skittles Skittles: It's just folks mentioning Skittles to get on the Skittles home page."

He clearly misses the point. They're mentioning Skittles and that's effective brand building.

<comment><USER5> Several of them seem to be mentioning Skittles to build their own 'brand' - online persona/spamming/looking cool/etc

I'm really not sure having your brand associated with spam/abuse/people trying to say idiotic+offensive things, is a good idea personally. It's like a massive bait to get people to abuse your product.

The google serps are already filling up with links between "skittles" and random abusive offensive stuff.

</comment></comment><comment><USER6> I totally forgot about Skittles before I saw this, I went to the store today and bought some. They are still awesome and taste like floor wax.</comment>


Silicon Valley Is Over, Says Silicon Valley - <AUTHOR> https://www.nytimes.com/2018/03/04/technology/silicon-valley-midwest.html <comment><USER2> [https://news.ycombinator.com/item?id=16517601](https://news.ycombinator.com/item?id=16517601)</comment>


Only Idiots Compete in Earnest Against Their Peers - <AUTHOR> https://dissention.wordpress.com/2014/04/18/only-idiots-compete-in-earnest-against-their-peers/ <comment><USER2> >White-collar types see their peers as life-long adversaries who do not belong in the same boat they are in. Some also believe that they "really" belong to a much more exclusive boat and were just plain unlucky to land in their one they are in.

>Almost every white-collar type sees his peers as his or her biggest enemy. His (or hers) biggest ambition in life is to somehow triumph over them and move to a "better" place.

While I don't doubt this occurs there are plenty white-collar employees that don't look at it this way and don't operate this way. The author has a very cynical view of white-collar employees. Makes me wonder if this is just an attempt to stir up some emotions in the readers of their blog piece.

Since graduating decades ago I have been a white collar employee and employer at times. Today I manage a few people, do work with them (we manage 130+ web sites and code backend and front end) and lead a cross department team. We don't express any of these tendencies. In fact if we did we would not be considered a high performing team and we are considered by others to be just that. We work with people on other teams that seem to be the same as us in terms of desire to get the job done right and in a way that is collaborative and at times fun. Maybe I would believe this more whole-heartedly if the author referred to senior executive white-collar employees. I see and have seen the tendencies the author speaks to more at the Vice President and Senior Vice President level than at the middle manager level.

</comment><comment> Sam</comment><comment>-- In a world with scarce resources, everybody competes. It is just who you compete with... Author attempts to say that the union is one group against management, while non-union compete against each other.

Another view is that white collar employees do there best for their employer-- thus competing against the employers' competitors. The incentive for doing so is that a rising tide often raises all boats... (See e.g. [http://www.wsj.com/articles/behind-rising-inequality-more- un...](http://www.wsj.com/articles/behind-rising-inequality-more-unequal- companies-1446665769)) This would lead you tho the conclusion that only an idiot competes within their own company.

Alas, as always, the truth is somewhere between the two extreme viewpoints.

</comment><comment><USER3> Article is (2014).

Also there's a massive difference between a person who "compete"s with their peers and a person who "sees his peers as his or her biggest enemy".

<comment><AUTHOR> Agreed.

The author makes a good point, and the proceeds to take the argument way too far.</comment></comment>


Postpwnium Writeup - <AUTHOR> http://rpw.io/blog/2013/06/11/postpwnium_writeup/

<comment><USER2> Excellent writeup! A good intro at a good level with enough keywords to get those of us who don't hack something to google.

Was it the pwnium3 contest? What was the author's standing? Is this "Pinkie Pie"?</comment>


Do you draw your iOS UI (1) in code or (2) in Photoshop/Illustrator, and why? - <AUTHOR>

(1) By overriding drawRect for example, which I assume would be more flexible in term of scaling and dynamic customization.
(2) By drawing assets in Photoshop/Illustrator and importing them in a catalog, which I assume would give more control over the quality of the assets.
From that, I am guessing that it depend on the use case. However, are there any of you who prefer a method over another, in general, and why?
For DN users: https://news.layervault.com/stories/12137-ask-dn-do-you-draw-your-ios-ui--1-in-code-or-2-in-photoshopillustrator-and-why <comment><USER2> You'll save a lot of time doing it in Photoshop/Illustrator. If it takes other screens and API requests to get to the UI you're building, it'll take a while before you can see what your code does. Using images, especially stretchable ones, is also lighter on memory.

Also, I don't know what you mean by "scaling." You should be able to zoom images with UIView animations, and should have different sizes of the images depending on whether you're targeting an iPhone/iPad.</comment>


Enterprise architecture tools suck - <AUTHOR> http://blackdoglabs.co/2018/04/27/ea-tools-suck/ <comment><USER2> Entreprise Architecture tools suck because Enterprise Architecture sucks. Archimate is still a step in the good direction though and it seems the only standard alive.</comment>


Callbacks are imperative, promises are functional - <AUTHOR> http://blog.jcoglan.com/2013/03/30/callbacks-are-imperative-promises-are-functional-nodes-biggest-missed-opportunity/ <comment><USER2> James does a good job of articulating why promises are such a useful abstraction, especially in JavaScript land. I've been working on a project recently that relies heavily on coordinating many asynchronously-populated values, and I don't even want to think about what the code would look like if we were wrangling callbacks manually.

We actually extracted our promises implementation from the work we've been doing, and released it as RSVP.js[1]. While other JavaScript promises libraries are great, we specifically designed RSVP.js to be a lightweight primitive that can be embedded and used by other libraries. Effectively, it implements only what's needed to pass the Promises/A+ spec[2]. For a comparison of RSVP.js with other promises-based JavaScript asynchrony libraries, see this previous discussion on Hacker News[3].

1: <https://github.com/tildeio/rsvp.js>

2: <https://github.com/promises-aplus/promises-spec>

3: <https://news.ycombinator.com/item?id=4661620>

</comment><comment><USER3> Not to focus too myopically on the given example, but I can't help but wonder why it's a requirement that the first file be handled specially? A less contrived example would make the argument more convincing.

If I wanted to compute the size of one file relative to a set, I'd probably do something like this:

      queue()
          .defer(fs.stat, "file1.txt")
          .defer(fs.stat, "file2.txt")
          .defer(fs.stat, "file3.txt")
          .awaitAll(function(error, stats) {
            if (error) throw error;
            console.log(stats[0].size / stats.reduce(function(p, v) { return p + v.size; }, 0));
          });

Or, if you prefer a list:

      var q = queue();
      files.forEach(function(f) { q.defer(fs.stat, f); });
      q.awaitAll(…); // as before

This uses my (shameless plug) queue-async module, 419 bytes minified and gzipped: <https://github.com/mbostock/queue>

A related question is whether you actually want to parallelize access to the file system. Stat'ing might be okay, but reading files in parallel would presumably be slower since you'd be jumping around on disk. (Although, with SSDs, YMMV.) A nice aspect of queue-async is that you can specify the parallelism in the queue constructor, so if you only want one task at a time, it's as simple as queue(1) rather than queue(). This is not a data dependency, but an optimization based on the characteristics of the underlying system.

Anyway, I actually like promises in theory. I just feel like they might be a bit heavy-weight and a lot of API surface area to solve this particular problem. (For that matter, I created queue-async because I wanted something even more minimal than Caolan's async, and to avoid code transpilation as with Tame.) Callbacks are surely the minimalist solution for serialized asynchronous tasks, and for managing parallelization, I like being able to exercise my preference.

<comment><USER4>
        do f1 <- fsStat "file1.txt"
           f2 <- fsStat "file2.txt"
           f3 <- fsStat "file3.txt"
           let ratio = (size f1) / (sum $ map size [f1, f2, f3])
           print ratio

Or, if you prefer a list

        do fs <- mapM fsStat files
           let ratio = (size . head $ fs) / (sum . map size $ fs)
           print ratio

And that seems to be one small example of why you may have already invented monads. I've been loving the impact of Javascript—modify and immediately see it on the browser—but every time I'm not using Haskell I miss it dearly.

<comment><USER5> Please use more readable names in your code. Use of names like 'fs' in key places makes it unreadable.

<comment><USER6> Generally this is of course good advice, but in Haskell it is common practice to use very short names (e.g. x, x', xs, ...) if the context is clear (which it usually is due to small scope, clear function names, type signature, etc.). This makes code much more concise and readable (it also makes it look very "mathematical").

<comment><USER7> > _(it also makes it look very "mathematical")_

Has that ever been an advantage?

<comment><USER8> For people that like math, sure, why not. When implementing mathematical concepts, if you squint at Haskell code you can see the original formulas, which should make it easier for people used to this way of thinking.

EDIT:

I'm not implying it's useful just for programming "math stuff", after all, everything can be reduced to a mathematical problem - including game engines[1], web application frameworks[2], etc.

[1] <http://www.cse.unsw.edu.au/~pls/thesis/munc-thesis.pdf> [2] <https://github.com/yesodweb/yesod>

<comment><USER9> And it's probably one of _the_ most significant things limiting adoption of Haskell.

<comment><USER10> Exactly. From my point of view, Haskell is the perfect language which unfortunately comes with the worst naming conventions. (I generally develop in C#, F# and JavaScript)

<comment><USER8> The naming conventions are fine, but they're _very_ different from C#, F# or JS - it's basically the difference between reading English text and reading formulas (i.e. compositions of weird letters and symbols).

<comment><USER8> I just want to add something - using Haskell's naming conventions in C# or JS is a crime against humanity. If your function is longer than 5-6 lines and wider than 10-15 characters `xs` or `<|>` are _not_ good names. I think you could get away with it in F#, but it will look weird.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11>
      > If foo takes many arguments we add more arrows, i.e. foo :: a -> b -> c
      > means that foo takes two arguments of types a and b and returns something of
      > type c.

Nitpick alert: since everything is curried in Haskell, it's actually more like `foo takes an argument a and returns a function that takes one b and returns one c`.

Other than that teeny thing, this article is awesome, and I fully agree. Promises are an excellent thing, and while I'm just getting going with large amounts of JavaScript, they seem far superior to me.

<comment><USER12> Really? Consider

        f :: a -> b -> a
        f a = g a

        g :: a -> b -> a
        g a _ = a

It doesn't seem right to say that g "returns a function that takes one b", whereas you could say that about f.

<comment><USER11> Yes. <http://www.haskell.org/haskellwiki/Currying>

<comment><USER12> Thank you for clarifying! I did not know that all functions in Haskell are considered curried. My surprise stemmed in part from reading a bit about "arity" from [1].

It's interesting how the theoretical model of Haskell--"all functions in Haskell take just single arguments"--differs from implementation, where, for functions of known arity, GHC in particular does not actually "follow the currying story literally" [2].

[1] [http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Hask...](http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/HaskellExecution/FunctionCalls#Genericapply)

[2] <http://community.haskell.org/~simonmar/papers/eval-apply.pdf>

<comment><USER11> Any time. It's one of the more interesting parts of Haskell to me, so it's one I always remember.

You're absolutely right to point out that implementations and theory often differ; compilers often do tricky things behind the scences.

</comment></comment></comment></comment></comment><comment><USER13> This is an interesting perspective. But to me, even having spent a year on a large node.js project, I just don't see how promises would have simplified things at all.

If you have some crazy graph of dependencies, I can see how breaking out promises could help simplify things. But I don't feel like that's a super- common scenario.

The author says:

> * [Promises] are easier to think about precisely because we've delegated > part of our thought process to the machine. When using the async module, our > thought process is:*

> _A. The tasks in this program depend on each other like so,_

> _B. Therefore the operations must be ordered like so,_

> _C. Therefore let's write code to express B._

> _Using graphs of dependent promises lets you skip step B altogether._

But in most cases, I don't _want_ to skip B. As a programmer, I generally find myself _preferring_ to know what order things are happening in. At most, I'll parallelize a few of database calls or RPC's, but it's never that complex. (And normal async-helper libraries work just fine.)

I swear I want to wrap my head around how this promises stuff could be useful in everyday, "normal" webserver programming, but it just always feels like over-abstraction to me, obfuscating what the code is actually doing, hindering more than helping. I want to know, specifically, if one query is running before another, or after another, or in parallel -- web programming is almost entirely about side effects, at least in my experience, so these things often matter an awful lot.

I'm still waiting for a real-world example of where promises help with the kind of everyday webserver (or client) programming which the vast majority of programmers actually do.

> _Getting the result out of a callback- or event-based function basically > means "being in the right place at the right time". If you bind your event > listener after the result event has been fired, or you don't have code in > the right place in a callback, then tough luck, you missed the result. This > sort of thing plagues people writing HTTP servers in Node. If you don't get > your control flow right, your program breaks._

I have literally never had this problem. I don't think it really plagues people writing HTTP servers. I mean, you really don't know what you're doing if you try to bind your event listener after a callback has fired. Remember, callbacks only ever fire AFTER your current imperative code has finished executing, and you've returned control to node.js.

<comment><USER14> The point is promises free you from wanting or needing to know about the order that things happen in. I hear you saying you fear promises, because it means it would get in the way of your ability to know that. But the truth is once you embrace them, that need becomes unimportant.

The idea that webservers are "all about side effects" gives me a chill. The whole architecture concept of HTTP is _no side effects_ , so to claim that it's all about side effects seems odd. It should only be the case for POST PUT or DELETE methods, and only in very specific ways.

<comment><USER15> > The idea that webservers are "all about side effects" gives me a chill. The > whole architecture concept of HTTP is no side effects, so to claim that it's > all about side effects seems odd. It should only be the case for POST PUT or > DELETE methods, and only in very specific ways.

There's nothing incongruous about that. It _is_ the case that side effects should only happen on POST, PUT, and DELETE methods (and the like), but almost all webservers are written because of a need to use these.

If your webserver is all GETs and HEADs, then it is either trivial and you would have used someone else's instead of writing your own, or its sole purpose is to repackage and serve existing data from other sources - a rare use case among all webservers.

If you were to take an inventory of all the webservers out there, you would doubtless find that almost all of them exist in large part in order to create side effects.

<comment><USER13> And I'm thinking about complex sites, not simple serve-up-a-page-and- that's-it.

A cache gets refreshed or added to. A user's viewcount is incremented. A new statistic is calculated and then stored. An item is marked as viewed. And these are all just on a GET.

On complex sites with a logged-in user, side effects are pretty much the norm.

</comment></comment></comment></comment><comment><USER16> I feel this is twisting the meaning of functional programming. Excel is not functional. It is declarative. You declare the relationships between the cells and Excel uses those to propagate changes. Just like a makefile is not functional but declarative. The dependency of the relationships are enforced to produce action. SQL is another example of declarative language and it is nowhere near as functional.

<comment><USER17> _Excel is not functional. It is declarative._

Alan Kay (yes, _that_ Alan Kay[1] -- the guy that's won a Turing award) formalized spreadsheets as a limited form of first-order functional programming.[0]

[0] <http://en.wikipedia.org/wiki/Spreadsheet#Values>

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

<comment><USER18> I'm afraid you've misunderstood that Wikipedia page. It attributes the phrase "first-order functional programming" to authors other than Kay. All it attributes to Kay is the phrase "value rule".

Kay's interest in spreadsheets wasn't about functional programming, it was about interactive and dynamic computation. I have a pdf of the 1984 Scientific American article that Wikipedia is quoting from. It does include the phrase "value rule"—by which he simply meant what we would call a spreadsheet formula—but I'm pretty sure it makes no argument about functional programming (it's all images so I can't search to be sure). If you'd like a copy, email me. It's a pretty neat article, ahead of its time as one would expect from Alan Kay.

<comment><USER17> I've already read the Alan Kay article you mentioned (recently, in fact), and that's not what I took away from it.

I guess we'll agree to disagree, I don't think someone needs to use the phrase "first-order functional programming" when they give the very definition of it, which is what Wikipedia does: summarize Kay's argument.

I do agree the article itself was quite interesting, and certainly ahead of its time.

<comment><USER18> What's Kay's argument, then? And how does it relate to FP? I'm curious.

I was making a textual point about the Wikipedia article. Its use of the phrase "first-order functional programming" is hyperlinked to [http://journals.cambridge.org/action/displayAbstract?aid=727...](http://journals.cambridge.org/action/displayAbstract?aid=72731). It's not citing Alan Kay.

<comment><USER17> I guess I wasn't clear, sorry. What Alan Kay meant by the "spreadsheet value rule" and what the phrase "a limited form of first-order functional progamming" means are semantically equivalent; they are the same thing.

I have no idea if Alan Kay ever used the latter phrase, but it was easier to use that phrase here on HN than Alan Kay's made up phrase, which would have be difficult to understand without the content of the article explaining it.

<comment><USER18> Ah, gotcha. I agree with you that spreadsheet formulas are a limited form of first-order functional programming. But the memory model with which they are coupled is just as important (I have in mind the grid addressing system and dataflow semantics) and this does not fit as nicely into the FP paradigm. But I'm repeating what I said in other comments.

<comment><USER17> _But the memory model with which they are coupled is just as important (I have in mind the grid addressing system and dataflow semantics)_

Totally agree. My startup is using hierarchical grids as our core datatypes for just that reason (we also support Function cells that are used as values).

"Naming" is one of the core problems in computer science, and grids/spreadsheets elegantly solve that problem for many ad hoc use cases, where functional programming (in all its forms) does not.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> Ryan Dahl in February 2010, when Promises were removed from core:

        Because many people (myself included) only want a low-level interface
        to file system operations that does not necessitate creating an
        object, while many other people want something like promises but
        different in one way or another. So instead of promises we'll use last
        argument callbacks and consign the task of building better abstraction
        layers to user libraries.

Those libraries do exist. There still isn't a canonical Promises specification. Node trying to force promises onto the ecosystem early on would've been like applying brakes and slow down adoption enormously.

<comment><USER20> > There still isn't a canonical Promises specification.

Yes, there is: <https://github.com/promises-aplus/promises-spec>

<comment><USER19> Promises/A+ surfaced less than 6 months ago, and is not implemented by most widely-used frameworks. Still a bit far from canonical.

<comment><USER21> Promises/A+ is just a more fully specified version of Promises/A, which has been around for about 4 years.

</comment></comment></comment></comment><comment><USER22> I don't agree that there is any fundamental difference in functionality between callbacks and promises.

Promises don't somehow magically make asynchronous code easy to write while leaving callbacks out in the cold. They have very similar strengths and weaknesses and I didn't find any of the OP's arguments compelling.

In fact, if I had to choose, I would take the opposite view and say callbacks are neater, cleaner and more consistent than promises.

<comment><USER23> Promises are values, and you can use them to compute things. Callbacks are procedures, and are non-composable in non-trivial ways (you can chain callbacks very simply, but that's basically it).

</comment></comment><comment><USER24> It is hard for me to fathom the negative feelings towards Promises. They are quite clearly a great way to perform async programming in a civilized way (see Twitter's Future/Promise in Finagle on github). JDK 8 will even have the equivalent in CompletableFuture. The only thing better is to combine Promises with coroutines for a more linear programming style like in Flow: <http://www.foundationdb.com/white-papers/flow/>

<comment><USER25> if you want this on the JVM today and can abide Scala, see: <http://doc.akka.io/docs/akka/snapshot/scala/dataflow.html>

<comment><USER24> The Twitter solution I mention above is in Scala — that said, I have one that also works in JDK 6/7 in a branch of <https://github.com/spullara/java-future- jdk8>.

</comment></comment></comment><comment><USER26> This code doesn't look right to me:

        // list :: [Promise a] -> Promise [a]
        var list = function(promises) {
          var listPromise = new Promise();
          for (var k in listPromise) promises[k] = listPromise[k];

Perhaps the assignment is supposed to be the other way around?

          for (var k in promises) listPromise[k] = promises[k];

<comment><USER27> I asked the same question in Twitter. Turns out James was actually augmenting (i.e. modifying) the array object `promises` to behave as a promise itself. I don't think this was a particularly beautiful way of doing it but it seems to work now that I think of it.

Promise libraries, like RSVP.js [1] he referred to, typically implement a way to construct a promise with a depends-on-many relationship, as a function possibly called `all([p1, p2, ...])` (with the same type signature as for `list`), `and(p1, p2, ...)` or something similar.

IMO, defining the `list` function that way would've been clearer to the reader and more FP'ish, treating the `promises` argument in as a value and not a mutable object.

[1]: [https://github.com/tildeio/rsvp.js/blob/master/lib/rsvp/all....](https://github.com/tildeio/rsvp.js/blob/master/lib/rsvp/all.js)

<comment><USER26> A day later I looked at this again and I'm a little closer to understanding.

          var listPromise = new Promise();

creates an object that, being a Promise object, has certain methods and internal state, derived from the prototype of Promise.

          for (var k in listPromise) promises[k] = listPromise[k];

This confused me because I thought "k" was a stand-in for a numeric index, e.g. that it was doing promises[0] = listPromise[0], promises[1] = listPromise[1], etc. That is not what's going on. Rather, "k" refers to attributes and/or methods that objects of the Promise class have by default. It's copying those onto `promises` — the array `promises` itself, not the individual items `promises[i]`, which keep their existing methods and attributes.

Coming from a Python background, I think I would have found this more obvious if the variable "k" were instead called "method" or "attr". If it was `for (var method in listPromise)` it'd be much clearer what's going on, whereas single-letter variables like i, j, and k are, to me, stand-ins for integers.

It was also confusing, as you said, that the function uses destructive update rather than treating the input as a value. James did mention this ("augmenting the list with promise methods"), but it's still unexpected, especially when the function is preceded by a Haskell type signature.

The reason I only say I'm closer to understanding, and not quite there yet, is I'm not sure what it means to do `new Promise()` or what is being copied over in the above for-loop. I tried James's code with a Promises/A+ implementation, rsvp.js (<https://github.com/tildeio/rsvp.js>), but it won't let me do `new Promise()` because it works differently:

        > var promise = new RSVP.Promise();
        TypeError: You must pass a resolver function as the sole argument to the promise constructor

Per an example in RSVP.js's readme, it's expecting this:

        var promise = new RSVP.Promise(function(resolve, reject){
            // set up a callback that calls either resolve(...)
            // or reject(...)
        });

If James is using a specific promises implementation in his code, it appears to be the one he defined in a past blog post ([http://blog.jcoglan.com/2011/03/11/promises-are-the-monad- of...](http://blog.jcoglan.com/2011/03/11/promises-are-the-monad-of- asynchronous-programming/)), which in turn builds on a module from his JS.Class library (<http://jsclass.jcoglan.com/deferrable.html>), which I hadn't heard of before.

I still think this is a great article, but that code snippet has proven to be quite a puzzle.

</comment></comment></comment><comment><USER28> Unfortunately, in practice promises end up making your code more difficult to reason about by adding cruft and _unnecessary_ abstraction. They're also very limiting from a control-flow perspective.

This is especially noticeable when you have branching behavior / want to resolve a promise early[1]:

Branching with promises:

      function doTask(task, callback) {
        return Q.ncall(task.step1, task)
        .then(function(result1) {
          if (result1) {
            return result1;
          } else {
            return continueTasks(task);
          }
        })
        .nodeify(callback)
      }

      function continueTasks(task) {
        return Q.ncall(task.step2, task);
        .then(function(result2) {
          return Q.ncall(task.step3, task);
        })
      }

As opposed to with stepdown[2]:

      function doTask(task, callback) {
        $$([
          $$.stepCall(task.step1),
          function($, result1) {
            if (result1) return $.end(null, result1)
          },
          $$.stepCall(task.step2),
          $$.stepCall(task.step3)
        ], callback)
      }

I would really love for a post to include a non-trivial problem implemented with promises, vanilla callbacks, and async (and I'd be happy to add a stepdown equivalent), and allow people to see for themselves (how in my opinion promises make code harder to read).

[1] [http://stackoverflow.com/questions/11302271/how-to- properly-...](http://stackoverflow.com/questions/11302271/how-to-properly- abort-a-node-js-promise-chain-using-q)

[2] <https://github.com/Schoonology/stepdown> (docs need updating, view tests for documentation)

</comment><comment><USER29> Promises are just tools for managing a list of callbacks with less boilerplate. I wouldn't call one imperative and the other functional. Both are functional. You might dislike callback patterns, but through one of the beautiful parts of JS, you can trivially wrap any callback-oriented API you want and have it become a promise based one. I've done this before when I had a very complex dependency graph at the start of a program and a few API calls were callback related. It looks something like this:

        SomeClass.prototype.someActionPromise = function(){
            var deferred = makeADeferred();
            SomeClass.prototype.someAction.call(this, function(err){
                err ? deferred.reject() : deferred.resolve();
            });
            return deferred.promise();
        };

Now you have a promise-based version that makes your code a little cleaner and easier to read.

<comment><USER30> The author "promisify"s a callback-based API in the article - which is worth a read by the way.

I'm interested in your opinion RE: his argument for why callback APIs are imperative - because I think he has a very good point and has supported it with a solid argument and you haven't offered any rebuttal.

<comment><USER29> Interesting. As you pointed out, I hadn't read the article but was rather replying to other comments.

After reading it, I think I have to agree that I had never thought about it that way. It makes a lot more sense that a promise is just a declaration of some unit of work, and when you can use a promise like any other data, you aren't just giving imperative commands, but rather describing work to be done and using that as a fundamental part of your code, which is why it drastically simplifies async programming (the relation of promises to monads is quite nice, too). Definitely a good article, thanks for kicking me :).

</comment></comment></comment><comment><USER31> " the decision, made quite early in its life, to prefer callback-based APIs to promise-based ones."

Rewind to the point when nodejs was being designed. In that world, in the context of javascript, callbacks were the only real pattern that existed. XHR? callback. Doing something in the future? callback.

If you imagine node trying to leverage the javascript ecosystem, callbacks were a no-brainer.

<comment><USER32> Various incarnations of the Promise monad have existed for quite a while, even in JS. The oldest one I can think of is MochiKit's Deferred, inspired by Twisted's. That one worked (and still does) seamlessly with any callback code.

<comment><USER33> (Twisted was inspired by the work I just pointed to in my answer. Not to take away from yours -- I wasn't familiar with MochiKit.)

<comment><USER32> Of course, using monads for asynchronous tasks is an old trick and E has always been ahead of its time (like many other languages ...)

</comment></comment></comment></comment><comment><USER34> Promises seem cool but if you are not liking callbacks very much you should take a look at just using CoffeeScript indenting two spaces, specifying functions instead of inline, he async module, icedcoffeescript with await and defer, and Livescript with backcalls. All of that is more useful and straightforward than promises.

</comment><comment><USER35> So, calling magic subroutines is more functional than passing about first class functions?

<comment><USER30> Functional programming is not just about first class functions and I disagree with the idea that using first class functions means you are doing "functional programming".

See the second paragraph of the article for the authors take on this. Specifically, the concept of values is very important.

</comment></comment><comment><USER36> This kind of programming certainly is promising </pun>

It's one of the reasons why i started learning haskell.

</comment><comment><USER37> there is also a third approach for those who want to write composable, functional javascript <http://dfellis.github.com/queue- flow/2012/09/21/tutorial/>

</comment><comment><USER38> All the code and such a big abstraction for the first example when it could have done like this:

        var result = [];
        paths.forEach(function (i, file){
            fs.stat(file, function (err, data){
                result.push(data);
                if (i === 0) {
                    // Use stat size
                }
                if (result.length === paths.length) {
                    // Use the stats
                }
            });
        });

Fairly understandable, more efficient and without introducing logic patterns foreign to many. It also meet his requirements (It is parallel and we only hit every file once)

<comment><USER39> To be fair, you haven't handled the complete case. What if one of the items fails? You need to handle the error, but only if it's the first error, and make sure to tell all later-called callbacks that they're too late and we have already failed. Except, if we got an error on an early callback but the 0th item comes back later, we need to do whatever we were going to do with that one piece of data.

        var result = [];
        var hasFailed = false;
        paths.forEach(function (i, file){
            fs.stat(file, function (err, data){
                // if previous callback failed, give up.
                // unless this is the first item, which we still need
                if(hasFailed && i !== 0) return;
                if(err) {
                    hasFailed = true;
                    // do something with the error
                    if (i === 0) // do something special for error on first item.
                    return;
                }
                result.push(data);
                if (i === 0) {
                    // Use stat size
                    // remember we might have already failed, in which case don't add the first item to the general result
                    if(hasFailed) return;
                }
                if (result.length === paths.length) {
                    // Use the stats
                }
            });
        });

That's almost certainly still not close to right. Which just illustrates the basic problem: without either promises or something like async.js, you're reimplementing control flow by yourself. You can easily start with perfectly- nice-looking code that balloons to be incomprehensible as soon as you start caring about error cases. And where two statements, perhaps dozens of lines apart, are preserving some invariant that is not obvious to someone editing your code in the future. Even yourself.

<comment><USER38> The example I'm talking about is the one where he doesn't handle errors either, this one: <http://pastebin.com/98CarwzU>.

And your example is disingenuous too, why do we need to add so much logic instead of collecting the errors if you want to handle them anyway?

        result.push(err || data);

So you don't need to copy around a variable called "hasFail", one line can be enough

        var failed = results.every(Buffer.isBuffer);</comment></comment></comment>


Brazil: hundreds of thousands of protesters call for Rouseff impeachment - <AUTHOR> http://www.theguardian.com/world/2015/mar/15/brazil-protesters-rouseff-impeachment-petrobas

<comment><USER2> This protest got a lot of people with different opinions together. As ridiculous as it sounds, some of them even want the military back in power. Some people had swastikas drawn on their flags. Some others just want someone else on power. All they have in common is their hate for the current president's party, who won the last election with roughly 52% of votes.

<comment><USER3> BTW, Brazil has a population of 200million, and this protest's had at most 1 million people. This isn't as representative of people's toughts as right hand media tries to show.

<comment><USER4> This is the only comment that rings true to me. I lived in Brazil for 7 years, and yes, people were unhappy with Lula before they were unhappy about Dilma Roussef. But overall, _poor_ people (which is a substantial part of the population) were happy with their governments.

On the other hand, most people I knew voted for Lula and Dilma because they actually benefitted from their policies. When Lula left power his approval rate was something over 80%, which was better than any other president before him. And yet, if you asked the right people, you'd the country was about to explode because people were so unhappy.

<comment><USER5> People are not happy here. The current president has taken unorthodox economic measures whose results we are now seeing. Electricity is up around 60% since last december due to the failure of the president's populist policies of controlling prices. Same for fuel, because Petrobras wasn't allowed to raise its prices, kept artificially low by the government in an attempt to control inflation.

The president was reelected on a campaign of lies, and is now doing what she accused and claimed her opponents would do, in one of the greatest cases of electoral embezzlement ever seen.

No, people are not happy with this government, and no, it's not only the rich.

</comment></comment></comment></comment><comment><USER6> The current party has been in the power for too long (Lula 2x 4 years, Dilma currently on her 2nd 4-year period). Petrobras, the largest company in the country is government-owned and run and lost 80% of it's value in the past 5 years due to corruption. The Brazilian Real devaluated 60% in 2 years. People have all the right to be pissed off. The biggest problem here is that the opposition is also very corrupt, so people are not protesting in favor of someone, but just against Roussef. Though situation.

<comment><USER7> > The biggest problem here is that the opposition is also very corrupt

Also, both situation and opposition have a very similar agenda.</comment></comment>


Germany Preparing Law for Backdoors in Any Type of Modern Device - <AUTHOR> https://www.bleepingcomputer.com/news/government/germany-preparing-law-for-backdoors-in-any-type-of-modern-device/ <comment><USER2> Cryptocurrency hardware wallets? Yubikeys?</comment>