Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Please rank programming languages by how well they provide OOP support.
5 points by granular on July 5, 2009 | hide | past | favorite | 14 comments
Is Smalltalk the best? Is Perl's Moose better than Python's built-in OO? How does CLOS measure up? Where do C++ and Java land on the scale?



Is Smalltalk the best?

Define "best".

Is Perl's Moose better than Python's built-in OO?

It is more complete. Better? Maybe, maybe not. It's very nice, though.

How does CLOS measure up?

Measure up to what? Other LISP object systems, or Smalltalk, and Moose, and Python?

Where do C++ and Java land on the scale?

On a scale of 1 to Verbose, they're pretty far up the scale.


> Define "best".

As someone replying to the discussion topic, you may choose any interpretation of "best" that you wish. In fact, that would be preferred, as it would probably produce more interesting discussion than me attempting to rigidly define "best" in order to allow someone to post "given your definition of 'best', language Y is 'the best'".

How about this: which language's OO implementation do you like the best, and why?


I'm not sure I'd call C++ verbose...at least, not in the same way Java is.

Java takes a lot of characters to express an idea. C++ (usually) requires you to take a big idea and break into smaller parts than Java might (because Java has large libraries).


What's the goal of this ranking? What are you trying to accomplish?


I was hoping it would lead to comments such as, "$lang1's OO implementation is good, except that it's missing $feature_X and $feature_Y, which means I can't do $technique_Z", or "$lang2's OO impl is more useful to me than $lang3's because it allows me to do $U and $V which I can't do in $lang3".


emacs or vim? You aren't asking a technical question, you are asking a religious question.


No it's not a religious question. You and I can take our respective dieties to task by choosing a test problem, then praying hard to see whose diety exists/answers, etc. Most likely, both of us will be disappointed (otherwise I would have had a jetpack by now :-)

Quality of object systems can be tested by posing a computational problem and letting people solve the problem in their language/object-system of choice, we can then rank the answers by various criteria (development speed, code clarity, code speed, system integration, run-time portability, scaling, maintenance costs, etc.)



That article is kinda slanted and pretty out of date. I suggest taking it with a very large grain of salt.


Thanks, gaius.


CLOS is probably the best, if you ignore the fact that built-in types aren't actually objects. (They can pretend to be, but aren't. You also can't make built-in functions generic, which is quite annoying.)

Moose is a close second, and provides a lot of sugar that I really wish I had in CLOS. Roles are pretty much mandatory for proper OO these days, and Moose is the only production system that has them. I also love sugar like lazy_build. The type constraint system is just wonderful.

Continuing down, Ruby is a bit better than Python, but both are workable. They give you what you would expect from class-based OO, and you have a basic MOP, too.

At the bottom are Java, C++, and PHP. This style of "OO" barely resembles OO. Java is probably the worst here, but C++ makes it very hard to do things right. PHP's design simply makes no sense at all. None have any useful MOPs to speak of, unless you consider "reflection" a metaobject protocol.

Smalltalk is a special case; it is obviously pure OO, but the features it provides to the programmer are less numerous than other systems. Smalltalk is what Java should have been, before Java was even conceived.

Anyway, my advice is to try them all and decide what you like best. CLOS has features I wish Moose had, and Moose has features I with CLOS had, but they are both quite usable, and allow me to model my program cleanly. It is also easy to steal features for one from the other.

The key feature of Moose and CLOS is their extensive MOP, which lets you tweak or completely override nearly every feature of the object system. Instance storage, method calls, attribute behavior, etc., etc., is all implemented in "itself". The end result is that you can extend the object system with the object system that you are extending. This is powerful because it means your extensions can be written in your extensions, making for code that works exactly how you desire. No compromises. (Moose is an object system built on top of Class::MOP, and it is possible to write Moose extensions in Moose. Excellent!)

Python and Ruby have a MOP, but it is not as featureful. Compare the availability of meta-object-protocol extensions for CL, like Elephant and Context; and for Perl, like the entire MooseX:: namespace; with extensions available for Ruby and Python. It is just not close

Even if you don't care about the MOP for yourself, you will care about how easy it makes writing useful libraries. Most of the MooseX:: modules you will find compose and work perfectly with other MooseX:: modules. The metaobject protocol makes sure everything stays compatible.

Personally, when I start using object systems other than Moose and CLOS, the implementation details get in the way of writing good code. I avoid them when possible. (If you haven't used Moose or CLOS, please don't reply and say, "oh, Java is fine, you're using it wrong". You don't know enough to make that argument.)


Clearly you've neverheard of Common Lisp


uh, the first system mentioned is CLOS (the Common Lisp Object System). So what exactly are you talking about?


Clearly you've never heard of gems!




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: