superbatfish

Downvoted for ...language, I guess?

I dunno, when faced with a somewhat troubling and frankly just bizarre concept like described in the OP's article, I think a recaction of "WTF" isn't exactly off-base...

What the fuck is wrong with people.

Yes yes yes. We read "Story of Your Life" in my Sci-fi reading club, and several people came away with the misunderstanding that the aliens could see the future or something like that. But your interpretation is correct (IMHO). Chiang was making a point about the subjective nature of consciousness, or at least one aspect of it.

That's interesting, because Chiang himself doesn't view "Liking What You See" to be his best work. In fact, he turned down a Hugo nomination for it, "on the grounds that the story was rushed due to editorial pressure and did not turn out as he had really wanted".[1]

Personally, I think Story of Your Life is a master work. I found the strange writing structure annoying at first, and then right at the end of the story you get an "ah-ha" moment that changes everything. What I thought was awkward writing turned out to be a masterful illustration about a theory of consciousness. I was floored by Chiang's ambition to even write such a story.

[1]: https://en.wikipedia.org/wiki/Ted_Chiang

I felt the same way, but ultimately decided it's a good attribute for an interviewer to have, even though it didn't work out this time.

A good interviewer should understand his interviewee's work, have ideas about it, and then use those ideas to probe for deeper insights than surface details like "who influences you as a writer?". But deep probes are a little risky -- you might not find anything in that direction.

In this case, more than one of the interviewer's probes was a little off-base, but -- to his credit -- he didn't pursue those questions too far after Chiang's responses came back somewhat tempered. Kudos for trying, and kudos for letting it go.

Finally, kudos to Chiang himself for being clear about how he views his work. When faced with an enthusiastic -- but incorrect -- interpretation of one's writing, some authors would just "go with the flow", hesitant to dampen their readers' enthusiasm (misguided as it might be). But Chiang gently shot down a few of the interviewer's ideas, ultimately strengthening the original meaning of his own work.

This piece isn't great. Sure, I agree that the election outcome was bad. In fact, I think it was an utter disaster. This piece tells young people (presumably, "millenials") not to worry, it'll be okay in the end. But it's too easily interpreted as "don't take action, it all works out in the end anyway".

A TON of millenials didn't vote in this election, and that's why the values they cherish (or will soon realize they cherish) will be trampled over. Marco's message isn't a call to action; instead it's placating. I hope someday we can look back and say "well, that was just a wrong turn." But goshdarnit, 3 days after the election is too early for that!

PS -- Like other commenters, I agree that this piece is a little too simplistic in its view of young=liberal=good and old=conservative=bad. I don't agree with that, and besides, it's a little tasteless to imply "don't worry, those people that disagree with you will die soon enough."

>You realize this same logic could seemingly dismiss any regulation

Well, kinda, but not to same degree. Wired money is obviously way easier to smuggle than physical goods...

Great points. It's true that whatever algorithm they end up with will definitely use ML. And it's also true that "interpretability" is one of the great challenges for ML in the coming years. But interpretability of a model isn't a binary attribute. Some techniques offer at least some intuition about why they chose their results.

But a human editor, on the other hand, is much less transparent -- basically, the best justification they can offer is "trust me, I know what I'm doing".

>I'm not comfortable with any given group of people doing such sort of approval

Historically, that's exactly what newspaper editors did. The algorithmic approach has the potential to offer greater transparency, but not if the algorithm isn't published.

Furthermore, now that Facebook is in a near-monopolistic position when it comes to picking winners and losers in what we read, acknowledging that fact publicly would be the bare-minimum first step they could take towards accountability. Then we can have a more open discussion about how news stories ought to be judged and propagated (or not).

>In python you can go from attribute access to using a property (getter/setter) without breaking anything.

True, but that should be avoided if possible. Python 'properties' violate the principal of "explicit is better than implicit". Once you realize "Oops, I need an accessor function here", the lazy programmer says "Aww, grepping for all uses of .foo and replacing them with .getFoo() will take 20 minutes. Instead, I'll just redefine it as a property and no one will notice." If you care about quality, go the extra mile: make it clear to the people reading your code that a function is being called.

Properties are a kinda nice language feature, but they are so frequently misused that I think the language would have been better off without them. They encourage bad habits.

The reviews for the car I looked at (Honda Fit 2008) all looked legit.

At least that totally rad cliff diving video that YouTube queued up afterwards was a nice chaser.

This whole article is a little misleading. It makes it sound as if anyone who happened to own Dell stock at the time of the buyout could have sued to get some extra cash.

But only in the footnotes does it mention this:

>To be eligible for the court-ordered price bump, investors must have voted against the transaction.

Clearly, everyone who owned Dell stock at the time thought it was worth more than $9.35. That's why they held the stock in the first place! Those who thought the company was worth much more (say, $18 per share), presumably voted against the transaction. They were understandably pissed when the transaction succeeded anyway, so they sued. But those who voted in favor of the transaction didn't get an extra penny -- they agreed on a price, and that's what they got.

On a related note, here's an interesting game theory tangent: If you think the buyout offer is a great deal, should you vote for it? After all, if you're confident the deal is going to succeed even without your votes, maybe you should vote against it -- to preserve your option to sue for even more money. But if everyone thinks like that, then the deal won't go through at all...

It sounds like these people did put their money where their mouth was. They owned the stock.

