skysight-inc/HackerNews huggingface dataset:
The problem is that the blacklists have no problem with harming the customers of the network, who have done nothing wrong.
My point with CHI is that they probably admit too many papers, or at least are very unfocused. OSDI and SIGGRAPH have high bars (not sure about AAAI), they don't so much as have a paper limit but just very high standards.

> Instead mostly people in the area submit to it, and a large proportion of the submissions are legitimately good.

Working groups or invite only workshops might work better in this regard. It depends on your area though.

> So it'd be easy to choose which 50% to accept, but when you're accepting 30%, now some good work is being rejected, just because you have to hit the arbitrary acceptance-rate target to count as "selective" in certain U.S. universities' bibliometric systems.

Its more about how tenure cases work in universities. Your judges don't read your papers, they just look at your bib.

> If we went down to a 20% acceptance rate, we'd have to fairly arbitrarily reject some more good papers.

In my reviewing experience, the PC never had to reject papers based on too many good papers; if anything we had to accept papers of questionable quality to fill the conference up. The rejection notices that PC chairs send out about there being too many good papers are often lies. But maybe our fields have different problems :) I'm a firm believer in accepting all the good papers and rejecting all the bad ones.

> We half-joke that the way to fix it next year is to spam the CfP to clearly unsuitable places, in order to elicit a flood of crap submissions that we can then easily reject, allowing us to hit a 30% (or 20%, or lower) acceptance rate without having to reject any good papers.

Just use Weibo to advertise your conference. There is a lot of talent in China and India who want to make it big, not all of it is great yet, but it will definitely push down your accept rates.
> where there is a huge demand for laborers that can install solar panels on houses, or something

Here's the kicker - any new industry, at any point in the future, that pops up demanding labor, is much more likely to invest (since they are investing anyway - it is new industry and new markets) in automating the labor out of the equation from the start. Industries are only slow in that transition today because they have established infrastructure around the usage of meat bags on two legs as units of work, but for anything brand new (like semiconductor plants, or the Tesla auto factory) even in the short term it makes more sense to automated the expletive out of any physical work because I'd imagine in even just a year at minimum wage it would pay for itself factoring in the fact you have to build everything up from scratch.

So the solar panel installer in 10 years would probably be a self-driving fork lift truck that carries a bed of industry-standard packed and oriented solar panels, where the vehicle has GPS and will drive to all customer homes and install the panels automatically, with only the need for an electrician to come wire them into the houses electric.

But that is short term. You can easily replace the electrician with some hand held spider robot that will use the blueprints for the house and sensors to find and rewire the electrical into the panel. In a hundred years, you aren't installing new panels, because every new house is factory made (by automated assembly) with the panels preinstalled, and they all have interchangeable parts quality electric systems that dumb non-sensing robots can rewire because they are standardized if necessary.

