🚀 go-pugleaf

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.

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.

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.

Philippe Kahn was ranting, a few years ago, about doing Turbo-Cobol, and how it  
would be the most significant language project ever on the PC.  Well, he might  
be right, but let's hope it doesn't happen.

However, something is missing in the middle.  I don't propose using Cobol, but  
to follow the Smalltalk Model-View-Controller (not the inaccurate  
interpretation of MVC that you can hear about at NeXT school) I suggest that  
the missing piece on the NeXT would be a data-definition tool, maybe called  
ModelBuilder, used to define data sets from predefined and easily extended  
classes of intelligent data model objects.  It should tie in to IB, but with a  
much more flexible connection scheme than hard-coded explicit "outlets."

I wonder (in ignorance) if this middle piece isn't what people are hoping to  
address using object-oriented databases.  I saw an help-wanted ad for one oodb  
company asking for people who knew Smalltalk.  I'd like the MVC out of this  
stuff, but not Smalltalk itself.  If that's the API, I'll check back on that  
idea in about 4 years.

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?

	jim

PS: as an interesting contrast, PenPoint from GO Corp has an MVC slant, with  
every object supporting an "observer list."  This is pretty great, and has many  
uses in an operating system (you observe a file-system directory to learn if  
its contents changes, you observe Preferences for changes, and so on).   
Unfortunately, although they might have recognized that the GUI isn't the  
center of the world, they provided no tools to work the GUI, Models, or  
anything else.

-- 
Jim Mackraz
jim@oceania.com