skysight-inc/HackerNews huggingface dataset:
I don't think that is really relevant to the discussion. Regardless of how a digital computer is physically implemented, we use it according to specification. We concretize the concept of binary by designing the machine to withstand noise. The thing what we get when we choose the digital abstraction is that this is actually realistic. Digital computers pretty much operate digitally. Corruption happens, but we consider that an error, and we try to design so that a programmer designing all but the most critical of applications, should assume that memory does not get corrupted

We don't squash the range of voltages. The digital component that interprets that voltage does the squashing. And we design it that way purposefully. https://en.wikipedia.org/wiki/Static_discipline

Turing specified that the reads and the writes are done by heads, which touch a single tape position. You can have multiple (finitely many) tapes and heads, without leaving the class of "Turing machine". But nothing like blending symbols from adjacent locations on the tape, or requiring non-local access to the tape.
Futuristic motorcycle so safe no helmet required
Yeah but OP is using pypy and I don't know if numpy works on pypy fully. I think I read it does but I haven't tried it.
I know you're probably not implying regression to the mean is causational, but that was my initial reading so I want to clarify for those who may not be familiar with the concept.

Regression to the mean is simply that any given datapoint is most likely to be the mean, or close to it. This means that any exceptional data point,up or down, can be expected to be followed up by the mean.

The example of this being misinterpreted that I am familiar with is that of a flight instructor's belief on training. When a pilot performed well, they wouldnt comment. If a pilot performed poorly, they would be punished. They believed this was better because when they praised a pilot, they would usually do worse the following run, and when they punish them they do better. This isn't technically wrong, they are just ascribing causation where there is none. I think I saw this example in Signal vs. Noise, but I'm not sure.

Basically, regression to the mean isn't a reason to pick someone who did poorly, it's a reason that that person will do no worse or better than they do normally.
ahh got it! thanks :)
Jay Turner, Head of Open Source CloudRouter Project, on SDN Tipping Point
> Does nobody see what a HUGE security risk that is???

I dispute 'HUGE' (or even 'huge'). No more than using any CDN controlled by a large company.

1. You're welcome to say that CDNs are a risk in general but many reasonable people would disagree.

2. You're welcome to claim that Google is not to be trusted but it rather depends on your audience. If you're providing a platform for especially the especially sensitive (anything related to politics/human rights/government/medical/financial might warrant extra caution) then I'd agree but for the large majority of sites - loading javascript from Google is an acceptable trade-off.

So - I'm not disputing it's a security risk - I'm just not sure it's HUGE-in-capital-letters for most people.
"If the team wants to do TDD, or pair programming, or staging servers - they get it all approved by the CTO. It’s up to him to consider the bigger impact of those changes."

As a CTO, my team knows I do not need to approve what the team wants in regards to TDD or how many environments they feel they need. We operate in a mode of "do whats best" and engineers smarter than me sure as shit dont need me to rubber stamp approval of writing unit tests. I absolutely create an environment that encourages high quality products and a robust testing process. How they accomplish that is up to them.
> My company's product backend is written in PHP

If it's a pure API (no HTML templating involved) I would use Go today. I personally find nodejs async programming obnoxious. Go isn't perfect (the type system is extremely limited, though It can be cheesed through reflection) but you have access to powerful concurrent constructs without having to write callbacks, promises and all that bullshit. Async programming is fine when it comes to GUI programming (it makes sense to write click event handlers). Having to perform an HTTP request in the backend asynchronously does not. Gimme threads,queues and pools and let me think synchronously.

Now if your backend is about serving some HTML files and forms, keep using PHP,there is very little reason to rewrite it in another language, that's where PHP shines.
I suppose I can see the similarity, in that there's some accumulated value (the sum) from reading some segment of memory, but otherwise I don't think the comparison is helpful.
When can I get my hands on this?!