If you think the market is over-valuing a stock you hold, you sell it. If you think it's worth more, then you keep it, and refuse any offers to purchase it for less than you think it's worth.

These people tried to refuse the offer. As mentioned in the footnotes, only those who voted against the deal were entitled to sue for compensation.

The link lists interesting stats about their revenue. Does anybody know if they've published estimates on their costs (team size, developer hours, etc)?

You're right. These were all good tips except for #10, where the "solution" is not thread-safe. Checking for null is better.

Crap, I upvoted this before I noticed which publication it's from. How do I downvote it?

This seems like a huge deal. How does this not have 100's of upvotes on HN? Am I missing something?

And one last point. In the blog comments, I wrote this, which I think sums up my view of the performance discussion:

...it's worth noting that many of the tricky things about tuning hdf5 performance are not unique to HDF5. For storing ND data, there will always be decisions to make about when to load data into RAM vs. accessing it on demand, whether or not to store the data in "chunks", what the size of those chunks should be (based on your anticipated access patterns), whether/how to compress the data, etc. These are generally hard problems; we can't blame HDF5 for all of them.

I liked the post (well, as an HDF5 user, I found it depressing...).

My main qualm with it was the claim about 100x worse performance than just using numpy.memmap(). To the author's credit, he posted his benchmarking code so we could try it ourselves. (Much appreciated.) But as it turned out, there were problems with his benchmark. A fair comparison shows a mixed picture -- hdf5 is faster in some cases, and numpy.memmap is faster in other cases. (You can read my back-and-forth about the benchmarking code in the blog's comments.)

One minor complaint about presentation: Once the benchmarking claims were shown to be bogus, the author should have removed that section from the post, or added an inline "EDIT:" comment. Instead, he merely revised the text to remove any specific numbers, and he didn't add any inline text indicating that the post had been edited.

I think the rest of the post (without performance complaints) is strong enough to stand on its own. After all, performance isn't everything. In fact, I'd say it's a minor consideration compared to the other points.

When it comes to performance, I think the main issue is this: When you have to "roll your own" solution, you become intimately aware of the performance trade-offs you're making. HDF5 is so configurable and yet so opaque that it's tough to understand why you're not seeing the performance you expect.

This article omitted one interesting part of the story, which is how AMD led the way to the x86_64 architecture while Intel was attempting to migrate to a conceptually radical architecture in its own products (Itanium). As I understood it, AMD's success in the early 2000s was largely due to their leadership in 64-bit, and Intel had to play catch-up to adopt AMD's approach. (But when they did, they reclaimed the throne.)

You clearly do not understand software.

I'm very excited to start using it. It will be the thing that finally pushes me to Python 3.

>Few people are using it in any case

Probably true, but it's only been out for 2 months now, and most people who needed this feature are either using an ugly workaround (guilty) or have moved on to other languages that already had this feature. This time, I'm glad Python joined the crowd.

I saw this article, enjoyed it, and then said to myself "Now let me go read the inevitable well-meaning but misguided comments about the GIL." And sure enough, the very top comment is a well-meaning but misguided comment about the GIL.

The author of this article is talking about CPU-intensive tasks that involve C-extensions. Such extensions typically release the GIL during their execution, which means that you can effectively parallelize such workloads in a ThreadPool. (He explicitly mentions this about Numpy/Scipy, but most other CPU-intensive extension libraries behave the same way.) Heavy users of Numpy use Thread-level parallelism very frequently.

OK, clearly some Julia fans down-voted my comment, perhaps because they misunderstood it. I was trying to say something about human psychology. We can admit that it is silly, but we can't pretend that it doesn't exist. This may be a bigger deal than they realize.

Programming languages are used primarily by humans, which means they must be designed with human psychology in mind. Today, Julia would have (even) more community support if not for this seemingly inconsequential decision. The fact that it seems to be succeeding anyway is largely in spite of, not because of, this design choice.

Sure, we should examine the features of languages past, keep the good things, and leave out the bad things.

I thought that Julia was aiming for Python's niche, i.e. good at numerical stuff, but also decent at inter-operating with other languages.

Argh. We were so close to leaving 1-based indexing behind as a historical relic. But now it seems we'll be stuck with it for a while longer. I'm not saying we can do anything about it now. I just want someone to validate my frustration :-)

Trying to come up with an appropriate response to your comment reminded me of this: http://goo.gl/KqXXDV

You're not the only one.

OK, this might sound even stupider, but I feel betrayed by the fact that otherwise good, technical people would voluntarily make such a major mistake, and then defend it so vigorously in the face of so many complaints.

>zero-based isn't as good as 1-based indexing for mathematics and science

[citation needed]

>nobody want to change it.

Love the claim here, followed by a link that reveals an ongoing controversy. True, the core developers don't want to change it, so it's not going to change. They chose to ignore the protests of many would-be users of the language.

StackOverflow took on a tough challenge in getting its members to self-curate the body of questions on the site. They were smart to recognize that "more isn't always better", and thus gave moderators an incentive to identify and close off-topic questions.

There's nothing wrong with that idea, they just have a bug in the implementation. Somehow they've incentivized the closing of good questions that are frequently on-topic.

Here's an example of a plainly on-topic-yet-closed question that annoyed me recently: http://stackoverflow.com/questions/2847655/find-threads-runn...