koops@elf.rice.edu (Ryan Richard Koopmans) (04/11/91)
I recently purchased THINK C 4.0. When I looked at their object oriented implementation of the Mac interface, I was more than a little bit confused. I've written lots of Mac applications before, and I'm comfortable with the traditional procedural kind of Mac programming. What I want to know is, is OOP the wave of the future in programming or just a passing fad? Is it worth learning a new way of programming just to use the TCL? Maybe I'm just old fashioned, but I like the straight procedural way. In all the message passing and things, I feel that the programmer gets too far away from the machine and works on a too abstract level. What do you think? --------------------- koops@owlnet.rice.edu "Life is very short, and there's no time for fussing and fighting" -J.L & P.M.
kevinh@cmi.com (Kevin Hegg) (04/11/91)
Ryan Richard Koopmans writes > I recently purchased THINK C 4.0. When I looked at their > object oriented implementation of the Mac interface, I was > more than a little bit confused... Yes, I thought their class library and examples were cute, but they made some standard Mac code a lot more complicated and unreadable than it needs to be. I decided not to use their stuff anymore because I am not comfortable with the structure of their code and their non-standard OO language (not C++). I use MPW C and C++ solely now. > is OOP the wave of the future inprogramming or just a passing fad? Yes and no. I lump OOP in with structured programming, 4GLs, CASE, etc. They are all attempts to produce better software more efficiently. The unfortunate thing is that they all end up going through the "buzz-word" phase where all kinds of outlandish claims are made. OOP is in this phase now. It will pass out of this phase. It will not totally revolutionize the software industry. It will provide important contributions to the programming community. In summary, I am all for anything that will allow me to develop quality software in the most efficient manner. But no matter what new method comes around there is no substitute for well-documented, well-structured, readable, reuseable code. If the method distracts from this then there is less of a chance of me adopting it in my work. That's my 2 cents. Kevin Hegg, EDS Corp - Center for Machine Intelligence 2001 Commonwealth Blvd., Ann Arbor, Michigan 48105 Phone: (313) 995-0900 Internet: kevinh@cmi.com Applelink: D5990
Eric Wasserman (04/11/91)
In article <1991Apr10.210516.25812@rice.edu> koops@elf.rice.edu (Ryan Richard Koopmans) writes: >I recently purchased THINK C 4.0. When I looked at their >object oriented implementation of the Mac interface, I was >more than a little bit confused. I've written lots of Mac >applications before, and I'm comfortable with the traditional >procedural kind of Mac programming. > >What I want to know is, is OOP the wave of the future in >programming or just a passing fad? Is it worth learning >a new way of programming just to use the TCL? [...] I've been using the Think Class Libraries for several months now and I think that they are a great help in getting the user interface side of applications done quickly and well. If you like, you can leave it at that and do all the real work in essentially a procedural fashion (i.e. don't use objects to do whatever it is that goes on behind your user interface). I don't agree with the complaint that this is too abstract and takes you too far from the machine. Passing a message is really just calling a subroutine. The Think Class Libraries do put a layer between you and the machine but let's face it, the Mac's ROMs are a much bigger black box than the Class Libraries especially since you don't have the source for the former. The Think implementation of OOP is really not all that complicated. I recommend writing a dumb little program to convince yourself that you understand polymorphism and so on. On the other hand the Class Libraries have a pretty steep learning curve though its not anywhere near as bad as learning the Toolbox from scratch. The best thing to do is read the overview a couple of times (esp. the chain of command and visual hierarchy parts), browse the descriptions of the important classes (CApplication, CDirector, CDocument, CWindow, CPane, and the CPane subclasses you are interested in), make a copy of the starter project and start modifying it a little bit at a time. Don't get too bogged down trying to figure out the details (eg. the event loop in the CSwitchboard or the message dispatching--use the source debugger someday to see how this all works though). Everyone I know who's started using OOP and the TCL has first told me that its stupid and not worth the trouble. Then they've come back and said they've "seen the light" and would never go back. I think its well worth trying out for yourself. I for one use the TCL extensively and furthermore have made OOP an integral part of my non-interface programming as well. For me, OOP is largely a new way of looking at some problems. Not every problem is amenable to such a viewpoint but for those problems you can restrict the OOP component to the user interface. It is, of course, possible to go too far with OOP by trying to make everything into an object. For example, I've seen a commercial object- oriented plotting package which makes each data point into an object. One needs to avoid forcing the paradigm on every aspect of every problem. Give it a try. Good luck. Eric egw.weakm@p3.lanl.gov
mlanett@ncsa.uiuc.edu (Mark Lanett) (04/12/91)
In article <1991Apr10.210516.25812@rice.edu>, koops@elf.rice.edu (Ryan Richard Koopmans) writes: > I recently purchased THINK C 4.0. When I looked at their > object oriented implementation of the Mac interface, I was > more than a little bit confused. I've written lots of Mac > applications before, and I'm comfortable with the traditional > procedural kind of Mac programming. > > What I want to know is, is OOP the wave of the future in > programming or just a passing fad? Is it worth learning > a new way of programming just to use the TCL? > > Maybe I'm just old fashioned, but I like the straight procedural > way. In all the message passing and things, I feel that the > programmer gets too far away from the machine and works on a > too abstract level. I'm converting NCSA GelReader 1.2 to a MacApp version. The original is 20,000 lines of C. The MacApp version is 3000 lines and has most of the interface and functionality. It'll be done before 5000 lines. This reduction is almost entirely due to not having to deal with the interface because MacApp does it for me. Having used MacApp, writing 4 times as much code as necessary is ridiculous just to manage windows, mouse tracking and undo-able commands. I'm using their (Apple's) code to implement the interface and most of the code I write is actually adding functionality to my program, rather than teaching it how to auto-scroll. Furthermore, it's *very* easy to modify my program, which is not true of GelReader 1.2 or any other toolbox program. There are some definite disadvantages to MacApp (like it's obscenely long compile times and high compile-time memory requirements) but over time these hardware restrictions will go away. We will still need tools that make programming easier, however, and OOP is one of them. -- //----------------------------------------------------- Mark Lanett, mark-lanett@uiuc.edu NCSA, Software Tools Group, mlanett@ncsa.uiuc.edu
schorsch@oxy.edu (04/12/91)
In article <1991Apr10.210516.25812@rice.edu> koops@elf.rice.edu (Ryan Richard Koopmans) writes: >I recently purchased THINK C 4.0. When I looked at their >object oriented implementation of the Mac interface, I was >more than a little bit confused. I've written lots of Mac >applications before, and I'm comfortable with the traditional >procedural kind of Mac programming. > >What I want to know is, is OOP the wave of the future in >programming or just a passing fad? Is it worth learning >a new way of programming just to use the TCL? > >Maybe I'm just old fashioned, but I like the straight procedural >way. In all the message passing and things, I feel that the >programmer gets too far away from the machine and works on a >too abstract level. > >What do you think? > I also am wondering this. I have heard that OOP produces mush larger code (4 times or more!!) If this is so, since I am a perfectionist, I would prefer to spend the extra time using procedural techniques to write smaller, faster code than to save time and create a "clunky-slow" application. I can't help but to wonder if OOP and not increased funtionality is the cause of the huge size of many recent professional applications.(4-8 Meg for one app!?!?) What do people think? -Brent ! "He was strangely relieved about Brent Schorsch ! getting rid of his old fridge and schorsch@oxy.edu ! looked forward to enjoying a new phase ! of fridge ownership" -Douglas Adams
davoli@natinst.com (Russell Davoli) (04/12/91)
In article <712@gate.oxy.edu>, schorsch@oxy.edu writes: > I have heard that OOP produces mush larger code (4 times or more!!) > If this is so, since I am a perfectionist, I would prefer to spend the extra > time using procedural techniques to write smaller, faster code than to save > time and create a "clunky-slow" application. I can't help but to wonder if OOP > and not increased funtionality is the cause of the huge size of many recent > professional applications.(4-8 Meg for one app!?!?) > While I haven't seen very many 4-8 Meg application files, I agree that applications are steadily getting bigger as memory becomes more plentiful. However, I don't think OOP deserves the blame. It's not difficult to write bloated applications in C, Pascal, or any other language. I figure that program size reflects in large part the soundness of the program design, and possibly a bit of the competence of the programmers. I seem to remember hearing a while back that a word processor (FullWrite maybe?) had similar functionality to Word was 2 Meg (or required 2 Meg to run, I don't remember now.) That sounds to me like one was designed better than the other, and this was before OOP was the oat bran of computer programming. I've written a debugger for a plug-in processor board and I wouldn't do it without MacApp. MacApp does some much for me and doesn't really add too much bloat or slow things down too much. Currently the application file size is 236K and seems to have acceptable performance on a Mac II (the lowest end platform this program will run on.) Sure, I could have spent a few more months learning to write user-interface code, but I'd rather spend that doing other more productive things. Note that this is from a guy who mostly works on drivers. --Russell Disclaimer: These are my opinions and don't necessarily reflect those of my employer.
captkidd@athena.mit.edu (Ivan Cavero Belaunde) (04/13/91)
In article <1991Apr10.210516.25812@rice.edu> koops@elf.rice.edu (Ryan Richard Koopmans) writes: >What I want to know is, is OOP the wave of the future in >programming or just a passing fad? Is it worth learning >a new way of programming just to use the TCL? >Maybe I'm just old fashioned, but I like the straight procedural >way. In all the message passing and things, I feel that the >programmer gets too far away from the machine and works on a >too abstract level. Disclaimer: I'm heavily biased here, since I *do* believe that OOP is indeed the wave of the future, and I'll try to outline why. In one respect, OOP is familiarizing oneself with the class libraries supplied in order to take advantage of them. In this respect it is not too different from having to learn how the Toolbox works in order to program the Mac: there's all this code that's been written for you, and you need to learn the interfaces in order to be able to use it. Thus it is not very different from using non-OOP procedure libraries, such as a prewritten application shell. OOP, however, allows you to make use of these libraries in a much more transparent manner through the object and message-passing concepts. With said app shell, tou have to go in, modify the code, and recompile. With OOP you just pass messages to the various components of the app shell without having to recompile, say, your window object (I know I'm not explaining it very clearly, maybe someone can expound on this a bit more). And this leads to another big win with OOP. The functionality inherent in object oriented programming makes it a natural for *reusable* code, when properly written. App-specific procedural code generally needs to be modified, sometimes significantly, in order to be reused in a different application. This is because procedural code does not necessarily lead to thinking in a modular and abstract manner, where the caller does not need to (nor should it) know the internals of how a specific routine is doing its work (it's the same concept as the INTERFACE/IMPLEMENTATION dichotomy in pascal units, for example). In programming in an object-oriented language and in an object-oriented manner (you can still write procedural C in C++, for example. I'm saying these advantages happen when you take advantage of the object features in the language), the designing and building of objects carries with it implicitly the creation of a well-defined calling interface for this code, and it tends to isolate the outer routines from the nitty gritty of what the objects do and rely on the abstract ideas of what the object is supposed to do. Reusable code in this manner is a BIG win, because although it's a fairly significant effort at the beginning, it will shorted development time in future projects (possibly by a lot). Another reason for OOP being extremely useful comes from the following idea: OOP buys you ease and speed of programmind and development generally at the expense of program size and speed. Although that seems to be a drawback (and it can be in some situations), I submit that it is a big advantage: computers are getting more and more powerful and cheaper and cheaper all the time. The point is that MIPS will continue to get more and more plentiful, and *something* has to be done with them. There comes a point where, except for seriously mega-apps that crunch huge amounts of data, the additional MIPS are not going to do squat for you. Except for the fact that OOP coupled with the extra power can give you a huge benefit: much shorter development times for newer software and software updates, and consequently being able to find new uses and do more things with your machine in a lot less time (from the perspective of the user). BTW, the same thing can be said for storage. In this sense, OOP is the wave of the future because as MIPS get cheaper and cheaper it will make more and more sense to develop in objective languages and be willing to take the performance hit (which I don't think it's that big, but on the other hand I wouldn't want to program a low-level driver using TCL ;-), and since OOP leads to reusable code and has a fairly steep learning curve, using OOP now starts one's library of 'reusable objects' which will become more and more useful in the future and also permits one to climb the learning curve now and be fully up to speed when it is useful rather than starting to learn it when it's useful and be *seriously* behind. One last point: I don't believe that for application-software (stuff that's supposed to interact with the user and perform a useful task as opposedf to internal code like a low-level driver) you can really get "too abstract," and "too far away from the machine." Proper abstraction, defining the problem to be solved in abstract subproblems and the data manipulated in an abstract manner without regards to the internal representation of the data is IMHO a good thing (you people out there who have programmed in CLU know what I mean - Is there anybody out here that has programmed in CLU , BTW?). It tends to make for more reliable and easier-to-test software, and additionally can add a level of machine independence to the software in question (by reimplementing the low-level abstractions, the program could be easily ported, for example). It makes for code that is much cleaner and much easier to read and understand, in general, which is a big plus since we all know that if you go away for a month from a nontrivial piece of code that is not properly commented you'll be up the proverbial creek without the proverbial paddle when trying to come back to it, and debug or understand it. I however do not mean that highly optimized machine specific code (especially assembly) is bad, but that it has its place, and there are tradeoffs involved, and that the balance tilts over time to the easily written, easily reused, easily debugged and easily tested object- oriented code for most tasks, IMNSHO. Flames ignored, scholarly debate and discussion requested and appreciated. -Ivan Cavero Belaunde Visualist Digital Video Applications Corp. (DiVA) Internet: captkidd@ATHENA.MIT.EDU
brugge@fss.UUCP (John Brugge) (04/13/91)
In article <712@gate.oxy.edu> schorsch@oxy.edu writes: >In article <1991Apr10.210516.25812@rice.edu> koops@elf.rice.edu (Ryan Richard >Koopmans) writes: >>What I want to know is, is OOP the wave of the future in >>programming or just a passing fad? Is it worth learning >>a new way of programming just to use the TCL? >> >>Maybe I'm just old fashioned, but I like the straight procedural >>way. In all the message passing and things, I feel that the >>programmer gets too far away from the machine and works on a >>too abstract level. >> >>What do you think? >> For the solitary programmer working alone on a (relatively) small program for a specific machine where running lean and mean is the highest design priority, the benefits of OOP may be obscured. BUT, if you're developing a more complex system, with a number of programmers involved, and the system may still be living and growing when you're no longer around, then the paradigm (what a great word) of object-oriented development has some more tangible rewards: support for encapsulation and data abstraction, class libraries (e.g. TCL and MacApp on the Mac) that give you a head start and a foundation on which to build, and possibly even platform indepedence (e.g. Objectworks/Smalltalk that runs unaltered on Macs, Windows & X systems). In the current world, this doesn't come free, however; there's some overhead, in terms of code size and speed, but I'd like to think that that is less important (to a degree; nobody wants a dog program, but I often find that I'm the limiting speed factor in using a program, not the program). And personally, I'd just as soon be as far away from the machine as I can when programming - I'm awaiting the day when I can write a significant Mac program without having to know anything about A7, or whether my handles are locked or unlocked, etc. With the variety of applications being found for computers today and tomorrow, the premium will be on analysis, design and adaptability - ideas which an OO mindset encourages (although doesn't enforce). There's nothing magic about OOP, just another way of looking at the world that can give better insights and payoffs in certain situations. John Brugge
Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) (04/14/91)
schorsch@oxy.edu writes in a message to All
S> have heard that OOP produces mush larger code (4 times or more!!)
S> If this is so, since I am a perfectionist, I would prefer to
S> spend the extra time using procedural techniques to write smaller,
S> faster code than to save time and create a "clunky-slow" application.
S> I can't help but to wonder if OOP and not increased funtionality
S> is the cause of the huge size of many recent professional applications.(4-8
S> Meg for one app!?!?)
S> What do people think
I don't know where "4 times or more" comes from. The Think Pascal Starter program
is 48k; the TinyEdit program is 53k. The overhead of 48k gives one a complete
menuing, printing, windowing, saving, opening, closing, etc system. The TinyEdit,
for 5k more, gives one a complete TE text editing program with all of the above
features. MacApp's overhead is said to be about 75k and gives all of the above
with more available options then the TCL's. Turbo C++/Object Pascal gives one
a TCL/MacApp clone with the same features in about 100k.
Seems like a pretty good deal to me...
Lawson
--
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English
Internet: Lawson.English@p88.f15.n300.z1.fidonet.orgLawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) (04/16/91)
Kevin Hegg writes in a message to All
KH> Yes, I thought their class library and examples were cute, but
KH> they made some standard Mac code a lot more complicated and unreadable
KH> than it needs to be. I decided not to use their stuff anymore
KH> because I am not comfortable with the structure of their code
KH> and their non-standard OO language (not C++). I use MPW C and
KH> C++ solely now
??? Think C is just a port of Object Pascal to C. As Object Pascal has been
around for ever and ever (the Lisa had a prequel called Clascal, and O-Pascal
was a Nickie Wirth rewrite for Apple), I would call it pretty standard (at least
on a Mac!).
KH> In summary, I am all for anything that will allow me to develop
KH> quality software in the most efficient manner. But no matter
KH> what new method comes around there is no substitute for well-documented,
KH> well-structured, readable, reuseable code. If the method distracts
KH> from this then there is less of a chance of me adopting it in
KH> my work.
Readable, yes. Well-documented, yes. Well-structured? If you are using an OOP-language,
use OOA/D. Structured design and OOP do not fit well together. If you use one,
the other tends to, well, stink.
A good book on the subject is Object-Oriented Analysis, by Coad and Yourdin.
Lawson
--
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English
Internet: Lawson.English@p88.f15.n300.z1.fidonet.orgLawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) (04/16/91)
Ivan Cavero Belaunde writes in a message to All
ICB> Disclaimer: I'm heavily biased here, since I *do* believe that
ICB> OOP is indeed the wave of the future, and I'll try to outline
ICB> why.
I agree with you but with slightly different em-faces:
Reusable code as a reason to use OOP? Reusable code has been around for many
years. Libraries that allow the one to use them with only minimal modification?
(a variation of the above and still not THAT significant, convenient, but not
the most important facet of OOP).
Analysis and Design!
That is where OOP has a BIG advantage over Structured Programming. If you read
Coad and Yourdin, they make a point that I agree with completely (can you tell
that I am an OOP-freak?):
One can go from a preliminary analysis, to more and more detail, through the
design phase, the algorithm-writing phase, all the way to writing the actual
code, without ever changing one's paradigm--you never have to switch from thinking
in terms of the problem (manipulating objects) to the solution (manipulating
computer symbols) as the strategy never changes:
Object-Oriented programming Structured-programming
Analysis (objects) Analysis (objects)
Design (objects) Design (DFD's, flowcharts, etc)
Coding (objects) Coding (traditional sequences,)
(loops, etc)
This makes things much easier for both the programmer/analyst and the customer
to understand. I can describe my work-in-progress in terms that both she and
I use, and any changes that need to be done don't need translation into an arcane
intermediate code like DFD's, etc. Certainly the more complicated the problem,
the more obtuse the programmer's view of things, but it is a natural kind of
complexity, stemming from the programmer's need to have exact knowledge of what
is going on, and not simply a translation from English to computerese. If I
have need for detailed knowledge of the flow of data, of message-passing, etc,
I can still simplify things enough for the customer to understand without deceiving
her (or me) into thinking that we are talking about the same thing when we are
not.
When I tell my client (or she tells me) that whatsis needs to be done with widgets,
x times a day, my preliminary analysis, design, and code all reflect this in
a straight-forward manner, and no matter what level of detail I look at the
program from, from the customer's description, to the final code, I can still
see the same process going on, just in more detail.
Resusability of code and such using OOP is nice, but that's like looking at
one or two trees and missing the fact that you are in the middle of a vast and
wondrous forest.
OOP simplifies analysis, design and coding and makes them just more detailed
aspects of the same thing. That's its most important advantage.
Lawson
--
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English
Internet: Lawson.English@p88.f15.n300.z1.fidonet.orglsr@Apple.COM (Larry Rosenstein) (04/17/91)
In article <1991Apr10.210516.25812@rice.edu> koops@elf.rice.edu (Ryan Richard Koopmans) writes: > >What I want to know is, is OOP the wave of the future in >programming or just a passing fad? Is it worth learning >a new way of programming just to use the TCL? If you already have programmed the Macintosh, then using TCL/MacApp might seem like a waste of time, since you do have to fit your code into someone else's application framework. On the other hand, you do get the benefit of features that you might not have tackled yet. (I haven't looked at TCL, but I know that MacApp handles a lot of nitty-gritty details that I don't think many casual programmers take the time to worry about.) I also think OOP is the wave of the future. As one example, look at the new IAC facilities in System 7. First, implementing IAC in an application will be much easier using MacApp 3.0 than if you were trying to do it yourself. You will find that there are a lot of little details about when to call various routines that could/should be handled for you by an appropriate framework. Second, you should notice that the interfaces to these features (esp, AppleEvents) are strongly object-oriented even though they were done in a procedural manner. For example, an AppleEvent is much like an object (there are event classes of AppleEvents). The same thing applies to any graphical user interface (Windows, X, ...). Each of these environments is gaining new features (eg, Microsoft OLE), which makes it more difficult to write applications. >Maybe I'm just old fashioned, but I like the straight procedural >way. In all the message passing and things, I feel that the >programmer gets too far away from the machine and works on a >too abstract level. The problem is that unless you create some kind of abstractions, you will be unable to fully implement a satisfactory application. The ROM is already pretty far away from the machine, but most people don't try to implement their own graphics package, menus, etc. You can implement abstractions with a set of utility procedures, but the problem is that simple procedures can't be easily customized. You can vary parameters to a call, but you can't modify what goes on inside a procedure. With OOP, you can override one method in a class an change a small aspect of its behavior. To respond to some other comments: There is a perception that OOP programs are big and slow. I think this is a myth. There are many MacApp-based programs on the market, which I think demonstrate otherwise. MacApp's code makes up a small fraction of a typical program. This perception comes from: (1) people looking at a MacApp program with debugging code compiled in (which adds 50-100K and slows the program by a factor of 2+) or (2) people comparing a MacApp program with one with less functionality (MacApp's simple text editor vs. TeachText). (I think the reason that applications are getting bigger and bigger is that developers feel the need to add more and more features. Part of the reason is to distinguish their program. Part of the reason is that reviewers seem to give more weight to features, so a program that does one thing really well loses out to one that does many things less well.) A method call in MPW Object Pascal takes no more space than a regular procedure call. Also, we implemented an optimization scheme in which the time overhead for calling a method id proportional to the number of times it is overridden. If you don't override a method (the most common case in a framework like MacApp) then calling that method is exactly the same as a normal procedure call. In straight C++ (ie not using Object Pascal-compatible classes) method calls take more space, but less time. (The time to call a method is constant, and not much more than a regular procedure call.) There will be some space and time overhead for using an application framework, due to the fact that one can more tightly code a specific application, than a general framework. But the OOP application will be easier to extend and maintain. -- Larry Rosenstein, Apple Computer, Inc. lsr@apple.com (or AppleLink: Rosenstein1)
emuroga@cbnewse.att.com (eisuke.muroga) (04/18/91)
In article <14@fss.UUCP> brugge@fss.Ems.MN.ORG (John Brugge) writes: >In article <712@gate.oxy.edu> schorsch@oxy.edu writes: >>In article <1991Apr10.210516.25812@rice.edu> koops@elf.rice.edu (Ryan Richard >>Koopmans) writes: >>>What I want to know is, is OOP the wave of the future in >>>programming or just a passing fad? Is it worth learning >>>a new way of programming just to use the TCL? >>> >>>Maybe I'm just old fashioned, but I like the straight procedural >>>way. In all the message passing and things, I feel that the >>>programmer gets too far away from the machine and works on a >>>too abstract level. >>> >>>What do you think? >>> > >For the solitary programmer working alone on a (relatively) small program >for a specific machine where running lean and mean is the highest design >priority, the benefits of OOP may be obscured. > >BUT, if you're developing a more complex system, with a number of programmers >involved, and the system may still be living and growing when you're no longer >around, then the paradigm (what a great word) of object-oriented development >has some more tangible rewards: support for encapsulation and data abstraction, >class libraries (e.g. TCL and MacApp on the Mac) that give you a head start >and a foundation on which to build, and possibly even platform indepedence >(e.g. Objectworks/Smalltalk that runs unaltered on Macs, Windows & X systems). > >In the current world, this doesn't come free, however; there's some overhead, >in terms of code size and speed, but I'd like to think that that is less >important (to a degree; nobody wants a dog program, but I often find that I'm >the limiting speed factor in using a program, not the program). And personally, >I'd just as soon be as far away from the machine as I can when programming - >I'm awaiting the day when I can write a significant Mac program without having >to know anything about A7, or whether my handles are locked or unlocked, etc. > >With the variety of applications being found for computers today and tomorrow, >the premium will be on analysis, design and adaptability - ideas which an OO >mindset encourages (although doesn't enforce). There's nothing magic about OOP, >just another way of looking at the world that can give better insights and >payoffs in certain situations. > >John Brugge > > In addition, I believe oop requires better design at the outset. It's hard (and can really kill you) to start writing code on the fly. A bad design can be more difficult to maintain than procedural code, so oop doesn't necessarily mean the code will be easier to maintain. Eisuke Muroga
lsr@Apple.COM (Larry Rosenstein) (04/19/91)
In article <1991Apr17.231641.7125@cbnewse.att.com> emuroga@cbnewse.att.com (eisuke.muroga) writes: > >In addition, I believe oop requires better design at the outset. It's hard >(and can really kill you) to start writing code on the fly. A bad design >can be more difficult to maintain than procedural code, so oop doesn't >necessarily mean the code will be easier to maintain. This is somewhat of a theoretical argument, because I think it is possible to do a good procedural design as easily as a bad OO design. In general, however, I disagree. If you're talking about a bad OO design then what often happens is that one class is too large (and should be broken up) or several classes could share behavior (and the class hierarchy should be rearranged). In either case, you clients of the classes should be isolated from their implementations, so changes to the class hierarchy should be relatively minor. A poor OO implementation would be one where clients are not isolated from the implementation. In that case, small changes to a class can cause problems. In both procedural and OO programming, you can't expect to write a large program on the fly. If you start an OO design by thinking about the fundamental objects in your program, then you will generally be on the right track. -- Larry Rosenstein, Apple Computer, Inc. lsr@apple.com (or AppleLink: Rosenstein1)
Louis.Pecora@f421.n109.z1.Fidonet.Org (Louis Pecora) (04/19/91)
> is OOP the wave of the future in programming or just a passing fad?
Ivan Belaunde gave a good long answer to this. I'll give a short one,
from a completely different (pragmatic) angle based on my own
experience: Try it, you'll like it, and you won't want to go back!
--- Lou Pecora
* Origin: Twilight Clone: Macintosh Files - 301-946-8677 (1:109/421)keith@Apple.COM (Keith Rollin) (04/21/91)
In article <7822.280F0E44@stjhmc.fidonet.org> Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) writes: >Kevin Hegg writes in a message to All > >KH> Yes, I thought their class library and examples were cute, but >KH> they made some standard Mac code a lot more complicated and unreadable >KH> than it needs to be. I decided not to use their stuff anymore >KH> because I am not comfortable with the structure of their code >KH> and their non-standard OO language (not C++). I use MPW C and >KH> C++ solely now > >??? Think C is just a port of Object Pascal to C. As Object Pascal has been >around for ever and ever (the Lisa had a prequel called Clascal, and O-Pascal >was a Nickie Wirth rewrite for Apple), I would call it pretty standard (at least >on a Mac!). More than that, too, I think. I heard that MicroSoft has a Pascal that uses the same OO extensions and method dispatching mechanisms that Apple does. Also note that Grady Booch makes extensive reference to Object Pascal in his definitive work "Object-Oriented Design with Applications." By the way, Object Pascal isn't just something Wirth whipped up for Apple. Object Pascal was the work of several people at Apple. I think that Wirth was "just" a consultant. -- ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "But where the senses fail us, reason must step in." - Galileo
tim@hoptoad.uucp (Tim Maroney) (04/22/91)
In article <1991Apr10.210516.25812@rice.edu> koops@elf.rice.edu (Ryan Richard Koopmans) writes: >>What I want to know is, is OOP the wave of the future in >>programming or just a passing fad? Is it worth learning >>a new way of programming just to use the TCL? In article <51593@apple.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >If you already have programmed the Macintosh, then using TCL/MacApp might >seem like a waste of time, since you do have to fit your code into someone >else's application framework. On the other hand, you do get the benefit of >features that you might not have tackled yet. (I haven't looked at TCL, but >I know that MacApp handles a lot of nitty-gritty details that I don't think >many casual programmers take the time to worry about.) On the other hand, it's awfully slow to keep up with both Apple's Human Interface Guidelines (see pop-up menus, for instance) and the features that people have been using in real commercial applications for years: features like floating windows, document-window menu bars, keyboard-walked menus, and so forth. It doesn't even support a basic feature like enabling and disabling of dialog buttons depending on whether there a selection in a list or text in an editable box, which is Mac 101 stuff. (The team seemed quite surprised when I mentioned this as a use for the TDialogView class in Phoenix!) It can also serve as a straightjacket if your application doesn't fit MacApp's assumptions. I had to change TApplication.SetupTheMenus the other day to make Undo enable at the appropriate times in Cachet, because we have a single working document and an arbitrary number of read-only reference documents, and it's necessary to allow changes on a non-frontmost document under that model. Then there are maintenance issues. When you wind up straightjacketed, there are two things you can do to escape. One is to change the source. This presents major problems when there's a new release. The other is to copy and edit large methods and make the edited versions your overrides. This presents exactly the same problem with new releases -- the edited copy has to be brought into line with the new version. This is what we had to do to handle the basic problem of dialog button enabling and disabling -- we made a new class of dialogs with an overridden PoseModally method, consisting of the default method plus one line of code. We've had to do this a number of places, and I am not looking forward to the upgrade to 3.0. MacApp is barely flexible enough for any sort of real commercial programming, and almost surely too inflexible for anything really innovative like HyperCard. A while ago, Keith said that no one who had used MacApp would ever go back to another way of programming. After a year of using MacApp, I would certainly consider starting my next application from scratch instead. >I also think OOP is the wave of the future. As one example, look at the new >IAC facilities in System 7. First, implementing IAC in an application will >be much easier using MacApp 3.0 than if you were trying to do it yourself. >You will find that there are a lot of little details about when to call >various routines that could/should be handled for you by an appropriate >framework. Which simply says that the low-level interface wasn't designed very well, and the MacApp team has managed to do better (they think). This doesn't say anything at all about object-oriented programming's benefits. >Second, you should notice that the interfaces to these features (esp, >AppleEvents) are strongly object-oriented even though they were done in a >procedural manner. For example, an AppleEvent is much like an object (there >are event classes of AppleEvents). Well then, given the virtues of OOP, you shouldn't need MacApp to make the system easy to use, should you? I'm sold on object-oriented programming, but the above are frivolous arguments. >You can implement abstractions with a set of utility procedures, but the >problem is that simple procedures can't be easily customized. You can vary >parameters to a call, but you can't modify what goes on inside a procedure. >With OOP, you can override one method in a class an change a small aspect of >its behavior. That is, provided that there is some small method which is perfectly placed to let you make just the change that you want. This is rarely the case. Far more often, you're faced with the change-source/copy-and-edit choice described above, which is no better than any other kind of source code library. Furthermore, it's almost always necessary to familiarize yourself with the internal details of the class you are modifying and most of its superclasses in order to make any nontrivial change. Just figuring out where to place an override can be quite demanding. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Do what you wanna, do what you will; Just don't mess up your neighbor's thrill. And when you pay the bill, kindly leave a little tip To help the next poor sucker on his one-way trip." - Frank Zappa, "You Are What You Is"
macman@wpi.WPI.EDU (Chris Silverberg) (04/22/91)
In an article tim@hoptoad.UUCP (Tim Maroney) rambles: >MacApp is barely flexible enough for any sort of real commercial >programming, and almost surely too inflexible for anything really >innovative like HyperCard. I find this a little hard to believe considering that a number of commercial products are already based on MacApp, most notably Adobe PhotoShop which has an excellent implementation... and I hear they already have a new version in beta test. I am under the impression that the developers have been very happy with MacApp thus far. - Chris =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Chris Silverberg INTERNET: macman@wpi.wpi.edu Worcester Polytechnic Institute Main Street USA 508-832-7725 (sysop) America Online: TfChris WMUG BBS 508-832-5844 (sysop)
kevinh@cmi.com (Kevin Hegg) (04/22/91)
Lawson.English writes > KH> Yes, I thought their class library and examples were cute, but > KH> they made some standard Mac code a lot more complicated and > KH> unreadable than it needs to be. I decided not to use their stuff > KH> anymore because I am not comfortable with the structure of their code > KH> and their non-standard OO language (not C++). I use MPW C and > KH> C++ solely now > > ??? Think C is just a port of Object Pascal to C. As Object Pascal has > been around for ever and ever (the Lisa had a prequel called Clascal, > and O-Pascal was a Nickie Wirth rewrite for Apple), I would call it pretty > standard (at least on a Mac!). I do not want to get into a language war. I think everyone should use whatever language they are most comfortable and productive with. However, my interests and work extend to more than the Mac. I have found C/C++ to provide me with the most flexibility when trying to move code from one computer to another. If I only lived on the Mac then I might have chosen a different language. > Readable, yes. Well-documented, yes. Well-structured? If you are using > an OOP-language, use OOA/D. Structured design and OOP do not fit well > together. If you use one, the other tends to, well, stink. When I said "well-structured" I wasn't referring to using the old structured design methods. However, over the last 20 years a lot has been learned about how to structure code for reusability and maintainability. Not everything was bad with the "old" way of programming and not everything is good with OOP. I have never found one design method to be totally suitable. I try to use the best features of each method. Kevin Hegg, EDS Corp - Center for Machine Intelligence 2001 Commonwealth Blvd., Ann Arbor, Michigan 48105 Phone: (313) 995-0900 Internet: kevinh@cmi.com Applelink: D5990
peirce@outpost.UUCP (Michael Peirce) (04/23/91)
In article <17229@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes: > A while ago, Keith said that no one who had > used MacApp would ever go back to another way of programming. After a > year of using MacApp, I would certainly consider starting my next > application from scratch instead. After working around a number of people using MacApp, I've reached one conclusion: some people love it, others hate it. This isn't really a big surprise since MacApp embodies a certain approach to programming the Mac and this jives with some people's view and not with others. You will do much better with MacApp if you "go with the flow." I knew one programmer who just didn't like the way MacApp did things - it wasn't his way. He fought it every step of the way and the results were pretty sad. It's not that he was a poor programmer - far from it - he just didn't catch on to the MacApp way. Personally, I love MacApp. It provides me a very rich environment for building my products. It lets me leverage all the knowledge about the Mac environment built into MacApp (check out how MacApp handles file saving sometime :-) But then it fits in quite well with my approach to programming. I don't push MacApp to do things it doesn't "want to do," but rather I build upon it and let it handle its things its way. My guess is that if you're one of those people who always though that they could have built the Mac better than Apple did and are always working around the standard behaviors, you may not like MacApp. -- michael -- Michael Peirce -- outpost!peirce@claris.com -- Peirce Software -- Suite 301, 719 Hibiscus Place -- Macintosh Programming -- San Jose, California 95117 -- & Consulting -- (408) 244-6554, AppleLink: PEIRCE
lsr@Apple.COM (Larry Rosenstein) (04/23/91)
In article <17229@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: > >On the other hand, it's awfully slow to keep up with both Apple's Human >Interface Guidelines (see pop-up menus, for instance) and the features You'r probably right about this. >that people have been using in real commercial applications for years: >features like floating windows, document-window menu bars, >keyboard-walked menus, and so forth. It doesn't even support a basic Since MacApp is used as the basis of many applications, the MacApp engineers have an extra responsibility to make sure that MacApp will be compatible with various system releases. In general, this means sticking to features that are supported in the system. >feature like enabling and disabling of dialog buttons depending on >whether there a selection in a list or text in an editable box, which What's the problem exactly. Can't you disable a button if you choose? Your comments about undo in non-frontmost documents probably should be changed. >MacApp is barely flexible enough for any sort of real commercial >programming, and almost surely too inflexible for anything really >innovative like HyperCard. A while ago, Keith said that no one who had Tell that to the companies shipping products based on MacApp. >>IAC facilities in System 7. First, implementing IAC in an application will >>be much easier using MacApp 3.0 than if you were trying to do it yourself. >Which simply says that the low-level interface wasn't designed very well, >and the MacApp team has managed to do better (they think). This doesn't An OO approach allows you to implement a framework, so that the system can take care of the standard behavior. A feature like Publish/Subscribe is going to require some (mostly) standard code as well as application-specific code, regardless of how you design the interface. In that case, the OO approach is going to work better than writing the common code over and over. >>procedural manner. For example, an AppleEvent is much like an object (there >>are event classes of AppleEvents). > >Well then, given the virtues of OOP, you shouldn't need MacApp to make >the system easy to use, should you? Right. If the system has an OO interface, then you wouldn't need a "wrapper" like MacApp. >I'm sold on object-oriented programming, but the above are frivolous >arguments. In what way? >That is, provided that there is some small method which is perfectly >placed to let you make just the change that you want. This is rarely >the case. Far more often, you're faced with the change-source/copy-and-edit Then the library is designed wrong. Designing a reusable framework is very hard, and MacApp has many reusability problems, which get fixed over time. In most cases, the methods are placed properly and the framework works. >Furthermore, it's almost always necessary to familiarize yourself with >the internal details of the class you are modifying and most of its Then the documentation needs to be improved. There's no question that MacApp has flaws, but most people who use it find that it saves them time and works very well. -- Larry Rosenstein, Apple Computer, Inc. lsr@apple.com (or AppleLink: Rosenstein1)
gtall@ogre.cica.indiana.edu (Gerry Allwein) (04/23/91)
I've been following the OO-debate and being a heavy MacApp user, I do have a question with respect to what is supported and what isn't. Floating windows are on top of my list for Fun Things To Have What Apple Won't Support. Even HyperCard has floating windows built into it now because they work well within the Interface guidelines and are particularly useful. Will MacApp 3.0 support floating windows? And if not, what does it take to get the MacApp engineers to recognize a feature of Mac programs as something standard enough to be supported? I don't buy the criticism that since MacApp doesn't support a lot of things, it isn't useful. You simply have to work a little harder to get some things. But this is one I don't feel I should have to work hard to get. Gerry
hallkd@mentor.cc.purdue.edu (KBOK) (04/23/91)
Sometimes I look at my THINK C code and wonder why I am doing this at all. Sometimes I Find myself lost in the maze of a contorted OOP hierarchy. Sometimes I am convinced Pascal is a crippled inflexible gibberish. but.... Then I remember it could be worse. It could be FORTRAN. It could be COBOL. Before undertaking the task of exulting the best language, remember the COULD-BEs. ....and, smile :-) ---------------------------------------------- ----------------------- | Kurt Hall (KBOK,The Human 'Tater Tot ) | KBOK International | | hallkd@mentor.cc.purdue.edu | "Now I Know" | ---------------------------------------------- -----------------------
lim@iris.ucdavis.edu (Lloyd Lim) (04/23/91)
In article <17229@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >[...] >Then there are maintenance issues. When you wind up straightjacketed, >there are two things you can do to escape. One is to change the source. >This presents major problems when there's a new release. The other is to >copy and edit large methods and make the edited versions your overrides. >This presents exactly the same problem with new releases -- the edited >copy has to be brought into line with the new version. [...] I agree. I ran into similar problems when trying to change some things with TCL. OOP is supposed to be easy to maintain but you often end up having to know too much about the internals of classes. >[...] A while ago, Keith said that no one who had >used MacApp would ever go back to another way of programming. [...] Well, the CAD program Dreams from IDD started out as a MacApp program but ended up as a straight THINK C program. The code still looks more OO than normal though. I believe they gave up on MacApp because of speed problems (which I think were design problems mainly) and because they ended up overriding tons of methods anyway (it has floating palettes and other stuff). +++ Lloyd Lim Internet: lim@iris.eecs.ucdavis.edu America Online: LimUnltd Compuserve: 72647,660 US Mail: 215 Lysle Leach Hall, U.C. Davis, Davis, CA 95616
davoli@natinst.com (Russell Davoli) (04/23/91)
In article <1991Apr22.191744.16196@cica.indiana.edu>, gtall@ogre.cica.indiana.edu (Gerry Allwein) writes: > I've been following the OO-debate and being a heavy MacApp user, I do have a > question with respect to what is supported and what isn't. Floating windows > are on top of my list for Fun Things To Have What Apple Won't Support. Even > HyperCard has floating windows built into it now because they work well within > the Interface guidelines and are particularly useful. Will MacApp 3.0 > support floating windows? And if not, what does it take to get the MacApp > engineers to recognize a feature of Mac programs as something standard enough > to be supported? I don't buy the criticism that since MacApp doesn't support > a lot of things, it isn't useful. You simply have to work a little harder to > get some things. But this is one I don't feel I should have to work hard to > get. > I don't think anyone should assume that the MacApp team doesn't think floating windows are useful just because such windows aren't implemented in the current version of MacApp (I last used v. 2.0). If memory serves, I believe there was an unused "fFloating" field in the TWindow class, which leads me to suspect that MacApp will someday offer floating windows, too. It's been a while since I've looked at the MacApp stuff (I spend most of my time writing drivers) so I welcome corrections. --Russell
ksand@Apple.COM (Kent Sandvik) (04/24/91)
In article <1991Apr22.191744.16196@cica.indiana.edu> gtall@ogre.cica.indiana.edu (Gerry Allwein) writes: >I've been following the OO-debate and being a heavy MacApp user, I do have a >question with respect to what is supported and what isn't. Floating windows >are on top of my list for Fun Things To Have What Apple Won't Support. Even >HyperCard has floating windows built into it now because they work well within >the Interface guidelines and are particularly useful. Will MacApp 3.0 >support floating windows? Yes, MacApp 3.0 will have support for floating windows. There are some experimental-and-unsupported code for floating windows in MacApp 2.0(.1). If my memory is not zapped I think that Macintosh Common Lisp 2.0 also supports floating windows. Kent Sandvik, MacDTS -- Disclaimer: Private and personal activities on USENET, non-company sponsored
michael@otago.ac.nz (04/29/91)
In article <0B010004.difjcc3@outpost.UUCP>, peirce@outpost.UUCP (Michael Peirce) writes: > > You will do much better with MacApp if you "go with the flow." I As someone who has been trying to use MacApp on and off for over a year I would have to agree but comment on the sometimes extreme difficulty of discovering where the flow is going. My main problem is that the documentation is just inadequate when I want to find the answer to a given question, and I usually can't even figure out whether or not the question is inappropriate. What I really need is a guide to each object type which would describe its fields and methods and *what they are intended to do*. This is what is so often missing from the present documentation and frequently forces me to read the MacApp source. This should not be necessary. Then there are other things that just aren't there; try finding a description of how to segment your application in the 2.0.1 documentation... If it weren't for the fact that I have become convinced that I never want to write a conventional application again I would drop MacApp, but its just so good at what it does that I can't... Michael(tm) Hamel, Computing Services Centre, University of Otago, New Zealand RICHMOND (adj.) Descriptive of the state that very respectable elderly ladies get into if they have a little too much sherry, which, as everyone knows, does not make you drunk.
ksand@Apple.COM (Kent Sandvik) (04/29/91)
In article <1991Apr29.092809.323@otago.ac.nz> michael@otago.ac.nz writes: >My main problem is that the documentation is just inadequate when I want to >find the answer to a given question, and I usually can't even figure out >whether or not the question is inappropriate. What I really need is a guide to >each object type which would describe its fields and methods and *what they are >intended to do*. This is what is so often missing from the present >documentation and frequently forces me to read the MacApp source. This should >not be necessary. Then there are other things that just aren't there; try >finding a description of how to segment your application in the 2.0.1 >documentation... True, this is a valid comment. MacBrowse (or 'Mouser does-something' for us initiates) is one way to establish relationship information between classes. For instance the function of flattening classes, i.e. find out all the instances where a certain method is called, is very useful. The combination of MacBrowse and 411 (inside MacBrowse) will help to a certain degree the problem with finding relationships in large object frameworks. I once answered a DTS question about how to name segments with MacApp code, it will become one of the standard answers in our DTS Q&A stack (if it's not there already). If I find it somewhere on my hard disk I will post it, but true, stuff like this should be better documented. The DTS Q&A stack, as well as the new Developer Tech Support Library on AppleLink is one way to fill in the gaps in the common documentation. Tech Notes that we produce is also one way to provide additional information. We have a couple of tech notes about MacApp - I will look into the issue how to streamline the tech notes and maybe provide a better framework for MacApp tech notes in future (instead of having x amount tech notes to check every time). Regards, Kent Sandvik, DTS -- Disclaimer: Private and personal activities on USENET, non-company sponsored