I was just looking for something like this yesterday! I pre-ordered a Shaper Origin (https://shapertools.com), which ships in September 2017, but I need something to use now.
why do you think the judiciary cares?

note that the UK does not elect its judges
Thanks for your thoughtful response

> I mainly objected to your 'Can I sample one without his permission?' since I don't think its the same thing.

I understand your point and I agree that's the reality of it, but I'm saying that isn't how it has to be. It isn't the same thing in some qualitative ways, as you say, but mainly because Dylan chooses to make it different. Like all the FOSS developers, all those Grateful Dead bootlegs, and all those traditional folk tunes, and some folk singers (and other musicians) in the recorded era, he could have made his libre. My guess is that like Tim Berners-Lee, Linus Torvalds, and many others, he wouldn't be homeless, that is unless he prefers to keep traveling.
Good point. It's important to take responsibility even if you think there should have been guardrails.
It dropped ~6.9% for blacks, ~5% for the population as a whole.

Prior to the financial crisis it was 4.6% overall, 8.3% for blacks[1].

So now it is 8.9% worse that the per-crisis number for all employment (ie, (5-4.6)/4.6) vs 8.5% worse for blacks (ie (9-8.3)/8.3).

Sure, I'm sure you can play with the numbers to give it the spin you want, and I can spin them the other way.

But it's pretty difficult to argue that it is significantly worse now than it was before.

[1] http://www.bls.gov/opub/reports/race-and-ethnicity/archive/r...
Yes I read the paper and I know what you mean, the media loves to jump to conclusions. Of course, they're also the reason I even found out about it. I'm super excited to read what comes from the future observations.
My stance is that this a nature/nurture kind of debate, to argue either extreme is ridiculous, there are clearly elements of both sides that are true.

No positive/negative turn in the economy can be isolated to a single cause, so neither side will ever be convinced by the others arguments.

A third point, which I think is often lost in these arguments, is that governments have interests that are beyond improving the financial standing of its citizens. A pure market capitalist probably wouldn't think subsidizing farming or shipbuilding a particularly good idea, but the government might be willing to accept some market inefficiency in exchange for food security or having an established ship building industry for times of war. Similarly, high income inequalities may cause high social unrest, it's in the governments own interest to prevent this, so it may be willing to accept lower total nation wealth in exchange for more evenly distributed wealth among its citizens by imposing progressive taxes and creating welfare programs.

Everybody agrees that markets work, the main questions are: are they optimizing for the thing you want? and are there cultural/political externalities that the market doesn't care about but a government might?
> And contrary to popular belief, HTML was indeed originally designed for applications. Why do you think it has the form and input elements?

For questionnaires and guest books. It was only later discovered that this
allows to have an application that runs server-side, but is displayed on
client's side.

> HTML was indeed originally designed for applications. [...] Why do you think HTTP has OPTIONS, POST, PUT, PATCH, and DELETE?

What on earth do HTTP verbs have to do with what HTML was designed for?
As extension to scripts like Noscript. Would be useful.
> If you're using Webpack, React, Redux, Typescript and NPM to render basically static content you're doing it wrong.

Yet this is what everyone does and what romaniv means. We have good tools for applications that people use for static content.

Here's my reasoning: As someone looking for a Web Dev job, your static site built with Handlebars or server-rendered HTML won't impress anyone. Build it with React/Redux/Immutable and suddenly you get more interviews or at least more hits. This has happened to me.

Therefore, when those people finally get employed they'll just keep building with the tools that got them the job and never think if they really need them. If you switched a complex React app to a server-rendered Node/Rails/Django one, how much more less work would you have to do?
The Curiosity rover has driven 9 miles in a little over four years on Mars.

The Lunar Rover that came with Apollo 17 drove 22 miles in a little over 4 HOURS.

As it turns out, humans are the best robots.
Surely it's a fairly simple technical problem to solve? Middleware or a build step in your static site generator could easily produce AMP and non-AMP-but-fast content from the same data and templates?
Reusable Nuclear “Shuttlecraft” using the martian atmosphere as fuel [pdf]
This is one of those situations where "trust but verify" takes on a whole new importance.

There's a world of difference in how you should treat someone you know almost nothing about that makes an mistake that is almost fatal for you and someone you know to be fairly responsible. That doesn't mean don't be nice if you can, relative to the situation ("nice" when someone has almost killed you doesn't necessarily mean be cordial, it may mean cool down for a sec before attempting to get them fired), but it would be stupid to assume the same mistake won't happen again without knowing a bit more about how it happened in the first place.
I used to use Delphi a lot, in the 1990's. It's a few things.

