skysight-inc/HackerNews huggingface dataset:
The answer is that those things are not valuable. People don't want news. This is not a bad thing. This means that people aren't like the elitist ideal of what you want in your socialist utopia.

Real people happen to like Facebook and Fox News and Snapchat and Yo. And that's fine. To say that those desires are somehow immoral because they aren't lofty enough is elitist, condescending, and anti-humanist.
I don't believe that the article's criticism would be effective also against art (also, games can be art) -- striving to make something beautiful that illustrates the human condition or makes us feel something, is a non-trivial effort; art can galvanize us socially [0] [1] and can effect meaningful change.

While Yo may prove to have some value, the author's post more speaks to how so many smart people are incentivized (by money) towards trivial ends; our economy seems often to reward trifles over things that benefit human well-being.

[0] http://en.wikipedia.org/wiki/The_Octopus:_A_Story_of_Califor...

[1] http://en.wikipedia.org/wiki/Uncle_Tom%27s_Cabin
The new Rust language by Mozilla makes similar promises,

* only pay for what you use

* memory safety

* testability

* portability

(They even got a standard testing module.)

EDIT: How do you make lists with Hacker News markup?
3D Dropcam
The tie-in with Weebly, Squarespace, Shopify, etc. tells me they're targeting the low end of the market. Freelance photographers, caterers, and people currently selling stuff on Etsy.

If I were targeting that market, I would also prefer "domain endings" over "gTLDs".
>This is such an important point, and why free markets work best.

Well, there's a subtlety there.

It's not that "free markets work best". It's that the efficient market hypothesis claims that a market with perfect information dissemination consisting of uniformly rational agents will deliver Pareto-optimal resource allocations.

There's a lot to disagree with in that sentence; market agents collude, people are demonstrably irrational/rely on cognitive heuristics and just because something is Pareto efficient doesn't mean it's fair or equitable.

All three are valid critiques, and the case in point in TFA - the market allocated money to Yo, but that doesn't mean a priori that funding Yo is a worthy and moral choice.

So, if we have markets that routinely deliver inequitable outcomes it's perfectly reasonable to ask - why is this happening?
Streams and Iteratees
And now we wait for the "Git is NOT Shit" response article.
Ask HN: What are the benefits of putting a beta sign close to the logo?
We are planning to release our first public version soon, but are worried that a beta sign close to the logo may cost us some users.
Hey Lance! You're right in that we aren't targeting newcomers to the retargeting space. We want to prove that event-driven retargeting performs better (both for websites and visitors), and we only can do it with customers already doing retargeting.
To me, the key line was "Most of the complexity of C++ is hidden from most of the users most of the time."

The complexity is there. Trying to understand the whole language at a language-lawyer level is mind-boggling. Trying to write libraries that make proper use of the goodies is very hard.

But using C++ isn't so bad, as long as you don't try to use every aspect of it. Just use the parts you need to be able to do what you're really trying to do. You don't have to pay for what you don't use. That's good enough for a huge number of programmers in a wide variety of contexts.

There's a lot of haters that can point out a huge number of flaws. But here's the thing: Most of them, I never run into. I don't care if the move syntax is confusing; I don't use it. Maybe I never will. If I have to, then I'll care about how good or bad the syntax is. In the meantime, the parts I actually use let me get my work done better than any alternatives.
Yes, Amazon have a rule to deploy during working hours, during core hours when engineers are around and available should things go wrong. Also, Amazon is one of a number of organisations who don't deploy releases on Friday.
> * I wonder if they have considered them as power switching devices.*

It's been a couple of decades since I last looked: The diamond thin-film guys thought that power would be a sensible application. There is a technological hurdle: If you notice in the diagram, the electrodes are pointed. This increases the field at the tip, in order to overcome the electric-potential barrier to emission of the electrons. Reliability issues arise because the emission is occurring over a smaller surface area.

