Cross With the Platform
Tim Bray tweeted, No platform has hit the big time till it's been flamed by JWZ. He was referring to this rant in which Zawinski systematically dismantles any claim the iPhone has to cross-platform compatibility. "I finally got the iPhone/iPad port [of Dali Clock] working. It was ridiculously difficult, because I refused to fork the MacOS X code base: the desktop and the phone are both supposedly within spitting distance of being the same operating system, so it should be a small matter of ifdefs to have the same app compile as a desktop application and an iPhone application, right? Oh ho ho ho. I think it's safe to say that MacOS is more source-code-compatible with NextStep than the iPhone is with MacOS. ... they got some intern who was completely unfamiliar with the old library to just write a new one from scratch without looking at what already existed. It's 2010, and we're still innovating on how you pass color components around. Seriously?"
#ifdef APPLE_HARDWARE
doItTheirWayOrHitTheRoad();
#endif
You complaining about a company that retains control of whether or not you can release the app to the device even if it conforms perfectly to their APIs. If that's not a deal breaker for you why do you think that complaining about shitty incompatible frameworks or passing colour components on slightly different programs is going to worry them? You're wasting your breath.
These posts express my own personal views, not those of my employer
No. People like making money with the iPhone. But development in the classical sense, i.e. "growth; progress", does not occur on iPhone.
IF the code requires forking, THEN it should have no pretenses about being cross-platform compatible.
Which was the original point.
It's not a complaint that iPhone is devilishly difficult to program. It is not. The complaint is that it's devilishly difficult to write an iPhone/desktop cross-platform compatible app, which should have been easy if the device actually was cross-platform compatible.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
He does have a point though, and I have also felt that while UIKit gets the important things right, it feels a little rushed around the edges. And it was rushed, so that's not surprising.
His example there is pretty clear, instead of using the perfectly good class NSColor, they rewrote it differently as UIColor, leaving some important functionality out. You can deal with it, sure, but it's kind of annoying.
Still, I don't know who was expecting any sort of compatibility on the GUI portion of the iPhone, since the paradigm is completely different. It doesn't even make sense to think that you wouldn't have to rewrite the front end. On the other hand, I haven't found any problem porting C code or C++ code to the iPhone; I don't claim to be an expert but it does use GCC. In other words, it is highly compatible with existing code, but you'll have to rewrite your user interface. Which is probably what you were planning on doing anyway.
Qxe4
Objective-C is what C++ could have been if they had done it right.
No, there is no real way of objectifying C well, because C is essentially a low level systems and high performance macro assembler, designed for people who want to and need to care about the underlying system. Now, C# is a fairly good language with C-type constructs,and Java is ok-ish, but they are managed languages more abstracted from the underlying hardware.
Objective C is an attempt to mix macro assembler with the beautifully pure OO language that is Smalltalk, giving the advantages of neither.
I did like Objective C when I first learnt about it, about 16 years ago. I was a teen and my knowledge of languages extended little beyond BASIC, C, C++, Forth and a vague understanding of LISP. I craved something fit for a more high level purpose. Objective C is an experimental half way house which has been hanging around because C++ is so bad and Jobs happened to run NeXT, but it's no pleasure.
And why should we care?
No.
More like Audi/BMW putting a 250 km/h speed limiter on the car you just bought. Sure, you can go ahead and remove the limiter yourself, and why the hell not change the fuel mappings on the ECU while your at it? Audi/BMW will not support the modifications nor honor the warranty on your car, but there's nothing 'physically' stopping you from making the modifications. They are by no means obligated nor legally required to tell you how to circumvent their limitations and reverse engineer their software.
When an engine suddenly catches on fire doing 270 km/h+, or you suddenly loose control on the car, the last thing they want is for you to point the finger at them and say: "Well you technically allowed us to do this". They are just doing everything possible to cover their asses.
Look at Windows Mobile for a minute. Stock installs are actually quite decent. But when Joe Sixpack starts installing "Bubble Popper 2.0", and "FREE XXX PIX" on his phone, and the phone shits a brick, guess who takes the blame? Yeah, Microsoft and their "damn unreliable OS".
Your evaluation period for Productivity 1.0 has ended. Please purchase more coffee to continue using this product.
No thanks.
Personally, I hate web apps. They're still vastly inferior to desktop applications. They need a constant connection, are less responsive than a desktop app, are limited in the GUI they can have, work or not depending on the browser, and are in many cases outside of my control, which is excellent for lock-in.
There still are many places where I have no internet connection. It happens when travelling in the underground. It's frequent above the ground in a train in some areas. It's unaffordable when roaming. It doesn't work in the middle of nowhere. I find it unacceptable to lose access to my stuff just because I happen to be somewhere without a cell tower.
What we need is more open architectures, where anybody can make anything they want without interference.
What's worse, you're at the mercy of the web app vendor. If they take down their app or start charging more money for it, you're SOL.
Request your free CD of my piano music.
It's like bitching against something billing itself as "Linux desktop compatible" when your Qt code isn't supported on it, only gtk. Which would be a legitimate gripe; "Linux desktop compatible" should support Qt as well as gtk.