🚀 go-pugleaf

In article <Bw4G4y.7B4@oceania.com> jim (Jim Mackraz) writes:
> Robert D. Nicholson writes
> > Does NeXT's Interface Builder impose a rigid design on applications?
> > 
> > If it does is this a good thing or a bad thing?

>  It strongly imposes a particular "GUI-centric" philosophy
>  to the architecture of the application.  While I believe
>  that taking a "user-centric" approach to software design
>  is good, making the application revolve around the GUI
>  architecturally is bad, in my opinion.

I fail to see how IB makes an app "revolve" around the GUI. If anything,  
it de-emphasises the GUI; it makes it very easy to slap a user interface  
onto an existing structure, and sets things up so that the placement and  
coordination of UI objects is no longer foremost in your mind. Anyone who  
makes an app "revolve" around a GUI is in for a big surprise down the  
road... having done about as much NeXT programming as Mac programming, I  
can say that it is much easier to separate the GUI from the app with  
NeXTSTEP. Of couse, you can couple them as closely as you want...

>  For example, if you want to deal with dates, and you want
>  your software to know that February has at most 29 days,
>  and only some of the time, the NeXT-IB approach would
>  have you create a nifty date-widget complete with data
>  validation, and stick that boy on a palette for
>  redistribution, presumably to people who make demos and
>  little else.

Huh? I've never made a loadable palette in my life. But I'd probably make  
some sort of reusable module to deal with dates, if I thought I'd be using  
it again. This isn't IB, it's just sensible.

>  There's an interesting article in a recent Computerworld
>  about "Why PC programming stinks" and it applies equally
>  to NeXT.  To paraphrase the article, a "serious"
>  application has three parts: the GUI, the database, and
>  between them, the "business rules."  For this last, I
>  prefer a Smalltalky term, "intelligent data models."
>  
>  Interestingly, the article points out that this middle
>  piece is handled in "traditional mainframe" development
>  by Cobol.  Tools which support this include 4GLs and CASE
>  tools which emit, you guessed it, Cobol. The article
>  points out that on PCs (and NeXT) software tools revolve
>  around the GUI only.

It is true that most tools revolve around the GUI, simply because it is a  
relatively simple domain to make tools for, and it is very painful to do  
it well by hand. The cost/benefit ratio is the highest in this domain.

It sounds to me, though, that your impression of a "serious application"  
is rather limited.


>  Remember, the GUI isn't always around when you happen to
>  be processing data.  You going to fire up the GUI to see
>  if a date or other piece of information you are importing
>  is valid?

Are you going to fire up the oven to take the dog for a walk? What would  
compel you to do so? I fail to see the connection.

-Anthony