qntm

> Nerds are expected to be horrendously, gratuitously crass, offensive and insensitive of people's emotions. This is like being mad that the sky is blue.

Speaking as one of millions of pleasant, sensitive nerds, I find this offensive.

I would be very interested to see a single real-world use for a fixed-point combinator. I have a reasonable understanding of what one does, but I still haven't got the faintest idea why you would ever need one, nor have I seen a single situation in which applying one doesn't make the situation unimaginably more complicated to understand.

By the "old news is still news to someone" logic, the same 2500 stories could circulate through the HN front page over and over again forever.

Of course, there are plenty of actual tricky programming concepts: closures, tail recursion, coroutines, memory management, concurrency, regular expression matching, caching, algorithmic complexity, naming things...

A function call in a for loop's conditional is practically C best practice. K&R do it on almost every page.

Isn't this more of a problem with rel="start" than rel="next" and rel="prev"?

> I think Google is right here. If you mark something as a sequence, it is reasonable to presume that the start of the sequence is the normal entry point, in this case the front page of your blog.

I disagree. Just because the rel="prev"/rel="next" commands provide the ability to browse forward and backward through a series of documents doesn't mean that the only possible entry point is the beginning of the series. It doesn't mean that there even is a single well-defined first entry in the series. There's nothing to stop a series of links connecting into a closed loop, or to stop a single page from having multiple rel="prev" links because it appears in multiple series, or multiple rel="next" links because a previously linear series bifurcates and the user has multiple choices.

Indeed. But the point I was making was that this hypothetical coder introduced more complexity by adding "i--;" whereas the code could equally well be fixed, in the same number of keystrokes, while reducing complexity, by removing "i++;".

What's wrong with the code, then, is that it was written under a little too much pressure for the developer to think clearly.

    for ( int i=0 ; i < this.MyControl.TabPages.Count ; )
    {
       this.MyControl.TabPages.Remove ( this.MyControl.TabPages[i] );
    }

The best I've managed is this: http://qntm.org/fib

I find that removing all mention of Y combinators made the whole thing a lot easier to read.

I'm going to write up some sort of explanation once I can get my head around it myself.

The way I look at it, there is only one reason to write tests: to assure shippability.

Everything else is a pleasant bonus. It amazes me that so much can be written without even touching on this.

Windows 7 was the first operating system I used which actually got this right. The options present, like "keep the second file, but rename it" and "do the same thing for all the rest", were options that I actually wanted to use and which were actually like meaningful, unlike the ambiguous and useless buttons such as "skip" and "ignore all" which came before.

Thus, mathematics unexpectedly turns into a Choose Your Own Adventure novel!

What is true in mathematics is whatever leads to no logical contradictions.

That has merit. Personally I usually find myself doing something more like this:

   if (argc != 3) {
      printf ("Wrong number of arguments");
      // throw an exception or return NULL or something
   }

   if (!fname) {
      printf ("File name cannot be null");
      // throw an exception or return NULL or something
   }

   /* Do stuff */

The important thing, to my mind, is the absence of an else block.

Certainly.

The else block in this case is executed when "NULL != fname" is false. That's an unnecessary double negative and takes a nonzero amount of mental effort to unscramble. The example I gave reverses this. This would also be acceptable:

    if(fname) {
        g = fopen(fname, "w+");
    } else {
        g = tmpfile();
    }

(I also don't regard either statement as an "exceptional condition", they both seem equally likely to me.)

In addition to everything else, please don't use a negative condition in an if/else statement.

    if(NULL != fname) {
        g = fopen(fname, "w+");
    } else {
        g = tmpfile();
    }

Better:

    if(NULL == fname) {
        g = tmpfile();
    } else {
        g = fopen(fname, "w+");
    }

Man, and here I thought that documentation-driven development was the top of the ladder (above test-driven development, above just writing the code first).

Well, if we are, then this certainly isn't the only industry in which everybody is a fraud. Look at the people who make movies, or generate electricity, or trade stock, or grow corn. Look at the people who run our various countries.

It's a really unnerving day when you realise that the whole thing is run by human beings.

Doesn't that become awfully confusing?

Speaking as a novice Ubuntu user, I don't even know what "install a port" means. Do you mean "open a port"?

This is not a perfect solution because the RLO character isn't printed, there is nothing to highlight. There are several other non-printing characters in Unicode that I'm aware of, like the zero-width space.

Just forcing a company to say "We expect X amount of growth in the next financial quarter, and the reason we expect this amount of growth is - even though we are an international financial corporation - guesswork and gut feeling, rather than any kind of formal model" would be a step forward.

You have two companies. Both predict X growth. One provides a full model which backs up their prediction. The other flat-out states that they made the number up. Which would you pick? It doesn't actually matter - the point is that their operations are more transparent and your choice is more informed.

Interestingly, the article explicitly states that our dictionary supports only the exact string lookup command, dict.contains(string). Strictly speaking, the full content of the dictionary isn't available to us, and we can't create the regular expression.

This was actually going to be my solution as well. Regex engines are optimised for exactly this sort of problem, why duplicate the work manually?

I'd be willing to say it right now, since I agree with it.

Just backslash-escape the internal right-paren.

   (So do I ;\))

I think the code is the solution. If the code isn't written, the problem isn't solved.

The boy should provide load-testing services as a spinoff business.