
JWZ on iPhone OS development: "This is why I sell beer" - bensummers
http://jwz.livejournal.com/1224702.html
======
tjogin
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>

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
_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
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
I think he's referring to the API to get the components out of the NS/UIColor,
not create the NS/UIColor object.

~~~
dchest
There are individual methods like `hueComponent` if you want them.
[http://developer.apple.com/mac/library/documentation/cocoa/r...](http://developer.apple.com/mac/library/documentation/cocoa/reference/ApplicationKit/Classes/NSColor_Class/Reference/Reference.html#//apple_ref/doc/uid/20000353-SW10)

I still don't get the point.

------
demallien
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
_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
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
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.

~~~
pohl
Could you deliver that text program to the user such that they could compose
it with others in a standard environment? I think that's the real point - that
programmers were discouraged from falling into habits of older platforms.

~~~
gaius
You certainly could with CodeWarrior, I can't remember about MPW.

And umm, of course programmers should be discouraged from falling into habits
of older platforms. Otherwise the web would look like an IBM 3270 :-)

------
pavlov
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>

~~~
tumult
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
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
_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.

------
heresy
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
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? ;-)

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

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

~~~
felideon
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
It's interesting because he's still mad that Perl killed Lisp 20 years ago.