Compiler designed for compilation speed above all else. Delphi did not attempt to ever compete with other languages/toolchains on raw runtime performance of the generated code .... I don't recall ever seeing Borland/Inprise boast that a new version generated more optimal code. This is because the code the compiler produced was fast enough for Delphi's target market (desktop business apps) and it was still a lot faster than Visual Basic, and a lot more compact than Java, which were its primary competitors. Delphi sold new versions to developers by giving them new productivity tools: for desktop apps that spend all their time idling, raw code performance was rarely an issue.

Single pass compiler. Structuring Delphi apps could be a nightmare. You could not have circular unit dependencies and breaking such dependencies could often be irritating as hell. Functions had to be declared in the right order.

No preprocessor or include based model. "Units" defined their header and implementation in the same file, so the compiler could rapidly load a binary representation of what a unit exported whilst it was compiling.

No generics. Thus, no explosion of code to generate at runtime, like with C++.

Grammar that was very easy to parse.

Compiler codebase that at its core was designed for very old computers, so is/was very tightly written.

Probably more. That's just what I recall.
> I hate environments where the technology department is simply implementing what was envisioned by others. It might as well be an outsourced development team because it becomes independent of the decision making process.

I'd argue that the technology department should be very independent and empowered when it comes to the _technology_ decision making process. I'm less convinced that that's true for the product decision making process. I've worked in places where Product Managers and designers wrote all the requirements and dictated the look and feel down to the pixel, tossing it over the wall to developers to implement. I've worked in a place without independent, dedicated product professionals, where software engineering decided what the product should be. Both extremes have major weaknesses. You have to find the right spot on the spectrum between the two that works for the company and mix of talent you have. It's not all or nothing.
Good article, well worth the read. It has some very common sense advice.

I specially like, "Don't use tools that are still too hard to get a grip on. Wait for a better time", excellent advice. I've seen the "cool language", tool, whatever new tech, hit productivity and code quality for no real reason other than it's "cool". Programmers often forget that it's the finished product that counts, not the tools that are used.

I've of the mind that a programmer can't produce quality code unless they have a true mastery of their tools. If we constantly use what's cool and new, it reduces our ability to out put the best product possible.
"If you ever find yourself writing a blog post on why PHP sucks, you are not ready."

About 4 articles down the article is about why PHP doesn't suck. This amuses me for some reason.
> making a serious mistake is often a sign that someone is careless, and more likely to make other, different mistakes in the future.

Or under external pressures they have no control over.
We're not too far off. Main thng in original quote that bothered me was "So if Romney had won Florida, Silver would have been wrong, but ONLY A LITTLE WRONG." Predictions of victory or loss are either right or wrong. There are not degrees of rightness or wrongness with the prediction; it's either right or wrong.

The probability analysis that the prediction is based on does admit of degrees; one probability assignment may be better or worse than another. But saying a prediction is "only a little wrong" implicitly refers to the probability assignment it was based on; it confuses the concepts of "prediction" and "probability". The probability assignment was not necessarily "wrong" to assign a higher probability to the event that didn't occur. It may have been a bad probability assignment, but discerning that would involve considering factors other than the outcome of the event.
It seems like former governor Jon Huntsman would have had an even better chance.
I never quite get these kind of comments.

