Talk:OOP vs type classes

Bulat, I think existential types somehow correspond to the idea of *subtyping* (as illustrated in the Existential type page, hope you can elaborate on that.

subtyping possible without existensuials, it's just "=>" in "class" declaration. as both me and John said, existensials just packs dictionary togehther with object what makes possible polymorphic lists and so on, i.e. using different _instances_ of the same class inside one list or other container, or in different arguments in function, Bulatz 15:14, 18 August 2006 (UTC)

This is written in the first person in places, which makes it difficult to collaborate on. —Ashley Y 09:25, 27 August 2006 (UTC)

I think Bulat wants to write a detailed tutorial himself and wants our contribution and comments. yes, this is difficult to collaborate on. --Pirated Dreams 09:54, 27 August 2006 (UTC)

my global goal is to write series of little tutorials which explains dark corners of haskell like imperative programming or type classes. i will be pleased by any edits as long as they make text more helpful for potential reader. if you are interested in writing/editing any part of text - don't mind about me. about "first person" problem - writing long texts is not easy task, one of tricks is to imagine that you write/say this to some concrete person. so, the text is started as a speach. you can just edit such parts of texts to more impersonal style, but i think it will be worser. we, humans, have natural ways to communicate and person-to-person talk is _natural_ one, while impersonal talk is unnatural. at last end this means that impersonal text will be not so involving and therefore not so motivating-to-learn. so, i think that the best way is to hold person-to-person style of text while this person, John de Mac-Lee, is our collective image :) but again - if you have alternative text, feel free to replace existing one (which anyway will be kept in History) or add your text in italics, so that Final Editor will select best one or combine them Bulatz 10:43, 27 August 2006 (UTC)

Bulatz, you may want to consider changing this topic a good deal. First off, it's clear you're comparing languages and not OOP as a general design principle. Various object-oriented languages have different strengths and weaknesses, and using C++ or Java as the "de-facto" OOP language is just skewing your comparison. Ruby's OO is tremendously more dynamic than C++'s, for better or worse, and using Ruby examples and principles here would drastically change the discussion. Additionally, you should give serious thought to avoiding C++ in your discussion altogether -- it's clear your C++ experience is somewhat limited. You use static classes instead of namespaces to group similar functionality? Why? And your example about a generic Point class doesn't make any sense or even compile. A single templated class in C++ would give you the ability to make a point out of any data type - int, float, char, double, std::string, custom classes, etc. You could define all your behaviors in a single class instead of that bizarre subclassing system you use, with one subclass for every data type.

I have no opinion on Haskell vs. C++ or even functional vs. OOP, but your comparison is incorrectly skewed against C++ and OOP because of what appears to be simple misunderstandings or maybe just a lack of experience.

Nerdmaster 17:30, 22 March 2008 (UTC)

i used static classes because in 90s namespaces was not yet in C++. C++ templates isn't OOP feature (and C++ isn't OOP-only language). i don't used C++ templates because i want to show how to replace OOP classes (written in any language) with Haskell code. i think that C++ templates are rather directly translated into Haskell type classes

generally speaking, OOP with virtual functions provides some functionality which lacks in Haskell. my idea was that many C++ programs that use classes use only part of OOP features that can still be easily translated into Haskell (which is impossible in general case). it was written as answer to very common question of C++ -> Haskell migrated programmers "how i can replace C++ OOP features with Haskell code". as you may see, this makes meaningless writing C++ template code - it' s not that they are asked for!

Bulatz 18:01, 22 March 2008 (UTC)

I have been looking at the section that compares C++ with type classes and it seems to me that there are 2 important points: 1) The abstract class is not used and not really necessary. The only reason for it that I can see is to have an "interface," but at the end the virtual method is not used in any dynamic way. The syntax is checked whenever the operator+ is used for a particular "instance." 2) The proposed technique works only when the dictionary can be found statically, so this would not work for existentials or anything similar.

C++ equivalent of "counter" closures example[edit]

The equivalent C++ code of the example of closures with a function taking two operations would rather be something like:

#include <iostream>

void proc(auto inc, auto read) {
    inc(); inc(); inc(); std::cout << read();
}

int main() {
    int x{};
    proc([&]{ ++x; }, [&]{ return x; });
}

Which is very similar in complexity and length as the Haskell version. There is no need to write classes and use inheritance in C++ either. The parameters could also be constrained using C++20 concepts.