Other OOP languages

A

anotherguy159

2[H]4U
Joined
Aug 7, 2002
Messages
2,093
I have used Python, C++, Java....

What else is there? Any links to more specific programming-centric forums?

STL? Hope I didn't offend you; I value your opinion.
 
Smalltalk. Simula. CLOS (Common LISP Object System). C# (I think).

C++'s object-orientedness comes from Simula. Smalltalk's object-orientedness also comes from Simula.

What "object-oriented" means should be made clear. It doesn't mean "has objects". Object-oriented programming revolves around inheritance. The programming paradigm that says that objects are things which maintain state and provide services is "data abstraction". Think about C. C has minimal support for data abstraction (structs and... structs), but absolutely no support for object-oriented programming, as C has no concept of inheritance.

Java is often claimed to be a "pure" object-oriented language. Yet it fails at that. For example, it lacks covariant returns.

Suppose (and I'll use C++ pseudocode here, since that's all I know), you have a class Mommy...

class Mommy;

which provides a method clone()...

virtual Mommy * Mommy::clone();

Now suppose you have...

class Kiddy : public Mommy;

which overrides the clone() method to do Kiddy-specific things. What does this method return? Overrides usually have to have the exact same signature as the original method. If you write...

virtual Mommy * Kiddy::clone();

You're being more vague than you could otherwise be. You know that Kiddy::clone() really returns a Kiddy *, but you declare it as returning a Mommy *. Why do you care?

Mommy m;
Kiddy k;
Mommy * pm = m.clone(); // Okay
Kiddy * pk = k.clone(); // ERROR

k.clone() returns a Mommy *, but you try to store it into a Kiddy *. You know that whatever k.clone() returns is really a Kiddy *, but the compiler doesn't know that. You don't get an implicit downcast. You'd have to dynamic_cast it yourself.

This is the situation in Java, because Java lacks covariant returns. There Is No Escape. But C++ has covariant returns. An overridden method may return a pointer to a more derived type. So declaring...

virtual Kiddy * Kiddy::clone();

Kiddy * pk = k.clone(); // Okay

works! Covariant returns across other hierarchies are okay, too.

class Base;
class Derived : public Base;
class Mommy;
class Kiddy : public Mommy;

virtual Base * Mommy::foo();
virtual Derived * Kiddy::foo();

Of course, covariant returns aren't implemented yet in gcc 3.3.3, but they will be in gcc 3.4 (and I think MSVC .NET 2003 already has them). In any event, they've been a part of the Standard since 1998.
 
Hilarious that I'm the first and only one to contribute a reply. And it was even detailed and on topic.

By the way, C++ FOR LIFE! ALL OTHER LANGUAGES SUCK!!!!11!!!!!@!#!!
 
Ocaml

from ocaml.org

"Caml is a programming language. It is a functional language, since the basic units of programs are functions. It is a strongly-typed language; it means that the objects that you use belong to a set that has a name, called its type. In Caml, types are managed by the computer, the user has nothing to do about types (types are synthesized)."

and from a quick google search

"One of Ocaml's extentions to the original ML language is an ObjectOrientedProgramming system. Ocaml's OOP has everything you'd expect after using Java or C++. The syntax is quite different -- class declarations are much more compact.

A big improvement is that container classes are polymorphic. In C++ and Java container objects only recognise objects inside themselves as being members of the Object class. You have to cast objects back the appropriate class when you remove them from the container. In Ocaml, if you want a container object to specifically contain objects that are of the class fruitbat, you can say so. "
 
PHP 4 has some basic OOP and PHP 5 is supposed to make it truely a OOP language.
 
Originally posted by STL
By the way, C++ FOR LIFE! ALL OTHER LANGUAGES SUCK!!!!11!!!!!@!#!!
Click to expand...

Obviously an informed opinion based on a vast wealth of experience in a multitude of languages, but then again maybe not.

Originally posted by STL
...and I'll use C++ pseudocode here, since that's all I know...
Click to expand...
 
Perl also has some object-oriented features, although I certainly don't know if I'd call Perl an object-oriented language.
 
Originally posted by deuce868
PHP 4 has some basic OOP and PHP 5 is supposed to make it truely a OOP language.
Click to expand...

It will never be a good OOP language. PHP 5 is definitely an improvement, but there are still some definite issues. I love PHP and think its a great language, but not one I would rely on to get a good firm grasp of OOP.
 
Originally posted by deuce868
PHP 4 has some basic OOP and PHP 5 is supposed to make it truely a OOP language.
Click to expand...
i'd like to note that i find php's classes, though limited, very useful.
 
It will never be a good OOP language. PHP 5 is definitely an improvement, but there are still some definite issues. I love PHP and think its a great language, but not one I would rely on to get a good firm grasp of OOP.
Click to expand...

I agree, if you are just learning classes and looking for a language to understand them with then the hackas and work arounds to get OO PHP is not a good way to start.
 
