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)?
> 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 chart isn't misleading--it shows what it purports to show: the share of total profits in the cell phone market. The chart suggests that Apple has managed to capture a big %-age of the total profits in the market by targeting a high-margin niche, which is in itself a useful observation.
The chart would be misleading if it were, say, comparing profit per phone (which would for no reason make companies that sold a lot of cheap phones look worse than companies that sold fewer expensive phones) but that's not what this chart is doing.
If the graph includes feature phones then that will necessarily dilute Apple's profits since they do not make a feature phone. Therefore that makes Apple's numbers appear less impressive.
I don't have an answer to your questions, but I'm sure Mr. Dediu would be happy to answer them transparently. He's not a journalist cooking sensational stats, he's a serious amateur analyst who tries to make revealing graphs with an intellectual honesty that is refreshing and a community-driven feedback process that is producing better punditry than most of the professionals. I know a lot of people have a chip on their shoulder about Apple, but it is possible to be both interested and impressed by Apple and also still be a rational observer.
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.
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.
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.
class C {
void mightFail() { ... }
~C() { doCleanup(); }
};
C c;
c.mightFail();
Anyway, I hate this slide deck so much.
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.
You seem to have failed to grasp that the slides are arguing for RAII. While admittedly mildly trollish, it disparages java along with C#/ruby/python implicitly in favour of C++ only because C++ has the most 'correct' implementation of RAII.
There is no argument against try/catch/finally, the argument is that the most common usage of try blocks is for dealing with resource management, not actual exceptions in program state. Given exceptions should be used to expression 'exceptional' program states, that is a significant downside to code readability.
Syntactic sugar like using/yield/with blocks improve the signal to noise ratio of try block usage but still rely on programmer acceptance of that idiom. Ideally, the responsibility of cleanup would be moved entirely to the class implementation rather than the consumer. C++ did this with destructors. In a managed world where maybe you don't always want an eager dispose, rather than syntactic sugar in the caller, move it to the signature of the dispose. Something along the lines of
public scoped void Dispose() {
....
}
Alternatively, @Scoped or <Scoped> if you don't want more keywords. The topic is partly to blame but RAII is orthogonal to whether a language is garbage collected or not. It's sad that in an age where PLs are undergoing a sort of renaissance period, mention of C++ causes everyone to circle their respective wagons.
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.
* Meta is mapped to the Command key (and the option key).
* Control is mapped to control.
* I suppose I should try to remap the Fn key to be Control to really make it work right instead of the weird curve that currently has to happen.
When I really am interested in getting typing done I hook up a MS Natural 4K. It's a much more pleasant experience. My keybindings are customized for maximum ease there (and believe me, my hands/wrists do not hurt after a long-term coding session there). Laptops are fine for messing around for a while, but after a period of typing my hands hurt.
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:
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)?