The lack of multiple inheritance, or at least some form of mixins makes any language broken in my opinion.
Here's my example that chaps my butt:
Class CartItem Inherits Part
Class CartGiftCert Inherits CartItem
Doing good so far. A cart item is a part plus some extra functionality. A cart gift cert is a cart item plus some extra gift cert information. Single inheritance. Everyone is happy right?
Class OrderItem Inherits CartItem
Class OrderGiftCert Inherits CartGiftCert
Now we're screwed. The order item acts like a cart item plus some order specific data. Fine. Now the OrderGiftCert has a hard choice to make. Do I inherit from CartGiftCert to get all of the good gift cert data/logic, missing out on the OrderItem specifics because I can't inherit from that too? Or does OrderGiftCert inherit from OrderItem, and miss out on all the data/logic from CartGiftCert? All we need is
Class OrderGiftCert Inherits OrderItem, CartGiftCert
"Make an interface" you hear. Great. I can make an IGiftCertItem interface, or an IOrderItem interface. In either case, now I have to implement the another class to house the logic behind those interfaces for reuse to people don't have to duplicate code. To make matters worse, everyone still has to waste time writing code to map properties/methods in/out of the implementation classes.
All problems that could just be solved with multiple inheritance. Interfaces have their place and this isn't one of them.
So, I could suck a heap of code out of the CartItem subclasses into global modules, but then you something out there that doesn't make sense all on its own.
Hey, let's just make a GiftCert that Inherits Part...but then CartGiftCert and OrderGiftCert could inherit that...but way, then they couldn't inherit CartItem and OrderItem.
I like the framework. I like the tools, but stuff like this just irks me. If Perl can do it, why can't you you stupid framework.