Re: troubling article
Re: troubling article
- Subject: Re: troubling article
- From: Andy Satori <email@hidden>
- Date: Tue, 10 Jun 2003 23:43:58 -0400
I believe that the gentleman is suffering what I will affectionately
call, RAD Tool Withdrawl. I know the feeling I suffer from it as well.
You see, I'm a Windows developer, learning Objective C. I know the
Windows API well, I know all three of the environments he mentions
intimately. They all hide an enormous amount of, 'grunt work' that,
upon first exposure to the Cocoa framework, you assume you have to do.
The first 2 weeks with Cocoa are a brutal, and frequently humiliating
experience, where you spend hours spinning your wheels without
progress. It's not until you are a couple of weeks in that it suddenly
starts to come together. Then, it all starts to come naturally.
That said, he's right. Windows development tools remain years ahead of
Project Builder and CodeWarrior in terms of dumbing down the developer
requirements. In none of todays commercial development environments
for Windows does the developer need an API or command reference, the
tools do the work. For example, in Windows, I want to solve a problem
I recently had, GetUser(). In any of the languages, with the exception
of VB (which doesn't have that call directly implemented), typing
'GetUser(' would prompt me with a tool tip containing the parameters
and types from the Windows.h definitions. In the Cocoa world you have
to dig through poorly indexed, HTML or PDF materials.
The situation with object methods and parameters is even worse. In the
Windows environments, if I declare an object as 'Variant', the IDE's
will make an effort to determine the object type by how it's
instantiated, if it fails, it doesn't work. If however, the object is
declared by type, typing 'objectVariableName.' or
'objectVariableName->' in the C++ world would give me a type specific
list of methods and properties, to pick from. '[objectVariableName '
could, and in my opinion, should, do the same type of thing. If you
declare everything as 'id' then it's probably going to fail, and that's
your prerogative, me, I'm going to strongly type things and happily fix
the compiler errors because they are less likely to become program
errors.
Don't get me wrong, now that I've come to grips with the fundamental
shift in methodology, I like Cocoa, but I still find PRoject Builder
and CodeWarrior to be inferior tools to Delphi, C++ Builder, Visual
Studio, Visual Studio.NET, and even Visual Basic ( a language and
environment that I detest ).
I've spent most of my early Cocoa development efforts writing tools to
make my Cocoa life easier. I don't like writing boiler plate code, so
I've spent a couple of weeks building tools to let me create my object
and collections, complete with NSTableView support, from a GUI, and let
that generate the appropriate code. In the Windows world, these
'Wizards' and template derived code is part of the package, and is more
necessary, as the code for a basic COM object is 1000 lines of boiler
plate code, but the advantage of filling out 5 fields and clicking
Finish, to generate the code for a collection object that can then be
assigned to an NSTableView with one line of code is far prefereable to
the hand writing of 25 lines of Objective C.
Call me lazy, but Code Reuse only gets you so far. You still have to
have the foundation work to glue the OO elements together. But I
disagree with his conclusions, once you get over the 'hump' Cocoa
becomes a fun, and elegant framework that is more complete than it
first appears. That doesn't mean that I don't long for Code
Completion, and ToolTips with function parameters in them. I don't
find hunting HTML documentation in a Safari Tabbed set for that stuff
fun, when I'm spoiled to having so very handy.
Andy Satori
druware software designs
On Tuesday, June 10, 2003, at 10:33 PM, Chris Meyer wrote:
Some of the points this guy makes are clearly off the mark, while
others are valid criticism and as a community it would be nice to
understand what those issues are and how to address them since it
benefits everyone on this mailing list to have more developers using
and happy with Cocoa, Project Builder, and the Mac in general.
Again, think constructive response...
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.