rcopm@koel.rmit.OZ.AU (Paul Menon) (06/21/87)
In article <8706180728.AA10707@ucbvax.Berkeley.EDU>, lcc.bill@CS.UCLA.EDU ("William J. Fulco") writes: > I saw a really nice system, (I mean REALLY nice - with good color support) > from Xerox PARC marketing spinoff at the 1986 AAAI show. It was running > on a Sun 3/260 and it really sizzles..... I can believe that, I was introduced to the 3/260 just recently. It would make anything sprout wings. The reason for my addition has a little to do with suns, Smalltalk, and technology in general, so please bear with me. This is long. I have just completed some sizable programs (well, to me they were), and am in the "recovery stage", ie sizing up what I have done... was it all worth while etc, etc. I have reached a few (frustrating) conclusions/opinions... * If I leave these programs for a while, and then come back to change them in the name of maintenance or further enhancement, I am not too much better off than someone who has never seen the package before. I don't mean that in the positive sense, nor would I have forgotten the techniques I used; it is the dependence of data being spread all over the program. It was written in Pascal. How many of you decide to change a data structure halfway through a program, not because of bad planning in the first place, but because a "new" and more efficient technique requires extra "bits" embedded into a data structure. Does "grep 'structtype' *.h *.p" ring a bell? Not even then am I too sure if everything is covered, especially if it belongs to an overall complex data structure with crosslinks. No amount of documentation or cross-references will relieve the manual task ahead. Good programming style can minimize this only to a certain extent. C, Algol, Modula 2, perhaps even Ada suffers from this. * If I want to re-use techniques in another program, major surgery is required. Some call this hacking. It's only ok if the same types are being used by the new program. There is static binding available from Ada, if you wish to learn such a complex language. But none of the "standard languages" allow complete type independence. Lisp and Prolog programs will suffer the same scalpel treatment as the others. If you haven't already guessed where I am heading, object-oriented programming languages will (in my opinion) relieve me of these woes. Ok says I, which one do I use? There is the Grand-Daddy, Smalltalk-80; the pure one. Then there are the nouveau hybrids C++, Objective-C and MacApp. Others come in different Flavors, Loops or feathered Flamingos and Owls. Lisp and Prolog do not satisfy my requirements because I cannot easily "build" on previous applications experience. I don't hold the generally dismal performance of Smalltalk aginst it. Hardware is zooming ahead as witnessed on suns, and soon on the Mac II (I hope). My questions to all who have not gone to sleep are... Will Smalltalk mature from being the toy that it was? ie a full 32 bit machine with > 32000 objects etc.. Methinks this is the ideal language to be using no matter how big or small the program. The objection to being such an "open" system can be countered by their "change management tools", if I may be permitted to steal the phrase. Of the hybrids, Objective-C appears my favourite. Although I have never used it, I delight in the similar Smalltalk syntax. It will be a good stand-in until Smalltalk meets its hardware match. Could any user out there please comment on Objective-C, including it's ease of use, availability, portability (ie, which o/s's can it run on), and price? My preference to Objective-C rather than C++ is that I "feel uncomfortable" in the way the latter has been implemented. The extended syntax does not "stand out", it either melds into the other hieroglphs, so I cannot pick the wood from the trees or it further confuses my understanding of C. I wish I had a video of me reading a C program.. I must have this perpetual frown. Is it common? I would love to hear from C++ users, especially those who have used C++ and Objective-C. Note that my primary preference to Objective-C is its syntactical similarity to Smalltalk. Why not MacApp as an interim? Why not indeed! It is another example of brilliance on the part of Apple, and once I get over the confusion of records and messages/methods, all should be swell. One hitch though. Apple had deemed it necessary to inflict a licencing fee on anyone producing/marketing software that uses MacApp, as well as restricting all such programs to the Macintosh. I don't know whether this still holds. I have noted MacApp being used on a 4.2 bsd system (refer to OOPSLA '86 procs pp 186 - 201). pity. My main hope is Smalltalk. It is a pity that the ones that can really benefit from such a system are usually the last to see it. Kids. It is the big kids; ie those who have been ingrained or fed up with procedural languages that get to use it. Does this make us shortsighted? Or perhaps fatally dependent on the past? This isn't a plug for trendy software. This is frustration with writing applications from scratch that use (nearly) the same techniques time and time again. I use the hardware of tomorrow, but give it the brains of yesterday. I am supposed to build on experience; all I do is re-invent the wheel. If you have read the book .. "Object Oriented Programming: An Evolutionary Approach" Brad J. Cox. Then a major part of my article echoes its theme. I could not have read it at a more pertinent time. Thankyou, Paul Menon. Dept of Communication & Electronic Engineering, Royal Melbourne Institute of Technology, 124 Latrobe St, Melbourne, 3000, Australia ACSnet: rcopm@koel UUCP: ...!seismo!munnari!koel.rmit.oz!rcopm CSNET: rcopm@koel.rmit.oz ARPA: rcopm%koel.rmit.oz@seismo BITNET: rcopm%koel.rmit.oz@CSNET-RELAY PHONE: +61 3 660 2619.