6 ms·

JWZ on iPhone OS development: "This is why I sell beer"

168 points by bensummers 17y ago

pavlov 17y ago
I don't really understand his complaints about the lack of compatibility between traditional Cocoa (i.e. Foundation+AppKit) and Cocoa Touch (Foundation+UIKit). I've been working with Cocoa for years. It took me just an afternoon to port a graphics and audio application from Mac OS X to Cocoa Touch. Granted, it's a pretty simple application [1] designed for maximum cross-platform compatibility by being written in C. But jwz's Dali Clock is even simpler with the same portability goal... In my experience the changes made in UIKit are perfectly reasonable given the constraints of the platform. In many places Apple has managed to substantially improve the experience of mixing plain-C CoreFoundation and Obj-C Cocoa by lowering the historical "impedance mismatch" between the two that still persists in AppKit. There's nothing wrong with doing an API cleanup when the opportunity for a break with the past presents itself. [1] http://lacquer.fi/2020 http://lacquer.fi/2020
- tumult 17y ago
  His initial goal was to not have to port it -- it was to get it compiling from the same source on both, since they're both Objective-C applications written atop OS X. What he found was that similar functionality was implemented with an arbitrarily different interface. UIKit is not exactly the same as AppKit (I think it's a little bit cleaner) and breaks AppKit code even for features that are supported on both sides. If you're used to stable APIs and expect strong justification for changing an interface, especially when there is no apparent change for features supported or efficiency, going from AppKit to UIKit is like having someone flick vinegar off of their finger tips into your eyes. And if you're used to being able to develop software (using other open source software) on a computer you paid for and run it on a device you paid for without having to pay again and sign a contract limiting your freedom, then it's like getting a right hook to the abdomen.
  - pavlov 17y ago
    IMHO, moving from a 23" screen and multi-GB memory to a 3.5" screen and 128 MB is strong justification for changing an interface. Most of AppKit just doesn't make any sense in a single-task, single-window system. They could have kept some of the classes, but what would be the point? A tiny minority of Mac apps are as simple as jwz's clock. Everything else would need rewriting anyway.
    - carussell 17y ago
      moving from a 23" screen and multi-GB memory to a 3.5" screen and 128 MB is strong justification This makes no sense in the context of the examples cited. Elsewhere, maybe.
demallien 17y ago
I always figured that the changes to the names of classes from Cocoa to CocoaTouch were done deliberately to make it difficult to port apps from the Mac. You're knowledge of the APIs transfers pretty well, so if you wrote an app for the Mac, it won't be hard to rewrite for the iPhone, but you will have to rewrite it. Apple seem to like doing this to force developers to become familiar with a new platform. It's much the same as not providing a command line for the original Mac, hence preventing text-based programming, or indeed not allowing cross-platform dev tools to be used for apps that will be sold on the app store. From a design perspective, I can understand why they do this. They want apps on their platform to be lovingly crafted, just as they themselves have laboured over their products. But still, it can be frustrating for devs.
- gaius 17y ago
  It's much the same as not providing a command line for the original Mac, hence preventing text-based programming Not true. Stephenson even talks about this in In The Beginning Was The Command Line. It was called MPW and provided a very Unix-like experience (Makefiles and so on). The rival was THINK Pascal, and then later CodeWarrior, which were IDEs.
  - demallien 17y ago
    I'm not entirely sure where you're trying to go with this. There was no command-line mode for the Mac. You couldn't take e.g. Wordstar (good grief, it's been a while since I last typed that name!) , and run it with little modification on a Mac. You would first have to write a GUI-based console for your text-only app to run in. There was no console SDK. Yes, it was possible to do, but as it would take as much work as writing the app as a proper GUI app anyhow, you might as well forget about the console.
    - gaius 17y ago
      Well, you said there was no text-based programming, whereas I remember doing it... I'm pretty sure you could run your code in the MPW shell and use STDIN and STDOUT as per any C program of the time. CodeWarrior also had this, called WASTE there.
