Re: Alexandre Bergel <bergel@iam.unibe.ch>

From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 12/03/03 

Date: Wed, 03 Dec 2003 16:36:10 GMT

Responding to Bergel...

First let me point out that, as a translationist, I am not a language
maven and, in particular, I don't know very much about MLS. So my
comments are just focused on the Oo perspective...

> After 1990 things become clearer with class-based features being
> emphasized. A very few (none?) of new languages are module-based. It
> seems that the prefered machanism for ADT and encapsulation is provided
> by the Object paradigm.

I suspect this is because OO provides for modularization at several
levels. (The notion of class-based modularization is vastly
oversimplified.) Classes provide modularization at the level of
identifiable problem space entities to be abstracted in terms of
encapsulated knowledge and behavior responsibilities.

While a class is logically indivisible in terms of the entity that it
abstracts, it can be further subdivided into attributes (knowledge
responsibilities) and operations (behavior responsibilities). At that
level of modularization one has ADTs for attributes. OO provides
similar encapsulation for operations through methods. In addition, OO
methodologically places constraints (e.g., self-containment) on the
definitions of attributes and methods. IOW, attributes and methods
represent fine-grained modular encapsulation.

At the level of layers and subsystems provides exactly the same sorts of
modularization and encapsulation. Moreover, modern OO practice dictates
that the interfaces for subsystems and layers provide even more
decoupling than class interfaces. So subsystems and layers represent
large scale modularization -- classes on steroids, as it were.

>
> A new trend of languages (Unit of MZScheme and its Java copy Jiazzi,
> MIX(FL), Moby or JavaMod), is coming up where module system is pretty
> advanced and offer features such as instanciation or first class entity.
> But in such case the goal is to offer some higher level of composition
> and not to replace the object paradigm.

I can't speak to the specific examples for lack of knowledge, but I have
noticed a disturbing trend in the industry to try to merge elements of
OO development and functional programming. These are two completely
different construction paradigms that are almost antithetical. IMO, the
paradigms are incompatible and any attempt at merging them is doomed to
inconsistency.

However handy or convenient a feature of one paradigm might seem in a
particular situation, one has to be concerned with how it plays with the
other paradigm in the general case. In the end 3GL languages syntaxes
implement methodological A&D approaches to software construction. Those
methodological approaches depend upon a degree of synergy among their
constituent elements. Inserting elements from other paradigms,
especially ones that are diametrically opposed, seriously risks breaking
the synergy.

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindersol.com
(888)-OOA-PATH

Relevant Pages

  • Re: Relational model versus object model
    ... Today almost all OOPL IDEs provide integrated class libraries. ... Note that OO classes with no behavior responsibilities are fairly ... >> paradigm as manifested by a relational DBMS. ... implement interfaces for inclusion polymorphism. ...
    (comp.object)
  • Re: Why is OO Popular?
    ... >> Children understand certain things behave in certain ways. ... >> using object oriented languages. ... becoming more and more distributed and the object paradigm has very good ... 'complex systems', where you have to almost embrace complexity to an extent. ...
    (comp.object)
  • Re: Relational model versus object model
    ... relational tuples in the same sense as rows in the RDB table. ... OO construction employs a different paradigm than relational data ... >>is better because it automates what the developer would otherwise do by ... subject may be tailored to its responsibilities. ...
    (comp.object)
  • Re: merits of Lisp vs Python
    ... mind-meld with the Haskell community. ... There's no question that other languages have some features that common lisp does not. ... Lispers just can't abide being locked into a particular paradigm because a language doesn't have the basic features necessary to provide new paradigms for ourselves when needed or wanted. ... a common lisp with optional static typing on demand would be strictly more expressive than common lisp. ...
    (comp.lang.lisp)
  • Re: EcmaScript 4
    ... structuring, and stack-based scope. ... But behaviors in an OO context messages just announce what the message sender did. ... Combining the I'm Done view with doing flow of control at a different level of abstraction ensures that one doesn't think about chains of operations when defining individual object responsibilities. ... In the OO paradigm there are essentially only three levels of decomposition: ...
    (comp.object)