Scores of developers that were raised on BASIC assert that knowledge of BASIC gives you brain damage. Presumably, they do not consider themselves to be brain-damaged. Similar things happen with, say, products of public schooling.

Which isn't to advance an, "I was spanked and I turned out fine..." kind of argument. Even if that's true, we can establish higher floors than "fine." It's the self-defeating hysterics around the presentation that make it come off the wrong way to me.
FWIW FreeCodeCamp eventually teaches fullstack JavaScript SPA application development. It'd be weird for its creator to suddenly say you don't need any of that.
> many of these people

How many, out of all the people you interact with? It's safe to make your assumption the people who revealed their workings to you, but not with everyone else.
And vaccines. Those two alone account for some huge chunk of our wins against death. The upthread posters are making a sorta valid point: the low hanging fruit has been picked, and recent innovations are more incremental. And that's true enough, though I agree that cynicism isn't the right response.
What is wrong with PCIe? Hasn't it been extremely successful?
I'm not talking about the pod depressurization, which is indeed analogous to the plane, but is a separate issue, and is actually much worse than the plane (planes don't fly in near-vacuum, and can descend very quickly).

I'm talking about the tube pressurization, which is much much worse.
Open source, hosted as a service. The world needs more of this. Major props for having the courage and wisdom to open source your product.

My weekend is packed already, but I'll be back to check this out. I'm just starting to take a second look at GraphQL and co. Last time I looked at it, the conclusion was "extremely interesting, but too alpha for work."

Did you notice that Facebook's ad / business manager uses a mix of GraphQL, REST, and RPC over HTTP POST? Watching the traffic in major production applications is fascinating.
I think I sat next to you at zynga back in 2008 and remember your php struggles vividly.
You can have all the autonomy of technical decisions you want, but you can not make business decisions and UX decisions. You can have a word about it, sure, but not authonomy about it.
Uh, what payout? The 9th circuit essentially ruled that his attempts to access Facebook servers after the cease-and-desist letter were illegal. Unless I'm reading this wrong, he lost, and is criminally liable.
Stupid ES6 tricks
One man's "crap" is another's fine dining.

I believe values are subjective and we choose what we value with our wallets.

> teaches them to have low expectations from what they buy

Do you not think that this is a paternalistic view of the world? What makes your opinion on what's "good" better than mine or anyone else's?

> So like van Gogh who died penniless?

I'd bet that there are several artists who died penniless who aren't as well remembered, skepticism is not the same as condemnation.
This is insane.

How could a small trader like that possibly move enough volume to even budge the market as a whole, never mind crash it?

They claim he was spoofing trades... That's more the domain of HFTs, where you can automate the process, not a lone trader, however sophisticated.

And finally, let's suppose this trader is guilty of everything they allege... He still couldn't have crashed the market, it would have been a chain reaction of algos dumping stock at the same time, which he can hardly be blamed for...
Php is objectively a bad language, and as the literature on why it is is wast like oceans, I don't feel the need to add to it. That said it's quite understandable why the language is used regardless of it's inferiority, there are some practical reasons, just like JavaScript. Thus it's understandable why people follow its news and also why it's harshly criticised. HN is a technical forum of tech entrepreneurs and computer hackers, and people discuss most often the technical aspects of things, and for Php it's more than expected that the tone be downplaying. Though I believe that should be taken as is and not be extended to community itself.
"Here comes the story of the Hurricane"[1] sure seems closer to a story than modern song writing.

[1] http://www.azlyrics.com/lyrics/bobdylan/hurricane.html
Intel has 99% of the server market.
I guess we're in the same boat on that one. It's a weird pronunciation, though, so it barely counts against us. ;)
It makes a nice headline to reduce the prediction to "a 54% chance vs an 84% chance," but most of these sites are predicting not just the statistical probability of a future event in "happens or doesn't" form, they're predicting the relative vote percentage for each candidate in each state.

So if Trump beats Clinton, that really embarrassing for 538, but if she wins the popular vote by less than 6.3%, that's also slightly off. If he wins Florida, that's slightly less off, but still a miss for 538, and so on.

