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

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.
>>

Received on Tuesday, 30 June 2020 10:22:56 UTC