duncanj

Includes EFI support. Interesting.

I imagine, "What's all this? Why not just write (dwim)?"

Also check out the author's site for picolisp: http://www.software-lab.de/down.html

I call it "true" mainly because it faithfully represents the code/data unification in lisp. In picolisp, there is no lambda, because the representation of a function is a list, and can be quoted directly.

I think you've cherry-picked that belief. The discussion I have seen has convinced me that the "hockey-stick busted" thing is a red herring.

"Why not ... [submit] his own analysis of the public data ... explaining how it improves on existing analyses?"

This is the meat of the matter. Scientists write letters to journals all the time saying that they think an author overstretched. Those letters, in and of themselves, do not negate the previous research. Scientists also write original papers showing that a previous hypothesis is invalid. Those papers, if they are well written, are easy to publish, especially if they make the journal more interesting.

I thought the discussion of computers from smoking households was interesting.

On the contrary, it is very relevant, as many of the links that rise on HN are similar to management/self-help guru type things.

I think you're doing the same thing as the "good" knuth algorithm which, as I read it, always exchanges the random card with the one at the decreasing index from the end of the deck.

I agree, except the seasonal "H1N1" flus are not "swine" flus per se. They don't tend to infect swine, and are best considered human flus. All type A flus are, originally, duck flus.

It moves too quickly for my tired eyes to read anything.

The HMO trend was based on the assumption that people were usually going to work for the same company for a long time. It made tons of sense, and still does in a union-provided health plan context, for example.

Perhaps the trend will be for employers to pay the tax, drop their company-based health plans, and then their employees will purchase their own plans that follow them around. Then, these plans will keep individuals in longer, making it more worthwhile to focus on prevention and overall health.

3.1 required you to do those things regardless of whether you upgraded or not :)

Note how the EPI shill is only allowed to make factual or neutral statements, while the Republican shill gets to discuss the only policy options in the piece.

The skepticism in the article about Abdussamatov's conclusions says to me that he has a long way to go before he can really show "solar, not human" cause. It's an alright article.

I think it's interesting that it is dated a year and a half after this discussion: http://www.realclimate.org/index.php/archives/2005/10/global...

"The shrinkage of the Martian South Polar Cap is almost certainly a regional climate change, and is not any indication of global warming trends in the Martian atmosphere. Colaprete et al in Nature 2005 (subscription required) showed, using the Mars GCM, that the south polar climate is unstable due to the peculiar topography near the pole, and the current configuration is on the instability border; we therefore expect to see rapid changes in ice cover as the regional climate transits between the unstable states."

This is called "puppy-dogging". You want to sell a puppy. The customer isn't sure he wants to shell out the money. So, you say, "Take the puppy home, and it's free for two weeks." It's obvious from there.

If only these opinions were carried in the WSJ, FT, etc.

I think critics tend to compare pair programming to those moments when they are most productive. One programmer in flow may be able to really crank something cool out in a day or so. He might even work 25 hours straight to do it, and really get it out there. If he spends the next week polishing, tweaking, and adding very little functionality, he doesn't include that in his comparison to pair programming. He did it in 25 hours, it took a pair of programmers three days, the pairs are slower, even though the pairs are done and have moved on to other, important stuff.

Pair programmers who work 6 hour days can finish a lot of useful functionality in a week or two. They also have social lives, get to take long lunches, go hiking on the weekends, etc., even though they are very productive. This is why I prefer it. Plus, it's totally sustainable, and it comes with a built-in training methodology.

I used to think that everyone really should start pairing. But I'm more in the camp now that people should form little organizations that pair and basically put everyone else out of business. If it's more productive, places like hashrocket are going to become the leading shops for software. Their employees are going to make twice the market rate, have social lives, good friends at work, interesting problems to work on, and relativley low stress. If it's not more productive, they'll probably eventually have trouble competing.

I don't know if LT and RMS would have gotten along in that way, but how productive over the years has each one been? If you put them on the same team and paid them well, and they had goals they shared, etc., etc., I don't find it all that unlikely.

A decent long-range offer should have a signing bonus for quick acceptance, that you lose if you take your time accepting it.

The meter is still off... as well as the rhyme.

My experience differs. I found it much easier to pair with poor/inexperienced programmers than to encounter their code later without having paired. By letting such a programmer do the driving and critiquing as they went, I felt like they were learning useful things and I was saving myself a lot of trouble in the future.

"Dumb software" -- FTFY (title)

I could totally hang out with that guy. Taleb's a fool.

Interesting press release about chlorophyllin, but natural compounds are already used as chemotherapeutic drugs, for example Taxol. Some drugs are wholly synthetic and others are found in natural sources. Whoop de do.

I can't seem to get an OH or O-H. Do I need ID? ;)

If it's important to you, why not ask and find out?

Why do most of the articles in the series start with "...Not"?

Transport layer

It still bothers me that web browsers don't really "do" REST without Javascript.