Cross With the Platform 307
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?"
Re:Could be worse (Score:0, Insightful)
do we want to start holding a Microsoft OS up as an example of something done *right*?
yes
otherwise you're blind.
#ifdef APPLE_HARDWARE (Score:4, Insightful)
#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.
Re:Could be worse (Score:4, Insightful)
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.
Re:We get it already (Score:1, Insightful)
I think the point is more, people *do* like developing for the iP[whatever]. There is however a vocal minority which happens to hit a note with people on Slashdot, who don't like that people like developing for iP[whatever]s.
Re:We get it already (Score:5, Insightful)
No. People like making money with the iPhone. But development in the classical sense, i.e. "growth; progress", does not occur on iPhone.
Re:Let's look at what JWZ said... (Score:5, Insightful)
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.
Re:UIKit != AppKit (Score:5, Insightful)
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.
Re:We get it already (Score:5, Insightful)
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.
Re:We get it already (Score:3, Insightful)
Objective-C is what C++ could have been if they had done it right.
You are kidding, right?
Who is JWZ? (Score:4, Insightful)
Re:Apple is like... (Score:5, Insightful)
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".
Re:Could be worse (Score:3, Insightful)
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.
Re:Stop making apps, start making web-apps (Score:5, Insightful)
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.
Web Apps Don't Work When You're Not Online (Score:5, Insightful)
Re:Could be worse (Score:4, Insightful)
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.
Re:Could be worse (Score:3, Insightful)
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.
Re:Something tells me he orders BigMac at Burger K (Score:3, Insightful)
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.
Re:#ifdef APPLE_HARDWARE (Score:4, Insightful)
"I will give Microsoft some credit, though, for generally waiting longer than most public, commercial software companies in maintaining strict backwards compatibility."
I no longer program, I moved on to a field where computers are ancillary to my line of work and happy about the reboot, but I remember this being the case even a few years back. Microsoft maintains strict backwards compatibility at all risks.
And this is the big difference between Microsoft and Apple. Microsoft cares more for their developers and the companies that make money off of them than they do their users. Apple cares more about the users than they do about the developers.
Microsoft has routinely left in holes in their OS that can't be easily fixed because a major software developer can't be bothered to fix their software.
Apple, on the other hand, I've seen them send out pretty terse notes to their major developers letting them know that if they don't change their use of an unexposed API (one they found has a hole it in...generally why Apple doesn't doesn't publish APIs until it is ready because they want to make certain it is ready for public...and apparently it applies to the iPhone as well)...and Apple will specifically tell major software houses that if their software isn't fixed in 30 days, it will cease working for anyone that updates their computer.
That said, I don't really care for Apple's walled garden approach to the iPhone and for those of us nerds, it is a major problem (I've had to jailbreak just for simple things like Googlevoice front ends...or tethering)...for the average user? not a problem. The point is, Apple cares far more for the user than the developer. Microsoft doesn't give a fuck about the user so long as the developers are happy.
So give credit to Microsoft for maintaining backwards compatibility, but you are just thanking them for providing a buggy OS that allows viruses to run rampant.
Re:UIKit != AppKit (Score:5, Insightful)
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.
Re:Stop making apps, start making web-apps (Score:3, Insightful)
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?
If it's already cross-platform, why the grief? (Score:3, Insightful)
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.
Re:UIKit != AppKit (Score:3, Insightful)
*head kersplode*
Re:We get it already (Score:3, Insightful)
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.
Re:Let's look at what JWZ said... (Score:3, Insightful)
So, in your world, the API for a variable resolution, mouse+keyboard driven GUI should be the same API as a fixed resolution touchscreen? And you think it's "incompetence" that the APIs are different for two interfaces that are different in size, input device and resolution, one of which can be rotated on the fly into different orientations?
You are surprised that an app that has existed for nearly 20 years on multiple platforms wasn't trivially easy to port to the iPhone because the developer was just too stubborn to understand that perhaps the API is a little different on the iPhone than on OS X despite them being "within spitting distance of each other" (which they are, below the GUI)?
Sure, there are a couple of inconsistencies that could have been in core frameworks shared by both platforms, but they are hardly game changing or enough to whine on the internet about.
Next you'll be telling me it should be super easy to make a KDE app look *identical* when running on a Gnome desktop with no inconsistencies or graphical issues at all. I'll bet that was super easy to get all the bugs ironed out of that. I'll bet it took less than an afternoon to fix it.
Re:We get it already (Score:4, Insightful)
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.