Look on the bright side, maybe you're getting off cheap: yesterday, it was two hours for me...

I'll assume from that comment that you're not an experienced stock investor. I think you confuse "profits" with the term I used of "return on invested capital." Here are links to the the financials of Apple, AT&T and Verizon.

Look at the bottom of each under the "Management Effectiveness" section. The numbers in that section and other numbers on those pages suggest that Apple, who is the most successful name-brand mobile phone producer, is earning several times as much money on each invested dollar as the other two, who are the commodity mobile carriers.

Although not all corporate management is as smart as Apple's, Tim Cook and his colleagues would never deploy their capital in such a poor business as commodity mobile phone service when they can earn several times as much deploying that same capital in some form of their existing business - assuming they can come up with the next 'i'-whatever-it-is.

That could change in the far future if Apple phones ever became commoditized the way Android phones are. For the time being, though, they are making a lot more money per dollar of investment than anybody who sells the carrier service those phones depend on. As the old song goes: Nice work if you can get it.

Translation: "We don't like commodity businesses. We'll do some things along the way, but in general, I like the fact that we've got a lock on the highest-margin portion of the mobile phone business, and I like the things carriers do, such as competing to see who can invest the most in expensive mobile infrastructure in order to minimize their return on invested capital."

When I was in high school, I took Chemistry II. Part of that was to do an advanced experiment of some kind. I ended up picking one out of a book the teacher had. It involved butyric acid.

The school chemistry lab was very well stocked, though many of the chemicals were quite old. For example, we had a large brick of sodium in a jar filled with kerosene. First thing, the teacher told us, "Absolutely leave that thing alone." He went on to tell us that it could explode if dropped in water.. He was serious, and we took him seriously.

But I digress. The lab also had the butyric acid I needed. I did the experiment (not very successfully, IIRC) and then proceeded to my next class. It was a computer class, on the original TRS-80 "microcomputers."

Everybody thought the computer teacher was a wonderful teacher and a very nice guy, including me. Just after class started, he said, "What's that smell?" We were all a bit puzzled, but we all started sniffing around, and the teacher ended up honing in on me.

I smelled of rancid butter. Having found the culprit, the teacher told me, "Get out - just get out."

I meakly protested, "Don't I need a hall pass?"

"I'll bring you one, just go."

It turned out that some of the butyric acid had vaporized and adhered to my clothes. I somehow managed to make it through the rest of the day by issuing various warnings and apologies in my remaining classes. I think we had to throw the clothes away.

By bringing "fair use" into this, I was trying to illustrate what I see as the optimum balance between society and API creators. Evidently, we disagree on where the balance should be (which is, of course..."fair"), but I wonder why someone would open an API if they don't want people to use it?

In the particular case of Java, I'm sure many of us here remember how hard - and successfully - they marketed it as a "write once, run anywhere" language when it first came out. I think that turned out to be a bit of a bait-and-switch thing, possibly due to the acquisition by Oracle, which may now have a different vision for it than Sun had originally planned.

Specifically, I don't think Java would have been adopted so widely and so quickly as it was when it first appeared if the marketing had instead been "write once, run anywhere, but never re-implement it." I'm not sure what specific legal promises were made about it at back then, but nobody understood it that way at the time. In fact, Sun took great pains to keep it standardized and even eventually succeeded in getting Microsoft to back out of the tactic of "embrace and extend" that they were known for at the time.

Likewise, on something like Python, its creator, Guido van Rossum, seems to like to steer it's future course, but doesn't try to quash alternatives. In that vein, in the book "Little Big Man," (highly recommended, BTW) the wise Indian chief, Old Lodge Skins, is not the chief because he forces anyone to do anything; instead, when he says "I think I'll put my teepee over there," people naturally put their own teepees nearby because they trust his wisdom.

Then again, tribal chiefs of the 1800s were much more oracular and less litigious than their counterparts in some of their modern corporate tribes. :-)

You make a good point, but what is the purpose of an API except to separate the interface from the implementation, if not to allow and encourage multiple implementations? In that vein, whenever someone publishes an API, they are implicitly allowing/encouraging multiple implementations. I suppose that one could argue that someone who does that might expect a royalty from someone who does an alternative implementation, but the "fair use" of APIs seems to be a train that long ago left the legal station.