IMO, the only way to really know which model is closer to reality is to wait until November 9 and find out. That's not helpful for deciding who to pay attention to in 2010, though.
It's funny-

developers commenting here seem to hope it dies, feel it's terrible, think nobody actually likes it, etc.

Yet as an end user, I'm already in love with the little lightning bolt. Maybe your site is fast (is it? Is it really? Even on a crappy phone on 20kbit DSL?) but so many sites are dog slow, ten seconds or more to load on a fast connection on a fast phone.
In my experience, most of the time those people in positions of authority aren't actually malicious. They're either misinformed (the higher you get, the less you're able to have both depth and breadth of knowledge), or they have competing priorities.
Diving Atlantis – 5 Best Places to Watch the Sunset in Tenerife
According to a recent survey of 28 carriers, 75% of them will deploy SDN in 2016. 100% of the carriers indicated that they will deploy SDN in the future. Read my article that highlights some of the current trends in SDN. https://app.console.to/article/5800004da934601092304492/
That's absolutely true, but we often forget that all medical interventions have to be balanced in terms of risk and benefit. Most patients expect treatment when they go to their doctor, even when the only available treatment options are marginally effective and carry significant risk.

For a variety of reasons, healthcare professionals find it very difficult to refuse treatment. We tolerate the risks of treatment far more readily than we tolerate the risks of watchful waiting, which leads to a lot of bad clinical decisions.

From the opiate epidemic to antibiotic resistance to rampant increases in insurance rates, overtreatment is a slow-burning crisis in healthcare.

https://en.wikipedia.org/wiki/Unnecessary_health_care
Constraints on the Universe as a Numerical Simulation (2012)
Indeed . . . from the first announcement, I was intrigued by the concept and I truly hope it works out. HOWEVER, as proposed, it is no real competition with high speed rail. In fact, in my opinion, Musk missed the point of high speed rail entirely. It is less about getting from LA to SF quickly than it is about getting from Bakersfield to SF or from Fresno to LA. High speed rail links LA to SF as well as ALL POINTS IN BETWEEN. It creates a single economic corridor. Hyperloop on the other hand just links two points much the same way as air travel. This, coupled with the massive disparity in capacity that you pointed out, makes it ridiculous to compare Musk's hyperloop to high speed rail; it is more comparable to air travel.
Job server + reasonable timeout/retry limits
I don't get it. It's essentially free to give desktop users just as good of results as mobile users, isn't it? How does intentionally crippling desktop help mobile?
SME Delivers an Evolved IBM SoftLayer Cloud Experience with S&M Cloud
Tend to echo your thoughts here. I spent a lot of time in PHP and even though I don't use it much anymore, it does not deserve all the hate it gets.

Expounded on that in this bit that HN picked up a while back: http://www.brightball.com/articles/no-such-thing-as-real-pro...
Well the question is whether drugs overall improve people's life expectancy, not whether some specific class of drug can lengthen people's lives. Some drugs make people live longer, but other drugs decrease life expectancy.

And even with antibiotics in specific, they save lives, but they also kill among the most people of any class of drug. They're a clear win if you're a burn victim or something, but most situations that are less acute either go away on their own or else were treated successfully with plant-based antibiotics. Despite what the pharma industry would have you believe, there's no law of the universe that decrees that fungi-based antiobiotics should be inherently more effective that plant-based antibiotics, the main reason the former are used today is just that they're less expensive to mass produce.
The ultimate color combinations cheat sheet
Certainly worth considering
> Imagine you’re a tourist in Germany driving on the right lane of the Autobahn, not knowing the very left lane is a much faster option. AMP is the thing that forces you to stay on the very left lane of the Autobahn, and keeps your path ahead clear of obstacles.

Not a good idea unless you want to pay an 80€ fine: https://de.wikipedia.org/wiki/Rechtsfahrgebot