There are some things that I kind of feel torn about, like operator overloading. I left out operator overloading as a fairly personal choice because I had seen too many people abuse it in C++. I've spent a lot of time in the past five to six years surveying people about operator overloading and it's really fascinating, because you get the community broken into three pieces: Probably about 20 to 30 percent of the population think of operator overloading as the spawn of the devil; somebody has done something with operator overloading that has just really ticked them off, because they've used like + for list insertion and it makes life really, really confusing. A lot of that problem stems from the fact that there are only about half a dozen operators you can sensibly overload, and yet there are thousands or millions of operators that people would like to define -- so you have to pick, and often the choices conflict with your sense of intuition. Then there's a community of about 10 percent that have actually used operator overloading appropriately and who really care about it, and for whom it's actually really important; this is almost exclusively people who do numerical work, where the notation is very important to appealing to people's intuition, because they come into it with an intuition about what the + means, and the ability to say "a + b" where a and b are complex numbers or matrices or something really does make sense. You get kind of shaky when you get to things like multiply because there are actually multiple kinds of multiplication operators -- there's vector product, and dot product, which are fundamentally very different. And yet there's only one operator, so what do you do? And there's no operator for square-root. Those two camps are the poles, and then there's this mush in the middle of 60-odd percent who really couldn't care much either way. The camp of people that think that operator overloading is a bad idea has been, simply from my informal statistical sampling, significantly larger and certainly more vocal than the numerical guys. So, given the way that things have gone today where some features in the language are voted on by the community -- it's not just like some little standards committee, it really is large-scale -- it would be pretty hard to get operator overloading in. And yet it leaves this one community of fairly important folks kind of totally shut out. It's a flavor of the tragedy of the commons problem.
http://www.gotw.ca/publications/c_family_interview.htm
Annyira imádom, amikor azért szar/használhatatlan/trágya/rosszul tervezett... egy nyelv, mert nincs benne valami, amiről a vélemények szanaszét megoszlanak. Hasznos időnként? Igen. Gyakran előfordul, hogy túlzásba viszik a használatát és legalább annyira ocsmány és olvashatatlan lesz a kód, mintha simán függvényekkel csinálnák? (nem lennék meglepve, ha valahol production rendszerben a Person típuson a +/- overloaded lenne és másik Person-nal a házasodást/elválást jelölné)
Nagyon jó hozzáállás az, amit Stroustrup-tól mindig idéznek, hogy "a programozó kezébe kell adni a döntést még ha a rossz döntést hozza is", evolúciós szempontból is jó lenne mindenkinek egy pisztolyt adni a kezébe, hogy ha akarja lábon lőhesse magát, csak mondjuk egy library kódban idiótán beszúrt OO azt jelenti, hogy az eredeti fejlesztő mindenkit lábon lő, akinek használnia kell majd a kódját.
De már egyszer valahol lent/fent leírtam: szerintem is NAGYON INDOKOLT ESETBEN kifejezetten jó lenne NÉHÁNY operátort felülbírálhatóvá tenni (meg is lehetne csinálni [byte kód szinten] backward compatible módon pl. a Java 9-re), de attól, hogy a nyelv nem biztosít egy eszközt, ami NEKED személy szerint tetszik, még nem feltétlenül szar a nyelv.
Nekem pl. a Smalltalk kifejezetten tetszik a tényleg minden objektum, de nem híresztelem, hogy a Java/C#/C++/... rosszul tervezett, csak azért, mert pl. primitív típusokhoz kell autoboxing, hogy objektumként kezeljem, vagy hogy nem tudok pl. egy metódusnak egy feltételt simán paraméterként átadni.
Edit: Ja, és még egy. Nyugodtan lehetne alternatív fordítót írni, ami akár csak annyival tud többet, hogy van benne OO, mégse tolonganak az OO-kiterjesztett javac forkok.
BlackY