Like I said, it's been a while since I last looked, but vacuum devices have had appeal for power apps for a long time.
Please point me to said markets so that I can become a billionaire!
Your analysis seems deliberately obtuse. The basic human emotion of empathy can explain sufficiently why someone can feel the way the OP does. You can question his assumptions (that in another world where incentives were aligned differently, Yo's creators would have been capable of contributing to alleviating human suffering) but to think there is some totalitarian undercurrent here is absurd when the more obvious explanation is frustration that people are suffering when they could be being helped.
That quote is dripping with hubris. There's a few high profile cases where it's true -- Ng at google and now Baidu, for example -- but I guarantee that the bulk of the "best minds" of the generation are not programmers at Google or Facebook.
I started doing it primarily so that I could leave my work computer and start working almost instantaneously on my home computer. Since the Retina, I've been using the same machine for both but it's been less of an issue but it's still nice to know that you could lose the machine and not lose any work in any repo in your ~/dev folder.

Sounds like the only way to do it right now is via the Seadrive client proposed below - will definitely move to the first major provider that offers this service.
Today, the internal ethics of accounting have receded from public view.

That's one way of putting it.
…and then rejected that noble use by allowing other tyrannical regimes to censor content so it can't be used that way again.
Like anything else in a language in which the syntax and other features permit writing correct code that is difficult to maintain or decipher, your objection has to be handled by a human being (or well-designed analysis tool) at the "meta" level (e.g. by code style guidelines/policies).

I agree "auto y = std::move(x)" is (likely) poor coding practice. I only use "auto" basically as a shorthand (e.g. instead of writing "hand_crampingly_long_container_iterator_type v = std::fn(c.begin(), ....)).

I have mixed feelings about "polluting" the namespace with "useless" typedefs and similar aliases versus using "auto". The former leads to very explicit code, but lots of extra "overhead." On the other hand, "auto" is much more powerful than a convenient in-place alias as I've described, and I've rarely found myself in the position of looking at code and having to truly ponder over the type of an "auto" variable. On the other other hand, seeing a lot of either may indicate something else about the code and whether it ought to have a design review. It's (somewhat) subjective.
It's hard, if not impossible, to learn stuff exclusively by tinkering. I developed my interest in HTML because I clicked an "Edit in FrontPage" button in IE6 (or was it IE5/4?), but I don't think I could learn HTML in thorough detail just by poking around FrontPage. The Internet then came to my rescue.

My point is, even if IE didn't include that toolbar button, I would've started up FrontPage on my computer sooner or later. It was just a matter of timing and a string of coincidences. Some other string of coincidences could've led me there, too. I say that the argument "some people would tinker and by moving the IDE into an add-on wouldn't let them tinker enough" is pretty weak. If you're curious about something, you tend not to get stopped by things such as that: that curiosity drives you to poke around incrementally until you either find what you're looking for or fuck up the computer (well, at the time, this was something I was prone to doing often because I loved messing with Windows' system files :)
Do you allow this to pass code review (ignoring the bad name 'foo')?

foo (A*x);

'A * x' creates a temporary with no documented type, but the conceit here is that we don't care. They could be ints, floats, matrices - any data type that implements '*'. By and large that is fine.

Here you are just moving x to y. What is the type of y? the same type as x, which supposedly didn't cause you heartache throughout the rest of the function.

Stroustrup gave an interesting talk this year about how, everytime he introduced a new feature, people complained that it was not clear and asked for very verbose syntax. Instead of foo<T>, we get template<typename T> foo<T>(T, well, you get the idea. Now everyone is familar with templates and loath the verboseness.

Back to auto, it allows for 'generic' programming. Do you object to templated functions?

template<class T>
T add (T a, T b)
{
return a + b;
}

That seems really clear to me, as is the auto version:

auto add (auto a, auto b)
{
return a + b;
}

If that is clear, why is

auto x = a + b;

unclear? I can certainly come up with counterexamples where it isn't clear, but by and large I love auto, and use it all the time. (counterexample: we care about the type of x because we need to cast to a 16-bit int because it is going to be use to communicate with hardware).
Hahaha, can't say I'm sure about your point (don't disagree, just reserving judgement for now) but I've gotta upvote the comment for your swift pun :)
"It's not that EVERYONE should be working on the big problems -- just that the incentive systems seem to lean towards triviality over deep human benefit."

Yes, exactly. And even more importantly: we can fix it, but we choose not to. I know brilliant people with extremely specialized training in chemistry, physics, biochemistry, and so on. People who should be developing new drugs, or high-speed trains, or improving solar energy, or creating new ways to generate hydrogen or ethanol from plants.

You know what? They can't get jobs in their field of training, and if/when they do, the jobs are crap. The sad truth is, it's not (currently) economically rational to devote your youth to these high-minded pursuits. In all likelihood, you will be rewarded with a lifetime of insecurity and low income, followed by an uncertain potential of a comfortable life in old age.

This is a societal problem. We're currently spending all of our resources on short-term wealth accumulation and neglecting longer-term technological development. We could stop it with the right set of financial incentives, but we don't.
Insurance is only an investment if it's used to hedge risk to some other asset of value. Employees aren't your assets, unless you're participating in indentured servitude. This is just gambling at best, hiding money at worst.

I get insuring your movie against the star dying. If someone wants to start a business insuring the internal projects of companies against people crucial to them either quitting or dying, that's fine with me. But with no asset at risk, there's no difference between your company buying life insurance on you and me buying life insurance on you.

Of course, CDSs are still legal to buy against companies who don't owe you anything, so I should really just give up the idea that financial regulation has an obligation to society in general rather than just in setting up a fair playing field between speculators.
As always, I would suggest A/B testing!

I would guess that a beta logo could potentially hurt if you only have a paid subscription. If you allow free access, it basically tells users that not everything might be in place (so that would actually help you keep users).
There's no deposits or presales to fund partial development or create an initial income stream

I don't know how widespread the practice is, but in the mid 2000's I went to a seminar that was exactly this. Pre-sales of condominium units in rental seniors-only housing.

The premise was that you could purchase (at a substantial discount) the condos before they were built, knowing the expected minimum rental income based on the surrounding neighborhood. It was likely that the tenants would stay there for the rest of their lives.

I decided not to invest, but I talked to some people who had done it before and, well, it was a goldmine!
While C++ programmers are still getting used to type inference, it's not really a new concept. It's been in other languages for decades.

Personally, I avoided type inference in C# for a long time. But I never ran into a bug caused by type inference. While C#'s (and C++'s) type system isn't as advanced as Haskell's, if you screw up the types you generally get a compiler error. If "auto y = std::move(x)" compiles, then why do you care what type y is? You know it's the same type as x, and you can do anything with y that you could have done with x.

There's really nothing to fear.
When one team is dominating another, they get multiple attempts to score for a single possession event (powerful shots on target are commonly redirected by the keeper which allows the attacking team another chance from a corner or rebound), and their probability of scoring from any shot increases because their control of play allows them to take more certain shots. And of course, brief possession in a teams own half does not really translate into any kind of scoring chance for them.

Of course I'm not sure that those factors are enough to completely sink the model, but there certainly are such factors in play.

> The issue (not well articulated in TFA) is that when both Poisson variables are expected to have low counts, it's difficult to distinguish slightly-different per-possession probabilities.

I take this to mean that in a match up between broadly comparable teams, the outcome will be indistinguishable from chance, which most fans would accept as completely fine (and possibly even preferable). I still find it hard to reconcile this with the dominance of a few teams over quite long periods of time in international soccer, even in the presence of relatively low scores although I suppose I would have to do some actual number crunching to tell whether this was relevant or not.
Very few professionals do night shifts. Equating a security guard with IT work is insane. The intellectual demands are nowhere near equivalent.

For professional examples of "night shifts", we have ER doctors. They do work 12-24 hour shifts -- but they're allotted a room they can sleep in between patients, and they often have 2-7 days between their shifts.

You going to pay infrastructure staff what you pay ER doctors for as much on-task work? Are those people going to actually know what to do when you put them on-task?

What happens when the IT staff needs to get a developer on-hand to resolve an issue? Wake them up?
Kind of a blanket statement, free market works best. It works adequately in many cases, at best. Completely ignores non-transaction, external participants, like the environment.

Attempting moral persuasion ("moral crusading" seems an extreme interpretation) is essential for society to progress. Not much of a future if value is only determined by some business-genius decision maker deciding that, "Hey, I can make a million bucks off this. Must be worthwhile!"
I found a combination of buildpacks + docker really useful.

We use the the slugbuilder from the flynn project[1] which gives us a finished version of the app in a .tgz which will than be extracted into a docker container that already has all the other necessary stuff setup (logging architecture etc.) which is needed in different parts of the application (webserver, background workers...)

[1] https://github.com/flynn/slugbuilder
Your Agile – But You Still Need a Product Roadmap
I just picked the first result from Google. This isn't StackOverflow, so I could imagine that the topicstarter would actually do some research himself.
Pearson correlation with Scalding
At SequenceIQ we are processing data in batch and streaming – for both we use Scala as our prefered language; for batch processing in particular we use Scalding to build our job and data pipelines. Actually there is Babylon at SequenceIQ as we use Java, Scala, Go, R, Groovy, Ansible, shell, JavaScript and what not – follow up with us for a post talking about the language heterogeneity.
Every time you talk about "Yo" an angel loses its wings or a kitten dies or... whatever.

If you stop talking about it, it will just fade into obscurity like Doogie Howser - only to appear years later as a successful, charming actor that can --- wait, where was this going?

Right. Stop talking about it and it'll go away. Don't be bitter about Yo; there's no point in it. Just let it go. Keep calm and carry on.
Thanks, we are planning to have a free version with some limitations but also some paid plans, but your point is clear.
All that fiat currency has to get invested somewhere right? The real estate bubble is re-inflating, check the S&P Case-Shiller 20-City Home Price Index: http://research.stlouisfed.org/fred2/series/SPCS20RSA

Dilbert touched on this back in '89: http://dilbert.com/strips/comic/1989-04-18/
If you told someone a top 10 app with over 300,000 users raised $1.2 million they probably wouldn't bat much of an eye. That's what Yo is now. It probably wont last, but that doesn't mean its creator can't take advantage of its success right now.
AdSense has phone support. If you generate enough revenue.
I think the issue buckles down to someone saying "I'm working on this important thing and I can't raise $1MM, while this trivial, non-important app just raised $1MM, WTF?!"

It just doesn't seem fair that a pointless app could raise 7 figures while others are struggling, but it does point back to the idea that fairness and judgment are human-made, and not absolute.
First off, I want to say this is a great concept. All startups either hate sales or need more sales, so it sounds like your business fits for both categories. I have some experience with door-to-door sales teams and cold calling for 2 different startups. The few comments I have are similar to other discussions but still need to be addressed:

1) Sales Team - Who is your sales team? What is their background? When I was on the door-to-door sales team I was working along side a lot of college students that were not motivated. This was a huge let down to the owners who paid for the sales team. Be upfront with your customers on who will be contacting their potential customers. As a startup founder I do not want my name/brand to be tainted in the industry as a company forcing outsourced sales team to pressure my customers into buying my product (this is an extreme case but does happen).

2) Channel - It sounds like you are cold-calling only, if this is the case then do not include "door to door" and "feet on the street" in your title if you are not going to be talking to potential customers in person. My recommendation would to have packages for cold-calling and a separate package for door-to-door sales. This may be beneficial for businesses to have the option and would be a great upsell for SalesInvaders!

3) Customers - It sounds like you are trying to cover most small business as a target customer. My recommendation is to specialize in one industry. This will allow your team to get better at coming up with pitches for the same industry while understanding your target customer. Also, your chances for getting other clients in the industry will increase when you can tell them that you got X amount of sales for another company in that same industry. This is a crucial selling point, as you would know since your in the business of sales.

