abstractfactory

The headline manufactures drama from the contrast between "8.7% market share [in units sold]" and 75% of profits. This is the silly part of the coverage.

It's not Dediu's fault that Elmer-Dewitt at CNN Money chose to be ridiculous, so your defense of Dediu's integrity is beside the point.

I don't doubt that Apple has vastly greater profits than any of its competitors, but stats like this are cooked to make the ratio seem even more impressive than it already is. The notion that a feature phone and an iPhone are substantially in the same market is silly. It's akin to categorizing ThinkPads and land line handsets as part of the same market. Of course, journalists optimize for the most dramatic headline, not the most informative or truthful article, so we're not going to see many apples-to-apples comparisons on this subject in the tech press.

Also I have a non-rhetorical question. Apple, and several of the competitors graphed here, have many lines of non-smartphone products. Is this graph tracking the profit/loss of their smartphone divisions only, or profits of the company as a whole? If the latter, then the comparison is silly, isn't it? And if it's the former, how does this analyst account for costs shared among multiple divisions, such as iOS development (which is a cost that's shared with their iPad and to some extent even their Mac divisions)?

Abstractions are partial and leaky models of the thing they abstract over. When you build your system as a tall, skinny tower of small abstractions, you are trading one problem for another. Eventually you will need to thread some new functionality all the way through your stack, or you will have to debug a problem that requires understanding cross-layer interactions, and you will end up spending much of your time fighting your abstraction choices.

Unfortunately there is no silver bullet. No single recipe will tell you how to cut up every project into modules. You have to work hard to find the right decomposition for your problem. Arbitrary size limits are as likely to hurt you as help you.

That said, programmers should indeed strive to write less code, as a rule of thumb.

Structural subtyping is not OO? Somewhere Luca Cardelli is scratching his head.

Bruce Sterling said some similar stuff in the Last Viridian Note, and he said it far better: http://www.viridiandesign.org/notes/451-500/the_last_viridia...

It's a little unfortunate that viridiandesign.org is basically unreadable due to that terrible background image.

English? Hah. I'm against the whole patent charade but if we're going to grant them, the inventors should be forced to disclose the entire goddamn source code, development infrastructure, and version control repository which proves that they've actually invented something and not just handwaved in the direction of an idea.

The second example should actually be

    class C {
      void mightFail() { ... }
      ~C() { doCleanup(); }
    };

    C c;
    c.mightFail();

1. The author's point could be made in far fewer slides. As in, like, two slides. I hate presentations that are disrespectful of the audience's time for the sake of being cute.

2. I am generally unimpressed by arguments of the form: (a) Language X has flaw Y. (b) Therefore language X is unsuitable for development. This can be instantiated for every language X for some flaw Y and is not an argument against any language. You need to additionally make the argument: (c) Y is so serious that it outweighs the considerations in favor of X and against the other languages one might reasonably use. Of course (c) is an incredibly high bar, which is why most anti-language zealot arguments do not even attempt to make it, and also why most anti-language zealotry is silly.

In order to do (c) in this case, you would have to make the case that writing finally clauses is worse overall than, e.g. debugging memory corruption errors, and writing copy constructors and overloaded assignment operators, and all the other baggage of C++, rather than handwaving them away with "the downsides have been exaggerated".

Which, by the way, is ironically the biggest flaw of this slide deck: the author vastly exaggerates the downsides of finally. try/finally is no worse than checking the result codes of C syscalls, and it is sometimes better. I don't recall the C style of programming stopping Ken Thompson from building great things and I doubt that try/finally is actually what stops Java programmers from building great things.

Thread hijack...

If you use Emacs all day on a Mac, what do you use for the Meta key? I find I'm not really happy no matter what I do. If I make Option into Meta, I have to bend my thumb way under my palm to hit Meta. If I make Command into Meta, then I lose access to lots of global Mac UI shortcuts. I guess I could experiment with swapping Option and Command and then using Option as Meta, although I'll have to retrain a lot of muscle memory.

And then there's the fact that one Emacs window in a terminal is still not as productive as five Emacs windows under X11, and X11.app still sucks, and the various native Mac Emacs ports still don't feel right to me.

Overall I find using Emacs on Linux X11 still provides the best Emacs experience. This alone will probably keep me on Linux as my primary work environment for the foreseeable future.

In 2004 Bacon et al. showed that tracing GC and ref-counting GC are special cases of a more general framework, and that it is possible to combine them to get the benefits of both. See "A Unified Theory of Garbage Collection" here:

http://www.research.ibm.com/people/d/dfb/publications.html

Scholar cluster:

http://scholar.google.com/scholar?q=bacon+unified+theory+gar...

Incidentally, it is not even remotely true that reference counting is more efficient than tracing GC in all cases.