in reply to Ancient Philosophy And Programming Languages

Looks like you're not talking about C++ but C only. C++ has a string type, and you can easily have everything as an Object (just like Java does for int -> Integer). I'd say C++ has some Aristotilian characteristics because of the C compatibility, but what was added (real C++, not C-style C++) is far more Platonic oriented. Imho not a good example to illustrate your (interesting, btw :)) discussion.
  • Comment on Re: Ancient Philosophy And Programming Languages

Replies are listed 'Best First'.
Re: Re: Ancient Philosophy And Programming Languages
by cyocum (Curate) on May 01, 2004 at 18:13 UTC

    The only reason that I added C++ to the list was because of its status as a super-set of C. This also illustrates the problem with Java nicely. Both C++ and Java have object structures but only Java requires an Object Oriented paradigm. C++ does not since it must support all of C. However, both languages have primitive data-types. I am still open to debate and discussion about how to seperate the types of languages.

      Well I think "types of languages" can not be strict, unless a language is crafted to follow one-and-only-one paradigm. If you have types of languages, some languages will perfectly fit one type, but others (particularly C++) may allow several paradigms, I wouldn't give them only one type.

      Then, think of such examples : a Java program using only static members (or singletons) vs a good POO C++ program. The former is closer to C-style modules than the latter. And there are examples of OO C programs (glib/gtk).

      It can be tricky. I think your categories apply to actual programs rather than languages. Then some languages are designed to provide one paradigm, so programs in this language will probably end up in only one of your categories, but not all of them (badly designed ones or other exceptions).

        The only problem I have with your argument (and it is a very good point) is that, in Java at least, you still must have an object which derives from Object. Even if all the methods are declared static, the object still must derive from Object. This is true even in Perl. As long as you bless a reference, you derive from UNIVERSAL.

        In the case of C++, I think that you are more correct. C++ only encourages OO but I am still impressed by the way it only really encourages Abstract Data Types (remember you can over load how operators work) rather than Objects (which lack the ability to act like data types). I realize that I may have to think about the differences between Abstract Data Types and Objects.

        I have a quote from another node, which I thought might be relevant to the current debate. This is really just more information to think about:

        Patterns aren't Platonic Ideals: Patterns are real-world observations from a particular development community. The patterns described by the Gang of Four aren't free-floating abstractions that somehow exist outside of time and space and were waiting for us to come and discover them; they're practical responses to various day-to-day challenges, including the limitations of C++. An attempt to document Perl Design Patterns should be looking at the best practices of the Perl development community, not just the parts that resemble a ten-year-old collection of patterns from a different language.