tom@stl.stc.co.uk (Tom Thomson) (06/28/90)
In article <26855613.749b@petunia.CalPoly.EDU> jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: > >A lot of what is gained in OOD is in the de-sequentializing of our problems. >Objects can be considered as independently executing processes. Because of >the extreme decoupling between objects, the problem is broken down into >more manageable pieces. This seems to me that it should make the problem Every OO language I have seen makes this claim. However, every OO language that I've seen (with one experimental exception, a laboratory toy language) insists that the messages are SYNCHRONOUS, that the channels between the processes are UNBUFFERED (and blocking), that every message has a REPLY whose sending is implicit (in result delivery). In other words, the languages require sequential execution, there is no de-sequentialising at all, programs written in OO languages would cease to work if the compiler and/or the execution system stopped enforcing sequential semantics. Claiming OOD provides a lot of gain in de-sequentialising our problems is pure bunkum. The things that OOD really has got going for it are Abstraction with strong encapsulation Inheritance mechanisms to facilitate re-use A reasonably expressive type system (sometimes) all of which are principles that were well understood and practised by competent software engineers (and language designers) long before the wonderful phrase "OO" appeared and became the flavour of the month. The only class of languages which generally provide an escape from sequentiality are the functional languages (logic languages like prolog have sequential semantics; languages like parlog, with moded arguments, may avoid sequentiality so there's a subclass of logic languages that provide the escape too). It's a pity that they don't provide decent abstraction and inheritance mechanisms too - maybe a functional OO language (a contradiction in terms?) would be the answer to our dreams? Tom Thomson [tom@nw.stl.stc.co.uk
cox@stpstn.UUCP (Brad Cox) (06/28/90)
In article <31116@cup.portal.com> cliffhanger@cup.portal.com (Cliff C Heyer) writes: >I think focusing on making the workplace a happier place by looking at >psychological issues, etc. would prove more fruitful for productivity than >OOP ever will. But participation in the psychology USENET newsgroup is >at an all-time low. You might be interested in how certain organizations are managing to beat our butts in terms of quality and time to market by *one to two orders of magnitude). Average of 2-3 programmers per terminal Obsolete software technologies (assembler often) 200-300 desks per room, side by side, managers at the end of each row. Workdays average 10-14 hours/day. The organization is, of course, a Japanese software development organization such as Hitachi, NEC, etc. These are a quick summary from memory of a workshop organized by Victor Basili and Colonel Will Stackhouse at Univ. of Md on Tuesday of this week. Of course this is not necessarily to disagree with your feeling that psychology is what's different here. It is only that the word psychology tends to be used to argue that the solution is reclining chairs and more window space, rather than the Japanese 'secret'; a devastating sense of *shame* on being found responsible for a bug that diminishes the group's (closely monitored) performance with respect to other groups, or (horrors) in the eyes of the customer. -- Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875 The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482
lgm@cbnewsc.att.com (lawrence.g.mayka) (06/29/90)
In article <3169@stl.stc.co.uk> "Tom Thomson" <tom@stl.stc.co.uk> writes: >provide the escape too). It's a pity that they don't provide decent >abstraction and inheritance mechanisms too - maybe a functional OO >language (a contradiction in terms?) would be the answer to our dreams? A grand unification of functional and OO programming would probably look a lot like the Common Lisp Object System: A generic function's behavior would vary according to the class(es) of its argument(s). Lawrence G. Mayka AT&T Bell Laboratories lgm@iexist.att.com Standard disclaimer.
wdr@wang.com (William Ricker) (07/03/90)
tom@stl.stc.co.uk (Tom Thomson) writes: >In article <26855613.749b@petunia.CalPoly.EDU> [John R. Dudeck] writes: >> >>A lot of what is gained in OOD is in the de-sequentializing of our problems. ^^^ >Every OO language I have seen makes this claim. However, every OO language ^^^^^^^^^^^ >that I've seen (with one experimental exception, a laboratory toy language) >insists that the messages are SYNCHRONOUS, that the channels between the >processes are UNBUFFERED (and blocking), that every message has a REPLY Who said OOD (Object Oriented Design) was limited to the design of one program? I'd rather use OOD to design a system using asynchronous messages between programs than any "functionally decomposed" SASD method. Yes, Asynchronous tasks are good models for many objects, and OOPLs will not be fully mature until the OOPLs supply this support naturally. We used a synchronous OOPL with an ansyncrhonous operating system to implement a system-level object that would respond asynchronously. We used old objective-C (3.3) on early beta OS/2 LanManager! and it worked. >Claiming OOD provides a lot of gain in de-sequentialising our problems is >pure bunkum. Confusing OOD & OOPL is confusion. OOD is a nice way to design asynchronous systems. Claiming C++ is a suitable OOPL to make use of non-sequential designs is bunkum. Claiming many OOPLs are desequentialized by nature is bunkum. But OO, like functional, does not require a sequential model, it's just [easier to start] implementing that way. <<exit jessica rabbit TM>> I would be much less surprised to hear of a parallelizing C++ compiler than a parallelizing C compiler. [I won't try to start a feud on wether C++ (or Ada-- as a friend calls it) is enough OOP for anything, but it's a good Lint, which is more than can be said for any pre-ANSI C.] What was the one lab-toy OOPL that you tought was not sequential? By the way, this debate on sequential/synchronous v. Asynch probably needs to be discussed relative to Brad Cox's (oh oh, grab asbestos, he's invoked a NAME of DOOM) different scales of OO Integration -- IF OOSA and OOD are discussing the interfaces of whole subsystems or programs rather than C++ classes or methods (as I think Brad would say and I'd agree with) THEN It is natural that at these higher levels of abstraction the OO glue is thought of, and should probably be implemented as, Asynch/nonblocking. And At finer levels of detail, it is natural to transition to Syncrhonous/ blocking semantics. (If this is below the HW/SW transition in your favorite system, why lucky you! for the rest of us, we've got to make it happen.) Thus, At some level of integration, there must be a tool that maps between the Asynchronous messages of one to the synchronous RPCs of the other & viceversa. This may be an operating system with Sockets, Pipes, Messages; or a spiffy linker, or an thing we'd call a programming language. Cheeers, Bill <I hope my silly signature file appears here> -- /bill ricker/ wdr@wang.com a/k/a wricker@northeastern.edu *** Warning: This account not authorized to express opinions ***
ejp@icd.ab.com (Ed Prochak) (07/04/90)
I am way behind in this discussion, so I this point has been covered go ahead and ignore my bringing it up again. One point that John mades is that you should be able to pick objects and use them without regard (at least initially) to performace: In article <26855613.749b@petunia.CalPoly.EDU>, jdudeck@polyslo.CalPoly.EDU (John R. Dudeck) writes: > > cliffhanger@cup.portal.com (Cliff C Heyer) writes: [deleted stuff about outside interfaces] > > > >But nothing to change the fundamental problem: When you are programming > >you are not assembling pre-engineered components. You are developing > >an new sequence of steps to perform a task. This is not and will never be > >accurately quantifiable. (I'm just waiting for some manager to give me > >his logic why this is wrong...and post it) > > I would like to see some managerial-level input on this topic, too! > [deleted psychology stuff too] > > >With objects, you may have to tune that internal algorithm for a specific > >task to save CPU time. Oh, but wait - you can't do this because this > >would violate the fundamental principle of objects. Why should you not be > >able to take advantage of a flexibility that software affords over hardware??? > > The idea is that you shouldn't have to be concerned unless you want to be, > about such aspects as algorithm fine-tuning. Certainly I wouldn't advocate > that algorithms shouldn't be fine-tuned to an application. I would say > that if you can show that an algorithm used in an object in your application > is the cause of performance that does not meet your requirements, then you > should find the sourcecode of the object and fine tune it, or else otherwise > come to a solution. > > >>But that does not > >>mean that every time I go to write a program I will write every line of > >>code from scratch. If there is a way that I can use well-made components, > >>so much the better. Then I can spend my energy working on the real design > >>issues of the project. > >I agree, but my experience with the "real world" makes me suggest this > >to be impractical. > > You're probably right for now. Whether or not this continues to be > impractical in the future will depend on how well the technology > catches on. > I haven't done any OOP yet, so my comments are based on reading this newsgroup and Abstract Data Types ideas. John assumes access to the source code. This is unlikely for objects purchased from a software vendor. It seems that for there to be a component marketplace, there must be several vendors of the same or similar objects. How will the vendors promote their product against a competitor? Consider a market for software components with two types of customers: 1 mainframe system users (or at least systems with virtual menory) with large processing requirements. 2 micro users with embedded systems applications. Both need some graphics widgets with essentially the same properties except that -users in group 1 expect fast response for many on-line users -users in group 2 need to have a known maximum memory requirement. Vendors may develop the widgets with various peformance properties, one vendor with a fast, memory hog widget and another with a slower, but memory lean widget. Beyond those attributes, the widgets are exactly the same. There may even be other vendors with widgets that have performance, momory requirements in between the first two. The users will buy the ones that match their requirements. And if the requirements change, they can move to another widget, possibly from another vendor. Hopefully, some interface standards will allow the vendors components to interoperate. I see it as very similar to the choice in hardware: should the product used super fast logic like ECL? Or must it meet strict power limits so CMOS is best? or something in between? Even in regular TTL there are families: Schotky (S), Lowpower Schotky (LS), Advanced LS (ALS), others?? with different power and speed tradeoffs. Note that hardware has interoperate requirements also, for example signal voltage levels must be compatible. My bottomline point is that tuning may not require change source code. It may just as likely involve swapping one object with a similar one having different performance attributes that better match the application. Does this sound close to being in the ballpark? (Pardon the inconvenience during our remodelling of the signature file) Edward J. Prochak (216)646-4663 I think. {cwjcc,pyramid,decvax,uunet}!ejp@icd.ab.com I think I am. Allen-Bradley Industrial Computer Div. Therefore, I AM! Highland Heights,OH 44143 I think? --- Moody Blues