It is glorious that we are eliminating the need for human capital to make things happen. We are removing people from so many equations you would otherwise be wasting someones time on. We may have some bumps in the road and some dark ages of depravity and extremely concentrated ownership of the means of production and all that, but a thousand years out (assuming we haven't destroyed ourselves yet) any human still alive (albeit with a nebulous definition of human if we start gene splicing and installing cybernetics pervasively) will almost certainly have no need to "labor" at all, because the machines and infrastructure built up over a thousand years will provide for them.
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.
For games specifically distributed under free software licenses take a look at https://libregamewiki.org/Main_Page. SourceForge's games section [1] is also still a surprisingly good tool for discovering smaller and more obscure Linux game titles. I wish there was this sort of cataloguing going on on GitHub (even if it was through a third-party website).

[1] https://sourceforge.net/directory/games/
Maybe so, but everything in this article goes back at least to the 90s with the E programming language (http://erights.org). Doug Crockford was involved in E. (Nowadays E's Mark Miller is on the Ecmascript committee.)
I have faced somewhat similar problems, testing complicated physics calculations. A few strategies:

- There are special cases where it is feasible to do
a calculation 'by hand' (actually with a calculator or
a much simpler program). The complicated program should get (nearly) the same answer as the hand calculation in those special cases.

- Any solution should have certain properties which it is
feasible to check 'by hand'. For example in physics there
are often conserved quantities (energy etc.). Or the output
should change as a known function of one of the inputs, if
you have a series of test cases where only that one input varies.

- Instrument the program. Write assertions that check intermediate results. Each intermediate result should
be a known function of preceding intermediate results - write code which checks that.

That last option is similar to the formal verification
recommended in another answer. In flow-blown formal
verification you try to write a proof that the intermediate
result is the intended function of the preceding intermediate results, for all allowed inputs -- and then
you produce a chain of such proofs from the input to the output. It is often much easier to just write code to check the intermediate results.
The problem is, the OP isn't talking about hackathons. He's talking about... Startup Weekend or other business oriented events.

Hackathons aren't about slides or business plans. They are about building something.
In this modern era, probably no. Someone doesn't need to. Go build a manure shoveling Roomba and never muck the stall again.
You rarely get serious innovation out of people who are naive and simply "think differently." As pointed out in the article, while Dirac and Einstein were outliers and making substantial contributions to science at 26, they both had persued extensive education leading up to that point.

Are there people who innovate out of whole cloth? Maybe. I can't think of any offhand but I'm sure they exist. But they're not representative. Representative are people like Larry Ellison, who build an innovative company like Oracle (it was cutting edge in its time) by leveraging substantial industry experience and theoretical developments.
Tesla Takes on Texas Dealer’s Association
I agree that I probably wouldn't go with Fender low-end (they are crap), but there's plenty of good bargains in the 300-400 range that won't frustrate a beginner. There's probably 4 or 5 Epiphone, Seagull, Alvarez or Ibanez low/mid-range guitars hanging up at your local pawn/small guitar shop right now. Even some old Harmonys, Kays or Silvertones can work out real well, depending on the guitar. My favorite acoustic to play right now is my '53 Kay arch top that I picked up for $400.
(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.)
Yes. The term hackathon here is being abused.

Hackathons aren't about slides or business plans. They are about actually building something. If there are prizes, they are fun and silly. In the end, every really does win.
How does an observed, measured, calculated and critically considered process of understanding everything around you considered "belief"? That's like saying, I believe in wine making. No, it's a process of making wine. Science is the process of understanding the universe.

One of the pet peeves when people say "believe in science".

Aside from that, are we sure that it's "causing" people to become more moral or is it that science itself encourages reflection and critical thinking that can develop into a moral compass? You're less likely to be rash, disorganized or deleterious to people around you if you also have to be a good scientist, which by definition involves a fair amount of observation and self-dicipline.

It's harder to be an ass when you perceive yourself to be one. Unless you're sociopathic to begin with.
Nice way to void a contract.
I have been playing the guitar for some time now, and wanted to offer my advice for people looking to get a beginner guitar.

I would recommend a solid body electric guitar that has either a Tune-o-matic or hipshot bridge (non floating bridge). The Ibanez RGA121 is an example of a great beginner guitar: http://tinyurl.com/dyjybwa and they go for fairly cheap on ebay.

This is for a number of reasons.

#1 Lighter string gauges and lower action makes it easier to fret notes, bend strings, make chords.

#2 16 inch neck radius really helps with getting a comfortable feel and starting to understand vibrato and legato techniques.

#3 Easy to tune / change strings / set up.

Unlike an acoustic guitar that uses thicker strings, with higher action, and has limited access to frets you can get started fairly easily with an electric, and you can pretty much play any style with it.
A type system that isn't 100% safe can still be a massive improvement over C or even C++.
Spitballing Indy: Lucas, Spielberg, and the creation of Indiana Jones
Startup Memories - The Beginning of Photoshop
I'm also a big fan of Marty Schwartz's, and I've learned a lot of great Blues licks and soloing techniques from him. Most recently I've been working on combining major and minor pentatonic licks and runs into my improvisations, and I'm loving my progress. Thanks Marty!

I love YouTube, I really do, besides great resources like justinguitar and Mary Schwartz, there are a huge number of excellent backing tracks you can use improvise over, here are a few of my favorite favorites

Happy Blues in E (great for mixing major/minor pentatonic)
http://www.youtube.com/watch?v=Dxo2bEX45KI

Acoustic Rock Style Backing Track - D Major
http://www.youtube.com/watch?v=ohbtYFRe-xc

Marty teaching 'Fly me to the moon' (great jazz standard)
http://www.youtube.com/watch?v=lr3fa1NDVB4
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)
If I had said, "Cars are used for transportation," would you say, "I know a guy whose car doesn't have a motor, but he sleeps in it"?

Or if I had said, "Tables are flat surfaces," would you say, "I saw a table in the museum of modern art that had a curving surface"?

So, yes, you are completely right, and I don't dispute what you're saying, but it does not invalidate the generalization. Analogously to the example cases I just gave.

There is probably some philosophical name for and explanation of this phenomenon, but I don't know what it is.
Please contribute to my new blog post about "Ideas that can kill you"
Hey guys! I'm working on a new blogpost for my blog about "deadly" ideas and I'm very curious what you think about that topic.

Would you agree that there are ideas which can almost kill you? Of course not literally, but those ideas wipe you off completly and leave you demotivated, lost and frustrated. On the beginning everythig looks awesome, you are sure that you going to change the world and your goals are clear. You know that your idea exist to solve some certain problem. You are trying to implement your idea to solve that problem. Sometimes though problem is starting to diminish and the idea becomes a goal itself. You are no longer interested in solving any problem, you only care about making your idea working. You completly loose touch with the reality, doubts and fact against your idea don't reach you. I think you can see clearly how dangerous a bad idea can be. They are parasites, because they kill your project and your motivation.

I have one expierience with neglecing reality and falling for a "deadly" idea - I don't wish anybody similiar stories. Hopefully we realised what's going on after a year, pivoted with all determination and left the "deadly" idea behind. We saved our business and it's going well.

I'd like to write about distinguishing "deadly" ideas from good ones. How do you validate your ideas? What's your favourite methodology? Can you share your stories about experiences with "deadly" ideas? I hope all your stories finished with happy-end!

I'd love to add reference to your projects and comments in my post, so please leave some contact info if you want to contribute and safe others form falling for a "deadly" idea:)
That MSKLC [keyboard layout creator] with a jailbroken Surface RT thing?
I would second this. justinguitar.com is a great resource for learning the guitar.
Rosalind [1] (previously posted on HN) is pretty good for something like a Project Euler for bioinformatics. The problems are pretty similar to the introductory computational biology course at my school for upper-year undergrads and first-year grad students.

It's a really good way to get a good overview of the field, and what some of the problems have been already solved in bioinformatics. It's definitely best to combine it with a more traditional textbook such as "Introduction to Computational Biology" (Haubold and Wiehe) or "Biological Sequence Analysis" (Mitchison, Krogh, Durbin, and Eddy).

Hope that helps!

[1]: http://rosalind.info/
I don't understand exactly how the site works...

I'm guessing that I'll get a newsletter with videos, and "curators" will decide which are those videos? Will you subscribe to curators, or how that will work? can you suggest a video without being a curator?
I'm not sure you've ever used XHR if you call it the callback pattern.

The XHR object is effectively a request and a response bundled up into one object that has promise-like traits. You attach event handlers to it to handle various state changes and scenarios, and then once you issue the request, the event handlers get invoked 0-N times. If it really was JavaScript callback-style, XHR would look like this:

window.xmlHttpRequest("GET", url, function (result, error) { ... } );

It doesn't. setTimeout/setInterval are definitely callback-passing, but they're not exactly glowing examples of stellar API design. They return integer IDs instead of handles or objects!

Honestly, the only way to classify node's callback-heavy design as a 'no-brainer' is if you excuse the design by saying no thought was put into it beyond simply doing what a bunch of other people were doing. If you put enough thought into how large applications will be built, and how difficult it is to build scalable, maintainable libraries, callback-passing style easily loses compared to promises.
This is simply false.

Here's a discussion about removing promises from node.js in 2010:

https://groups.google.com/d/msg/nodejs/RvNoQtoWyZA/ar_lYLhK8...
I prefer company meals since it saves my time. I don't have to go out and get food or bring my own. This is assuming the food is good and healthy, which it happens to be.
> Gremlin-Clojure, and Gremlin-Scala are being developed/maintained by community members

Would be nice if other Groovy-based products like Gradle enabled a Scala and/or Clojure frontend to appeal to us who are fussier about what shell language we use.
Welcome to 1991, Web browsers.

http://en.wikipedia.org/wiki/Direct_Client-to-Client
> One of the pet peeves when people say "believe in science".

The phrase "believe in" can also mean "have faith in".

The majority of scientific discoveries are not something that most people can observe, measure, calculate, etc -- either because they don't have the ability or the time to do so. In order to trust scientific finding, people have to have faith in the science that's been performed by others.
St. Croix
For bars and the like: It's not the bar (well, some and/or some places do have atmosphere), it's the people you meet.

If your visitors are from "out of town" in some significant fashion, and if they are nice enough that you don't think they'd be an imposition, arrange to meet with some of your friends.

Any place can become magical, if you're there with good people and making friends.

(Plus, someone's always doing something, or has some time free, and maybe they'll extend an invitation. (Just don't expect anything.))

P.S. This may be a bit OT, I realize, with respect to the idea of an online resource of things to do/see.

P.P.S. This is somewhat personality dependent, but when I visit my cousin in the Bay area, we end up stumbling into all kinds of small encounters because she simply, directly -- if politely -- asks questions. If something peaks her curiosity, she simply asks. She has no fear!

Walking through Chinatown, we decide to try some tea with tapioca balls -- she's heard they're useful in dieting. She asks some questions of the server. We also end up talking with one of the other customers. A random "tourist" encounter turns into a few pleasant minutes learning a number of things and getting a bit of the local "vibe".

Multiply that by several-fold through the day, and it ends up being a pretty interesting day. Thanks, cous'!
white on gray?

Please change that.

http://contrastrebellion.com/
Use Emacs, then you don't need several not very good editors. /flamebait
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.
If the dealer's way is "better" then why do they need laws to enforce it? Another example of an entrenched business fighting to maintain a legislated monopoly by buying off the legislators. Capitalism fail!
First, in agile teams, there is no assigning of tasks, each member takes the ones they feel like tackling.

Agile in not optimal for maintenance or emergency production issues. These are dealt immediately and only mention in the daily stand up as a blocker stopping you from finish the task you actually intended to complete. They are not even added to the product/sprint backlogs.

As a rule of thumb all user stories added to a sprint should take between half and 2 days to complete. If you have a whole bunch of small bug fixes, group them together so they fit in that time-frame (i.e. all UI bugs in page foo). Otherwise you end up polluting the backlog with hundredths of little things and turning your planning meetings into overwhelming nightmares.

Just think about it: if everybody in the team is working on only one or two tasks every day, the daily stand up will take each member about 30 seconds and the whole meeting less than 5.
Don't a lot of programs first check for program-specific EDITOR values? So if you want to change the one for git, set GIT_EDITOR? Seems a lot cleaner than trying to recognize the filename.
Joyce Mauldin People Search Results | PrivateEye.com
The excuse you gave for Buffet's long term success was that legions of others copy his investments and they become self fulfilling prophecies. But Renaissance Technologies are very secretive - they publish virtually nothing about what they do. What are the odds of them greatly outperforming the market (and always having positive returns) for all those consecutive years? What will you if they do it again this year?

(and I dont think anyone claims they've been playing by a single strategy all this time)
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.
Most contracts include a severability clause, which basically says that if any part is found to be invalid, the rest of the contract continues to apply anyway.

http://en.wikipedia.org/wiki/Severability