Good luck with the idea!
Skills are not fungible - just because I can make a web app doesn't necessarily mean I can learn how to perform surgery - but most people with certain skillsets certainly are.

How else would people build products by hiring more developers?

So, in so far that there are more socially useful problems that iOS developers can help resolve it remains a valid critique to say that those developers could have worked on something else.
I was always weary of Heroku because it's exactly what @hunvreus said: a black-box. Very appealing when you're strapped for resources in the beginning, but increasingly frustrating as you scale. Case in point: http://rapgenius.com/James-somers-herokus-ugly-secret-annota...

That being said, it seems like the model itself is not flawed, just the execution. I've met many developers, especially in the Node community, who fundamentally believe they as software engineers should not have to spend any time learning devops.

My position is that a good software engineer today should be familiar with the full stack from frontend (SPA, javascript, html, css) to backend (sql, basic db admin, db design) and devops. Obviously, you can't become an expert in everything, but the knowledge level required to become "proficient" in these areas seems pretty achievable if you're well-versed in software engineering fundamentals.

FWIW, it took me about 4 weeks to get a "startup-ready" fully open source 3-tier stack running in EC2 with full automation using Chef (which is a whole other topic) plus continuous deployment using Jenkins. Ultimately, we'll pay more for EC2 per month upfront, and I had to absorb the upfront time hit, but now that we're setup, it's extremely easy to tweak things, and we have complete transparency.
The plan is to never have an outage. Instead be scheduling maintenance that should, at worst, result in some backed up queues or non-functional admin functions.