heresy 17y ago
I think this is a function of age. I'm only 30 now, but I'm starting to get crusty when shit changes for the sake of changing shit :)
- Silhouette 17y ago
  I'm somewhat older, and I feel your pain. :-) But more, I'm disappointed that we haven't spent the effort that goes into reinventing these things every ten minutes on something more productive. There are plenty of simple things in my everyday programming work that could be automated to take less time, given the right language tools or libraries or development environment, but where it is still faster in practice to do everything the "hard" way than the "easy" way. How am I ever going to code up all my pet project ideas in a single lifetime at this rate? ;-)
- Zev 17y ago
  And AppKit is almost 18 years old; it was started by NeXT and Sun in 1993 or so. UIKit removed a lot of cruft and fixed some pretty big design decisions in AppKit. It was a rewrite that was needed, not because an intern had too much time on his hands.
- tjpick 17y ago
  I know plenty of 30 year olds that love to change things just for the sake of it
tjogin 17y ago
JWZ makes no sense what so ever. I'm sure he's really good at some kind of programming, or at least that he once was, but he often talks from what he thinks is a position of insight, while actually he's quite ignorant. The first commenter's explanation of why OpenGL and OpenGLES differ is a fantastic example. JWZ simply never bothered to learn enough about the subject in the first place, but comfortably speaks about the "defining characteristics" of it. Reminds me of a similar hubbub when he proclaimed that CSS is bullshit and decided to stick with table-based markup, this because CSS (in April of 2003), required a span inside of a h1 to replace his table-soup (to mark up just a headline), when he'd prefer just a h1. http://jwz.livejournal.com/193866.html http://jwz.livejournal.com/193866.html Being talented in programming is simply not a binary situation, which JWZ shows quite well: he might be really good at some things, I really don't know, but he is also really ignorant in some of the other things he rants about with confidence.
- stcredzero 17y ago
  No, 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? Actually, in the first example, the MacOS code looks like the API designed by clueless interns that don't get OO. It's the same classic mistake of passing in an X and a Y instead of a Point Object from the 1st generation Java GUI library. The iPhone code does the right thing. Instead of passing around un-encapsulated data, pass around Objects instead!
  - dchest 17y ago
    What object would you pass to NSColor to generate a color from HSB components? Wrap them to NSHue, NSSaturation, and NSBrightness? Or generate NSHueParameters first? (Please note that I don't intend to argue, I'm asking for a better solution. Thanks!)
    - tlrobinson 17y ago
      I think he's referring to the API to get the components out of the NS/UIColor, not create the NS/UIColor object.
garply 17y ago
Who is JWZ? Is he well-known as a techie? As a techie who runs a non-tech business, I find him interesting due to the fact that he runs a nightclub.
- jaaron 17y ago
  Jamie Zawinski was an early Netscape Navigator, Mozilla, and XEmacs developer. He now runs a nightclub: http://en.wikipedia.org/wiki/Jamie_Zawinski http://en.wikipedia.org/wiki/Jamie_Zawinski
- felideon 17y ago
  He's interesting for far more reasons than running a night club. If you get a chance, check out Coders at Work---he's the first chapter (interview).
  - jrockway 17y ago
    It's interesting because he's still mad that Perl killed Lisp 20 years ago.
- garply 17y ago
  It's fine to leave me at 0 points but why was I down-voted? In what way have I violated the spirit of the site with this honest question?
  - petsos 17y ago
    http://lmgtfy.com/?q=wikipedia+jwz http://lmgtfy.com/?q=wikipedia+jwz Additionally: "Resist complaining about being downmodded. It never does any good, and it makes boring reading." http://ycombinator.com/newsguidelines.html http://ycombinator.com/newsguidelines.html
Lagged2Death 17y ago
It seems to me that stating opinions as if they are flat facts presented by an authority is as good a recipe as any to create needless drama, tempests-in-teacups, which in the end amount to nothing.

