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
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
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.
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.
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).
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