Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Cross With the Platform

kdawson posted more than 4 years ago | from the ifdef-hell dept.

Iphone 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?"

cancel ×

307 comments

Could be worse (-1, Flamebait)

BadAnalogyGuy (945258) | more than 4 years ago | (#31893742)

It could be much worse. You could have all that legacy crap left in the OS bloating up the system and wasting space.

Windows Mobile may have a backwards compatibility advantage over iPhone/iPad/OSX OS, but really, do we want to start holding a Microsoft OS up as an example of something done *right*?

Re:Could be worse (2, Insightful)

Adolf Hitroll (562418) | more than 4 years ago | (#31893746)

do we want to start holding a Microsoft OS up as an example of something done *right*?
yes
otherwise you're blind.

Re:Could be worse (-1, Offtopic)

BadAnalogyGuy (945258) | more than 4 years ago | (#31893752)

No, yuo.

Re:Could be worse (3, Insightful)

Bert64 (520050) | more than 4 years ago | (#31893806)

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:Could be worse (5, Informative)

beelsebob (529313) | more than 4 years ago | (#31893824)

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

Re:Could be worse (4, Informative)

blackraven14250 (902843) | more than 4 years ago | (#31893956)

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.

Re:Could be worse (3, Informative)

blackraven14250 (902843) | more than 4 years ago | (#31893988)

Oh, btw, it was deprecated in OpenGL 3.0 - 13 years off from being accurate.

Re:Could be worse (1)

Trepidity (597) | more than 4 years ago | (#31894174)

Oh but don't worry, if you use the new enlightened way [duriansoftware.com] of doing OpenGL programming, you can write a "Hello World" app that fades between two images in:

380 lines of C and a couple dozen lines of shader code

Re:Could be worse (1)

chill (34294) | more than 4 years ago | (#31894334)

As a non-OpenGL programmer, help me out here.

Is that sarcasm or are you impressed? I'm having a hard time telling. 380 lines of C for "Hello World" is a tad much, but using OpenGL to fade between images...

Re:Could be worse (0)

Anonymous Coward | more than 4 years ago | (#31894168)

DirectX 2 was released in 1996. Which is kind of 15 years ago except it's only 14 and that it's DirectX but not OpenGL.

Re:Could be worse (1)

Suiggy (1544213) | more than 4 years ago | (#31894028)

Yeah... I don't know what he's complaining about. iPhone OS uses OpenGL ES 1.1 and OpenGL ES 2.0. Of course you can't use immediate mode primitive drawing functions. In fact, you shouldn't be using them on the desktop either, if you're at all concerned about performance. Vertex buffers are the way to go.

Re:Could be worse (2, Insightful)

Trepidity (597) | more than 4 years ago | (#31894162)

In fact, you shouldn't be using them on the desktop either, if you're at all concerned about performance

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:Could be worse (3, Insightful)

zippthorne (748122) | more than 4 years ago | (#31894192)

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 (3, Insightful)

Skowronek (795408) | more than 4 years ago | (#31894214)

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:Could be worse (2, Informative)

beelsebob (529313) | more than 4 years ago | (#31894274)

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.

Re:Could be worse (3, Interesting)

PopeRatzo (965947) | more than 4 years ago | (#31894320)

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

Carry on, guys.

Re:Could be worse (5, Interesting)

Skowronek (795408) | more than 4 years ago | (#31894550)

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:Could be worse (1)

Trepidity (597) | more than 4 years ago | (#31894300)

That I agree with, which is why I purposely quoted the part of his sentence including "on the desktop". On the desktop, the vast majority of OpenGL apps, i.e. anything except state-of-the-art AAA game, does not really need to squeeze that last bit of performance out.

Re:Could be worse (1)

moosesocks (264553) | more than 4 years ago | (#31894480)

You missed the part where this is the Dali Clock. The iPhone needs to melt in order for the program to be completely functional.

Re:Could be worse (0)

Anonymous Coward | more than 4 years ago | (#31894030)

Indeed you are right, LOL at glBegin !

Man (-1, Troll)

arcite (661011) | more than 4 years ago | (#31893756)

What a whiner.

Ubuntu (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#31893770)

Of course we're still innovating!

All innovation is good! It's never a waste of time! Ever!

Ask Ubuntu!

UIKit != AppKit (5, Interesting)

Anonymous Coward | more than 4 years ago | (#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.

Re:UIKit != AppKit (5, Insightful)

phantomfive (622387) | more than 4 years ago | (#31893926)

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.

Re:UIKit != AppKit (2, Insightful)

Sir_Lewk (967686) | more than 4 years ago | (#31894576)

it is highly compatible with existing code... ...but you'll have to rewrite...

*head kersplode*

Re:UIKit != AppKit (5, Funny)

Linker3000 (626634) | more than 4 years ago | (#31894200)

Meh - the fix to get the Dali clock working is trivial - rename all pointers to smell like the colour yellow, and change all LONGINTs to SURREALs.

Re:UIKit != AppKit (4, Insightful)

Chris Mattern (191822) | more than 4 years ago | (#31894342)

It's like bitching against linux when trying to build your Qt code against gtk.

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.

We get it already (1)

kickme_hax0r (968593) | more than 4 years ago | (#31893780)

People don't like developing for the iP[whatever]. I suppose we'll be seeing a new article every time someone somewhere complains about it.

Re:We get it already (1, Insightful)

beelsebob (529313) | more than 4 years ago | (#31893838)

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 (4, Insightful)

FuckingNickName (1362625) | more than 4 years ago | (#31893886)

No. People like making money with the iPhone. But development in the classical sense, i.e. "growth; progress", does not occur on iPhone.

Re:We get it already (2, Interesting)

phantomfive (622387) | more than 4 years ago | (#31893944)

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.

Re:We get it already (4, Insightful)

FuckingNickName (1362625) | more than 4 years ago | (#31893992)

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 (1)

MikeFM (12491) | more than 4 years ago | (#31894340)

I don't find Obj-C any worse than Java really. I do wish it had a more extensive lib of useful classes but that isn't really a failure of the language. The biggest annoyance to me has been the mojo around doing things the Obj-C way. Rather than giving good feedback on your code functionality Obj-C fans just go on about how your coding style isn't the one true way. Of course Java fans can't explain why Java has problems with basic OOP functionality other than saying that you can't do that in Java. Fun.

I think most Obj-C books suck though. Don't believe that they'll have you coding iPhone apps in a week. Even as an experienced programmer it took me longer than that to get familiar with Obj-C and learning Cocoa and Touch is more involved than they tell you. XCode is okay but stay away from their crappy Interface Builder as it's a complete waste of time.

Re:We get it already (3, Insightful)

bostei2008 (1441027) | more than 4 years ago | (#31893996)

Objective-C is what C++ could have been if they had done it right.

You are kidding, right?

Re:We get it already (1)

Nerdfest (867930) | more than 4 years ago | (#31894212)

RDF exposure ... give the man a break.

Re:We get it already (1)

ThePhilips (752041) | more than 4 years ago | (#31894276)

Objective-C is what C++ could have been if they had done it right.

ObjC and C++ have totally different design goals.

For some applications I would prefer C++, for others ObjC. They do not compete against each other, but rather complement.

Why in the end the Objective-C++ was actually born: to get the weak typing and messaging where it is needed it - without loosing compile time binding and strict typing where it counts.

Re:We get it already (1)

FuckingNickName (1362625) | more than 4 years ago | (#31894292)

Why in the end the Objective-C++ was actually born:

"Just because you shouldn't, it doesn't mean you can't."

to get the weak typing and messaging where it is needed it - without loosing compile time binding and strict typing where it counts.

With the utmost respect, anyone who fails to recognise the very basic difference between `loose' and `lose' is unlikely to have a proper appreciation of when (or indeed whether) weak or strong typing is needed. 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.

Re:We get it already (1)

HuguesT (84078) | more than 4 years ago | (#31894446)

The difference is very relevant. I don't think there is a nice way to pack the kind of information that exists in a NIB file using C++ as a development language. Certainly none of the Microsoft, Gnome or KDE designers have done it. You basically have to specify all the callbacks by hand somehow in the interface file in C++, and compile the interface in. Compare this with the NIB+objective C way. The NIB file contains your whole interface, you can change almost everything about the appearance of your application, and you don't have to recompile at all.

So in theory you are right, in practice, objective-C works well in its context, better than C++.

Re:We get it already (0)

Anonymous Coward | more than 4 years ago | (#31894406)

Objective-C is the World's Worst Programming Language. Even Wikipedia says so! (Well, at least until someone revises my edit.) It is nothing like C++, where the compiler is capable of catching all sorts of problems.

It's also VERY slow.

#ifdef APPLE_HARDWARE (4, Insightful)

syousef (465911) | more than 4 years ago | (#31893796)

#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:#ifdef APPLE_HARDWARE (5, Interesting)

10101001 10101001 (732688) | more than 4 years ago | (#31894260)

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:#ifdef APPLE_HARDWARE (4, Insightful)

Anonymous Coward | more than 4 years ago | (#31894296)

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

Never underestimate... (-1, Troll)

Anonymous Coward | more than 4 years ago | (#31893812)

...the power of JEWS.

Re:Never underestimate... (0)

Anonymous Coward | more than 4 years ago | (#31893862)

Do you mean JAWS? Because that would make sense.

Re:Never underestimate... (1)

Hal_Porter (817932) | more than 4 years ago | (#31894026)

No, Java Enterprise Web System I believe. I see a lot of self parodic posts blaming that API for all manner of implausible ills.

Re:Never underestimate... (0)

Anonymous Coward | more than 4 years ago | (#31894038)

Just like with the Jews.

Re:Never underestimate... (2, Funny)

x2A (858210) | more than 4 years ago | (#31894218)

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.

Something tells me he orders BigMac at Burger King (1)

jo_ham (604554) | more than 4 years ago | (#31893840)

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?

And at the core, they are - they share a large amount of code, with iPhone OS running a slightly modified version of the Darwin kernel. Where they diverge though, might have something to do with the whole UI being completely different. I assume he just didn't realise that the UI was different, since that seems to be the level of discourse available. So an app written for OS X, using a window manager with a point and click mouse and variable screen res, just dropped right onto a fixed resolution, touchscreen device.... Right. No need to change any code! (or rather, it'll be a simple case of "if iphone then do x..").

I'm all for criticising the iPhone's genuine faults, but this sounds like a kid who threw his toys out of the pram and is whining to get them back, only to want to throw them out again.

Re:Something tells me he orders BigMac at Burger K (4, Interesting)

SharpFang (651121) | more than 4 years ago | (#31893932)

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:Something tells me he orders BigMac at Burger K (2, Insightful)

bar-agent (698856) | more than 4 years ago | (#31894262)

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.

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:Something tells me he orders BigMac at Burger K (-1, Flamebait)

tyrione (134248) | more than 4 years ago | (#31894360)

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

How the hell do you get listed as Interesting? Interesting to what? A 12 year old?

Re:Something tells me he orders BigMac at Burger K (0)

Anonymous Coward | more than 4 years ago | (#31894560)

"I'm all for criticising the iPhone's genuine faults"

No you're not, you're one of the biggest fanboys going. You couldn't see an iPhone fault if your iPhone blew up in your face.

Which is a possibility I suppose, thanks to Apple's crappy engineers ensuring that has actually happened to some people.

You're one of those idiots who owes a company nothing but would gladly support the DRM, child labour, and other general rapery that the company is heavily involved in simply because their fancy little UI animations give you a hard on.

To give you an example of why you are wrong, take a look at the likes of the .NET compact framework to see that an API for mobile devices doesn't have to be so horrendously different from the desktop API that you have to pretty much re-write large swathes of your application.

Let's look at what JWZ said... (4, Interesting)

el_flynn (1279) | more than 4 years ago | (#31893872)

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

Re:Let's look at what JWZ said... (4, Insightful)

SharpFang (651121) | more than 4 years ago | (#31893902)

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:Let's look at what JWZ said... (3, Interesting)

mwvdlee (775178) | more than 4 years ago | (#31894156)

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?

Re:Let's look at what JWZ said... (1)

Shadowmist (57488) | more than 4 years ago | (#31894178)

So after the decades of the Slashdotters complaining about MacOS being MacOS, thier complaint about the iPhone OS is that it's NOT MacOS? What IS the OP smoking? Where where all of you when it was made abundantly clear that the iPhone and especially the iPad were not to be treated as shrunken down Macs? And throw away any of that objection about the iPhone not being "open" that argument leaves the building when you decide to develop for the device.

Re:Let's look at what JWZ said... (1)

drinkypoo (153816) | more than 4 years ago | (#31894370)

So after the decades of the Slashdotters complaining about MacOS being MacOS, thier complaint about the iPhone OS is that it's NOT MacOS?

Reading comprehension fail. The complaint about the iPhone OS is that it IS MacOS, but that it's castrated in completely inexplicable ways, and the changes smack of incompetence.

Re:Let's look at what JWZ said... (1)

TheKidWho (705796) | more than 4 years ago | (#31894404)

Incompetence, yes that's what you call selling 85 million+ devices running the OS.

Re:Let's look at what JWZ said... (1)

drinkypoo (153816) | more than 4 years ago | (#31894512)

Incompetence, yes that's what you call selling 85 million+ devices running the OS.

By the logical extrapolation of your argument, Windows NT is the finest operating system on the planet.

Re:Let's look at what JWZ said... (1)

Bungie (192858) | more than 4 years ago | (#31894298)

I don't get it though...why would you want to write a cross platform app between a desktop OS and a smart phone with the same UI? That what made Windows Mobile a disaster, having to navigate apps designed for a desktop UI on a small screen with a stylus.

Re:Let's look at what JWZ said... (1)

Savage-Rabbit (308260) | more than 4 years ago | (#31894458)

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.

Anybody expecting it to be easy to take an app which was written for a desktop system and porting it to a mobile system is going to unpleasantly surprised. Porting is always a bitch and if the platform you want to port to is less capable than the one you originally wrote the app for you'll have allot of work ahead of you. Even in CP languages like Java you'll have problems since the Java implementations for mobile platforms aren't as capable as their desktop counterpart and there are always issues with implementations for different mobile platforms. Mobile development is also subject to totally different laws than desktop GUI app development often is. There are limited resources which leads to more limited APIs which means either using the least common denominator or getting ready for an awful lot of #ifdeffy. If you really want to write an app for both desktop and mobile systems you have to write it with that in mind from the very beginning. This means manual memory management, using only the lowest common denominator in terms of APIs, programming languages, etc... and you better get your MVC separation straight from the very beginning as well since you are going to have to write separate UI's for each platform. Mobile UIs tend to be fundamentally different in concept from desktop UIs. You'll also want to write as much of your app as possible in platform independent modules that can be 'plugged into' your apps as required.

Apple is like... (-1, Troll)

Anonymous Coward | more than 4 years ago | (#31893878)

Imagine being able to buy a Dodge Viper for $20,000. A good deal right? Now what if part of the deal, you could not drive the car out of the state, and you cannot go more than 50mph in it, and if you break any of the agreements, you must actually pay the full $80,000.

Anyone want to take the deal?

My point is, if you buy something, you should be able to do WHATEVER THE HELL YOU WANT WITH IT.

- From a PC.

Re:Apple is like... (4, Insightful)

Kooty-Sentinel (1291050) | more than 4 years ago | (#31894154)

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

jwz (0)

Anonymous Coward | more than 4 years ago | (#31893888)

Who is JWZ?

John William Zoidberg?

Re:jwz (0)

Anonymous Coward | more than 4 years ago | (#31894024)

jwz = Jamie W Zawinski (Yes, he has a single-letter middle name, because he's that awesome.)

A great hacker whose name you are not worthy to speak.

Stop making apps, start making web-apps (1, Interesting)

StripedCow (776465) | more than 4 years ago | (#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.

Re:Stop making apps, start making web-apps (0)

Anonymous Coward | more than 4 years ago | (#31894140)

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.

Why should google do that when there are plenty of other ways to get paid for your work?

Re:Stop making apps, start making web-apps (0)

StripedCow (776465) | more than 4 years ago | (#31894322)

Why should google do that when there are plenty of other ways to get paid for your work?

To make it a little easier.

They will benefit from an increased focus from developers on the web (their core business) instead of on apple products (on which they have no grasp).

Re:Stop making apps, start making web-apps (5, Insightful)

vadim_t (324782) | more than 4 years ago | (#31894184)

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.

Re:Stop making apps, start making web-apps (2, Insightful)

arth1 (260657) | more than 4 years ago | (#31894356)

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.

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?

Re:Stop making apps, start making web-apps (2, Interesting)

Trepidity (597) | more than 4 years ago | (#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.

Web Apps Don't Work When You're Not Online (4, Insightful)

MichaelCrawford (610140) | more than 4 years ago | (#31894186)

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.

Re:Stop making apps, start making web-apps (1)

timmarhy (659436) | more than 4 years ago | (#31894280)

this post wins fail of the day.

web apps are slow, lack features easily implemented in an exe and worst of all leave you even more at the mercy of some other asshole who could pull the plug on your app at anytime.

web apps have their place, but they aren't a solution to the apple syndrome.

Re:Stop making apps, start making web-apps (1)

StripedCow (776465) | more than 4 years ago | (#31894386)

this post wins fail of the day

But I still got modded +4 interesting at the moment, haha.
However, I do agree with you to some point.

web apps are slow, lack features easily implemented in an exe

True, however, with HTML5 things will improve. The current javascript engines are sufficiently fast to allow most complicated tasks. Further, there are technologies in beta which allow execution of machine code in the browser (in a sandboxed environment). See google code/labs (I forgot the name of that project). This may eliminate problems with performance of web apps altogether, in the (hopefully near) future.

and worst of all leave you even more at the mercy of some other asshole who could pull the plug on your app at anytime

Yes, I'd hate that too (even the thought of it). But web-apps can be programmed such that they function also off-line (although some better support in browsers would be nice).

Programming for the web is not perfect, but the web will evolve in an open way. If you are basing your code on the web, then at least apple can't pull the plug on the developer...

Re:Stop making apps, start making web-apps (1)

betterunixthanunix (980855) | more than 4 years ago | (#31894284)

"web applications instead of for a proprietary platform."

Almost all web apps, by their very nature, are proprietary. How many websites make their source code available? How many websites can you set up on your own web server? How many websites allow you to opt out of software updates (i.e. updates to the website itself)? Such examples certainly exist, but they are few and far between.

oh noes! (1)

hom3chuk (977560) | more than 4 years ago | (#31894020)

First, if you can't modularize your code - it's not framework' fault.

Second, if a piece of code work like a clock (read: goodwritten), then you can port it to any modern platform with any modern language. That not includes special cases, e.g. porting from OGL ES 2 to OGL ES 1.

And third, don't fight against framework, use it perks instead. ifdefs is not a framework but compiler feature, it may not work fine with framework because framework was written for a particular device, not for a GCC.

Who is JWZ? (4, Insightful)

AmonTheMetalhead (1277044) | more than 4 years ago | (#31894070)

And why should we care?

Re:Who is JWZ? (0)

Anonymous Coward | more than 4 years ago | (#31894172)

I really don't think this is a troll. It's honestly a valid question, on both parts. If I had mod points, I'd fix this. If I had any clue who JWZ was, I'd answer.

Re:Who is JWZ? (1)

cg0190 (1790740) | more than 4 years ago | (#31894180)

I have no idea either. It's like some geek in joke or something...

Re:Who is JWZ? (0)

Anonymous Coward | more than 4 years ago | (#31894324)

Congratulations to you and your parent poster for obviously being newfags. I guess IN GENERAL (note, it's OKAY to generalize, you will not burn in hell and it's not a sin against reason to make generalizations) you can judge a poster by his size of his ID.

Re:Who is JWZ? (0)

Anonymous Coward | more than 4 years ago | (#31894228)

Who is JWZ? An internet-famous geek celebrity. Hence the three-letter acronym. See also: RMS, ESR.

Why should we care? Because he insulted the iPhone, dude! That's like dressing up as Satan, going into the Vatican and pissing on the Pope. Except it isn't funny. Here is this big shot free-software-guy-turned-club-owner, Netscape and X11 apps behind him, who dares to suggest that his difficulties with iPhone development are somehow Apple's fault, rather than (as well all know) his own fault for being massively, massively retarded.

Re:Who is JWZ? (0)

Anonymous Coward | more than 4 years ago | (#31894352)

Who is JWZ? An internet-famous geek celebrity. Hence the three-letter acronym. See also: RMS, ESR.

Literate people call them initials , you dingleberry.

Re:Who is JWZ? (1)

chengkhoon (805474) | more than 4 years ago | (#31894256)

Re:Who is JWZ? (0)

Anonymous Coward | more than 4 years ago | (#31894518)

According to the Wikipedia, he has a LiveJournal account. I can pretty much ignore what ever he has to say in light of that fact.

Re:Who is JWZ? (1)

fredrik70 (161208) | more than 4 years ago | (#31894302)

geek card, hand it over, now

Re:Who is JWZ? (0)

Anonymous Coward | more than 4 years ago | (#31894420)

I don't know him either.
Does he have a name, or is it just the initials?

Re:Who is JWZ? (1)

AmonTheMetalhead (1277044) | more than 4 years ago | (#31894472)

It's funny how you demand my geek card whilst avoiding to demonstrate any knowledge on the subject at hand, you don't happen to work in the marketing department or on an executive level do you?

Re:Who is JWZ? (1)

will_die (586523) | more than 4 years ago | (#31894396)

He owns & runs a bar/night club in california.

Re:Who is JWZ? (0)

Anonymous Coward | more than 4 years ago | (#31894430)

He runs a bar and used to write software 15 years ago.

I'm not sure either.

So why is this guy and his Nerd Rage on /. ? (0)

Anonymous Coward | more than 4 years ago | (#31894116)

See title

Want Real Cross-Platform? Try ZooLib! (2, Funny)

MichaelCrawford (610140) | more than 4 years ago | (#31894176)

While the 68k Classic Mac binding hasn't been maintained for a while, it wouldn't be hard to get it working again. That would enable you to use the same client code all the way from the Mac Classic running System 7 to Mac OS X, Windows 7, Haiku, BeOS, Linux (mostly), BlackBerry and the iPhone.

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.

Re:Want Real Cross-Platform? Try ZooLib! (0)

Anonymous Coward | more than 4 years ago | (#31894268)

Their list of applications that use zoolib is suspiciously short - only three links, of which two are broken, and the third is a web app.

That's my fault, not ZooLib's. Check Andy's page! (1)

MichaelCrawford (610140) | more than 4 years ago | (#31894470)

Andy Green of The Electric Magic Company [em.net] .

He's been developing ZooLib for twenty years, but it has only been Open Source for ten.

Andy is a consultant; whenever he gets a new contract, if ZooLib doesn't already provide some functionality he needs for his gig, he adds it into ZooLib.

As for the website not listing many apps - I'm the webmaster, but not a very diligent one. Most of ZooLib's apps are sold by the various clients that Andy and I have had over the years.

Nobody Ever Claimed Cross-Platform (1)

SkydiverFL (310021) | more than 4 years ago | (#31894188)

I suggest that you watch the very first dev video on beginning development for iPhone and Mac OS X and continue on from there. At no point does ANY of Apple's materials ever mention that you can write once and compile for both platforms. All they claim is that the tools and syntax and the same (XCode, Interface Builder, Objective-C, etc.). I've been programming for a few decades now and specialize in .NET. And, although I hated the experience of going from comfy C# to Objective-C, that's really the only pain. If you really look at how UIKit differs from AppKit, you may actually realize that it's the right tool for the job. Although Microsoft has paid the bills for quite some time now, I can honestly say that writing for Windows Mobile SUCKS... not because of syntax or compatibility issues, but because of the bloat and limitations of the mobile environment (Compact Framework on Windows Mobile). At least Apple got it right by accepting that the iPhone platform really IS a different animal, compared to a MacBook or Mac Pro, and built a more appropriate framework.

Properly cross-platform code cares not for the UI (1)

MichaelCrawford (610140) | more than 4 years ago | (#31894220)

I haven't actually read TFA, but if he has a problem porting between Mac OS X and the iPhone, just wait until he tries to port his app to Windows CE, Android, BlackBerry and Symbian.

There are some important architectural points to keep in mind if you ever hope to take your application cross-platform. One is the separate the "engine" or core code cleanly from any kind of user interface. That way you can keep what is most fundamental about your application constant, then write a new UI to exercise it for each new platform.

Another consideration is to avoid using any platform specific APIs, formats or protocols for anything that extends outside of the application itself. I'm sure Apple's Core Data is the best thing since sliced bread - until you try to email a Core Data document to your buddy who's got an Android phone.

What is ironic is that the iPhone provides sqlite, which is a simple SQL database that keeps all its data in single files. sqlite is Open Source, and widely available, so you really could use an sqlite database as a user document, in just the same way that you couldn't do with a Core Data doc.

Re:Properly cross-platform code cares not for the (1)

NNKK (218503) | more than 4 years ago | (#31894450)

I haven't actually read TFA

You needn't point out that out, because it's painfully obvious that you know absolutely nothing about Dali Clock, its cross-platform history, or JWZ's own well-documented history and experience.

Educate yourself first, then speak.

http://www.jwz.org/xdaliclock/ [jwz.org]
http://en.wikipedia.org/wiki/JWZ [wikipedia.org]

If it's already cross-platform, why the grief? (2, Insightful)

MichaelCrawford (610140) | more than 4 years ago | (#31894568)

I think JWZ's crucial mistake was in expecting the Mac OS X source to just work out of the box on the iPhone. Apple never made that claim. It's the wrong approach to take.

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.

I'm thinking this is worse with Windows CE... (0, Redundant)

cmowire (254489) | more than 4 years ago | (#31894272)

As far as I can remember from when I did some Windows CE hacking, that's actually worse than the difference between Windows CE and standard Windows.

Wow.

Re:I'm thinking this is worse with Windows CE... (1)

TheKidWho (705796) | more than 4 years ago | (#31894434)

Wow dude man.

Defining moment (1)

OzPeter (195038) | more than 4 years ago | (#31894442)

For the me, the defining moment in this rant (where I couldn't take it seriously any more) was when he complained about the $100 developer fee required to get his code running on a real iPhone. I know that other people have sad it before me - if you want to play with Apples ball, you have to play by their rules. So that knowing what the (in this case well known - App approval is different) rules are and then bitching about them comes across as childish.

I'm also tempted to comment on his choice of development hardware (G4) being a bit on the cheapskate side, but I am not familiar with it and don't know how serviceble this older hardware is.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...