Building a system for graceful degradation costs time and money.
Would a guitar amp built with these sound like a tube amp?
I disagree with the premise that being able to create an app that sends "yo" to somebody implies that you should be able to solve any of the various health crises around the world.

For one thing, this is incredibly insulting. Do you think that nobody is working on solving these already? Do you think that the people conducting medical research are just so unbelievably stupid that they couldn't comprehend how to write an app that says "Yo"? Maybe these problems are a little harder than you think.
some C doesnt mean "know C"

do you know how the memory allocation works when you create a list in python by inferring from how you'd do it in C?

its a very basic question and I don't know many python devs that know the answer right off the bat. its going to be "u malloc stuff right?"

Another basic question: what happens exactly when you open and start reading a file?
"u call open right?"

thats not enough to figure out how things work. Coding "real" C (as in being able to do anything in C, not just code snippets) means that you probably understand how most things work under the hood, including libc, the kernel(s), file system, etc - at a pretty good level of detail.

If you know many like that, its great, but if you think the majority (or even a third) know these things - then I also think that either you or I live in an imaginary world =p
Not to be harsh, but why would HP owe you any of that money? This is a legal way for them to avoid taxes, yes it sucks that your mother died, but HP payed the premiums, they did not take them from your mom, and they didn't lead her to believe the insurance would payout to her heirs, and they didn't prevent her from taking out an insurance policy for herself. You have no claim or right to that insurance money.
Regarding the opening anecdote - some have suggested the Soviets used vacuum tubes so that their planes would survive the electromagnetic pulse from a nuclear explosion.
The lack of GPU support is indeed widespread and really quite forgivable today. Threads, SIMD and restrict are not.

And you're right about C++11, my bad. It's funny how C is actually pioneering a lot of the changes actually required for performance while C++ thinks about standardizing Cairo for 2d graphics...