skysight-inc/HackerNews huggingface dataset:
I disagree somewhat--the conductor may not strictly be needed for the performance (with enough rehearsal, of course), but it's likely to be much better with them than without. For one, keeping a steady tempo by consensus is pretty hard when you're trying to listen for it from your fellow musicians while simultaneously attending to your own pitch & timbre. (Not to mention accelerando and ritardando--changing tempo in sync is nigh impossible without a benevolent dictator in front of you!)

Also it's very easy for an individual musician to forget that oh, this is the THIRD repetition of this really loud phrase, and this time we're supposed to move on to the really quiet part, and seeing the wildly gesticulating figure in your periphery suddenly shrink down smaller is a good reminder that things are changing to the quiet part.

And as a former percussion player who had to wait for sometimes hundreds of measures of rest before coming in precisely on time with, say, an extremely important bass drum hit, it's extremely reassuring to get eye contact and a finger-point from the conductor to verify that you're not about to ruin the entire performance by coming in four measures early just because you lost count and were therefore trying to base your entrance on the repetitive phrasing of the piece. Not that this ever happened to me...
Apache Kafka – for JavaScript devs with redux-lenses-streaming npm lib
> "Yikes my dude - a trip through your comment history shows me you're not going to be an enjoyable debate partner."

Please don't do this. If you think having a discussion with a particular individual is going to be problematic, choose not to have it, or engage as constructively without calling them out like this. You're already involved in a contentious discussion. If your goal is to actually move the needle in some meaningful way, doing this is counterproductive. Regardless of how wrong you may feel someone else is, you have an obligation to raise the bar yourself, even more so when discussing topics such as these.
> and... we'll just give a big 'fuck you' to everyone else who gets sick at some point, and can't go back to work, or has skills that get passed by in the marketplace.

Capitalism doesn't care if you get sick. It only cares if you have time/skill to trade. That's the cold hard reality. In this country, capitalism trumps just about everything else. It has its advantages and disadvantages for sure. By the way, I'm not saying all of this is morally "right" - it's just the way it's always been, capitalism/business comes first in the USA.

I agree that society needs people to be doing low-end crappy work, but maybe if there were fewer low-skilled laborers in the job market, there would be more competition for their services (i.e. the employers would have to offer better benefits.)

I'm all for universal-healthcare and frankly my family would be a primary beneficiary.

As far as safety nets go, how far do we go? If I got sick, I wouldn't expect you (and everyone else collectively) to pay my mortgage, grocery bills, etc. for potentially years on end. Where do we draw the line? How do we prevent people from gaming the system? I know people in Europe who have been "sick" for years.
whenever i feel the need for jquery these days, i typically reach for the much smaller, faster, ie11+ https://github.com/franciscop/umbrella
I've been using LLDB for well over a year with integration into VSCode for GUI based stepping through code, etc.

There's a minor inconvenience of setting up targets for the LLDB to launch tests, etc, but for when it's needed this isn't a huge effort to get going.

I've not yet tried IntelliJ's CLion integration, which I think I've heard is good.
Seems like most of the comments on here pertain to the relevance of jQuery, rather than jQuery UI and jQuery Mobile.

Sure most sites still use jQuery, but do very many use jQuery UI anymore? jQuery Mobile? I've never seen a project use jQuery Mobile.
The merge – or crossing if you will – is going to happen at some point anyway. The point of driving in the cycle lane would be to do the merge first, well in advance of the turn, and once you reach the turn you can safely proceed with the knowledge that you won’t miss a cyclist coming in from behind. (Probably.)

If you don’t merge first, you have to not only consider cyclists in the lane but also whatever may be involved with the turn itself, such as people crossing the street you’re turning into, or other obstacles.

Basically you spread the risk over time and space instead of concentrating it all into this one maneuver at the end.
I wouldn't put them on a pedestal. And to think that MSNBC airs any kind of content that is non-partisan is a joke.
If you enjoy this article, you'd love this book:

Absolutely on Music: Conversations (Haruki Murakami and Seiji Ozawa)

https://www.amazon.com/Absolutely-Music-Conversations-Haruki...
> Except public domain only happens

Flip it: Public domain happens by default. The problem is that some very powerful lobbyists ensure that the government declares otherwise for ridiculously long (and constantly increasing) periods.
Isn't it mostly being manipulated by drug traffickers and money launderers right now?
1) JavaScript allows for arbitrary code execution

2) Apple’s App Store policies disallow the user from executing arbitrary code

I think you can figure this out yourself.
Back in 91-92 the biomed Eng students at University of Illinois built a cart for a dog that lost both hind legs to a downed powerline. Dog could run (it had wheels), sit, and most importantly squat to poop. They ran out of time and money to make a version that would allow for leg lifting and proper boy-dog peeing.
I did not mention it in the article, but it's also completely fine to abandon your own project if you state so and wait for anyone willing to maintain it.

