Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation

Re: Re: Ancient Philosophy And Programming Languages

by cyocum (Curate)
on May 01, 2004 at 18:13 UTC ( #349655=note: print w/replies, xml ) Need Help??

in reply to Re: Ancient Philosophy And Programming Languages
in thread Ancient Philosophy And Programming Languages

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.

  • Comment on Re: Re: Ancient Philosophy And Programming Languages

Replies are listed 'Best First'.
Re: Re: Re: Ancient Philosophy And Programming Languages
by theon (Beadle) on May 01, 2004 at 19:02 UTC
    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.

        In Java you have int, and base types. That't exactly what you said in your initial post, but I fail to see why what is ok with Java (we can use Integer instead of int) is not ok with C++ (we can use Integer instead of int and DerivedFromObject instead of NotDerivedFromObject). Only user-defined types are Objects in Java, I would say it's not enough to fit your first category (at least, real OO languages are probably better examples).

      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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://349655]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (8)
As of 2017-04-24 04:44 GMT
Find Nodes?
    Voting Booth?
    I'm a fool:

    Results (433 votes). Check out past polls.