Slashdot Mirror
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?"
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.
#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
Windows mobile probably has more of a backwards compatibility problem than the iphone... The core OS of the iphone is the same as normal OSX and it's only the interface APIs which are different - and rightly so, the whole interface is fundamentally different in how you interact with it.
Windows mobile on the other hand is a whole different os with a completely different kernel.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
The only valid complaint I see in this whole article is with NSColor/UIColor – NSColor really should be in the Foundation API (common to both Mac OS and iPhone OS), not the AppKit/UIKit APIs.
His OpenGL example is hilarious. "Oh my god, I can't use glBegin and glVertex"... Function calls which have been deprecated in OpenGL since version 2, that was 15 years ago!
As for UIKit being very different from AppKit... Well of course it is! UIKit is for building touch based UIs, if you transfer the exact same things as you have on Mac OS straight over, you end up with a shit mishmash of rubbish. The important thing here is that both APIs share their Foundation API (the basic programmery stuff you need like dictionaries, arrays, strings, etc).
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
The Wknd Sessions - Malaysian and South East Asia independent music
No. People like making money with the iPhone. But development in the classical sense, i.e. "growth; progress", does not occur on iPhone.
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."
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
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.
Qxe4
Function calls which have been deprecated in OpenGL since version 2, that was 15 years ago!
Unless I'm missing something, or you're living in 2020, OpenGL version 2 was released in 2005, and you're 10 years off.
Oh, btw, it was deprecated in OpenGL 3.0 - 13 years off from being accurate.
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.
Objective-C is what C++ could have been if they had done it right.
You are kidding, right?
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.
If you mean, are making an AAA game title, sure, but then your job is probably "3d graphics programming specialist" or something, so you can jump through whatever hoops are necessary. There's a huge range of apps for which performance is not really a concern; they ran fine on hardware of 10 years ago, so they ought to be able to run fine on today's. xDaliClock is one of those.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
All with one set of C++ client code, compiled to native executables for each platform.
If you want iPhone support, you'll need the Subversion source base; the code works, but we haven't rolled a release for a while.
Its Open Source under the MIT License, chosen specifically to be compatiable with both GNU GPL and proprietary development.
Request your free CD of my piano music.
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.
No, performance is *always* a concern on a battery powered device. Every single instruction has a cost in ergs. You don't want to waste them.
Can you be Even More Awesome?!
The problem with this "explanation" is that the application's effort to use vertex buffers is significantly higher than the effort to use immediate mode.
A hardware implementation of IM (like the one in Silicon Graphics machines) would probably bring much higher energy efficiency than carefully packing up VBOs with software. Even when there's no hardware implementation, the packing up can be equally well performed by a driver, thus just shifting the energy consumption around, not increasing it.
Thus, immediate mode is actually at worst just as efficient as VBs for small vertex counts or dynamic objects, and at best allows hardware acceleration where there is none with VBs.
Blame and credit alike... it does claim that if you read C code into memory, that it can then parse the read C, but I don't think it could parse the read C, which is why the java is being used for things it really doesn't want to be used for in Egypt to this day.
The revolution will not be televised... but it will have a page on Wikipedia
No, the UI is completely different. Events are completely different, because of multi-touch-related stuff, and consequently, everything else needed to be rewritten as well. It shares naming conventions and some concepts with Mac OS X's AppKit, but that's all. Focus is different, windows are different, views are different, the first responder is mostly unused, etc.
i'd hit it so hard, if you pulled me out you'd be the king of britain [bash.org]
The problem with this "explanation" is that the application's effort to use vertex buffers is significantly higher than the effort to use immediate mode.
No, no it's not.
Immediate mode requires at least as many (usually more 3 times more) calls as you have verticies in your model, during which the GPU is wasting time, and the driver is doing complex things to pack data into buffers in graphics memory.
Meanwhile, vertex arrays require a single upload of a constant array to graphics memory, which happens quickly as a single memcpy, and then frees the graphics card to get on with it. After that point, all the CPU need to is yell at the graphics card "now render this".
The *reason* we've moved from immediate mode to vertex attribute arrays is because they're faster and more efficient. Of note, these days, even shader pipelines are more efficient than fixed function ones, because the fixed function pipeline is commonly implemented in the driver as a shader. A shader that is doing a bunch of stuff you don't need it to, along side the stuff you do want to happen.
Can I take this opportunity to mention that I find programmer-fights fascinating?
Carry on, guys.
You are welcome on my lawn.
Hear, hear!
In addition to not being future-proof. I predict that any data will be inaccessible in a mere decade or two, and you can't just boot up a 15 year old and compatible version of your web app, even if the company should exist down the road. :-)
Which, incidentally, is a big problem. As an example, much of JWZ' source code is 20+ years old.
I for one, is happy that he didn't store it with a properietary editor running under EMBED, stored in Netscape's old roaming storage.
Speaking of... who sits on the old Netscape source now? Oracle?
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.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
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).
While there are many conceptual similarities between the two operating systems, they are different enough that they really should have been considered separate platforms from the very start.
I've been doing cross-platform development for twenty years. Don't Even Get Me Started.
Request your free CD of my piano music.
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.
STOP . AMERICA . NOW
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".
All hope abandon ye who enter here.
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
What you might mean is, "I can't build up a random method call at runtime in an ANSI standard way". Your "trivial problem" is soluble at compile time, as is the intention for statically typed languages.
Nor you can't represent a method as a variable.
However "insane" you like to think it is, a method isn't a variable (although you can indicate a particular non-static method of an class in a variable using member function pointers). You probably want to use an pointer of abstract base class type, i.e. interface. Why do you keep wanting to defeat static typing?
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++.
I don't define messaging as "queueing up a random sequence of method calls chosen at runtime for later calling". Again, you're probably looking for some array type from which elements are consumed to call methods (perhaps chosen using member function pointers) via a pointer typed to an abstract base class.
If you want to be able to queue random calls to /anything/, represented in some language-defined way as calls with all their parameters, just because it's nice to say you can, you are probably looking for a completely dynamically typed language like Smalltalk.
However "insane" you like to think it is, a method isn't a variable (although you can indicate a particular non-static method of an class in a variable using member function pointers).
Method pointers are bound to a class.
That means code need to know explicitly the interface to call a method.
You probably want to use an pointer of abstract base class type, i.e. interface.
When you get a pointer to the object of a base class, you can't upgrade it inside of the message dispatch - because that would require the message dispatch to know all the hundreds/thousands interfaces used all over the program. And that's simply impractical, most of the time impossible.
Why do you keep wanting to defeat static typing?
I'm not.
It was you who tried to indicate that the messaging is somehow implementable with polymorphism. And it is not. As you yourself point out between the lines: it is simply incompatible with static typing.
If you want to be able to queue random calls to /anything/, represented in some language-defined way as calls with all their parameters [...]
That what messaging often boils down to.
Constantly serializing/deserializing is way too expensive.
[...] you are probably looking for a completely dynamically typed language like Smalltalk.
The End.
P.S. I have tried to implement messaging in C++ at least twice. Once by serializing the calls, second time by trying to have interfaces for all used methods. First failed due to miserable performance. Second failed when more people were assigned to the project and it became impossible to maintain -in any sane fashion- list of used interfaces and dispatch code was constantly broken due to changes to the other parts of the software.
All hope abandon ye who enter here.