Many years ago, I asked a lawyer the corporation where I worked at the time if I could use the old Hayes modem command set for another purpose. He said that I could. Of course, that was just his own opinion and likely was uninformed by any relevant court rulings. Still, it illustrate that the concept of an API needing to be licensed made a certain amount of sense in order for me to ask it, and it illustrates that a trained legal mind could easily conclude that it didn't.

To me, the idea of "fair use" in copyright law is intended to draw a line between the net benefit to society of people being able to use works in certain non-revenue-producing contexts such as scholarship or research, while allowing creators of works to be paid in the remaining commercial context. My common-sense, IANAL perspective on this is that society gains more than API creators lose in the process of allowing APIs to be used without licensing.

Agreed. Let's not throw the legal baby out with the semantic bathwater.

Regarding theocrats, see patriarchy. In fact, I can't think of a single theocratic country that is run by women...

Maybe I'm not as smart as you if it took me longer years to figure it out. Even so, based on our figures, it sounds like it takes you about three times as long to get something working well after the point that it nominally works. That might explained why you noticed this effect almost immediately. ;-)

In the safety-critical world I work in, we have to do both unit tests and what we call "system tests," aka black-box tests.

As an analogy, you could test test that a mechanical clock "works" because it tells time accurately, but if you really need to be certain that it will be reliable under all conditions, you're also obligated to individually test all of its gears and other various parts.

I'm glad the people who write code for things like airplanes and medical devices do that, even if the Linux folks don't. That my be why Linux can only be used in airplanes in non-safety-critical applications like the wi-fi router that lets you watch movies as you fly the friendly skies. If it were to be used for something at the highest level of safety-criticality like an autopilot, The Authorities, worldwide would require you to produce evidence that you had requirements-based module tests that covered every bit of the object code that the compiler generates.

Exactly true. I've found over many years of engineering that there is a vast difference between something that nominally works and something that works perfectly under all conditions. Once you've achieved the former, you've done perhaps 1/3 or less of the work required to get to the latter.

I think you confuse "the art of programming" with "the craft of programming." If it were the former, you'd be allowed to put the noses on sideways, like Picasso, and call it "art". But as a craft, you need to produce the best work possible, even though it certainly contains an element of art.

I work on safety-critical software. We are required to do rigorous unit testing on every line of code by The Authorities. And I regularly find bugs in my code in the process. In fact, since I will be developing unit tests anyway, I (try to) make it a practice to do develop a module and its test simultaneously, which is more efficient than doing the unit test at the end, as is the common instinct by those who regard unit tests as "useless."

I also think you confuse "useless" with "efficient." Depending on the use of the software, unit tests may be an inefficient use of development time - as the Linux folks evidently believe. So, I don't do unit tests for every category of software. For example, there's no need to do that for a simple utility script. But I wouldn't want to fly in an airplane whose autopilot code was never unit-tested, and whose developers instead simply assumed that all the code they write is bug-free.

Yes, it's hard to imagine how anything could be better - until someone invents it.

Here's my wish list: wouldn't it be nice if Git had some mechanism for ad-hoc sharing of individual files? Where I work, we replaced an older commercial version control system that was excellent at that with Git a couple of years ago. Git is an improvement overall, but we still lost something significant along the way. Git's submodules are a great design for sharing large blobs of code but they don't serve quite the same need. In effect, the transition to Git has made us change major aspects of how we develop software.

I know there are various systems for bolting-on ad-hoc sharing to Git, but I'm looking for that as a feature of Git itself. I'm sure Git meets its original purpose of managing the gigantic Linux code base very well, but in a corporate setting, it would be nice to be able to share little blobs of code in any combination, as we used to. That causes some problems of its own - namely, divergence over time - but it's a major benefit if done judiciously. I'm not sure if ad-hoc sharing is 1) something that's anathema to Git, 2) something they don't care about, or 3) something they just haven't done yet.

Dear Mayor Chang,

What part of "building permit" and "property taxes" don't you understand? If you folks let Apple build a giant doughnut in Cupertino without the city collecting adequate local taxes on it, you can hardly blame us, can you...?

your friend,

Tim Cook

A puzzle unsolved is far more interesting than a puzzle solved.

I always think of the JFK assassination in these cases. The fact that Lee Harvey Oswald appears to have done it, yet we have numerous things that don't quite seem to add up, e.g. "the magic bullet," "the grassy knoll," etc., makes it far more interesting than the Lincoln assassination, where all the basic facts are pretty cut-and-dried.

Regardless of whether Wright is a con man or the real deal, he's clearly toying with us: his most recent statement seems more likely to spark our interest than to quell it.