Re: class/subclass and the dominance of object-oriented programming

Amirouch
yes to your points

OO , like most things, can be useful to some extent but has limitations
I actually don't do OOP, I do OOM, modelling, not programming

In theory you could model using OOM and the using any programming language
to implement the model
I think this is why people like programming, they are the masters of the
universe and do what they want
I am familiar with OO modelling design, and know its usefulness.
I cannot think of what methods people use if not OO modelling  to design
their software
because thats more or less all I did.

When you code in python or what not, dont you do some design before coding?
if so, what design method do you follow?

PDM


On Tue, Jun 30, 2020 at 6:22 PM Amirouche Boubekki <
amirouche.boubekki@gmail.com> wrote:

> Le mar. 30 juin 2020 à 03:25, Paola Di Maio <paola.dimaio@gmail.com> a
> écrit :
> >
> > Amirouche
> >
> > the problem is scale and complexity,
>
> That is the point of "divide and conquer" strategy or "separation of
> concerns" for instance one problem faced in KR is the importance to
> figure that representation of time and space are not necessarily
> related in a tree relation. That is time does not inherit space
> attributes and space does not inherit time attributes. One could even
> say they are completely different types. If we consider time spans or
> points that are in the past and never in the future, we can figure
> that time and space can be represented similarly and as finite
> geometric shapes.
>
> Another more explicit example where tree inheritance is completely
> off-topic is the dichotomy between unstructured text and geometric
> shapes. The way databases deal with those two types is completely
> different. Methods or functions that apply to those two types have
> zero intersection.
>
> (One can possibly extract geometric information from unstructured
> text, hence relate geometric shapes to text but that is a relation of
> inclusion has-a geometric shape information, and not inheritance)
>
> > Due to cognitive limitations of humans, there is only so much human can
> conceptualilze/compute
>
> Yes, I agree. That is again a "divide and conquer" strategy that aims
> to organize knowledge. Stressing the importance of inheritance is not
> that useful. Tree structure is another tool among many others.
>
> > To organize classes and objects is comparable perhaps to categories and
> subcategories
>
> Yes
>
> > The beauty of OO was that it used encapsulation, inheritance and other
> things which I do not remember
>
> My point is not that all of the concepts bolted together in OO are
> useless. My point is we should carefully think about what patterns
> (encapsulation, inheritance, polymorphism, mixin, interfaces, traits,
> generics, etc...) in OO are helpful and break free from the
> long-running marketing campaign around OO programming and its
> implementations (Java, C++, Python ...). Eventually, that is not OOP
> that is successful (I deal with OOP-based code daily), it is a
> particular programming language implementation that implements some
> sort of OO. Eventually, people use those languages for various reasons
> and that is not necessarily related to a particular pattern found in
> OOP. For instance, C++ is fast with a giant stdlib, Java is the
> defacto enterprise programming language and Python is handy, easy to
> learn (!) and easy to use.
>
> > so you can see OO as a type of method that implements category theory,
>
> I am not familiar with category theory.
>
> > It does come with limitations,
> > There are many ways OO can be used in parallel to sequenntial programming
>
> > what is your experience then?
>
> There is too much buzz around OOP, not enough analysis about why OOP
> is used all around the corner. My take on it boils down to the "army
> of developer". A lot of people know about OOP, so people are used to
> that approach of programming and use it everywhere. BUT they pay the
> cost of a poor choice of abstraction along the way every single day
> (invisible cost).
>
> > how do you structure a software /system domain before you start coding
> if not using objects?
>
> That is objects are not strictly an OOP concept. In the LISP family of
> language, OOP is an opt-in library. Still, all objects that are
> manipulated have a type and are objects. (somewhat unrelated to OOP,
> dynamically _typed_ programming languages have types!).
>
> I borrow patterns and ideas from OOP but I do that little by little,
> step by step in a way where I only fallback to OOP concepts only
> when/if there is no other way. This keeps the complexity to a minimum
> and avoids over-engineering.
>
> >
> > On Tue, Jun 30, 2020 at 3:32 AM Amirouche Boubekki <
> amirouche.boubekki@gmail.com> wrote:
> >>
> >> I going through the Wikipedia article
> >> https://en.wikipedia.org/wiki/Knowledge_representation_and_reasoning
> >>
> >> I find the following sentence very interesting:
> >>
> >> > the frame communities and the rule-based researchers realized that
> there was a synergy between their approaches. Frames were good for
> representing the real world, described as classes, subclasses, slots (data
> values) with various constraints on possible values
> >>
> >> That goes against my own experience where the class/subclass hierarchy
> >> does not help with system design, in fact, it constrains a programming
> >> language in a framework that leads to broken architectures. Class and
> >> subclass I think should be the exception, not the rule. It is more and
> >> more plausible to me that thinking in terms of hierarchies is a social
> >> heritage that comes from the concentration of power. It is not
> >> necessary. One or two levels of trees can help understand a problem
> >> better, but not generalized trees. It seems to me, the class/subclass
> >> thing that is embodied in the programming language community as
> >> Object-Oriented Programming was forced by western / european natural
> >> language heritage because of the structure of sentences in English and
> >> French and other languages where the subject comes before the verb
> >> followed by "complements". It leads to a notation in English that easy
> >> to read like a sentence:
> >>
> >>   amirouche.likes(scheme, programming, language)
> >>
> >> I am not saying, one should break everything apart and rebuild.
> >> So-called, Object-Oriented-Programming bolt several things together
> >> that must be taken apart, studied separately and carefully.
> >>
> >> NB: If mathematicians were stuck with subject-verb-complement
> >> notation, I bet we would not have computers as of yet.
> >>
>