HackerNews is an ad for yc, pg's articles and talks are for publicising yc. I think the real difference b/w blatant advertising and the type Joel and pg (Buchheit, Greenspun, Yegge, maybe 37Sigs) is they impart knowledge, useful knowledge. If they did not entertain, inform and question readers wouldn't bother reading their pieces.

But I do understand the continuous 'Fogbugz' references. Maybe it's the geek in you rejecting someone telling you need something when you don't.

Maybe nickb is right. The page design also sucks making it hard to read and possibly needs some attention?

I don't think so. PG was writing essays and giving talks about startups before YC.

Of course this were insights he had accumulated through many years, its hard to keep churning out great insights on a regular basis, so I think people just get disappointed.

Also, his insights are mostly related to business and high-level decisions. When he writes about coding, his opinions seem slightly curious: exceptions suck, Hungarian notation rules and so on.

Have you actually read his article on this? I think it's very good.

http://www.joelonsoftware.com/articles/Wrong.html

Joel doesn't say that you should prefix integer variables with 'i' or use -1 as an error code (he prefers returning multiple values). He only says that every line of code should indicate as clearly as possible what it's doing so that you can still understand it six months later.

Exceptions eliminate one problem (a function can only return one value) but introduce another: it's impossible to tell by looking at a block of code where it will exit. If a series of statements might get interrupted halfway through, there needs to be an indication of this or else it's very easy to create bugs. I know this from experience.

He could solve the tainting problem by just wrapping the unsafe string in an object. This would be safer even in a dynamically typed language. His example is only relevant to very early versions of VBScript that didn't support classes.

Regarding exceptions, they are NOT supposed to be used for returning multiple values. They supposed to be used for exceptional results that cannot be handled locally. They don't have to be "invisible", e.g. in Java you have to either explicitly handle an exception or explicitly declare that you may propagate it. Using return values OTOH you may forget to handle a return value, and the compiler will not complain. His complaint is more valid wrt. C# where exceptions are indeed not checked by the compiler. But since he don't even seem to be aware of this difference, I'm pretty sure he knows about neither.

The point is that there is no such thing. Exceptional situations should always be handled locally, and by locally I mean on the very next line. If they can't be, then the program should stop running.

Writing code with exceptions is very hard to get right. Not checking return values is just stupid.

Consider a module that does some IO. The module might be used in different kinds of apps, both GUI apps, services and command line apps. How should this module handle a "disk is full"-error? Should it show a dialog with a warning, or write the message to the console and die? The appropriate action would be completely different depending on the type of app and the context wherein the module is invoked.

Exceptions allows the module to delegate the error handling to the right level of abstraction.

You need to do the explicit propagation after every single line that might generate an error. That seems to me to lead to a lot of boilerplate code, and it would be easy to forget or mess up one of these lines.

I kind of see Joels point though, that if you write:

    openFile();
    doSomething();
    closeFile();

A language for programming nuclear devices like Joel hints at, might make the throws clause explicit on every method call:

    openFile();
    doSomething() throws IOErrors;
    closeFile();

However I prefer something like the using pattern in C#:

    using (file) {
        doSomething();
    }

Say you write a function that takes input given by the user, inserts it into a list, and then sends the action across the network. Every item has an ID, so when the function finishes, the current ID number needs to be incremented.

 add_item (item) {
     var item_id = current_id;
     insert_item(item, item_id);
     update_current_id();
     send_item(item, item_id);
 }

Two months later, you come back to the function and think, "That's messy. I should clean that up." So you do.

 add_item (item) {
     insert_item(item, current_id);
     send_item(item, current_id);
     update_current_id();
 }

What if the function header had said "throws NetworkException"? You might have been more careful, but I wouldn't count on it. If the function were longer, which it would be in real life, you probably wouldn't catch your mistake.

On the other hand, what if the code looked like this?

 add_item (item) {
     if (insert_item(item, current_id) == INSERT_ERROR) {
         return INSERT_ERROR;
     }
     if (send_item(item, current_id) == SEND_ERROR) {
         return SEND_ERROR;
     }
     update_current_id();
     return SUCCESS;
 }

This isn't "nuclear power plant" paranoia. What I'm describing is a real bug I had recently. It wasn't the first time that I've done something like this, either.

I like your idea of putting the throws clause next to the function call. I'd like to see something like that for checked exceptions, and eliminate unchecked exceptions completely.

I still prefer to write exception-based code, but I understand how you could prefer to use return values.

You can mitigate this by relying more on return values and less on side-effects. If the higher-level code depends on some side-effect, why not place the side-effect in the higher-level code after the function returns?

-Joel Fanboy