168 points by bensummers 17y ago

I don't really understand his complaints about the lack of compatibility between traditional Cocoa (i.e. Foundation+AppKit) and Cocoa Touch (Foundation+UIKit). I've been working with Cocoa for years. It took me just an afternoon to port a graphics and audio application from Mac OS X to Cocoa Touch. Granted, it's a pretty simple application [1] designed for maximum cross-platform compatibility by being written in C. But jwz's Dali Clock is even simpler with the same portability goal... In my experience the changes made in UIKit are perfectly reasonable given the constraints of the platform. In many places Apple has managed to substantially improve the experience of mixing plain-C CoreFoundation and Obj-C Cocoa by lowering the historical "impedance mismatch" between the two that still persists in AppKit. There's nothing wrong with doing an API cleanup when the opportunity for a break with the past presents itself. [1] http://lacquer.fi/2020 http://lacquer.fi/2020

tumult 17y ago
His initial goal was to not have to port it -- it was to get it compiling from the same source on both, since they're both Objective-C applications written atop OS X. What he found was that similar functionality was implemented with an arbitrarily different interface. UIKit is not exactly the same as AppKit (I think it's a little bit cleaner) and breaks AppKit code even for features that are supported on both sides. If you're used to stable APIs and expect strong justification for changing an interface, especially when there is no apparent change for features supported or efficiency, going from AppKit to UIKit is like having someone flick vinegar off of their finger tips into your eyes. And if you're used to being able to develop software (using other open source software) on a computer you paid for and run it on a device you paid for without having to pay again and sign a contract limiting your freedom, then it's like getting a right hook to the abdomen.
- pavlov 17y ago
  IMHO, moving from a 23" screen and multi-GB memory to a 3.5" screen and 128 MB is strong justification for changing an interface. Most of AppKit just doesn't make any sense in a single-task, single-window system. They could have kept some of the classes, but what would be the point? A tiny minority of Mac apps are as simple as jwz's clock. Everything else would need rewriting anyway.
  - carussell 17y ago
    moving from a 23" screen and multi-GB memory to a 3.5" screen and 128 MB is strong justification This makes no sense in the context of the examples cited. Elsewhere, maybe.

demallien 17y ago

I always figured that the changes to the names of classes from Cocoa to CocoaTouch were done deliberately to make it difficult to port apps from the Mac. You're knowledge of the APIs transfers pretty well, so if you wrote an app for the Mac, it won't be hard to rewrite for the iPhone, but you will have to rewrite it. Apple seem to like doing this to force developers to become familiar with a new platform. It's much the same as not providing a command line for the original Mac, hence preventing text-based programming, or indeed not allowing cross-platform dev tools to be used for apps that will be sold on the app store. From a design perspective, I can understand why they do this. They want apps on their platform to be lovingly crafted, just as they themselves have laboured over their products. But still, it can be frustrating for devs.

gaius 17y ago
It's much the same as not providing a command line for the original Mac, hence preventing text-based programming Not true. Stephenson even talks about this in In The Beginning Was The Command Line. It was called MPW and provided a very Unix-like experience (Makefiles and so on). The rival was THINK Pascal, and then later CodeWarrior, which were IDEs.
- demallien 17y ago
  I'm not entirely sure where you're trying to go with this. There was no command-line mode for the Mac. You couldn't take e.g. Wordstar (good grief, it's been a while since I last typed that name!) , and run it with little modification on a Mac. You would first have to write a GUI-based console for your text-only app to run in. There was no console SDK. Yes, it was possible to do, but as it would take as much work as writing the app as a proper GUI app anyhow, you might as well forget about the console.
  - gaius 17y ago
    Well, you said there was no text-based programming, whereas I remember doing it... I'm pretty sure you could run your code in the MPW shell and use STDIN and STDOUT as per any C program of the time. CodeWarrior also had this, called WASTE there.

