gukjoon

The engineer ends up under the car. The hacker doesn't even change the bulb.

This is a great question. I can't speak to Facebook, but I ask hard algorithm questions and this is why I do it.

The point of these hard questions is not to assess if you know some obscure algorithm. The algorithms in these questions are obscure precisely because you're not supposed to know them. If the candidate clearly knows the algorithm I switch to a new question.

The point of these questions is to assess your ability to perform under pressure in an unfamiliar situation, which is a fundamental skill that all productive engineers require. I expect that any engineer I greenlight to encounter novel situations. These are not necessarily Hard Problems dun dun dun, but these situations will challenge your problem solving skills and you won't be able to look up the right answer on StackOverflow. I expect candidates to have the ability to deliver a solution that works and makes the right tradeoff between time, quality, and scope.

I have also had interviewers ask hard problems for the wrong reasons. Frowntown to that.

Love seeing this. Is there a bigger Erlang community now in DC? I went to a meetup in 2011 and it was like 4 people.

The real question is whether aquaponics can create higher quality food than organic produce, which is not subsidized. Subsidies are also unsustainable in the long run. The major costs in aquaponics are in the technology, which will inevitably get cheaper. If aquaponic agriculture truly represents an order of magnitude improvement in water use and space use, and can produce better food, it's only a matter of time before not even subsidies can keep traditional agriculture economically sustainable.

This is just what I needed to see after the front page of HN was dominated by bullshit about Surface and iPad mini. Finally, technology used to make something other than toys for bored rich people.

I think the site load time is an allegory for how long it takes for the JVM to start up.

There are some good links in this blog. If you are a Clojure newbie, definitely check out the text-only cache of this blog.

I also want to note that "Clojure newbie" has many meanings, depending on which direction you approach Clojure from. Depending on whether you come from Java, LISP, Python or nothing, you will start with different tracks. I would recommend that Java programmers actually start with protocols and reify, typically billed as advanced subjects, then the concurrency primitives, before getting into macros and advanced LISP stuff.

Is one of those patents "A novel technique for running a company into the fucking ground"?

A bit of the ole Ralph Nadar effect going on here, I presume. Java's share is being cannibalized by Groovy, Scala, Clojure, etc. They should start making a JVM ranking to start consolidating all those languages.

Ugh. Spoken like a true Ravens fan.

In all seriousness, yeah. Gilt went from black/yellow to predominantly black/white for a good reason.

I do like how the yellow pops though. Unfortunately, it also makes my eyes bleed. Maybe try a duller yellow, like goldenrod. My emacs theme is goldenrod on dark gray and it is pleasant.

This is awesome, but what gives me pause is the part where you have to write a foreign function interface for every single Carbon API call. Also, I would assume that Cocoa is completely unavailable when going to C. Is that correct?

I'm very happy to see the multi-platform vision of Clojure becoming closer to reality. I'm not in the "write once, run everywhere" camp. That goal is a bit ridiculous, but the choice of VM and the choice of language should be independent decisions. I like Erlang's VM a lot, but the language itself is not very nice. When writing iPhone code, I don't want to be forced to use Objective C.

Wow. 1. Have you written or debugged C sockets code? Because if you have, I doubt you would be dinging him on not wanting to do that. 2. He doesn't want to handle C/C++. I would say that most people who write application code are with him. 3. Yeah... I'm pretty sure Python, an interpreted language, is slower than Go, a compiled language. Even with the progress PyPy is making, I doubt it's going to beat Go.

The author needs no age defense. He makes a ton of valid points for why you should try out Go.

Very neat. How does this treat forks? Does it consider only the commits you make?

You could say that it's ironic.

You know what? I realized that I didn't read the whole question. I switched from Octave, not Python. Oops.