Re: iCode development tool
Re: iCode development tool
- Subject: Re: iCode development tool
- From: Rich Wardwell <email@hidden>
- Date: Tue, 3 Jan 2006 15:59:34 -0600
To be honest, the make-based tool nature of Xcode is the only reason
I can use it in our primarily Linux-based corporate development
environment. Of course, we're delivering highly-scaleable server
based applications in C++, not your UI bound category. Then again, I
think a lot more of development really is "systems" development than
end-user GUI apps. So I think I would fall in the category saying
that it's more like 80% non-UI development... or it least a more
balanced median.
Rich Wardwell
Software Developer, Mac Fanatic
On Jan 3, 2006, at 3:41 PM, Mark Munz (DevList) wrote:
On Jan 3, 2006, at 12:53 PM, Markus Hitter wrote:
Am 03.01.2006 um 19:54 schrieb Mark Munz (DevList):
Xcode is this hybrid-IDE trying to appease the command-line folks
and trying to appease the GUI folks. Unfortunately, the GUI-side
suffers as a result.
I don't see a necessary constraint here. Forking a task is almost
as cheap as forking a thread.
Well, I wasn't just referring to performance. Instead, I was
referring to UI design. But compare Xcode to Codewarrior and there
is a HUGE performance difference, even now.
I shouldn't have to determine what the command-line options are
for most of the functionality.
One shouldn't have to determine that many options at all. But
reality is, folks ask for every imaginable feature in the world
and the Xcode team tries to catch up.
Correct one shouldn't. And as such, one doesn't need to be exposed
to all "imaginable" options either. More importantly, the UI for
setting options needs to be more than a line separated command
argument. The pathname options is the most obvious example of this.
Is it really a Mac-UI to specify paths that may or may not be quote-
delimited, space separated with possible duplicate entries?
I believe that 80% of the "users" (developers) are looking for a
fast C++/Obj-C IDE that can create Carbon/Cocoa applications.
From my point of view, I can see these groups:
1) Open Source stuff. About 50% of the market I can see. Strong
addiction to the make-based build system. Various code editors.
The command-line hasn't gone away. Those folks that want make-based
build systems still have it. The problem is that Xcode is trying to
appease these folks.
2) Companies maintaining a big traditional code base. Science
companies, Apple, Adobe, ... you name it. Build system developed
over the years, CLI based. Developers have to code with the build
system as an unchangeable asset in mind.
While there are those that use a CLI-based build system, I know
that some companies like Microsoft and folks at Apple (based on
discussions I've heard in the past) also used IDEs like Codewarrior.
Again, the CLI is already there. And IDE will never really solve
their problem.
3) A bunch of small companies doing Mac OS X centric apps. These
use either Cocoa/Obj-C or reconsider their language of choice for
each task to be done. Building from the GUI, because it's the
easiest and quickest way.
4) Developers with the unfortunate job of porting Windows apps to
Mac OS as cheaply as possible.
I don't see how one would count 80% from the latter two.
Do you believe that Xcode's IDE is targeting make-based build
users? These folks are already using the CLI to do their work. The
IDE's target audience has always seemed more for the latter two,
yet the functionality in Xcode is targeted towards the former two
groups. So while the latter two don't constitute 80% of the
developer community, they do likely constitute 80% of the target
audience.
The command-line hasn't gone away. Instead, Apple appears to be
squeezing in CLI-behavior into the IDE (Build-Phases, AppleScripting).
The key here is focus.
ProjectBuilder had the focus on Cocoa and it worked great. Then
came Java, Carbon, ...
The focus is not about the language used (Codewarrior's paradigms
worked with Obj-C, C++ and Java), but the build approach. There is
the IDE and the CLI approach. The CLI folks have always had their
CLI-tools to do their builds.
Given that Xcode is trying very hard to mimic CW's look, I think it
would be a reasonable argument that Xcode's target is the same
folks that used CW (ie. the IDE crowd).
That's not to say that the whole thing isn't run by command-line
tools behind the scenes, but the user should never have to be
exposed them. I don't care about the underlying implementation,
unless it directly affects me (and in the case of Xcode, it
unfortunately does -- as I'm forced to look at CL results when
errors occur, deal with CL options in the build settings, etc).
Mark Munz
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden