Re: Confessions of an "OO Foreigner"

From: Peter E.C. Dashwood (dashwood_at_enternet.co.nz)
Date: 01/01/04 

Date: Thu, 1 Jan 2004 12:53:34 +1300

"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0312302022.526dab20@posting.google.com...
> "Peter E.C. Dashwood" <dashwood@enternet.co.nz> wrote
>
> > That is already possible with components. "Web Services" are dependent
on
> > the adoption of MS .NET
>
> I almost thought it was JeryMouse writing that. In what way is
> anything dependent on adopting what MS want to sell you ?
>

Yes, I don't like it either. (Especially as I can't afford to acquire a .NET
compiler...<G>)

It has been my understanding, from various papers I have read, that the .NET
framework is required in order to support "Web Services". In the light of
Thane's post and your comment here, I may have been misinformed or (more
likely) simply misunderstood what I was reading.

> > Your view of OO seems limited to COBOL (where I agree it has not
fulfilled
> > its promise yet.) In other areas and other languages it HAS fulfilled
its
> > promise.
>
> That may be partly because most other languages had problems that
> needed to be solved and OO did that. Cobol already had solutions to
> many of the problems inherent in other languages.
>
> For example operator overloading. If C one could write expressions
> involving the built in types. Beyond that, for user defined types, it
> was necessary to invent functions specific to each type. This
> impacted on the name space making it impractical to have many user
> type.
>
> C++ solved that by allowing one set of method names to be used with
> any number of different types (using name mangling), and also allowed
> expression operators to be methods, also with overloading. Now user
> types can be used as if they were built in types via objects.
>
> Cobol never had the problem. User types can be used in any rational
> statement. MOVE, ADD, etc don't need to be overloaded to cope with
> mixtures of different variable types.
>
> Cobol doesn't wind up with name space pollution problems that occur in
> large scale C systems.

Yes, you've commented on this before, Richard, and I agree with you.

Pete.

Relevant Pages

  • Re: Confessions of an "OO Foreigner"
    ... > the adoption of MS .NET ... In other areas and other languages it HAS fulfilled its ... For example operator overloading. ... Cobol never had the problem. ...
    (comp.lang.cobol)
  • Re: Theodore Adorno, a prophet of data systems design
    ... Hey, goose man. ... >> especially those who cling to outdated languages. ... Buddy of mine wrote an efficient chess program in Cobol to demonstrate ... Levine the Genius Tailor says, "no problem, just hold your arm like ...
    (comp.programming)
  • Re: Gartner on Assessing the Age of Software Languages and Tools
    ... with no mainframe COBOL at all, ... And general-purpose computers running general-purpose applications are a ... movement in general programming toward better ... But are these pockets of "old time languages" significant in a global ...
    (comp.lang.cobol)
  • Re: Could this save COBOL?
    ... I am personally of the opinion that any languages not supporting the OO ... paradigm will be gone within 10 years, and that includes COBOL, unless it is ... OO COBOL running in the Dot NET environment could have a real chance of ... If the lifeblood of COBOL is going to be 1960s code in a mainframe ...
    (comp.lang.cobol)
  • Re: Is there a mainframe skills shortage?
    ... That's because the author of the article is comparing it to standard SQL. ... and material around Lamdas and functional programming. ... obvious which languages were the ones to learn. ... stick to writing system software and leave applications to the COBOL ...
    (comp.lang.cobol)
Loading