Originally posted by STL
Hilarious that I'm the first and only one to contribute a reply. And it was even detailed and on topic.

By the way, C++ FOR LIFE! ALL OTHER LANGUAGES SUCK!!!!11!!!!!@!#!!
Click to expand...

Welcome back from the great beyond Stephan… ;)
Your particular blend of humor\insight has been missing around here…


On topic, as previously mentioned, C# and VB are OO. If you want a full list though, I’d suggest throwing “object oriented” “programming languages” into Google.
 
Javascript is OO. It's unusual in that's prototype-based, instead of class-based like the vast majority of other OO languages.

There's a very new pure OO and (impure) functional language called Scala that looks pretty interesting.

Ruby is a pure OO scripting language that is a lot of fun to write.

Smalltalk is always worth checking out, too. It took the inheritance ideas from Simula that STL was talking about, and combined them with the idea that programming should be very interactive, or dynamic, as opposed to the traditional file-based, edit/compile/run or edit/interpret system. It's an image-based language, which means that you do your development inside the equivalent of a live JVM or .NET runtime. The "objects" you work with are alive from the get-go, and change in realtime as you add to and change their source code. It's really unlike anything else out there.

The easiest way to try out Smalltalk is to download Squeak, but you'll need to look past the fruitiness of the UI; it's a fairly serious platform underneath the gaudiness -- the developers include the same people who started Smalltalk back in the late 70s (including Alan Kay), and Squeak in fact includes Smalltalk code from way back then. If the "whimsical" look puts you off, then Cincom and IBM both have free Smalltalk downloads that are much more conventional as far as UI looks go.
 
Originally posted by binary digit
Ocaml

from ocaml.org

"[snip]A big improvement is that container classes are polymorphic. In C++ and Java container objects only recognise objects inside themselves as being members of the Object class. You have to cast objects back the appropriate class when you remove them from the container. In Ocaml, if you want a container object to specifically contain objects that are of the class fruitbat, you can say so. "
Click to expand...

::spittake::

Oh, now I remember, they're living in 1992, with Sir Mixx-A-Lott, MC Hammer, Arsenio Hall, Right Said Fred, and pre-Standard Template Library C++. Back when some C++ programmers thought that a universal Object, TObject, or CObject subclass might be a good idea. The OCaml people really ought to learn something about collections in today's (or 1994's) C++, because they can surely pick a better "feature" to distinguish OCaml.

(Yes, yes, yes, I know that Java 1.5 also features some type of generics, suitable for typed collections, but it's probably still a fair enough criticism of Java for the next while, until most Java programmers move to 1.5)
 
[MonkeyShave]
> Oh, now I remember, they're living in 1992, with Sir Mixx-A-Lott, MC Hammer, Arsenio
> Hall, Right Said Fred, and pre-Standard Template Library C++. Back when some C++
> programmers thought that a universal Object, TObject, or CObject subclass might be a
> good idea. The OCaml people really ought to learn something about collections in
> today's (or 1994's) C++, because they can surely pick a better "feature" to
> distinguish OCaml.

Ha ha HA!

> (Yes, yes, yes, I know that Java 1.5 also features some type of generics, suitable for
> typed collections, but it's probably still a fair enough criticism of Java for the
> next while, until most Java programmers move to 1.5)

The generics support in Java 1.5 will suck. (According to a professor at a graduate school I'm looking at who works with Java extensively and doesn't hate it like I do.)
 
Originally posted by STL
The generics support in Java 1.5 will suck. (According to a professor at a graduate school I'm looking at who works with Java extensively and doesn't hate it like I do.)
Click to expand...

[MonkeyShave reads about Java Generics]
::spittake:: (again)

Well, this guy summed up Java Generics pretty well. It looks like they're 100% as bad as .NET Generics (which have the same gimpy specify-an-interface-when-you're-writing-the-generic gimpiness). It appears that their one and only goal was to take the casts off of their container interface. This culminates 9 FUCKING YEARS of development effort wow, it stuns me, and I'm sure glad that I'm not a Java programmer right now. Cast-free containers and no other capabilities, I just refuse to believe that they've ignored every C++ development for the past 10 years, that they somehow haven't noticed everything that's happened in that area, but somehow it appears that that's what they've done.

Anyway, back to 1992, Nintendo produced the Super Scope for the SNES console, I owned a 486DX2 (running Windows 3.1), President George Bush had just won a war with Saddamm Hussein, but the slumping job market and fear of jobs moving out of the U.S. had hurt his popularity, and intel had followed AMD's lead by announcing a 64bit low-end server cpu [sorry, for a moment I confused 1992 and 2004].

I guess I hadn't intended to hijack the thread, but does anybody else have any fond memories of 1992?
 