There's no shame in ignoring feedback in open-source if that's a struggle on your side, health before open-source :)
Red hair map of Europe
Crikey! You wouldn't wanna allocate closures in a loop anyway, would you? Even if the compiler is smart about it. Doesn't read so well either.. what's wrong with adding a simple argument to your anonymous-func allocated outside of a loop? It's readable, and there are no 'gotchas'. The args are evaluated at the point of defer/go, not func execution. Simples.

Shadowing bites you sooner or later if it becomes a habit and gains you almost nothing in real terms. I keep running into subtle nasties in coworkers' commits from quick'n'dirty-that-stayed "convenience" shadowings. Need I say `err`.. of course linters help, but aren't a given in a "bring-your-own chosen dev-env" team. =)
Context is problematic because it infects everything. If a function gains context support, every call to it has to be updated, and if you're going to do it right (and not just use context.Background()), every function calling those functions need to be updated, and so on. And the context has to be passed downwards, too. It's turtles all the way up and down.

There's been talk of adding context to io.Reader and io.Writer, which would of course affect pretty much every single Go codebase. For backwards compatibility/convenience you therefore see a lot of APIs with complementary functions Foo and FooCtx, one which takes a context and one that doesn't. That's awkward, and even less elegant when interfaces are involved.

And the network packages (sockets, etc.), of course, have a parallel, non-complementary mechanism to provide timeouts and cancelation that doesn't use contexts. (The key/value pair context stuff is also unfortunate, in my opinion. It's not typesafe, and results in awkward APIs.)

All of this happened because goroutines, as designed, cannot be forcibly terminated. I don't know what the better solution is. I'm not sure why the runtime cannot provoke a panic at the next context switch, but I bet there's a good technical reason. It's unfortunate.

But it's not unreasonable that a large part of any codebase needs "contexts", and so if everyone wants it, why not make it mandatory? Make it an implicit argument threaded through every function call, a bit like "this" in languages such as C++ and Java. The compiler could optimize it away from those codepaths that are guaranteed not to need it. Go has a lot of built-in generic magic, adding some global helpers to set a scope's context wouldn't be too bad.

The other route is to imitate Erlang's processes, which have their own heap, and so killing a process doesn't leave cruft behind. Given how goroutines are allowed to share memory, that's not likely to happen.
Saying method 2 is better than method 1 is not the same as opposing method 1.

What about outright opposing Method 1 because you don't think the Ends justify the Means? Even if you agree with the Ends? Even if you like Method 2?

I'm my experience, that gets me branded as a monster. I tend to keep my mouth shut.
You reference an eternal (and eternally valid) debate, namely one’s right to express oneself versus another’s right to not be exposed to material perceived to be upsetting. I am usually on your side of the camp, firmly believing that somebody’s right to be offended by what I express is entirely their problem and does not impinge upon me nor does it create an implicit obligation that I not offend them.

I do, however, draw a line when there is material circulating that normalises the rising trend of boys and young men using their cellphones to take unauthorised snapshots of women’s underwear and sometimes genitalia without their consent. Such photos would clearly violate Facebook’s Community Standards, but a cartoon does not?

My reference to them being “dirt” and being “two powerful” were separate sentences for a reason. I wanted there to be a bit of distance between the two statements. They are ‘dirt’ because they remove photos of breastfeeding mothers (probably the least offensive form of partial nudity one can think of, and the most natural thing in the world) as being somehow offensive, but they apparently they give this smut a free pass.

They’re too powerful because they have no competitors that could really supplant them. There’s plenty of alternative social networks to choose from, yes, but moving to a social media network without your contacts totally disrupts your habits. To a very real extent, we who use Facebook are a captive audience.

The irony of all this is that in less than an hour my account was reactivated and the cartoon was gone. I suspect I wasn’t the only person who reported it, perhaps multiple times each, and eventually Facebook had to capitulate and as a token of apology released me early from my suspension.

But think of that... in a working, democratic institution, you know what you are held guilty of, what the process is, and what the penalties might be. You get a chance to argue your case (or better still, have it argued for you). This is citizenship in a democracy with institutions. On Facebook, we’re all little serfs, and then there’s the feudal lord (the company itself) that gets to degree by fiat what is and what isn’t wrong (often not even bothering to explain the motivation so that it might become doctrine or at least a heuristic to use when making decisions) .

So in short, no: I am against more censorship by faceless incommunicado Facebook contractors sitting in their cubicles half way across the world with minimal pay. I the power to censor to be returned to the people.
You appear to lack any authority or knowledge here because almost every part of your comment is completely wrong.
> The article is more geared toward those who think they don't fit into the open-source community.