heresy 17y ago

I think this is a function of age. I'm only 30 now, but I'm starting to get crusty when shit changes for the sake of changing shit :)

Silhouette 17y ago
I'm somewhat older, and I feel your pain. :-) But more, I'm disappointed that we haven't spent the effort that goes into reinventing these things every ten minutes on something more productive. There are plenty of simple things in my everyday programming work that could be automated to take less time, given the right language tools or libraries or development environment, but where it is still faster in practice to do everything the "hard" way than the "easy" way. How am I ever going to code up all my pet project ideas in a single lifetime at this rate? ;-)
Zev 17y ago
And AppKit is almost 18 years old; it was started by NeXT and Sun in 1993 or so. UIKit removed a lot of cruft and fixed some pretty big design decisions in AppKit. It was a rewrite that was needed, not because an intern had too much time on his hands.
tjpick 17y ago
I know plenty of 30 year olds that love to change things just for the sake of it

tjogin 17y ago

JWZ makes no sense what so ever. I'm sure he's really good at some kind of programming, or at least that he once was, but he often talks from what he thinks is a position of insight, while actually he's quite ignorant. The first commenter's explanation of why OpenGL and OpenGLES differ is a fantastic example. JWZ simply never bothered to learn enough about the subject in the first place, but comfortably speaks about the "defining characteristics" of it. Reminds me of a similar hubbub when he proclaimed that CSS is bullshit and decided to stick with table-based markup, this because CSS (in April of 2003), required a span inside of a h1 to replace his table-soup (to mark up just a headline), when he'd prefer just a h1. http://jwz.livejournal.com/193866.html http://jwz.livejournal.com/193866.html Being talented in programming is simply not a binary situation, which JWZ shows quite well: he might be really good at some things, I really don't know, but he is also really ignorant in some of the other things he rants about with confidence.

stcredzero 17y ago
No, 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? Actually, in the first example, the MacOS code looks like the API designed by clueless interns that don't get OO. It's the same classic mistake of passing in an X and a Y instead of a Point Object from the 1st generation Java GUI library. The iPhone code does the right thing. Instead of passing around un-encapsulated data, pass around Objects instead!
- dchest 17y ago
  What object would you pass to NSColor to generate a color from HSB components? Wrap them to NSHue, NSSaturation, and NSBrightness? Or generate NSHueParameters first? (Please note that I don't intend to argue, I'm asking for a better solution. Thanks!)
  - tlrobinson 17y ago
    I think he's referring to the API to get the components out of the NS/UIColor, not create the NS/UIColor object.

garply 17y ago

Who is JWZ? Is he well-known as a techie? As a techie who runs a non-tech business, I find him interesting due to the fact that he runs a nightclub.

jaaron 17y ago
Jamie Zawinski was an early Netscape Navigator, Mozilla, and XEmacs developer. He now runs a nightclub: http://en.wikipedia.org/wiki/Jamie_Zawinski http://en.wikipedia.org/wiki/Jamie_Zawinski
felideon 17y ago
He's interesting for far more reasons than running a night club. If you get a chance, check out Coders at Work---he's the first chapter (interview).
- jrockway 17y ago
  It's interesting because he's still mad that Perl killed Lisp 20 years ago.
garply 17y ago
It's fine to leave me at 0 points but why was I down-voted? In what way have I violated the spirit of the site with this honest question?
- petsos 17y ago
  http://lmgtfy.com/?q=wikipedia+jwz http://lmgtfy.com/?q=wikipedia+jwz Additionally: "Resist complaining about being downmodded. It never does any good, and it makes boring reading." http://ycombinator.com/newsguidelines.html http://ycombinator.com/newsguidelines.html

Lagged2Death 17y ago

It seems to me that stating opinions as if they are flat facts presented by an authority is as good a recipe as any to create needless drama, tempests-in-teacups, which in the end amount to nothing.