Viktor Klang wrote: > > Even so I: > > 1. Reject the notion that it is acceptable to require syntax > highlighting for a language to be meaningful. > 2. Fear the brevity trap. > * Operators are only 1 character. Programmers are > lazy. Undisciplined programmers in cases will take > most any random few operations and add them to their > API as operators rather as descriptive method names. > It's just too tempting. > > Neither item applies to a 1 man project, but when faced with a > large project with 100's of developers of a wide range of skills I > want the language to tend to eak some level of readability out of > even mediocre developers. This is not for their sakes but rather > to protect the rest of the organization from them. > > > So operator overloading is bad because people have HR problems? > Don't blame the gun, blame the shooter. Sure -- by this same measure C++ was fabulous apart from the lack of garbage collection.
Even if you only have the brightest bulbs on your team, you're likely to have a some that are a bit overly creative -- who just like to overdo things period. In Java I've seen these types thrust this activity into over-engineering -- 6 classes (several factories and interfaces and layers) where one would do. One can do that in any language. This is really bad -- but in other languages there are worse avenues for such excess. I've heard the saying that you shouldn't dumb down a language for your dimmest bulbs at the cost of your bright ones. It's not that simple, though. If you have a sizable team without a /really /rigorous, zealous code review (and mandatory code amendment) program you're not ready for a language with features like operator overloading. Sure you can say "don't use those language features", but unless the language provides a means of easily enforcing this, you're left to do so manually via heavy code review or via home-brewed compiler-like tools to reject undesirable language features -- unless your team is exceedingly small, of course. Don't get me wrong -- small, well-honed teams are great. If that's not what you have and the culture does not lend itself to draconian code review, then extra language features like operator overloading /are/ harmful. -- Jess Holle --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
