NEXTSTEP vs. Delphi: An Informed comparison
Gregory H. Anderson
post an informed comparison of the differences our firm has discovered
between programming in NEXTSTEP/OPENSTEP and Delphi. This article is being
cross-posted to c.s.n.programmer and comp.lang.pascal.delphi.misc, because
I thought it might be of interest there too. Much of this article talks
about techicial issues, but I do raise business issues at the end.
A short paragraph of background, for those unfamiliar with AFS: We write
custom trading systems for Wall Street firms. We have 13 years of total
experience, 5 of which are with NEXTSTEP. We started using Delphi about
6 months ago, at the request of a customer. We have maintained essentially
the same award-winning OOP design through that transition. (Yes, it truly
is award-winning. We were a finalist in the OMG/ComputerWorld competition
at ObjectWorld two years ago.)
Without further ado, here are our observations. Feedback is welcomed.
Language/runtime issues
-----------------------
Delphi is based on Object Pascal, the latest iteration of almost a decade
of Pascal technology from Borland. NEXTSTEP uses Objective C, which reads
like traditional C with the Smalltalk '[]' messaging syntax. Like ObjC,
ObjPascal offers runtime type information. One thing I like better about
ObjPascal is that you can control the private/protected/public visibility
of methods, not just ivars as in ObjC. In ObjPascal, you can also decide
whether to dispatch methods statically (resolved by the linker, similar
to function calls), virtually (resolved at runtime with VMTs, like C++),
or dynamically (resolved at runtime by selector, like ObjC method calls).
ObjPascal is more strongly typed than ObjC, but you can typecast all
objects as necessary. The 'IS' and 'AS' operators determine class type
information at runtime, plus there are numerous methods to query the RTTI
information.
Message passing: You can vary messages dynamically through the Windows
messaging system using Dispatch(Message). That's not quite the same as
passing @selectors, but it covers most cases in which you would pass
selectors. You can look up method addresses dynamically in ObjPascal, but
you must refer to them in conjunction with an object. Remember, the
programmer decides the visibility of its methods. As a result, not all
messages are resolvable at runtime, even if the methods exist deep in the
class information. This is a good thing. Any method declared as 'public'
and 'dynamic' can be dispatched a-la ObjC.
A disadvantage of Delphi is that it doesn't do categories, but it is
capable of building and using DLLs, which gives you dynamic loading. DLLs
do have some limitations -- for one thing, you can't pass OUT a pointer to
memory allocated within the DLL -- but those limitations exist for all
Windows programs, not just Delphi.
Development environment
-----------------------
I like Delphi's better. There, I've said it, and I wasn't struck down by
lightning. One of the two other AFS developers working in Delphi strongly
agrees with this sentiment. The other finds them about equal, based on
different strengths and weaknesses in each product. I find Delphi's pieces
to be more strongly integrated, although it is still missing a few
built-in things that NEXTSTEP provides.
Form Design: Both visual designers use a drag-from-palette approach to
instantiate new objects. Delphi's designer is more flexible with event
handling; you're not limited to a single target/action. Delphi does not
provide as much direct manipulation and in-place editing, but I like its
Object Inspector better. NeXT's InterfaceBuilder is better at manipulating
groups of objects visually, but its Inspector cannot set attributes in
bulk when the group contains objects of different classes. The one major
Delphi 1.0 designer deficiency -- that all Forms must descend directly
from the TForm class -- has been corrected in the 2.0 release.
Editing: Delphi's built-in editor is a bit quirky, but you get used to it.
It's missing some things I like in Edit.app, like top-level compression
(Cmd-0). On the other hand: it supports the full set of cursor keys, text
can be selected using only the keyboard, breakpoints can be set directly
in the margins, and when you click on objects on the visual form, it takes
you straight to the right place in the source code. A tossup.
Compiling: The Delphi compiler/linker is blazingly fast. You have to see
it to believe it. You can 'Build All' in Delphi from scratch in the time
it takes NEXTSTEP to rebuild one module with a normal number of include
files. The 1.0 version was limited to linking Delphi object files, but
2.0 is willing to deal with conforming .obj files from other products.
Debugging: NeXT's gdb is more powerful than Delphi's integrated debugger.
Delphi's integration is better, but its features are weaker. Still, I have
yet to run into a problem I couldn't solve in Delphi. Another deficiency:
Delphi does not include a profiler. I expect to miss that when it comes
time for final tuning.
Components: Components and palettes are easier to build and maintain in
Delphi. Delphi's VCL (Visual Component Library, equivalent to AppKit/
FoundationKit) comes with source. This has proven invaluable in learning
how to design new components without hours of hit-or-miss testing. I've
been harping about this deficiency in NEXTSTEP since day one, and I still
think it's a mistake not to provide source. 'Nuff said.
Project Manager: Project-level defaults are easier to maintain in Delphi,
and inter-module dependencies are monitored automatically. However, when
it comes time to make major changes (like names of things in multiple
modules), Delphi does not have built-in tools to grep and diff. You can
perform those tasks with other tools, but it's not as convenient.
Database access
---------------
Delphi ships with a powerful set of data-aware components, and it's easy
to add data-aware features to 'plain' components as you need them. There
is good support for tables, queries, stored procedures, and batch moves.
Tables can be joined programmatically in the designer, and you can work
with a live data set in design mode (even open-ended queries!). Delphi
data access uses a three-layer model, with intermediate data-set objects
bridging raw tables to user interface objects. Our AfsModel wrappers
inherit from the intermediate DataSet objects, and that has proven an
excellent place to define business rules without UI reliance.
Delphi database access is generally accomplished through the well-proven
BDE interface. Even the baseline version of the product comes with a copy
of the Local Interbase server and the Database Desktop (for schema
maintenance). For C/S projects, you can either buy a copy of the high-end
product -- which includes native 'adapters' for all popular databases --
or you can use any ODBC driver in your possession.
On balance, I would say that Delphi is well beyond the original NEXTSTEP
DBKit, but not yet on par with EOKit. However, for anyone enterprising
enough to tackle such a project, I don't see any technical limitations in
Delphi that would stand in the way of building it.
Other factors
-------------
Delphi is essentially a tight and understandable wrapper around the
Windows API. In this respect, it reminds me of the way NEXTSTEP wraps
around PostScript and Mach: You can accomplish an amazing amount of
useful work almost immediately, without learning too much about the more
complicated layers. But when you are ready to delve deeper, the tools are
there to do it. In this respect, Delphi blows the doors off all other
Windows RAD tools. PowerBuilder and Visual BASIC, by comparison, just
don't keep up.
For deployment purposes, Delphi's approach of building self-standing
applications that use the standard Windows DLLs makes it superior to
OPENSTEP/Win in two key respects: no runtime royalties, and minimal RAM
footprint. Delphi requires no special DLLs or extra drawing layers to
distribute or charge extra money for. Personally, I think this will be
OPENSTEP/Win's achilles heel. I know what NeXT wants to charge third-
parties to distribute its runtime libraries with applications, and
it's ludicrous. Even for MCCA developers, given the choice between no
runtime royalties and $x00 per seat, OPENSTEP will be a tough sell.
Especially since the Delphi development environment costs only half as
much as OPENSTEP. Throw in $200 for an extra 8MB of RAM with OPENSTEP,
and it all adds up.
Depending on needs, one of Delphi's disadvantages is lack of support for
multiple operating systems. My customers generally don't care, because at
this point they are committed to variants of Win32. For developers that
need to support the same source tree for both Windows and Unix (or OS/2),
Delphi is not the right tool.
Conclusions
-----------
As skilled and knowledgeable OOP practitioners, we are extremely pleased
with Delphi. We will have a native Windows trading application deployed to
a very sophisticated client before OPENSTEP even ships. That application
is based on the same hierarchy of objects that comprises our NEXTSTEP
release, with very few design changes to accommodate differences between
the products. If a customer demands OPENSTEP for Win32 deployment, we will
use it. But for general purposes, OPENSTEP's runtime liabilities are too
significant to ignore. Delphi seems destined to be our first choice for
future work on Win32 projects.
--
Gregory H. Anderson | "Honey, there're few programming
Gaffer/Best Boy/Key Grip | problems that can't be solved
Anderson Financial Systems | with duct tape." -- 'Father' Duke
gr...@afs.com (NeXTmail OK) | (paraphrased), Doonesbury, 2/17/95
Felipe A. Rodriguez
Anderson) writes:
[snip]
>Components: Components and palettes are easier to build and maintain in
>Delphi. Delphi's VCL (Visual Component Library, equivalent to AppKit/
>FoundationKit) comes with source. This has proven invaluable in learning
>how to design new components without hours of hit-or-miss testing. I've
>been harping about this deficiency in NEXTSTEP since day one, and I
still
>think it's a mistake not to provide source. 'Nuff said.
>
I quite agree. If I had a nickle for every time I interpreted NeXT's
documention to mean dis when it actually meant dat, well lets just say I'd
have some real money.
[snip]
>
>Conclusions
>-----------
>
>As skilled and knowledgeable OOP practitioners, we are extremely pleased
>with Delphi. We will have a native Windows trading application deployed
to
>a very sophisticated client before OPENSTEP even ships. That application
>is based on the same hierarchy of objects that comprises our NEXTSTEP
>release, with very few design changes to accommodate differences between
>the products. If a customer demands OPENSTEP for Win32 deployment, we
will
>use it. But for general purposes, OPENSTEP's runtime liabilities are too
>significant to ignore. Delphi seems destined to be our first choice for
>future work on Win32 projects.
>
Ouch!
>--
>Gregory H. Anderson | "Honey, there're few programming
>Gaffer/Best Boy/Key Grip | problems that can't be solved
>Anderson Financial Systems | with duct tape." -- 'Father' Duke
>gr...@afs.com (NeXTmail OK) | (paraphrased), Doonesbury, 2/17/95
--
Felipe A. Rodriguez # ...it cannot be called ingenuity to kill
Agoura Hills, CA # one's fellow citizens, to betray
# friends, to be without faith, without
f...@ix.netcom.com # mercy, without religion; by these means
(NeXTmail preferred) # one can acquire power but not glory.
(MIMEmail welcome) # --Nicolo Machiavelli
Wei Chen
>
> Conclusions
> -----------
>
> As skilled and knowledgeable OOP practitioners, we are extremely pleased
> with Delphi. We will have a native Windows trading application deployed to
> a very sophisticated client before OPENSTEP even ships. That application
> is based on the same hierarchy of objects that comprises our NEXTSTEP
> release, with very few design changes to accommodate differences between
> the products. If a customer demands OPENSTEP for Win32 deployment, we will
> use it. But for general purposes, OPENSTEP's runtime liabilities are too
> significant to ignore. Delphi seems destined to be our first choice for
> future work on Win32 projects.
>
Although I essentially agree with your assesments on Delphi. I would
like to point out that Delphi is not truly object-oriented development
platform as far as reusability is concerned.
Without taking additional steps, Delphi developers would put all the
logic (be business or control) on the form object( NeXT's equivalent
Window object .) It's quite well-known that when programming in
NeXTstep, developers should put this logic on a custom controller object
rather than a Window or its subclass object in order to achive greatest
reusability. NeXT also advised developers not to subclass Application
for exactly the same reason. NeXT achieved this by providing, e.g.,
target/action configurable at the design time via IB. However, Dephi's
target is hard-coded to be the form object. In terms of M-V-C paradigm,
Delphi seems mixing the C component with the V.
Anyway, Dephi is still the best PC based development environment, unitl
OpenStep shows up, I think...
Jonathan Hendry
: Although I essentially agree with your assesments on Delphi. I would
: platform as far as reusability is concerned.
: Without taking additional steps, Delphi developers would put all the
: logic (be business or control) on the form object( NeXT's equivalent
: Window object .) It's quite well-known that when programming in
This isn't because of an inherent shortcoming in Delphi. This is
a result of being new to objects, as most Delphi users are. A
similar phenomenon can be found among people new to NeXTSTEP.
Everyone who's written an app where all the functionality is implemented
in 'AppController.m' or such, raise your hand.
: NeXTstep, developers should put this logic on a custom controller object
: rather than a Window or its subclass object in order to achive greatest
: reusability. NeXT also advised developers not to subclass Application
: for exactly the same reason. NeXT achieved this by providing, e.g.,
: target/action configurable at the design time via IB. However, Dephi's
: target is hard-coded to be the form object. In terms of M-V-C paradigm,
: Delphi seems mixing the C component with the V.
That's not entirely true. There is a default, which you get by double-clicking
on an event. Which in many cases is adequate. You can also specify different
methods.
NeXTSTEP certainly doesn't enforce good design.
--
Jonathan W. Hendry j...@exnext.com stee...@ix.netcom.com
Steel Driving Software, Inc. Delphi And OPENSTEP Software & Consulting
Partner, Hendry & Associates, Delphi & Java Training Services
List maintainer, delphi-announce mailing list
Gregory H. Anderson
> Although I essentially agree with your assesments on Delphi. I would
> like to point out that Delphi is not truly object-oriented development
> platform as far as reusability is concerned.
> Without taking additional steps, Delphi developers would put all the
> logic (be business or control) on the form object( NeXT's equivalent
> Window object .) It's quite well-known that when programming in
> NeXTstep, developers should put this logic on a custom controller object
> rather than a Window or its subclass object in order to achive greatest
> reusability. NeXT also advised developers not to subclass Application
> for exactly the same reason.
Whoa, whoa, whoa, hold the phone, Chester! You can do bad design with ANY
development tool. Just because most Delphi developers are newer to OOP and
make some mistakes, you can't blame that on the tool. If you know what
you're doing, Delphi is every bit as capable as NEXTSTEP of promoting
reusability. Our trading app framework is 100% M-V-C. Our AfsController
component is dragged to a form, all business models descend from AfsModel
(which inherits from TDataSet), and TForms are very minimally subclassed.
> NeXT achieved this by providing, e.g., target/action configurable at the
> design time via IB. However, Dephi's target is hard-coded to be the
> form object. In terms of M-V-C paradigm, Delphi seems mixing the C
> component with the V.
Now this is a legitimate point that I meant to mention in my original
article. The Delphi and NEXTSTEP form designers have different strengths
in the area of "event attachment," but both are deficient. In NEXTSTEP,
InterfaceBuilder allows any target, but can only assign one action. In
Delphi, the form designer can attach multiple actions, but only one target
(the form itself). You can work around both deficiencies, but it requires
programmatic runtime assignment. In Delphi, our controller object is smart
enough to revector the targets as it loads. But I agree, I wish you could
do it directly in the designer. Delphi's default approach _does_ encourage
the unwitting to create less reusable code. We noticed this right away
and designed around the problem.
> Anyway, Dephi is still the best PC based development environment, unitl
> OpenStep shows up, I think...
Delphi will be the better choice even after OPENSTEP shows up, I think.
Once you suss out the Delphi RTTI system (which admittedly needs better
documentation, but we did it), there is almost nothing you can't do in
the way of dynamic object programming ala NEXTSTEP.
Alex Duong Nghiem
I thought that OpenStep/NeXTSTEP (and MVC) advocate that the model (in
the form of business classes) should be doing the processing that
you're talking about.
Maybe I'm missing something here?
- Alex -
Wei Chen <wc...@gramercy.ios.com> wrote:
>Gregory H. Anderson wrote:
>>
>> Conclusions
>> -----------
>>
>> As skilled and knowledgeable OOP practitioners, we are extremely pleased
>> with Delphi. We will have a native Windows trading application deployed to
>> a very sophisticated client before OPENSTEP even ships. That application
>> is based on the same hierarchy of objects that comprises our NEXTSTEP
>> release, with very few design changes to accommodate differences between
>> the products. If a customer demands OPENSTEP for Win32 deployment, we will
>> use it. But for general purposes, OPENSTEP's runtime liabilities are too
>> significant to ignore. Delphi seems destined to be our first choice for
>> future work on Win32 projects.
>>
>Although I essentially agree with your assesments on Delphi. I would
>like to point out that Delphi is not truly object-oriented development
>platform as far as reusability is concerned.
>Without taking additional steps, Delphi developers would put all the
>logic (be business or control) on the form object( NeXT's equivalent
>Window object .) It's quite well-known that when programming in
>NeXTstep, developers should put this logic on a custom controller object
>rather than a Window or its subclass object in order to achive greatest
>reusability. NeXT also advised developers not to subclass Application
>for exactly the same reason. NeXT achieved this by providing, e.g.,
>target/action configurable at the design time via IB. However, Dephi's
>target is hard-coded to be the form object. In terms of M-V-C paradigm,
>Delphi seems mixing the C component with the V.
>Anyway, Dephi is still the best PC based development environment, unitl
Gregory H. Anderson
> Wake up Greg!
Oh, I am quite awake, thank you. NEXTSTEP _was_ a complete OO environment
(including a really good unified user environment), but OPENSTEP will not
be. In fact, many of the complaints I have heard about OPENSTEP/Win from
a functional point of view is how much of that wonderful NEXTSTEP we take
for granted has been "dumbed down" for the sake of being a "first class NT
citizen." In other words, NEXTSTEP loses some of its magic on the way to
OPENSTEP/NT. Are you sure about those Services? I've heard otherwise.
You described a lot of cool stuff that we currently take for granted
which I'm not sure will be included in OPENSTEP/NT. I share your rapture
for that environment, but it's on its way out. Mail.app? NeXT has already
stated they won't be shipping it.
Furthermore, NEXTSTEP is not uniform once it becomes OPENSTEP. It will use
the traditional UI in the Mach version, but Windows UI in the NT version.
I think Pete Clark posted that you will have a choice between traditional
and Motif in the Solaris version. And I hate to burst your bubble, but I
have extremely good information that the Sun and NeXT versions _already_
differ in some important ways. GNUstep will differ from both of them. Even
if you maintain 100% fidelity to the spec, Sun and NeXT will not. Face it,
OPENSTEP will never be as source-compatible and MAB-capable as NEXTSTEP
already is.
As to PDO, I have never found a "must have" use for it in my applications.
You may prefer to focus there instead of AppKit, but PDO is NOT where the
bulk of the corporate applications market is. Yes, I know about options
and derivatives firms who need to run massive Monte Carlo simulations on
Alpha chips, but you'll have to work awfully hard to convince me that
straightforward forms-based apps -- the bread and butter corporate apps --
benefit from PDO. NeXT made this argument to the customer who is paying us
to move from NEXTSTEP to Delphi, and the customer didn't buy it. Besides,
if you really need PDO/D'OLE, my understanding is that it will not be
limited to OPENSTEP apps. I hope not, or it will find a limited market.
In which case, there is no reason a Delphi app couldn't leverage it too.
Georg, it doesn't sound like you have actually worked much on Delphi or
even Windows 95/NT. For example, the integration of Delphi's editor and
form designer goes WAY beyond IB's limited parsing of header files. The
statement that "Only NEXTSTEP makes it possible for over 30 people from
I don't know how many countries to work together so nicely [on MiscKit]!"
is patently wrong. More is possible in other environments than you think.
Before you spend much more time on your GNUstep labor of love, you should
take a step back, draw a deep breath, survey the market, and ask who
you're building this for and how much it is worth the effort.
Georg Tuparev
writes:
> Delphi will be the better choice even after OPENSTEP shows up, I think.
> Once you suss out the Delphi RTTI system (which admittedly needs better
> documentation, but we did it), there is almost nothing you can't do in
> the way of dynamic object programming ala NEXTSTEP.
Greg! This is a bit to much for a guy spending his free hours working on GNUstep!
;-)
Well, I wanted to post a followup to your firs article, but now I _have_ to do it!
Although I almost agree with your comparative analysis, what you told is only the
half of the story. What you _forgot_ to mentioned is that NEXTSTEP is a complete OO
environment. Of course this is well known to all c.s.n.* groups, but you are
crossposting to other newsgroups too.
But let me start with more general comments:
- You are comparing Delphi from today with NeXTSTEP from the past but this is not
very fair! Yes, it is true that AppKit and IB are not unique any more, but nowadays
nobody claims it! The main focus now is not the AppKit, but the (P)DO. The times
where we had to write huge monolithic programs belong to the past. The reality today
is "distributed". And here NS/OS is light years ahead of anybody else. Just to give
an example from what I'm testing now: I wrote a small molecular dynamics app witch
consumes hell a lot of CPU time. Well, the main calculator object looks for the box
with the lowest load (it could be in US, Japan or even on Mars ;-), and starts
working there, then moves to another host, and then again, and again ... one can
follow it how it migrates around the globe. When the calculation is ready, the
result is waiting in my mailbox. The source for implementing this behavior is about
500 lines (including pgp security and exception handling). Now try to do this with
Delphi or any other tool! Try to do it even with CORBA & NEO! I wish you good luck!
And then all this nifty Foundation kit classes! You was talking about target/action.
And why on earth not mention the Notification Center? What about Object Archiving,
The autorelease pool, the exception handling, the Run/Event loops, the events, the
Unicode strings, threads, .... well I can continue... You may claim, "well, Win has
no multitasking, threads, sockets, ...", but what about D'OLE?
- Now to return to the GUI classes. None of them is unique, but because they are
building an entire environment the net result is something very special! Just
several keywords: Services, drag and drop, pasteboard, and yes of course, FILTERS!
You drag one document (say a jpeg image) from an ImageViewer and drop it in your
Mail.app The filter converts it to tiff and here we are! the image is in your mail.
Drag the folder from the fileviewer and drop it in a terminal, <Alt> drag the
document (h-file) from Edit.app and drop it in IB ... and Oh wonder! , IB parses the
file! Every single bit of NEXTSTEP is the money worth! It makes your life much
easier. What you are talking about are details, but take NEXTSTEP as an entire
developer environment and compare it again!
- The NEXTSTEP is uniform. Thsi is something very, very, very, important, but you
forgot to mentioned it. This uniformity has one huge implication to _all_
developers: one can write very easily reusable general purpose classes or even
entire frameworks, and these frameworks can work together without any problem! Have
you ever seen something like the MiscKit for any other developer environment? Only
NEXTSTEP makes it possible for over 30 people from I don't know how many countries
to work together so nicely!
Wake up Greg!
very nextish...
--
Georg Tuparev
EMBL / Protein Design Phone: +49 - 6221 - 387437
Meyerhofstr. 1 FAX: +49 - 6221 - 387517
D-69117 Heidelberg
Germany
Tup...@EMBL-Heidelberg.de (NeXT-mail)
d...@misckit.com
> [...] The statement that "Only NEXTSTEP makes it possible for over
> 30 people from I don't know how many countries to work together so
> environments than you think.
As the administrator of the MiscKit, I ought to at least state that
I agree with Greg's statement here. The is no technical reason
that I am aware of that would rule out a Java-based MiscKit, or
even a Delphi MiscKit. That said, the NEXTSTEP _community_ is what
bred the MiscKit, which is more a political/social thing than
anything to do with the NEXTSTEP environment per se. I don't know
of anything like the MiscKit for Java or Delphi, but it could
happen someday if it hasn't already. Perhaps enough NEXTSTEP
developers will cross over that the MiscKit will make the same
transition. Heck, if some NEXTSTEP-based operation (or anyone for
that matter) decided that they wanted a Java or Delphi MiscKit and
wanted to offer me a research grant to work on it, I'd cross over
right now. I've actually discussed the idea with a few folks... :-)
For those not in the NeXT groups who may be wondering what this
MiscKit thing is, it is basically a huge library of Objective-C
objects--foundation classes, GUI widgets, and all kinds of
wrappers around UNIX functionality. More information on the kit
is available from http://www.misckit.com/ including listings of
exactly what the kit contains and a more in-depth description of
license, charter, etc. Feel free to check it out if you're
curious. (Warning: this web site is slow since it is still in
experimental stages and therefore located on one of my home
machines across a 14.4k link to the Internet.)
--
Later,
-Don Yacktman
d...@misckit.com
<a href="http://www.misckit.com/don.html">My home page</a>
Sundial Services
>As to PDO, I have never found a "must have" use for it in my applications.
>You may prefer to focus there instead of AppKit, but PDO is NOT where the
>bulk of the corporate applications market is. Yes, I know about options
>and derivatives firms who need to run massive Monte Carlo simulations on
>Alpha chips, but you'll have to work awfully hard to convince me that
>straightforward forms-based apps -- the bread and butter corporate apps --
>benefit from PDO. NeXT made this argument to the customer who is paying us
>to move from NEXTSTEP to Delphi, and the customer didn't buy it. Besides,
>if you really need PDO/D'OLE, my understanding is that it will not be
>limited to OPENSTEP apps. I hope not, or it will find a limited market.
>In which case, there is no reason a Delphi app couldn't leverage it too.
>Georg, it doesn't sound like you have actually worked much on Delphi or
>even Windows 95/NT. For example, the integration of Delphi's editor and
>form designer goes WAY beyond IB's limited parsing of header files. The
>statement that "Only NEXTSTEP makes it possible for over 30 people from
>I don't know how many countries to work together so nicely [on MiscKit]!"
>is patently wrong. More is possible in other environments than you think.
>Before you spend much more time on your GNUstep labor of love, you should
>take a step back, draw a deep breath, survey the market, and ask who
>you're building this for and how much it is worth the effort.
>--
>Gregory H. Anderson | "Honey, there're few programming
>Gaffer/Best Boy/Key Grip | problems that can't be solved
>Anderson Financial Systems | with duct tape." -- 'Father' Duke
>gr...@afs.com (NeXTmail OK) | (paraphrased), Doonesbury, 2/17/95
Gentlemen, I found your collective postings to be among the most interesting
ones I've read on the net in recent memory. But before the conversation
degrades too much from the central points that have been so well-made, I think
you are truly comparing apples and oranges here.
NextSTEP does some things magnificently well, such as the things Georg is
doing; Delphi does not and it was never designed to do so. For a "bread and
butter business application" it might be overkill -- but that's not an issue
because as far as I can see, NeXT never really penetrated that market at all
(because they were overkill).
Perhaps the strategy for OpenSTEP is indeed a deliberate compromise -- to give
up some features and/or perfect compatibility, but in so doing bring down the
cost and increase the market penetration of NeXT products into the areas
where, as Gregory points out, less sophisticated functionality is adequate.
Delphi is a dramatically-better development product partly because it
introduces some advanced concepts into the Windows world, and indeed it is
comparable to NeXT products, but it's not the same and does not need to be.
It bears not being compared to NeXT too closely.
/mr/
Georg Tuparev
> > Wake up Greg!
> Furthermore, NEXTSTEP is not uniform once it becomes OPENSTEP. It will use
> the traditional UI in the Mach version, but Windows UI in the NT version.
> I think Pete Clark posted that you will have a choice between traditional
> and Motif in the Solaris version. And I hate to burst your bubble, but I
> have extremely good information that the Sun and NeXT versions _already_
> differ in some important ways. GNUstep will differ from both of them. Even
> if you maintain 100% fidelity to the spec, Sun and NeXT will not. Face it,
> OPENSTEP will never be as source-compatible and MAB-capable as NEXTSTEP
> already is.
communication to the workspace, user default database etc. What it is not specified
is if the window close button is on the left or the right side, if the title bar is
blue or black, which mouse button is doing what , etc.pp. This is IMHO very wise
decision, because having the same source and even the same nib files, you can get
different look & feels. Of course stuff like drag & drop will work only between
OpenStep apps, but if I have Tailor.app, Stone Design, Lighthouse, and AFS ;-) apps
on top of W$ I will be completely happy and never will think on using any other Win
crap!
> As to PDO, I have never found a "must have" use for it in my applications.
> You may prefer to focus there instead of AppKit, but PDO is NOT where the
> bulk of the corporate applications market is.
Oh really? And how your apps are talking to the workspace manager? How is your
license server pinged? How could you implement pasteboard daemon? How to implement a
API in a heterogeneous environment? And further: everybody is talking about
client/server systems, accessing remote databases, EOF, WOF,... I'm really very
curious how you can implement it without PDO. Well, you can use sockets on UNIX!
Have you used them? It's great fun indeed ;-) And what about W$? Don't tell me OLE
please! I prefer to go to work in a sheep farm but not using OLE!
> Yes, I know about options
> and derivatives firms who need to run massive Monte Carlo simulations on
> Alpha chips, but you'll have to work awfully hard to convince me that
> straightforward forms-based apps -- the bread and butter corporate apps --
> benefit from PDO.
Now I'm really lost! I was expecting to hear such an argument form a newcomer, but
it surprise me to get it from you! Each (even small) company needs tools like:
distributed time/appointment scheduler; documentation/ordering/accounting systems;
database ... just to mention few. By using PDO you can develop such applications an
order of magnitude faster! I do not start talking about large corporate
environments, like Hospital management system ... there the benefits of using PDO
are gigantic!
> Georg, it doesn't sound like you have actually worked much on Delphi or
> even Windows 95/NT. For example, the integration of Delphi's editor and
> form designer goes WAY beyond IB's limited parsing of header files.
Yes, it's true that I'm not a Delphi guru, and yes it is true that "the integration
of Delphi's editor and form designer goes WAY beyond IB's limited parsing of header
files", but I'm talking about overall integration! What if I do not like the
Delphi's editor? With NS I can use any! With Delphi I have only one option...
> The
> statement that "Only NEXTSTEP makes it possible for over 30 people from
> I don't know how many countries to work together so nicely [on MiscKit]!"
> is patently wrong. More is possible in other environments than you think.
You know better then I that the NS community is not very large. So one could expect
that for larger communities one can find much more universally applicable
frameworks. But this is just not true! Every now and then I have to work on a X11 +
C++ project. There are no two different class frameworks (written by different
software vendors) with the size of MiscKit which are capable to work together. Think
about it! I even played with the Talignet ... no wonder that they bit the dust!
Believe it or not, NS/OS was and still is the only complete development environment.
If I found a better one I will perhaps change the train, but there is nothing else
out!
> Before you spend much more time on your GNUstep labor of love, you should
> take a step back, draw a deep breath, survey the market, and ask who
> you're building this for and how much it is worth the effort.
Or perhaps you should spend a bit more time with GNUstep ;-) It will work on
virtually any platform. Not to mentioned that some of the most intelligent and
talented folks have gravitated to GNUstep.
Amen ;-)
Marco Scheurer
[...]
> In terms of M-V-C paradigm,
> Delphi seems mixing the C component with the V.
Isn't it also also the case with NEXTSTEP, where the View class implements
many things that are in the Controller component of the MVC triad, like
mouse event handling? NEXTSTEP "Controllers" are different from the
original MVC Controllers. Not a bad thing IMHO.
---
Marco Scheurer
Sen:te
Parc Scientifique EPFL -- CH-1015 Lausanne -- Switzerland
ma...@sente.epfl.ch (NeXT, MIME mail welcome)
Fabie...@free.fdn.org
This offer is only for Delphi 1.0 customer (Which I am not! :-) )
Here are the price:
Delphi Desktop 2.0: 1200 FF or $234, reg. price: 2405 FF or $481
Delphi Developper 2.0: 1561 FF or 312, reg. price: 3612 FF or $722
Delphi Client/Server 2.0 which i think could be compared to NS+EOF
18900 FF or $3780 (For this one I donï¼µ have the regular price and will post
it later).
Delphi Client/Server 2.0 also includes Interbase NT 2 users licence and
ReportSmith 3.0.
ReportSmith 3.0 might be of some interest, but not Interbase NT.
Conclusion: The discounted price Delphi Client/Server 2.0 is not so far from
NS+NSDev+EOF, but I think that I get more for my money with the NEXSTEP
stuff.
Cheers
Fabien
(Prices quoted above include french sales taxes (20,6%) 8^( )
--
---------------------------------------------------------------------
Fabie...@free.fdn.org (NextMail/MIME accepted)
Fabien Roy Consultant
NEXTSTEP/OPENSTEP/EOF Consultant, SYBASE DBA
10 rue de la DEFENSE 93100 MONTREUIL, France
Tel: 33 1 45 28 32 23 Fax: 33 1 48 55 09 90
Karl Harbour
>Wei Chen (wc...@gramercy.ios.com) wrote:
>: Although I essentially agree with your assesments on Delphi. I would
>: like to point out that Delphi is not truly object-oriented development
>: platform as far as reusability is concerned.
>
>: Without taking additional steps, Delphi developers would put all the
>: logic (be business or control) on the form object( NeXT's equivalent
>: Window object .) It's quite well-known that when programming in
>
>This isn't because of an inherent shortcoming in Delphi. This is
>a result of being new to objects, as most Delphi users are. A
>similar phenomenon can be found among people new to NeXTSTEP.
>
>Everyone who's written an app where all the functionality is implemented
>in 'AppController.m' or such, raise your hand.
Maybe so, but at least it would be a controller object, and not a
subclass of Window or View. All this example shows is that novices put
too much functionality in one class, but at least a NextStep novice
separates Controller logic from View logic right from the word go, and
they don't do bizarre things like subclassing Window because it
contains some Controls that the designer of the Window class didn't
anticipate.
>
>: NeXTstep, developers should put this logic on a custom controller object
>: rather than a Window or its subclass object in order to achive greatest
>: reusability. NeXT also advised developers not to subclass Application
>: for exactly the same reason. NeXT achieved this by providing, e.g.,
>: target/action configurable at the design time via IB. However, Dephi's
>: target is hard-coded to be the form object. In terms of M-V-C paradigm,
>: Delphi seems mixing the C component with the V.
>
>That's not entirely true. There is a default, which you get by double-clicking
>on an event. Which in many cases is adequate. You can also specify different
>methods.
>
>NeXTSTEP certainly doesn't enforce good design.
But it does encourage it, and that's what matters.
Something "which in many cases is adequate" is hardly encouraging good
OO design.
>
Karl Harbour
>Georg Tuparev writes
>> Wake up Greg!
>
>Oh, I am quite awake, thank you. NEXTSTEP _was_ a complete OO environment
Still is, last time I looked.
>(including a really good unified user environment), but OPENSTEP will not
>be. In fact, many of the complaints I have heard about OPENSTEP/Win from
>a functional point of view is how much of that wonderful NEXTSTEP we take
>for granted has been "dumbed down" for the sake of being a "first class NT
>citizen." In other words, NEXTSTEP loses some of its magic on the way to
>OPENSTEP/NT.
I think you confused the issue by using the word NextStep in the
thread title.
<-- snip -->
>
>As to PDO, I have never found a "must have" use for it in my applications.
>You may prefer to focus there instead of AppKit, but PDO is NOT where the
>bulk of the corporate applications market is. Yes, I know about options
>and derivatives firms who need to run massive Monte Carlo simulations on
>Alpha chips, but you'll have to work awfully hard to convince me that
>straightforward forms-based apps -- the bread and butter corporate apps --
But I thought your argument was based on a nearly-award-winning OO
app which you translated remarkably easily from Next to Delphi, not
some straightforward triviality?
>benefit from PDO. NeXT made this argument to the customer who is paying us
>to move from NEXTSTEP to Delphi, and the customer didn't buy it. Besides,
>if you really need PDO/D'OLE, my understanding is that it will not be
>limited to OPENSTEP apps. I hope not, or it will find a limited market.
>In which case, there is no reason a Delphi app couldn't leverage it too.
>
Surely, the point with (P)DO is that you hardly know you're doing it,
i.e. local and remote messaging have the same syntax. With Distributed
OLE as your ORB, surely OLE is gonna come and smack you in the face
like a really badly smelling fish? BTW, for a really good and
impartial treatment of CORBA/OLE etc, I can recommend "The Essential
Distributed Objects Survival Guide" (ISBN 0471-12993-3).
>Georg, it doesn't sound like you have actually worked much on Delphi or
>even Windows 95/NT. For example, the integration of Delphi's editor and
>form designer goes WAY beyond IB's limited parsing of header files.
I would think IB doesn't need to go further than header file parsing,
due to its object archiving nature, a subject which I know has been
discussed here before. (IB does need improving, but not in this
direction.)
<-- SNIP -->
Karl Harbour
>Wei Chen <wc...@gramercy.ios.com> writes
>> Although I essentially agree with your assesments on Delphi. I would
>> like to point out that Delphi is not truly object-oriented development
>> platform as far as reusability is concerned.
>
>> Without taking additional steps, Delphi developers would put all the
>> logic (be business or control) on the form object( NeXT's equivalent
>> Window object .) It's quite well-known that when programming in
>> NeXTstep, developers should put this logic on a custom controller object
>> rather than a Window or its subclass object in order to achive greatest
>> reusability. NeXT also advised developers not to subclass Application
>> for exactly the same reason.
>
>Whoa, whoa, whoa, hold the phone, Chester! You can do bad design with ANY
>development tool. Just because most Delphi developers are newer to OOP and
>make some mistakes, you can't blame that on the tool. If you know what
>you're doing, Delphi is every bit as capable as NEXTSTEP of promoting
>reusability. Our trading app framework is 100% M-V-C. Our AfsController
>component is dragged to a form, all business models descend from AfsModel
>(which inherits from TDataSet), and TForms are very minimally subclassed.
>
Obviously I haven't seen your AfsController class, but I find it hard
to accept that you can achieve 100% MVC with it. I accept that it
separates out the business logic from the UI, but I think there is
more to MVC than that, especially considering your claim of complete
purity.
Surely it's a requirement of MVC that the model objects ARE objects.
A TDataSet operates on a SET of rows in a table. How is it possible to
subclass something which represents a set, and yet have instances of
it represent a single model object instance?
In any case, how can it be good OO design for a Currency class, say,
to inherit methods such as
procedure CursorPosChanged;
procedure Delete;
procedure DisableControls;
procedure Edit;
procedure EnableControls;
If my model classes have non-persistent attributes, how is this
modelled in your scheme? Calculated fields are no good, as I may want
the attribute to be settable by another object through public API. How
do I do this with a TDataSet subclass, because clearly any instance
variables apply to a set of model objects, not just one.
If such attributes were stored somewhere else, it wouldn't be a very
OO design. That's fine if you're putting a simple bread-and-butter
business app together, but you have made bold statements about awards
for OO design and 100% MVC purity.
Also, I'd be interested in how you solved the classic OO to
relational-database mapping problem? When you've got a Model class
hierarchy, do subclasses have their own table, go in their parent
class's table, or spread across both? If this hasn't been an issue for
you, is it perhaps because your model is computationally complex but
structurally fairly simple?
Does your framework provide an object-uniqueing facility like EOF
does? If you've got an OO API, surely it's important that object
identity is preserved in this way?
<-- snip -->
Gregory H. Anderson
> [French pricing information deleted]
In the US, the price differential between Delphi and NS is considerable.
Remember, if you don't need Borland's custom C/S drivers, the basic
"developer" package is sufficient for use with local or ODBC drivers.
Even the C/S version is only $1995.
Compare that to NS, which costs $795 for the User version, plus $4,995
for the Developer edition, plus $495 for EOF, plus... And your description
completely ignores runtime fees. NS has them. Delphi doesn't.
Jonathan W. Hendry
> >
> >As to PDO, I have never found a "must have" use for it in my applications.
> >You may prefer to focus there instead of AppKit, but PDO is NOT where the
> >bulk of the corporate applications market is. Yes, I know about options
> >and derivatives firms who need to run massive Monte Carlo simulations on
> >Alpha chips, but you'll have to work awfully hard to convince me that
> >straightforward forms-based apps -- the bread and butter corporate apps --
> But I thought your argument was based on a nearly-award-winning OO
> app which you translated remarkably easily from Next to Delphi, not
> some straightforward triviality?
Straightforward != trivial
Straightforward means 'minimal chrome' not 'minimal complexity'.
Greg's design was lauded not because it had every whiz-bang feature under
the sun, but because it's a solid, finely crafted design which has shown
real benefits.
> >benefit from PDO. NeXT made this argument to the customer who is paying us
> >to move from NEXTSTEP to Delphi, and the customer didn't buy it. Besides,
> >if you really need PDO/D'OLE, my understanding is that it will not be
> >limited to OPENSTEP apps. I hope not, or it will find a limited market.
> >In which case, there is no reason a Delphi app couldn't leverage it too.
> >
> Surely, the point with (P)DO is that you hardly know you're doing it,
That's all well and good. But most applications simply don't need it.
Many applications of DO are little more than prettied-up RPC calls. For
this, DDE would work as well. And, it doesn't cost $500/seat to deploy.
> >Georg, it doesn't sound like you have actually worked much on Delphi or
> >even Windows 95/NT. For example, the integration of Delphi's editor and
> >form designer goes WAY beyond IB's limited parsing of header files.
> I would think IB doesn't need to go further than header file parsing,
> due to its object archiving nature, a subject which I know has been
> discussed here before. (IB does need improving, but not in this
> direction.)
Alas, all the objects you use in IB are not palettized. In that case, you
do have to parse headers. Unfortunately, IB doesn't notice if you change
the headers in the editor.
Jonathan W. Hendry
>
> jon@heinlein (Jonathan Hendry) wrote:
> >
> >Everyone who's written an app where all the functionality is implemented
> >in 'AppController.m' or such, raise your hand.
> Maybe so, but at least it would be a controller object, and not a
> subclass of Window or View. All this example shows is that novices put
> too much functionality in one class, but at least a NextStep novice
> separates Controller logic from View logic right from the word go, and
> they don't do bizarre things like subclassing Window because it
> contains some Controls that the designer of the Window class didn't
> anticipate.
NextStep novices don't create a Controller because of anything inherent in
NeXTSTEP. They generally do it because that's what Garfinkel & Mahoney did,
or what was in NeXTDeveloper/Examples.
Actually, the Form-reliance makes some sense considering that Windows is
based on Windows, and not Applications. If I'm not mistaken, if you want to
get a handle to another process in Windows, you have to go through the
on-screen windows. Yeah, it sucks. But that's Bill Gates for ya.
> >
> >NeXTSTEP certainly doesn't enforce good design.
> But it does encourage it, and that's what matters.
Oh, yeah. I forgot about the NeXT OOA/D Wizard that raps you on the knuckles
if you access an ivar without going through the accessor.
> Something "which in many cases is adequate" is hardly encouraging good
> OO design.
A person who hasn't a clue about OOD will botch just as well on NeXTSTEP
as on Delphi. Good OOD doesn't come from your tools.
Jonathan W. Hendry
> Now I'm really lost! I was expecting to hear such an argument form a newcomer, but
> it surprise me to get it from you! Each (even small) company needs tools like:
> distributed time/appointment scheduler; documentation/ordering/accounting systems;
> database ... just to mention few. By using PDO you can develop such applications an
> order of magnitude faster! I do not start talking about large corporate
> environments, like Hospital management system ... there the benefits of using PDO
> are gigantic!
Georg, NeXT is moving to the Windows world. Most of this software already
exists - there's no need to write it.
Sure, PDO is nice. If the benefits (and more importantly, cost-benefits) of using
PDO were that gigantic, it wouldn't be the DO bit-player that it is.
> You know better then I that the NS community is not very large. So one could expect
> that for larger communities one can find much more universally applicable
> frameworks. But this is just not true! Every now and then I have to work on a X11 +
> C++ project. There are no two different class frameworks (written by different
> software vendors) with the size of MiscKit which are capable to work together. Think
> about it! I even played with the Talignet ... no wonder that they bit the dust!
> Believe it or not, NS/OS was and still is the only complete development environment.
> If I found a better one I will perhaps change the train, but there is nothing else
> out!
C++ wasn't exactly made for easy exchange of classes. Bad example. :)
Delphi was made for that.
The Free/Shareware Delphi component 'market' is booming. New components are coming
out faster than NeXTSTEP palettes *ever* did, even when NeXT had an academic
presence. They just plug right into the Delphi palette, and 'just work'.
Jonathan W. Hendry
> Conclusion: The discounted price Delphi Client/Server 2.0 is not so far from
> NS+NSDev+EOF, but I think that I get more for my money with the NEXSTEP
> stuff.
That's not quite right.
For one, you can do database development without Delphi C/S.
Second, a large part of the cost of Delphi C/S is due to database driver licenses
which allow you to redistribute the drivers with your application. It's more
akin to NSDev+EOF *with no runtime fee*. Since the EOF runtime is $500/seat
it doesn't take many deployment seats to get a major price advantage from
Delphi.
Gregory H. Anderson
> Just because you have not had the need for PDO does not mean that the
> corporate environment is not going in that direction! When you start
> talking about sales force automation, distributed processing centers and
> branch office automation you are talking about a PDO functionallity.
Please don't overstate what I said. I have nothing against [P]DO; in
fact, I pointed out that the WriteUp API relies on it. I do understand
that some enterprise apps need [P]DO functionality, I just pointed out
that my company's fairly sophisticated Wall Street MCCA does NOT. As a
result, I do not accept this is a must-have, make-or-break feature.
Georg seemed to be saying NEXTSTEP couldn't take a leak without it.
Gregory H. Anderson
> Obviously I haven't seen your AfsController class, but I find it hard
> to accept that you can achieve 100% MVC with it. I accept that it
> separates out the business logic from the UI, but I think there is
> more to MVC than that, especially considering your claim of complete
> purity.
I need to be more careful with my wording; everyone takes things too
literally in this group. By "100% MVC," I mean that we use MVC as a
fundamental design principal in all of our work. I do NOT mean that
we adhere to slavish execution of a particular object organizational
model. Pardon my smugness, but in a methodology as new as OOP, I do
not accept that Booch's or Rumbaugh's or anyone else's ideas are
necessarily better than mine. My point was that we DO divide our apps
into Models, Views, and Controllers in a way that works for us. I
would never claim that we are "pure" to anyone else's ideas.
> Surely it's a requirement of MVC that the model objects ARE objects.
> A TDataSet operates on a SET of rows in a table. How is it possible to
> subclass something which represents a set, and yet have instances of
> it represent a single model object instance?
A TDataSet CAN operate on a set, it doesn't have to. What if it's hooked
up to a TQuery? You're thinking if TTable mode. In any event, this is one
of the compromises we made, given budget and delivery schedules. Yes, we
could have built AfsModel as a direct subclass of TObject, but why? We
found an existing class that seemed appropriate and started from there.
That's what REUSE is all about.
> In any case, how can it be good OO design for a Currency class, say,
> to inherit methods such as
>
> procedure CursorPosChanged;
> procedure Delete;
> procedure DisableControls;
> procedure Edit;
> procedure EnableControls;
In what universe do models not have to be deleted? Or prepare for editing?
And just because Enable|DisableControls methods exist in the superclass,
it doesn't mean we actually use them.
> If my model classes have non-persistent attributes, how is this
> modelled in your scheme? Calculated fields are no good, as I may want
> the attribute to be settable by another object through public API. How
> do I do this with a TDataSet subclass, because clearly any instance
> variables apply to a set of model objects, not just one.
Even if a TDataSet happens to contain multiple records at a given time,
there is only one "cursor" position. The attributes of that record are
expressed through a series of TField-derived objects, which may or may
not be hooked up to UI. You only operate on one record/object at a time.
Each has access to all properties declared in the Model subclass.
> Also, I'd be interested in how you solved the classic OO to
> relational-database mapping problem? When you've got a Model class
> hierarchy, do subclasses have their own table, go in their parent
> class's table, or spread across both? If this hasn't been an issue for
> you, is it perhaps because your model is computationally complex but
> structurally fairly simple?
Actually, this problem solves itself with multiple tables. An AfsModel
subclass defines the properties it needs. Those properties are then
attached to whatever TFields from whatever TTables/TQuerys are needed
to provide the necessary data. The model literally does not care how
the parent/child aspect of database tables are organized structurally.
However, it does support a parent/child concept (analogous to visible
parents and children) for more complex situations where multiple MODELs
need to get a particular job done, like cross-model validation.
> Does your framework provide an object-uniqueing facility like EOF
> does? If you've got an OO API, surely it's important that object
> identity is preserved in this way?
No, but the OOPness of the database is not what matters in our app.
David Stes
Gregory H. Anderson
> jon@heinlein (Jonathan Hendry) wrote:
> > Everyone who's written an app where all the functionality is
> > implemented in 'AppController.m' or such, raise your hand.
> Maybe so, but at least it would be a controller object, and not a
> subclass of Window or View. All this example shows is that novices
> put too much functionality in one class, but at least a NextStep
> novice separates Controller logic from View logic right from the
> word go, and they don't do bizarre things like subclassing Window
> because it contains some Controls that the designer of the Window
> class didn't anticipate.
The first iteration of our now-properly-organized TradeKit was based
entirely on Window subclasses. It turned out to be a sub-optimal design,
but it didn't suck. Just don't try to tell me that NS naturally forces
people to use controllers. We paid for that mistake for several months,
when we finally decided to make it right.
> > NeXTSTEP certainly doesn't enforce good design.
> But it does encourage it, and that's what matters.
Perhaps you would like to cite an example of how that oh-so-famous
two-layer database access library, DBKit, separated Controller logic
and encouraged novices not to do bizarre things. I'm not beating on
NeXT, I'm just pointing out that at a time when most NeXT programmers
were cutting their teeth on database access, NeXT's solution was poor
from several perspectives, notably overall design. I am proud to say
that AFS stuck with its homegrown solution through all that, and has
never regretted it for a moment. In fact, when Felix visited with his
DBKit II (now EOF) slide show, my first comment was "That looks great.
Would you like to buy it right now?"
Delphi's database access layer, mercifully, began its life as a 3-layer
hierarchy, which is why we were able to interpose our AfsModel class
between the raw tables and the UI expression of the data. Delphi newbies
will never know how much pain they have been spared by that decision.
The bottom line is, only clueful managers and skilled programmers can
encourage and support good design. Unfortunately, both are in dreadfully
short supply.
Andy Robinson
> Compare that to NS, which costs $795 for the User version, plus $4,995
> for the Developer edition, plus $495 for EOF, plus... And your description
> completely ignores runtime fees. NS has them. Delphi doesn't.
Why does everyone keep insisting that NS has this $5000 entry point for the new
developer? Just get a black box second-hand for $1000 and get the upgrades.
It is quite true that a serious professional or corporate developer probably wants
some serious horsepower and has to buy non-black hardware and a full developer
licence. But the costs of a PC with Delphi is not too different to the cost of
a black box and Next Developer.
--
Andy Robinson
Charles William Swiger
Delphi: An.. by Karl Har...@mail.bogo.c
> For once, can we not make a comparison on purely technical grounds?
> There's enough Next pricing policy bashing as it is.
Greg Anderson did perform a rather detailed comparision on purely
technical grounds, without ever mentioning price tags. The article was
posted on 2/20/96 with a message-ID of <4gdbv3$s...@shelob.afs.com>.
I didn't see any "bashing" of NeXT's pricing policies in Greg's
comments, which I'll quote in full at the end of this message. For that
matter, I can't think of any other comments in this thread that I'd call
"bashing" either, although certainly several people have been trying to
figure out the economics of NeXT's pricing. Perhaps Karl is fortunate
enough to have the luxury to make decisions without considering
financial matters, but that isn't something that I'm free do to.
The results I've gotten lead me to criticise NeXT's proposed runtime
licensing fees because they appear to make it unviable for an ISV to
develop many products using OPENSTEP, at least those which do not sell
for thousands of dollars per seat.
-Chuck
>>In the US, the price differential between Delphi and NS is considerable.
>>Remember, if you don't need Borland's custom C/S drivers, the basic
>>"developer" package is sufficient for use with local or ODBC drivers.
>>Even the C/S version is only $1995.
>>
>>Compare that to NS, which costs $795 for the User version, plus $4,995
>>for the Developer edition, plus $495 for EOF, plus... And your description
>>completely ignores runtime fees. NS has them. Delphi doesn't.
>>
>>--
>>Gregory H. Anderson | "Honey, there're few programming
>>Gaffer/Best Boy/Key Grip | problems that can't be solved
>>Anderson Financial Systems | with duct tape." -- 'Father' Duke
>>gr...@afs.com (NeXTmail OK) | (paraphrased), Doonesbury, 2/17/95
Charles Swiger | cs...@andrew.cmu.edu | standard disclaimer
----------------+---------------------+---------------------
I know you're an optimist if you think I'm a pessimist.
Joe Freeman
Karl Harbour wrote:
>
> >Perhaps you would like to cite an example of how that oh-so-famous
> >two-layer database access library, DBKit, separated Controller logic
> >and encouraged novices not to do bizarre things.
>
> Well, this is an unexpected change in the direction of the debate. It
> seems a rather weak argument to criticise a kit which has been defunct
> for over 18 months. What relevance does DBKit have to Nextstep and EOF
> now? How well did Turbo Pascal 5.0 separate Controller logic?
OK, we can look at some other kits and see the same lack of
separation. The Appkit has a very poor separation between
the application and UI control logic. Applications which
follow the 3.x appkit generally have a very poor partition
between the program control and the UI control layer. EOF
1.x has similar issues where the best "Controller" class is the
EOController class which has user interface features rolled into
it also. (EOF 2.x should fix this with the breakup of the controller
class) 3.x DO is a great product except that it has no split
between the DO protocol and the underlying transport layer. The
controllers responsible for user object managment and notifications
are the same objects which go down to the wire. (Hopefully the
new DO will fix this).
> Next's past is irrelevant as far as I'm concerned.
Only if the progress is across the board. Progress in one
group, EOF, does not translate to understanding across
all projects.
> No Next newbie needs to go through any of this pain either. DBKit has
> been completely superceded (some time ago) by EOF. EOF allows you to
> do real business objects, and also, for example, provides an edit undo
> mechanism - how does Delphi support undo again?
The current, EOF 1.x, undo architecture is nice except that it is only
really supported in the UI layer. I dont see anything UI centric
about object attribute editing rollbacks.
--
FreemanSoft Inc. NEXTSTEP and WEBOBJECTS software in the DC area.
Governer Glendenning of MD wants to spend $300M of the
people's money on a rent free pro football stadium which
is only used 10 times a year.
For whom is he really doing this deal?
Joe Freeman
> And why did Garfinkel & Mahoney and the people who wrote the
> NeXTDeveloper/Examples do it that way? Because of target/action and
> the design of the AppKit generally separating UI from application
> logic.
This is definately not true. The target/action paradigm has done
nothing to aid in separating out the application logic. Applications
have several different types of process, presentation, application,
and model to name the most common. The insertion of controllers into
nib files where those controllers implement UI control logic and
application logic is a "bad thing" IMHO. It makes it very difficult
to deploy an application across presentation layer architectures..
> I'm sorry, but your argument is completely bogus.
I think that completely should be used about as often as "never"
and "always".
> I suppose you don't think the AppKit provides any help to the
> developer for writing consistent apps in terms of the look and feel of
> cut & paste, spell checking, fonts, colours, printPSCode, faxPSCode
> and so forth? If two apps handle these things in the same way, is it
> down to the application developer or what's provided by Next's AppKit?
These are nice features but I'm not as convinced any more that they are
as important as an application frame work, a standard doc architecture,
application and document controllers and some policy aides. Almost all
of the subsystems you mention are really abstractions for system resources
and are basicly consumable objects. (printPSCode and faxPSCode are
actually interface protocols) So, NeXT did a nice job wrapping their
internally developed resources which is good. It is not clear what
portion of the development time that these resources represent
Gregory H. Anderson
>[reasonable stuff about the use of TDataSet vs TDataSource]
> Surely it's TDataSources that are hooked up to TDataSets?
> I think you have to concede that you are working with database
> records, and not model objects. This one record at a time, may / may
> not be connected to UI aspect seems to introduce a nasty coupling into
> your framework.
Yikes. I need to wait until I'm fully awake before posting. I think
this whole argument could have been avoided if I hadn't typed 'TDataSet'
where I meant 'TDataSource'. I've been talking about the three-layer DB
access hierarchy, and how we use the middle part, but when it came to
naming it, I used the wrong one. AfsModel derives from Source, NOT Set.
And yes, our models do fully encapsulate the business rules and logic.
Sorry for the confusion. I think we're actually on the same page.
Gregory H. Anderson
> Greg Anderson wrote:
> >Perhaps you would like to cite an example of how that oh-so-famous
> >two-layer database access library, DBKit, separated Controller logic
> >and encouraged novices not to do bizarre things.
>
> Well, this is an unexpected change in the direction of the debate. It
> seems a rather weak argument to criticise a kit which has been defunct
> for over 18 months. What relevance does DBKit have to Nextstep and EOF
> now? How well did Turbo Pascal 5.0 separate Controller logic?
As I said, I raised this point only to demonstrate that even NeXT, whose
programmers I respect enormously, botched this first time out, and a lot
of early programmers either learned a bad thing or spent too much time
working around the deficiencies. Delphi at least got the DB part right,
but I agree they botched the Form-dependence part. I guess I'm saying,
cut Borland some slack. Delphi is (was) a 1.0 tool, and a better 1.0 tool
than NS was when it was 1.0. They already fixed some of the worst TForm
buggery. And don't forget, some of this window-centric stuff comes from
the Win API. Messaging is intimately tied to visual objects.
> Next's past is irrelevant as far as I'm concerned.
To you, perhaps. But it affected a lot of programmers. I know, I have the
DBKit-workaround class library to prove it. And it's ugly.
Jonathan W. Hendry
Georg Tuparev wrote:
>
> In article <4h1viu$m...@shelob.afs.com> Greg_A...@afs.com (Gregory H. Anderson)
> writes:
> [...]
> > As I said, I raised this point only to demonstrate that even NeXT, whose
> > programmers I respect enormously, botched this first time out, and a lot
> > of early programmers either learned a bad thing or spent too much time
> > working around the deficiencies. Delphi at least got the DB part right,
> [...]
> At the time when DBKit was out, it was the coolest R/DB access framework around.
> It's not a shame when other people write something better later. But it's a shame if
> other people write _worse_ stuff later, and that is what is continually happening.
> NS is already 8 years old, and even NS0.8 was better than most OO environments are
> now.
> And another point: if you are saying that it's very horrible to change/rewrite
> sources you better work something else.
The point (I think) was this: Mr. Harbour claimed that NeXTSTEP encourages good
design.
DBKit points out the fallacy in this: NeXT themselves, with the advantage
of having massive brain power, source code, and the designers of NeXTSTEP
itself, STILL produced a piece of software which is widely recognized as
a suboptimal design.
If *NeXT* doesn't 'automagically' produce good designs with NeXTSTEP, how
can one claim that NeXTSTEP somehow automagically encourages good design?
Perhaps I'm wrong, but I don't think that EOF includes the spirit of
Grady Booch.
> But I think we should stop this discussion.
> I'll just summarize:
> - You made a comparison between Delphi and NeXTSTEP mentioning details only;
Details? As opposed to what? Opinion? Fantasy?
> - I answered you that you should compare the OpenStep & Delphi, and that the NeXT.
> Inc's focus changed drastically last 3 years and that NeXTSTEP != OpenStep;
Seemed to me that Greg compared OpenStep & Delphi. OpenStep/Windows - NeXT's main
product now - is competing against Delphi (in some problem domains).
> - You continue to bringing arguments from the NeXT's past completely ignoring OS
> (with an exception of arguments from one of your NEO sources ... but these arguments
> ware just false or misleading). You never compared the new features of OS and never
> mentioned the new stuff NeXT is bringing to the market.
Are those new features really enough to justify OpenStep to many customers?
> We are talking two different languages. I presume your inaccurate statements
> according the present products of NeXT Inc. are because of negative emotions.
> In the past you ware one of the most accurate and open minded people in this
> news group, soI'll recommend you to join the GNUstep community and when our
> OpenStep book we are writing now is ready I'll promise to send you one free
> copy with the hope to bring you again where I'm sure you (as a developer) will
> feel best.
Translation: I prefer not to read wrong-thinking statements critical of NeXT
and/or OpenStep. Those who would make critical or negative statements must be
feverish and should lay down for a bit, until they regain their senses. A little
warm milk and a nap should have Greg back to normal in no time.
Georg, GnuStep may be fabulous. Your book may be wonderful. But if OpenStep
tanks out, GnuStep isn't likely to keep someone's family fed, his mortgage paid, his
investors happy. No business owner can afford to go through life with their head
firmly planted in the sand. Such business owners don't own businesses for long.
Ignoring the realities of the software marketplace, and only believing NeXT's PR
announcements is an excellent strategy for rapidly achieving bankruptcy. This may
not be an issue for you. Many people have more at stake than their spare time.
Garance A Drosehn
> Greg_A...@afs.com (Gregory H. Anderson) writes:
> [...]
> > As I said, I raised this point only to demonstrate that even
> > NeXT, whose programmers I respect enormously, botched this
> > first time out, and a lot of early programmers either learned
> > a bad thing or spent too much time working around the deficiencies.
> > Delphi at least got the DB part right,
> [...]
> At the time when DBKit was out, it was the coolest R/DB access
> framework around. It's not a shame when other people write
> something better later. But it's a shame if other people write
> _worse_ stuff later, and that is what is continually happening.
> NS is already 8 years old, and even NS0.8 was better than most
> OO environments are now. And another point: if you are saying
> that it's very horrible to change/rewrite sources you better work
> something else.
>
> I'll just summarize:
> - You made a comparison between Delphi and NeXTSTEP mentioning
> details only;
> and that NeXTSTEP != OpenStep;
> completely ignoring OS (with an exception of arguments from
> or misleading). You never compared the new features of OS and
> never mentioned the new stuff NeXT is bringing to the market.
I think you've completely misunderstood the comments Greg has
been making. He isn't bringing up examples of NeXT's past to
say how bad NeXT was, he's doing it to say how quickly
improvements can happen.
The fact that Delphi is where it is now indicates that they at
least "get it". Now that they "get it", the fact that they
aren't as far along as NeXT does not prove that they will never
be as far along as NeXT. Thus, it is very reasonable to assume
that some of the deficiencies that have been noted in Delphi (by
both you and Greg) may be addressed soon.
From my reading of Greg's comments, it seems fairly clear to me
that he is interested in the long-term success of OpenStep. He
is just commenting on the issues which he considers a barrier
to that success. You're reading his comments as if he's got
some vendetta against NeXTSTEP, and I don't see that at all.
The reasoned comparision of NeXTSTEP to Delphi was not the work
of a raving lunatic who wants to tear down NeXT. It was the
analysis of someone who has worked a lot with NeXTSTEP, and
has the experience to do an intelligent comparison of the two
environments.
> We are talking two different languages. I presume your inaccurate
> statements according the present products of NeXT Inc. are because
> of negative emotions. In the past you ware one of the most accurate
> and open minded people in this news group,
In my mind, he still is.
> so I'll recommend you to join the GNUstep community and when our
> OpenStep book we are writing now is ready I'll promise to send
> you one free copy with the hope to bring you again where I'm sure
> you (as a developer) will feel best.
I think that GNUStep goes a long way to addressing some of the
concerns that Greg has mentioned, even though it will not be a
viable solution for every potential customer. I think you're
reading his remarks as an enemy attack, when in fact he's still
quite much on the side of NeXTSTEP and OpenStep. The fact that
he's on the side of these products does not mean he has to
overlook the areas which he thinks might cause trouble for
those products.
I am totally baffled by the people who are responding to
Greg as if he's got some grudge against NeXT.
---
Garance Alistair Drosehn = g...@eclipse.its.rpi.edu
ITS Systems Programmer (handles NeXT-type mail)
Rensselaer Polytechnic Institute; Troy NY USA
Georg Tuparev
[...]
> As I said, I raised this point only to demonstrate that even NeXT, whose
> programmers I respect enormously, botched this first time out, and a lot
> of early programmers either learned a bad thing or spent too much time
> working around the deficiencies. Delphi at least got the DB part right,
[...]
At the time when DBKit was out, it was the coolest R/DB access framework around.
It's not a shame when other people write something better later. But it's a shame if
other people write _worse_ stuff later, and that is what is continually happening.
NS is already 8 years old, and even NS0.8 was better than most OO environments are
now.
And another point: if you are saying that it's very horrible to change/rewrite
sources you better work something else.
But I think we should stop this discussion.
I'll just summarize:
- You made a comparison between Delphi and NeXTSTEP mentioning details only;
- I answered you that you should compare the OpenStep & Delphi, and that the NeXT.
Inc's focus changed drastically last 3 years and that NeXTSTEP != OpenStep;
- You continue to bringing arguments from the NeXT's past completely ignoring OS
(with an exception of arguments from one of your NEO sources ... but these arguments
ware just false or misleading). You never compared the new features of OS and never
mentioned the new stuff NeXT is bringing to the market.
We are talking two different languages. I presume your inaccurate statements
according the present products of NeXT Inc. are because of negative emotions. In the
past you ware one of the most accurate and open minded people in this news group, so
I'll recommend you to join the GNUstep community and when our OpenStep book we are
writing now is ready I'll promise to send you one free copy with the hope to bring
you again where I'm sure you (as a developer) will feel best.
Regards
Gregory H. Anderson
> Gregory H. Anderson writes
> >
> > > The Delphi and NEXTSTEP form designers have different strengths
> > > in the area of "event attachment," but both are deficient. In
> > > NEXTSTEP, InterfaceBuilder allows any target, but can only assign
> > > one action. In Delphi, the form designer can attach multiple
> > > actions, but only one target (the form itself). You can work around
> > > both deficiencies, but it requires programmatic runtime assignment.
>
> This is basically false. For example, Button in NS/OS can be assigned
> to one out of ANY number of actions reponded by ANY number of targets,
> while Dephi's button allows one and only one action to assign to a fixed
> target viz. Form. I am curious to know in what systematic way your form
> responds to multiple buttons on the form in your program in order to
> make your code more reusable. I hope that you will not tell me that you
> have a big case statement to achieve this.
Heavens no. Here's a further clarification of what I see as the event
attachment differences:
In NEXTSTEP, you can attach a Button to any "sender" method of any other
object. But the only Button message you can attach is its 'click', the
primary action of the Button. That's because the target->action paradigm
is hard-wired, non-extensibly, into InterfaceBuilder. This assumes, of
course, that you are using the standard classes. It is possible, with
some effort, to build custom IBConnectors for custom classes.
In Delphi, the Designer can only attach Button events to methods of the
Form on which the Button resides. This is a deficiency, and I acknowledged
that. HOWEVER, Delphi Buttons can send many events, not just clicks. In
Delphi, the Designer can attach all of the drag/drop, enter/exit, and
keypress events to custom methods. This part of Delphi's scheme is better
than NEXTSTEP, because multiple attachments are possible. The downside is
that they all point to the same, fixed responder.
For standard data entry forms, we have an AfsController object that points
to all the primary buttons, like 'New', 'Edit', 'Delete', etc. (It needs
those attachments primarily so it can enable/disable the buttons,
depending on edit state.) When the DFM file is loaded into memory, the
AfsController object checks to see if the OnClick events of these buttons
are attached to anything. If so, it assumes the programmer has something
special in mind. Otherwise, they are attached to the standard processing
methods of the controller. That is what I meant by automatic programmatic
attachment. We have to do the same thing in NEXTSTEP, where the validation
and field-help targets must be attached programmatically, since only one
target->action is assignable in IB.
> IMHO, using a form as a target is a past technology which started from
> 4GL and later used in VisualBasic, Powerbuilder and even Forte ... Too
> bad, Delphi could not get over this, even though it came out years later
> than NS. However, Smalltalk is similar to NS. This might be telling how
> a TRUE OO development environment should be like. :-)
My understanding is that Delphi is 'Form-centric' with respect to events,
because Windows itself is so window-centric about dispatching events.
That's not an excuse, just an observation. As to "TRUE" OOP environments,
clearly you can make any Delphi object send a message to any other
receptive Delphi object. You just can't use the Designer tool to do it.
Frankly, I can't think of any reason why you couldn't write a custom
component editor for Delphi to accomplish this. I've seen how the existing
event editor does its work, and the RTTI is certainly available to do it.
It shouldn't be hard to extend that functionality for any random receiver.
Steve Dekorte
> Gregory H. Anderson wrote:
>
> >Karl Harbour writes
> >> jon@heinlein (Jonathan Hendry) wrote:
> >> > Everyone who's written an app where all the functionality is
> >> > implemented in 'AppController.m' or such, raise your hand.
> >
> >> Maybe so, but at least it would be a controller object, and not a
> >> subclass of Window or View. All this example shows is that novices
> >> put too much functionality in one class, but at least a NextStep
> >> novice separates Controller logic from View logic right from the
> >> word go, and they don't do bizarre things like subclassing Window
> >> because it contains some Controls that the designer of the Window
> >> class didn't anticipate.
That's true. But I've also seen people write controller classes with 150
ivars and a 100 or so methods - they put the entire app within one or a few
massive controllers. Although this is mostly due to a lack of OO competence,
IB does make it difficult to write elegant OO apps as well. Most notably, there
major problems with making palettes which can, for example, lead to a tangled mess
of controllers for doing things like field validation, etc. Catagories can be used
as a hack around this problem, but that technique has severe limitations.
--
Steve Dekorte
NEXTSTEP/OPENSTEP consultant - Anaheim, CA
mailto:dek...@suite.com (NeXTmail, MIME welcome)
Karl Harbour
>Karl Harbour wrote:
>> And why did Garfinkel & Mahoney and the people who wrote the
>> NeXTDeveloper/Examples do it that way? Because of target/action and
>> the design of the AppKit generally separating UI from application
>> logic.
>
>This is definately not true. The target/action paradigm has done
>nothing to aid in separating out the application logic.
> Applications have several different types of process, presentation, application,
>and model to name the most common.
I haven't the faintest idea what this last sentence means. Are there
some words missing?
> The insertion of controllers into
>nib files where those controllers implement UI control logic and
>application logic is a "bad thing" IMHO. It makes it very difficult
>to deploy an application across presentation layer architectures..
>
Couldn't find "presentation layer architecture" in my buzzword
dictionary. What are you on about?
<-- snip -->
>Almost all
>of the subsystems you mention are really abstractions for system resources
>and are basicly consumable objects.
What?
> (printPSCode and faxPSCode are actually interface protocols)
Thanks for the quick lesson on the AppKit API. I always thought
printPSCode was a method in the View class.
> So, NeXT did a nice job wrapping their
>internally developed resources which is good. It is not clear what
>portion of the development time that these resources represent
What is not clear is what the hell you are on about.
Karl Harbour
>I'll let Greg speak for himself, but I feel a need to respond...
>
>Georg Tuparev wrote:
>>
>> In article <4h1viu$m...@shelob.afs.com> Greg_A...@afs.com (Gregory H. Anderson)
>> writes:
>> [...]
>> > As I said, I raised this point only to demonstrate that even NeXT, whose
>> > programmers I respect enormously, botched this first time out, and a lot
>> > of early programmers either learned a bad thing or spent too much time
>> > working around the deficiencies. Delphi at least got the DB part right,
>> [...]
>> At the time when DBKit was out, it was the coolest R/DB access framework around.
>> It's not a shame when other people write something better later. But it's a shame if
>> other people write _worse_ stuff later, and that is what is continually happening.
>> NS is already 8 years old, and even NS0.8 was better than most OO environments are
>> now.
>> And another point: if you are saying that it's very horrible to change/rewrite
>> sources you better work something else.
>
>
>The point (I think) was this: Mr. Harbour claimed that NeXTSTEP encourages good
>design.
>
>DBKit points out the fallacy in this:
Actually, it doesn't. If you encourage someone to do something, and
they don't do it, it may be because they were unwilling or unable to
do it. Failure on someone's behalf to do something is certainly not
proof that you didn't encourage them.
>NeXT themselves, with the advantage
>of having massive brain power, source code, and the designers of NeXTSTEP
>itself, STILL produced a piece of software which is widely recognized as
>a suboptimal design.
>
DBKit was a poor design, as Next themselves have admitted. But what
does DBKit have to do with the AppKit or any other part of NextStep?
It was designed from first principles, and, yes, Next got it wrong.
At a guess, I'd say DBKit and the AppKit were designed by different
teams in Next.
My point is that the design principles of the AppKit and EOF encourage
/ enable an application developer to create well-designed
applications. Perhaps enable is a better word.
<-- snip -->
Karl Harbour
>Wei Chen <wc...@webquill.com> writes
>> Gregory H. Anderson writes
>> >
>> > > The Delphi and NEXTSTEP form designers have different strengths
>> > > in the area of "event attachment," but both are deficient. In
>> > > NEXTSTEP, InterfaceBuilder allows any target, but can only assign
>> > > one action. In Delphi, the form designer can attach multiple
>> > > actions, but only one target (the form itself). You can work around
>> > > both deficiencies, but it requires programmatic runtime assignment.
>>
>> This is basically false. For example, Button in NS/OS can be assigned
>> to one out of ANY number of actions reponded by ANY number of targets,
>> while Dephi's button allows one and only one action to assign to a fixed
>> target viz. Form. I am curious to know in what systematic way your form
>> responds to multiple buttons on the form in your program in order to
>> make your code more reusable. I hope that you will not tell me that you
>> have a big case statement to achieve this.
>
>Heavens no. Here's a further clarification of what I see as the event
>attachment differences:
>
>In NEXTSTEP, you can attach a Button to any "sender" method of any other
>object. But the only Button message you can attach is its 'click', the
>primary action of the Button. That's because the target->action paradigm
>is hard-wired, non-extensibly, into InterfaceBuilder. This assumes, of
>course, that you are using the standard classes. It is possible, with
>some effort, to build custom IBConnectors for custom classes.
>
Surely an important point is that Delphi event handlers correspond to
two different paradigms in Nextstep, namely target/action and
delegation. Anything the Delphi event handlers can do can be handled
by one of these two paradigms as appropriate.
Granted, there are some classes in the AppKit which are missing
desirable delegate methods, but this is a minor problem for an
experienced developer.
As I'm sure you're aware, the OpenStep version of Interface Builder
allows any Control to be easily subclassed, so you'll be able to roll
your own delegate methods.
Nevertheless, I agree IB could be better in this area in some ways.
For example, double-click actions should be assignable in IB.
But the key thing for me is that workrounds to these limitations only
require a few lines of code.
Plus of course delegation gives you the unique "Can I do this?" /
denial functionality, which is absent from Delphi.
And NSNotificationCenter (available now) gives you "To whoever wants
to know, I did this...", which is also absent from Delphi.
Oh, and what's the equivalent of the Responder chain in Delphi?
<-- snip -->
William Grosso
tup...@mailserver.EMBL-Heidelberg.DE (Georg Tuparev) writes:
>
>Everybody has to take his own decision: Ferrari and heart attack
>or fun and Volkswagen-golf. I prefer the later ;-)
>
That's nice George, but hardly relevant to the issue at
hand (a quick reminder: it was OpenStep versus Delphi).
When you stay in the MCCA world (which is where this debate was
centered), I don't see the analogy at all. Custom apps are custom
apps; the choice of development environment doesn't suddenly
swing the pendulum from Golf/Fun to Ferrari/Heart-Attack.
But, when you leave MCCA-land, the story changes entirely.
Outside of MCCA land, Delphi has an enormous advantage over
OpenStep and holds far greater promise for the independent
developer (he who seeketh the Golf-Fun Happy Meal).
The argument:
I think Delphi (or Java), combined with the web, offer far
more opportunities for people to stop, enjoy themselves, and
still make a comfortable living.
How many copies of a shrink-wrapped app do you have to sell
via traditional channels to break even ? The web cuts that
number by at least an order of magnitude. It's a delivery channel
and an advertisement medium, all for the price of an ISDN connection
In the world of the future, we (the eccentric software architects
of the world) will be able to go after those niche markets that
intrigue us *and* still stay alive.
Our customers ? The Digitally-literate. People who can click
on Alta-Vista or WebCrawler and search on a relevant set of
keywords. Get 500 of them a month (in a web of 30 million +
<currently huge growth rate>) and you're *fine*. Word of mouth in
the niches.
The caveat: We have to be working in a good, productive development
environment (like OpenStep or Delphi) and we have to be working
on a "universal platform." I.e. people have to be able to run
our apps easily and without huge additional costs. This last
sentence is a big virtue of Delphi (to paraphrase the commercial:
"Windows, it's everywhere you want to be") and where Java holds
such huge promise.
Sample Java Dialogue:
Employee: Hey! Microsoft just changed the Windows API again.
Damn that Evil Monopoly (tm). Our app is crashing !!!!!!
Boss: Hey. Chill out. No problem. Netscape and SUN are porting
the app, even as we speak.
Where does OpenStep fit in this picture ? It just doesn't and it
just won't (unless there are major changes in the NeXT business
model).
Of course, while I'm waiting for the world of the future to
materialize, I'm still programming NEXTSTEP.
Cheers,
Andy
Gregory H. Anderson
> Greg_A...@afs.com (Gregory H. Anderson) wrote:
> > In NEXTSTEP, you can attach a Button to any "sender" method of any
> > other object. But the only Button message you can attach is its
> > 'click', the primary action of the Button. That's because the
> > target->action paradigm is hard-wired, non-extensibly, into
> > InterfaceBuilder. This assumes, of course, that you are using the
> > IBConnectors for custom classes
>
> Surely an important point is that Delphi event handlers correspond to
> two different paradigms in Nextstep, namely target/action and
> delegation. Anything the Delphi event handlers can do can be handled
> by one of these two paradigms as appropriate.
Buttons have delegates? Please explain how, WITHOUT SUBCLASSING, I can
get notified and then do something special about mouse in/out and drag
enter/exit events in NEXTSTEP buttons. I can in Delphi.
> Granted, there are some classes in the AppKit which are missing
> desirable delegate methods, but this is a minor problem for an
> experienced developer.
By which you mean, anyone willing to write a subclass, add a 'delegate'
ivar, create a delegate messaging protocol, and add default processing
methods for these events. Which is already done for you in Delphi.
> As I'm sure you're aware, the OpenStep version of Interface Builder
> allows any Control to be easily subclassed, so you'll be able to roll
> your own delegate methods.
I think this is easier said than done. But to each his own.
> Nevertheless, I agree IB could be better in this area in some ways.
> For example, double-click actions should be assignable in IB.
> But the key thing for me is that workrounds to these limitations
> only require a few lines of code.
Once you know what you're doing, have a firm sense of how NeXT does
things, and trial-and-error your way around brain damaged classes,
yes. I can do it. You can do it. But unless someone really knows what
they're doing as an object architect, I don't recommend it. I have
seen many poor examples of apparently simple override stuff.
> Plus of course delegation gives you the unique "Can I do this?" /
> denial functionality, which is absent from Delphi.
This is a lie. OnCloseQuery, OnChange, and all BeforeXxxx methods of
Tables -- just to name three that spring to mind -- provide exellent
structured exception handling (or Boolean function returns) to deny
continuation of a proposed operation.
> And NSNotificationCenter (available now) gives you "To whoever wants
> to know, I did this...", which is also absent from Delphi.
Yeah, it's a new class in FoundationKit. Our apps have had such a class
for _five_years_. If anyone in Delphi-land needs such a component, I'll
be happy to sell it to them. It's just not fair to compare the native
environments object-for-object. I can cite numerous counter-examples.
So what? They are not 100% orthogonal, nor do they need to be.
> Oh, and what's the equivalent of the Responder chain in Delphi?
There isn't one. Again, so what? This happens to be how NeXT implemented
a part of its control hierarchy. Explain how its absence cripples Delphi
in some way for MCCA apps, because I haven't missed it.
Richard Mazzaferri
I don't know anything about NeXTStep, but I know a bit about Delphi.
> Plus of course delegation gives you the unique "Can I do this?" /
> denial functionality, which is absent from Delphi.
I'm pretty sure that you can do (something like) this with Delphi, as in
"does this object have the given method?" using RTTI, but it may not be
very "clean" syntax. I don't know if you can check the procedure
parameters or not - haven't needed to do that.
> And NSNotificationCenter (available now) gives you "To whoever wants
> to know, I did this...", which is also absent from Delphi.
Don't you just need a list of object member function pointers to call to
perform notification? Very simple to do, or am I missing something?
Have fun,
Mazz.
ma...@faceng.newcastle.edu.au
Karl Harbour
>Karl Harbour writes
>> Greg_A...@afs.com (Gregory H. Anderson) wrote:
>> > In NEXTSTEP, you can attach a Button to any "sender" method of any
>> > other object. But the only Button message you can attach is its
>> > 'click', the primary action of the Button. That's because the
>> > target->action paradigm is hard-wired, non-extensibly, into
>> > InterfaceBuilder. This assumes, of course, that you are using the
>> > standard classes. It is possible, with some effort, to build custom.
>> > IBConnectors for custom classes
>>
>> Surely an important point is that Delphi event handlers correspond to
>> two different paradigms in Nextstep, namely target/action and
>> delegation. Anything the Delphi event handlers can do can be handled
>> by one of these two paradigms as appropriate.
>
>Buttons have delegates? Please explain how, WITHOUT SUBCLASSING, I can
>get notified and then do something special about mouse in/out and drag
>enter/exit events in NEXTSTEP buttons. I can in Delphi.
>
I agree that it's easier in Delphi, especially with buttons. I guess I
was trying to say the difference is less in the case of TForm vs
Window, since Window has a good set of delegate methods.
<-- snip --->
>> Plus of course delegation gives you the unique "Can I do this?" /
>> denial functionality, which is absent from Delphi.
>
>This is a lie. OnCloseQuery, OnChange, and all BeforeXxxx methods of
>Tables -- just to name three that spring to mind -- provide exellent
>structured exception handling (or Boolean function returns) to deny
>continuation of a proposed operation.
>
Well, a mistake actually, rather than a lie. I didn't look closely
enough at TForm's events. Sorry if I misled anyone.
<-- snip -->
Ben Moseley
Anderson) writes:
> Hugues RICHARD writes
> > In article <4h67pc$k...@reader2.ix.netcom.com>
> apul...@ix.netcom.com(William
> > Grosso) writes:
> > >
> > > Aujourd'hui, le programmation est morte...
> > ^^
> > la
>
> I spent a summer in Avignon, because you cannot graduate from the
> Georgetown University School of Foreign Service without demonstrating
> proficiency in a foreign language, and it was evident that only total
> immersion was going to get me to that point. Anyway, one day I walked
> into a boulangerie and made the mistake of asking for "un baguette".
> The proprietress brusqely responded "UNE baguette." At that moment, I
> understood why most Americans hate the French.
> --
> Gregory H. Anderson | "Honey, there're few programming
> Gaffer/Best Boy/Key Grip | problems that can't be solved
> Anderson Financial Systems | with duct tape." -- 'Father' Duke
> gr...@afs.com (NeXTmail OK) | (paraphrased), Doonesbury, 2/17/95
Hey Greg, let's get back to the point and cut out the racist remarks shall
we?
When you return to commenting on Delphi I'm sure we'll be more interested.
--Ben
Robert B. Love
> > The proprietress brusqely responded "UNE baguette." At that moment,
I
> > understood why most Americans hate the French.
> >
> > --
> > Gregory H. Anderson | "Honey, there're few programming
> Hey Greg, let's get back to the point and cut out the racist remarks
shall
> we?
The French are a race??? Lighten up.
I enjoyed learning a little about Mr. Anderson's background. How
he came to work in software must be an interesting story. I'm also
thankful for the comparison between Delphi & NS.
Besides, I'm sure the French have just as much fun laughing at us
as we do at them.
----------------------------------------------------------------
Bob Love, rl...@neosoft.com (local) MIME & NeXT Mail OK
rl...@raptor.rmnug.org (permanent) PGP key available
----------------------------------------------------------------
Allan S. MacKinnon, Jr.
Since we're all in a chest-thumping finger-pointing
nationalistic mood, I want to know which country
is responsible for those horrible 'MENTOS' candy
commericals!!!
My sources tell me that there is a connection
between the rise in MENTOS commericals and
NEXTSTEP 4.0's imminent release...
(I had to tie this post back to the newsgroup somehow!)
:)
ASM
In <4hvtse$s...@paladin.american.edu> Torrey McMahon wrote:
> In <4ho2ak$1...@xanadu.io.com> Terry Wilcox wrote:
> >
> > Imagine being a naive Canadian in Washington D.C. I felt safer in China,
> > surrounded by communists.
>
> I'm an American and _I_ don't feel safe in D.C. It goes with the territory.
>
> > And yes, I think the French are rude.
> >