Exactly what I wanted to outline in the article. Too often I thought that open-source people where inside the NBA of developers, that's not true at all. It's just people that have code visible by everyone. It's just code.
For what it's worth, while I would regularly use a debugger for C code, I've never once tried or had the urge to use a debugger on Rust code. (I've been using Rust for almost 4 years.)
Thank you. Tech’s constant lionizing of the Big Five is noxious. Feels just like high school.

Falsehoods programmers believe: all the best devs work at the Big Five.
Not sure, but I was mostly joking. I mean, it was true, and my diet had not changed from when I was more sedentary, but I've ratcheted things down quite a bit since then with careful meal tracking and even more exercise (130mi/week on the bike, 18 mi/week running, plus strength training and core training).
Here is real TLDR;

- Scott Gonzalez has lead the jQuery UI project for many years now and has helped to improve the quality tremendously.

- However, we do hope to continue reducing the amount of duplicated code and widgets in the projects moving anything common to jQuery UI.

- We think going forward this needs to change; we will now be looking for and accepting people that are just interested in maintaining a single piece of the library, requiring a much smaller time contribution.

- Over time however, we have seen a large decrease in the number of people on IRC while other projects have had great results with easier to use tools like Slack.

- Anyone who is interested can feel free to reach out to Alex Schmitz, the new team lead for both projects, join our slack channel or even find us on IRC (we are still there).
I've done this on many phones. The phone often isn't the same as it was initially because it was not designed for this. Many phones have tape that has been adhered through the use of heat. Changing the battery requires removal of many screws and disassembling very sensitive parts. Little mistakes can make the phone inoperable.

Not to mention you take it to a technician who has the tools and you'd assume is doing a good job right? No, often it's some high school kid who is not invested in doing a good job but rather just getting it done. It's sloppier than if you were to do it yourself. So you have to resort to buying hundreds of dollars of tools and taking painstaking hours to get it done right and even then it might not turn out.

To the other posters who argue'd that we make a choice about this - no we really don't get a choice. If you want a cutting edge phone there are simply 0 options with replaceable batteries. This is planned obsolescence in an age where my several year old Motorola works just fine for my needs.
Nissan Finance Canada Suffers a Data Breach
Yeah, I generally feel the same way. For fairly simple use, scope is more consistent (all scopes / closures are identical), but func is a bit more flexible if you're willing to pay with simple boilerplate.

I mean, you can convert them into each other. Scoped can do something like this (go+python blended code 'cuz lazy):

func f(){
deferred := []
defer func() { for d in deferred.reverse(): d() }() // plus error handling
if x.something() {
deferred.push(func(){ cleanup() });
}
// same as func scope
}

but that's a bit more ridiculous / error-prone (though a helper func is obviously possible) than the equivalent IIFE for func -> scope. More explicit, I suppose, but bleh.
I tried subscribing a few months ago. Their payment form was busted. The state entry on the billing address was a "smart" dropdown that could only be advanced by keyboard and only one state per focus. Advancing from Alaska to Arizona required switching focus back to the city field, then tab, then down arrow. Getting to Arkansas required doing that again. I closed the tab well before I got to Pennsylvania. Was whatever conversion boost this javascript abomination was designed to achieve worth it?
The problem is that the volatility of BTC should be priced off tail risk more than gaussian drift, and that's not a rigorous part of the theory. Black-Scholes certainly doesn't characterize the tails very well.
Buying a wildcard cert means they can mismanage their keys for *.battle.net.

Having a CA means they can mismanage any domain.
Equating a change in insurance benefits and costs based on changes to the ACA with "taking ... health care away from people" is simultaneously dramatizing the negative effect of the policy you dislike and minimizing the effect of the policy you prefer. As above, there are a lot of people whose "health care is being taken away", to use your terminology for "undesired fluctuations in insurance benefits and costs, including being completely priced out of their former policy", with the ACA in place. In reality, people are rarely rendered unable to access important health care services regardless of their insurance status.

Referring to "the citizen's best interest" is a tautology; political dialogue fundamentally arises from differing perspectives on how those interests are best served. In a free country, political discourse and representative government is the process by which "the citizen's best interest" is determined.

But I want to avoid the nitpicks. The issue is that when we hear coherent, valid perspectives that don't align with our own, we feel "not only insulted, but [endangered]". That's the sentiment we have to get away from.

I feel like I spent a pretty good amount of effort fulfilling your request. I presented reasonable perspectives that describe how the policies you mentioned can be interpreted to benefit the average citizen. That doesn't prove they're perfect or that they have no downsides, and it definitely doesn't mean that you'll agree. But as a society, we need to be able to engage in this dialogue without name-calling, threatening, or berating -- without condescension -- if we want to be able to stay stable and unified.

This is obviously not a simple task. What things could help us improve the mutual toleration and respect for actually-different POVs and the people who hold them? How can we refrain from hyperbolizing issues (e.g., pretending that a change to the current insurance regulations will leave scores dying in the streets, or conversely the confiscation of private medical facilities and destruction of all private medical industry) and present them in a way that allows each other to acknowledge the middle ground and agree to disagree?
The C++ support is impressive. It doesn't work well enough to handle "idiomatic" C++ libraries, with templates all over the place, but that it works as well as it does is really impressive.
That's completely fine, doing open-source is not a mandatory experience for your own career. Also you can do open-source contributions at work, when it's related to work or just if your company thinks that on the long term it's good and that the benefits are great.
> Yes, it's probably true, but also irrelevant to the point that the research is trying to make, which is that training yourself to delay gratification seems to pay off to your own benefit.

Oh, that was your point -- I complete agree then! Seems like we talked past each other a bit (or at least I to you). Apologies :D.

> Of course he would. And I challenge you to do the same thing with non-homeless people in your neighborhood. I bet they would react exactly the same way. Because a random nobody suddenly appearing out of the blue and offering you money in 90 minutes sounds like a prank or a scam. And because non-homeless people will also have (in fact, are more likely to have) more productive things to do in those 90 minutes than waste brainpower on whether/when/how you're planning to give them those $5. If this is how you're going to design counter-experiments you really don't seem to be in a position to criticize these experiments.

Most of the things you said here can also be applied to the children in the original experiment fwiw.

> I see people ordering 1 cup of coffee all the time and being satisfied that it's enough. When was the last time you saw someone being satisfied after eating 1 marshmallow?!

Indeed, which was my point. Without knowing how much the kids want a marshmallow/marginal utility of it, the marshmallow itself as an incentive is dubious, at best. Despite this I still think the experiment was solid.
> Like it'll skip lines, or stay on the same line for many steps.

I've never hit these problems, though I have the source for everything I'm compiling in Rust in general.
My best guess is that the "store-of-value that can't be manipulated by banks" is effectively over. Big banks it seems will take over the trading volume of the big crypto coins and develop their own exchanges.
Actally there are some motion sensor based reseach in this domain, e.g.: http://journals.plos.org/plosone/article?id=10.1371/journal....
It's a myth that Google literally sells your information to advertisers. It uses your information to show you advertisements which both it and its advertisers hopes are relevant and useful (so you will click on them). If you think about it, that business model essentially requires that the ads not be too annoying, because if they are, people will use ad blockers and the business model dies.

The really annoying ads which auto-play videos, block content, etc., tend to be served by companies who aren't taking the long view --- which is why Chrome is going to be adding adblocking for those ads that are ultra-annyoing early next year.

There's a pretty big difference between "using your information for marketing", and "marketing your information to advertisers". The second implies that your private information is getting divulged for a price, and that's simply not true.
How to Think Like a Medieval Monk
The idea to gather types at runtime is as old as PEP 484. The Dropbox and Facebook teams working on Python type checking know each other. We both worked on our implementations independently since we wanted to first test internally whether the idea holds water. For example, I personally thought it wouldn't be as useful in practice as it turned out to be!

We knew we're going to open-source each others' implementations, esp. that Instagram's is focusing solely on Python 3 which isn't useful for Dropbox at the moment. It just took a while to get through the process of open sourcing what we had (cleaning up the early implementation with limited documentation, decoupling from internal data stores, etc.).

Would it be cheaper if this started out in the open? Probably, but I don't think by quite the margin as you expect.
You're imagining it happening at an unreal pace. This is really close to what most large intersections in the Netherlands look like. The shoulders for the cycle lane are actually behind the curb, and for a cyclist still feel like 'going straight'. If I'm not mistaken, this is even known as a "dutch junction".

This video explains it well: https://www.youtube.com/watch?v=1bG6ZrbCO2g
It's only four items. I appreciated the enumeration.
> Specifically, system package managers are about providing a unified set of packages to end-users. Language package managers are for developers to build applications.

One thing that might help people see this distinction better is if Cargo offered better post-build hooks to allow community-driven add-ons that handle packaging for the various system package managers. If a Rust developer could run cargo dist-package (or whatever it's called) and have it build a deb/rpm/pkg/msi, it'd be really easy to use cargo for the development phase and the other package managers for the distribution phase. As it is, if I want to run someone else's Rust software, I'm basically using cargo install to pull from crates and build locally.
With relevant blog post @
http://medium.com/@SebDragomir/connecting-to-kafka-using-red...
Curiosity on Quora in 2017
Nice hash – new investor so returning funds?