Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!uunet!abvax!iccgcc!klimas
From: klimas@iccgcc.decnet.ab.com
Newsgroups: comp.object
Subject: Re: Object-Oriented COBOL?
Message-ID: <1864.2736eae0@iccgcc.decnet.ab.com>
Date: 6 Nov 90 21:54:56 GMT
References: <694@ghp.UUCP>
Lines: 49

In article <694@ghp.UUCP>, tom@ghp.UUCP (Tom Huras) writes:
> Has anyone managed to work object-orientation into a traditional data
> processing environment?

	It is my understanding that CODASYL has begun working on a standard
	for OO Cobol
..stuff deleted....

> Our client recognizes the benefits of OO for lower long-term
> maintenance costs and wants to be ready to take full advantage of OO
> when the technology (ie. object-oriented COBOL) arrives.
>
> The most pragmatic approach to meet these requirements seems to be:
> -  Express the conceptual design in OO terms.
> -  Use some COBOL language tricks to simulate messaging.
>
	In his book on OO Software Construction, Bertrand Meyer talks 
	about some of the issues associated with writing object based 
	programs using languages that don't support it.  Although he
	has a number of cute examples in a number of languages, he points out
	that "faking it" is ugly, and not in general a practise to
	be promoted.  Hence I think that one would be ill advised to
	expect much from such an endeavor.
 
> I don't know if anyone has done this before.  If no one has, is it
> because the problem domain is not suitable to OO treatment?  Or is it
> that no one has been gutsy enough to try it?  Or is it just because the
> technology is not yet there?
	Basically, OO in a language that doesn't properly support it 
	is a real problem!
> 
> I'm typically enthusiastic about the OO approach (because it works well) but
> I'm not too sure in this case.

	Along with criticizing an approach one is obligated to propose a
	solution.  Therefore I'd like to pass along some food for thought!
	While discussing issues associated with introducing OOP into an
	organization at the rescent OOPSLA, a curious phenomena surfaced,
	it seems that many COBOL programmers readily adapt to Smalltalk
	(much more so than the users of another ubiquitous language).  Why
	not consider prototyping your application in Smalltalk first and then
	when they've gotten the proper functionality down they can use the 
	prototype as a living spec by which to rewrite the application in
	COBOL?  There are some rather remarkable productivity gains that can be
	used for the numerous initial itterations required to get user
	requirements right initially!

	OOP dilettanti beware, two million + Smalltalk programmers might be
	waiting to take your job!