Forgot your password?
typodupeerror
Iphone OS X Operating Systems Programming Apple

Cross With the Platform 307

Posted by kdawson
from the ifdef-hell dept.
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?"
This discussion has been archived. No new comments can be posted.

Cross With the Platform

Comments Filter:
  • UIKit != AppKit (Score:5, Interesting)

    by Anonymous Coward on Monday April 19, 2010 @05:01AM (#31893772)

    The OS is the same, but UIKit is NOT the AppKit. It's like bitching against linux when trying to build your Qt code against gtk.

  • by el_flynn (1279) on Monday April 19, 2010 @05:21AM (#31893872) Homepage

    In TFA, JWZ said "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?"

    FLAMESUIT ON
    At the risk of being shot down by every MacOS/iPhone hacker here... There are two main points that JWZ makes which are quite interesting:

    1) I refused to fork the MacOS X code base
    2) the desktop and the phone are both supposedly within spitting distance of being the same operating system

    So the beef he has, while totally valid is because of:

    a) refusal to fork the codebase
    b) assumed that both iPhone OS == MacOS X

    Hmm. I understand the refusal to fork the codebase, but if that's what's _required_ then that's what needs to be done to have the app on the iPhone. And what's the other bit about "assume" making an ass out of you and me? Ditto for the OpenGL/OpenGLES rant...
    FLAMESUIT OFF

  • by SharpFang (651121) on Monday April 19, 2010 @05:37AM (#31893932) Homepage Journal

    The problem is not that the UI is -completely- different.

    It's an UI that is massively the same, just ran through a bulk rename, shuffle parameters order around in function calls and explode/implode some methods / typical sequences.

    The UI -could- have been VERY similar, with only minimal differences easy to #ifdef through - the underlying philosophy is. Instead, there was some active effort put in making it totally incompatible, where making it compatible would be easier and more obvious.

    A typical case of "an extra week of writing code can save you a hour you'd spend on reading documentation instead."

  • Re:We get it already (Score:2, Interesting)

    by phantomfive (622387) on Monday April 19, 2010 @05:41AM (#31893944) Journal
    I think the GP is right, I for one at least really enjoy programming for the iPhone. Core Animation is a thing of beauty. If you haven't seen it, you should check it out. Objective-C is what C++ could have been if they had done it right. The default GUI elements make it easy to create decent looking apps. Overall, if you ignore the DRM, programming for the iPhone is quite nice.
  • by StripedCow (776465) on Monday April 19, 2010 @06:00AM (#31894012)

    Can we all please stop making apps, and start making web-apps?

    Then we can all benefit from your development effort, and we are not restricted to buying apple hardware. As an added bonus, you don't have to bend to the idiosyncrasies of the iphone api.

    Yes, I know, apps allow us developers to use the convenient micro-payment system which exists in the form of the app-store, but come on, there are plenty of other ways to get paid for your work.

    In the meantime, it *would* be nice if some other big company (google?) would invent a micro-payment system similar to the app-store, but (of course) for web applications instead of for a proprietary platform.

  • by mwvdlee (775178) on Monday April 19, 2010 @06:43AM (#31894156) Homepage

    I don't really care about developing for any Apply product myself, so I haven't looked into it in-depth, but does Apple actually claim OS-X and iPhone development is cross-platform compatible?

  • by 10101001 10101001 (732688) on Monday April 19, 2010 @07:07AM (#31894260) Journal

    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.

    Um, not quite. The company doesn't control whether you can release the app to a device. The company controls whether the app will run on a device (either by buying the app through an app store or paying a set fee to the company). This isn't too far off from the XBox 360, either. To some extent, it's not that far off from most any commercial library/OS (the main difference is whether you effectively pay the fee upfront or whether they try to nickel and dime you later).

    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?

    Apparently the Dali Clock is a rather old program (nearly 20 years) that's been ported to a variety of platforms. Presumably, the author chose to port the Dali Clock to the iPhone precisely because it was supposed to be relatively trivial to port from a Mac OS X version. The blog highlights how untrue that ended up being; comments on the blog suggest it's because Apple provided multiple graphical APIs and if the author had been lucky several years ago, he would have chosen the one that worked on the iPhone.

    In short, it doesn't sound like the author bought his iPhone to write apps for it. It was more a porting exercise to see just how trivial the task would be.

    You're wasting your breath.

    No doubt. But, then, most blogs are a "[waste of breathe]". These comments, both yours and mine, would likely qualify as well. I don't think that'll stop me from commenting or considering the blog for what it is, a recognition of Apple having the same sort of failings that Microsoft does: designing too many APIs/interfaces/file formats, dropping support for them whenever they can, and generally being about as bad as any other platform when it comes to having a unified, solid solution to the many problems that exist for the developers. I will give Microsoft some credit, though, for generally waiting longer than most public, commercial software companies in maintaining strict backwards compatibility.

  • Re:Could be worse (Score:4, Interesting)

    by PopeRatzo (965947) * on Monday April 19, 2010 @07:35AM (#31894320) Homepage Journal

    Can I take this opportunity to mention that I find programmer-fights fascinating?

    Carry on, guys.

  • by Trepidity (597) <delirium-slashdot&hackish,org> on Monday April 19, 2010 @07:50AM (#31894374)

    Not sure it answers all your concerns, but on the iPhone at least, you can package up a web-app so it installs locally. Then it's basically a local app that happens to be written in Javascript and render via the Webkit toolkit.

  • Re:Could be worse (Score:5, Interesting)

    by Skowronek (795408) <skylark.unaligned@org> on Monday April 19, 2010 @08:25AM (#31894550) Homepage

    Entirely correct @ shaders.

    However, I have to take exception with your description of immediate mode - the reason it performs so poorly now is that modern graphics chips are designed pretty much exclusively for DirectX (at least, this goes for ATI).

    On machines where immediate mode performance was actually some kind of a priority (for instance, SGI Octane IMPACTSR and relatives), executing a glVertex command amounted to 3 memory writes into a command FIFO that was mapped into a fixed address in userspace which was accessible with a short form of a SW opcode (remember, this is MIPS, there is a range of 64k addresses that can be accessed without loading a base register: -32768 to 32767).

    The hardware even managed the hiwater/lowater status of the fifo, and notified the kernel to perform a context switch to a non-gfx process when the gfx process was filling up the command FIFO. Those switches were as a matter of fact "virtualized" (before it was cool) by a combination of hardware, kernel (if hardware contexts are exceeded) and userspace - not entirely unlike what DX10 ADM was supposed to be, except this was in 1995.

    For large static meshes (only transforms applied with Vertex Shaders), buffers are definitely going to perform better, because the meshes can be located in local memory (VRAM). However, if something is dynamically generated, immediate mode in a good implementation is no slower than a memcpy, and it does not require a kernel transition to submit a command buffer to card's ring (like modern cards like to do).

  • Re:We get it already (Score:4, Interesting)

    by ThePhilips (752041) on Monday April 19, 2010 @09:02AM (#31894782) Homepage Journal

    As for "messaging", well, just because Objective C calls it a message and C++ calls it a polymorphic method call, it doesn't mean there's a relevant difference.

    You apparently never tried to implement the message passing in general or in C++ in particular. I unfortunately did.

    It all boils down to the trivial problem: given an object, one should be able to call a random method on it.

    C++ forbids this due to strict typing and compile time binding. Nor you can't represent a method as a variable. Nor implementing hundred/thousands of abstract classes is practical or sane.

    Objective-C has that as a feature. Selector is a basic data type.

    You can queue up selector/object pairs in ObjC for later calling - you can't anything close to it in C++. Thus no native messaging in C++.

    P.S. One can implement that also in C++ - see all the insanities TrollTech had to go into to do it in Qt. They use strings to identify methods during compile time, create class vs. method tables during link time and during run-time perform look-up on the table to identify the method's entry point.

    P.P.S. loosing v. losing. Give me a break, man. It's Monday. I obviously meant "losing".

  • Re:UIKit != AppKit (Score:4, Interesting)

    by Assmasher (456699) on Monday April 19, 2010 @09:11AM (#31894852) Journal

    Thank you for that :). I was having a shitty day - it's a little bit better now.

  • Re:Who is JWZ? (Score:3, Interesting)

    by SuiteSisterMary (123932) <slebrun@g[ ]l.com ['mai' in gap]> on Monday April 19, 2010 @09:44AM (#31895158) Journal

    IOW, he's an archetypical cyberpunk character. Former hacker and coder who now runs a bar/nightclub, who sometimes dispenses wisdom from on high, and whom newbs deride and experienced people listen to.

    The only thing missing is moving stolen data or cyberware, and/or arranging squads of disparate professionals to perform quasi-legal or illegal actions against corporations, generally on the behalf of other corporations.

  • by OzPeter (195038) on Monday April 19, 2010 @10:19AM (#31895668)

    And why should we care?

    web (specifically, web browser) development, with Major (capital M) contributions to the mozilla/netscape/firefox ecosystem since before mozilla/firefox existed as projects in their own right (going all the way back to Netscape 1.0), as well as fingers in things like Emacs and popular X applications.

    Yes, we know he is a smart cookie, but that still doesn't answer the OPs question.

    After looking at the webpage of the app in question (as posted by someone else here - I had never heard of the app before) all I see is some nostalgic clock App that seems to be being forced into a cross-platform test case where it doesn't really fit, and then complaining about the process. And then gratuitously throwing in some rant about the $100 developer cost. Yet nowhere have I seen any claims that a) OS-X and iPhone OS are meant to be *cross-platform* at all, and b) that the developer registration cost has ever been anything but $100. All I have seen is someone who disagrees with Apples development process for OS-X and the iPhone and does so in the same way as a multitude of un-notworthy people have done before.

    So to me, none of this is really newsworthy and I am also left with the OPs question being unanswered.

  • Re:We get it already (Score:2, Interesting)

    by ThePhilips (752041) on Monday April 19, 2010 @01:08PM (#31898376) Homepage Journal

    Why does every argument with an Apple fanboy end up with some comment like this?

    I'm very very far from being anything like an Apple fanboy.

    Neither I'm a huge fan of ObjC. Strict typing of C++ is better suited for the types of applications I write (and kind of mistakes I usually make - love the compiler finding the errors for me).

    I have simply tried to correct where you were wrong.

    But it does seem you lack practical experience to even understand the problems ObjC was introduced to solve.

    Any interface in the world is assigned a single unique unchanging number [...]

    If you can ask an arbitrary object for "method 56 of interface 11", your problem is sorted.

    Well, you really do lack experience to understand all the practical problems that causes (e.g. branching, collaboration), why in some scenarios it is not possible at all (e.g. plugins/dynamic linking) and why it is pretty much never used (waiting days for release to become compilable while people resolve the merge conflicts of the "unchanging number" lists).

    And apparently I'm simply incapable of explaining that to you.

    You should try to implement what you suggest in a commercial project with team 5+ people: you would understand the problems within few months down the development road.

    You're either a troll or in the frame of mind which resulted in the "loose" typo right at the start of this thread...

    Hehe. Payback for being a grammar nazi :D

Never test for an error condition you don't know how to handle. -- Steinbach

Working...