> It appears that their one and only goal was to take the casts off
> of their container interface. This culminates 9 FUCKING YEARS of
> development effort wow, it stuns me, and I'm sure glad that I'm not
> a Java programmer right now.

IDIOTS!

> Cast-free containers and no other capabilities, I just refuse to
> believe that they've ignored every C++ development for the past 10
> years, that they somehow haven't noticed everything that's happened
> in that area, but somehow it appears that that's what they've done.

Well, they already ripped out operator overloading, etc, etc.

> I guess I hadn't intended to hijack the thread, but does anybody
> else have any fond memories of 1992?

Let's see... I was 9. Heeh.
 
Originally posted by MonkeyShave
[MonkeyShave reads about Java Generics]
::spittake:: (again)

Well, this guy summed up Java Generics pretty well. It looks like they're 100% as bad as .NET Generics (which have the same gimpy specify-an-interface-when-you're-writing-the-generic gimpiness).
Click to expand...

C# generics are FAR superior to Java generics. Java generics basically reduce everything to Object, and insert the casts you didn't write. This also involves boxing of primitive times.

In C#, generics are built in, and instanciated at runtime, as need. The whole "spedcify-an-interface-when-you're-writing-the-generic gimpness" is for strong type-checking. And you don't need to specfy an interface; you can also specify a base class (with Object being implicit). It's not too bad of a trade-off, for having strong typing, and much better than Java's hack.
 
Originally posted by STL
> It appears that their one and only goal was to take the casts off
> of their container interface. This culminates 9 FUCKING YEARS of
> development effort wow, it stuns me, and I'm sure glad that I'm not
> a Java programmer right now.

IDIOTS!

> Cast-free containers and no other capabilities, I just refuse to
> believe that they've ignored every C++ development for the past 10
> years, that they somehow haven't noticed everything that's happened
> in that area, but somehow it appears that that's what they've done.

Well, they already ripped out operator overloading, etc, etc.
Click to expand...
It looks like it gets even worse, try reading about the horrors of "type erasure" (page 12). (At first glance, it seems like "type erasure" creates the same type of problems as the ODR in C++, except without any chance for the end-user to insulate himself from the problems. Fortunately the compiler will catch erasure errors, but the language does little help you avoid them.)

Yep, you read it right, Java 1.5 chucks all of their meager Generic support before generating code, so you can get extra errors (when the stupidified non-generic types return) by trying to overload on Generic types [example].

There was a time (a few minutes ago) when I thought that Java was a good fit for some tasks, a time when I'd even considered learning it (due to political pressures at work), but having seen this, I'd rather live in a cardboard box and eat rats than try to work with this crap. It seems that Sun's implementation of Generics was designed to be not only useless, but actively harmful to the idea of generic/generative programming.

I'm certain that within 30 or 40 years, Sun will have caught up to the sophistication and expressiveness of C++, but it just doesn't seem like they even want to make a useful language. :(
 
Originally posted by Velox
C# generics are FAR superior to Java generics. Java generics basically reduce everything to Object, and insert the casts you didn't write. This also involves boxing of primitive times.

In C#, generics are built in, and instanciated at runtime, as need. The whole "spedcify-an-interface-when-you're-writing-the-generic gimpness" is for strong type-checking. And you don't need to specfy an interface; you can also specify a base class (with Object being implicit). It's not too bad of a trade-off, for having strong typing, and much better than Java's hack.
Click to expand...
Better than Java? Yes
As good as C++? No

While I admit that I may have missed some distinction between .NET Constraints and Java interface specifications, it strikes me that you face the same ultimate tradeoff: specify a Constraint, or use dynamic downcasts within the Generic. Unfortunately this doesn't do what *I* want it to do, I want to be able to avoid:

1. Runtime cast errors
2. Forced interface inheritance (frankly, I don't want to fuck up my code with mandatory base classes from each and every library I use).
and
3. Cryptic error messages (as I've accustomed myself to C++ template errors, this does not concern me very much, but I know that they vex many, many programmers)

.NET, Java, and C++ all permit #1, Java and .NET seem to require #2, and C++ can provide #3. With C++ I can avoid #3 by using something like boost::concept_check, but I just can't see how to avoid #2 with either Java or C#. I'd like to be able to implement my own operator< and ignore IComparable. OTOH, I haven't used these systems, so I can't properly gauge the size of the problem (though I resent mandatory base classes whenever I encounter them, even in C++ libraries (like MFC and the standard C++ streams interface)).

I really have tried to educate myself on this but Anders Hejlsberg's interview about .NET generics didn't relieve my fears.

I don't believe that I'm dismissing .NET generics. It's possible that the tradeoff isn't too bad, but I don't mind my current tradeoffs. It appears that .NET generics don't solve the same problems as C++ templates. Personally, I love the power and flexibility that C++ templates provide and I'm willing to pay the price that they require (occasional burdensome compile-time error resolution).
 
You must log in or register to reply here.
Back
Top