I am a software engineer at Google on the Android project and the creator of the Java testing framework TestNG. When I'm not updating this weblog with various software-related posts or speaking at conferences, I am busy snowboarding, playing squash, tennis, golf or volleyball or scuba diving. Cedric is a DZone MVB and is not an employee of DZone and has posted 90 posts at DZone. You can read more from them at their website. View Full User Profile

Why Java Doesn't Need Operator Overloading (and Very Few Languages Do, Really)

04.13.2009
| 71381 views |
  • submit to reddit

Operator overloading is a topic that never fails to generate very passionate responses, and this monster thread on Artima is no exception.

First of all, I'd like to address a common complaint heard from people who dislike operator overloading, and which usually goes along the lines of:

In Java, when I see a + b, I know exactly what is going on. If Java supported operator overloading, I would have no idea what + means.
I have very little sympathy for this argument because this example is hardly different from a method call such as o.init(). When you read such code in Java, you don't necessarily assume that it's the method init on o's class that is being invoked. You know that you will have to look at how this object is created in order to determine its effective type before you can find out which method init is being invoked.

Operator overloading is no different, and if you knew that the language that you are reading supports it, you are just going to extend this mental path to operations that involve overridable operators.

Very often, I find that operator overloading is being demonized because its uses in other languages has led to excesses. I have found that many people who dislike operator overloading can trace it back to some personal experiences where they once had to deal with code that was clearly abusing this feature. This is unfortunate, but I still think that Java is doing fine without it and that overall, it only leads to clearer code in very few and uncommon cases.

Here are a couple of objections I have with operator overloading:

  • The number of operators that you can overload is very small and each of them is attached to very specific semantics that makes little sense outside the realm of scalars and of a few other specialized mathematical concepts (e.g. matrices).

     

  • In exchange for infix notation, operator overloading severely restricts my freedom to name my methods in a meaningful way.

The most common operators that people want to overload are + and -, and they are also the operators that probably make the most sense outside simple arithmetics. I can see these two operators make sense for types that represent a collection of elements (java.util.Collection obviously, but also strings or streams). However, even in this ideal case in favor of operator overloading, the metaphor quickly breaks down when you realize that you need to supplement these two methods with ones that have slightly different meanings, such as addAll(). Would you rather have an interface that contains add() and addAll() or +() and addAll()?

Of course, there are more operators that can be overloaded, such as * or /, but I find that even strong advocates of operator overloading quickly run short of arguments when trying to justify why one would even want to overload them outside of specific algebras.

I am a big fan of clear names, and I dislike the name + for the simple reason that it doesn't carry enough meaning to explain to me what is going on. This operator is very clearly defined when it is used in a mathmatical sense but it becomes very vague when you start to extend it to concepts that supports the idea of addition in a more vague sense. For example, adding to a List is very different from adding to a Map since the latter can produce an object that's equal to the one you started with, even though the object you added is not zero. And what is zero in the sense of a collection, anyway? Doesn't it make much more sense to use add() for a List and put() for a Map?

Overall, I find that code that makes heavy use of operator overloading is harder to read and harder to maintain because it is severely restricted syntactically (forced to use specific names taken from a very small pool) and semantically (since you are using symbols that have very precise mathematical definitions, it is very unlikely that your usage will match the mental model that people who read your code have of their meaning).

I would love to see some good examples of operator overloading, if you have any to share...

From http://beust.com/weblog

Published at DZone with permission of Cedric Beust, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Jeroen Wenting replied on Mon, 2009/04/13 - 7:08am

"I have very little sympathy for this argument because this example is hardly different from a method call such as o.init(). "
Au contraire, it is very different. Unless you stopped your education at kindergarten level you will have a very strong connection in your brain between the mathematical operators and what they're supposed to do. Sadly many people using languages where operator overloading is allowed seem to not have had such an education as they do the weirdest things with those operators, things that bear no resemblence whatsoever to the way they're supposed to work. Adding apples and oranges to get raspberries is usually a pretty mild case of operator overloading abuse.

Jean-Philippe Toupin replied on Mon, 2009/04/13 - 8:16am

It might be only me but I have yet to run in a case in Java where operator overloading is needed.

Eric Galluzzo replied on Mon, 2009/04/13 - 8:31am

In general, I agree, although I have run into very infrequent situations where operator overloading would be useful and unambiguous (primarily mathematical types).

However, I couldn't help noticing that although you criticize opponents of the first argument:

In Java, when I see a + b, I know exactly what is going on. If Java supported operator overloading, I would have no idea what + means.

your own "semantic" argument is really the same:

I dislike the name + for the simple reason that it doesn't carry enough meaning to explain to me what is going on. This operator is very clearly defined when it is used in a mathmatical sense but it becomes very vague when you start to extend it...

Matthew Hall replied on Mon, 2009/04/13 - 8:44am

In my cabinet manufacturing work I frequently come across situations like this where I need to calculate door width:

Size width = Size.inch(24.5);
Size spacing = Size.mm(3);
int doorCount = 2;

In order to calculate the door width I have to do this:

Size doorWidth = width.minus(spacing.multiply(doorCount-1)).div(doorCount);

It would be really nice if Java let me do this:

Size doorWidth = (width-spacing*(doorCount-1))/doorCount;

This is just a small example, there are situations where it gets a lot more complicated than this.  The lack of operator overloading is really painful when the situation calls for it.

 

Nicholas Choate replied on Mon, 2009/04/13 - 9:09am in response to: Matthew Hall

I agree completely.  Think about how much easier manipulations of BigInteger, BigDecimal et al, become with operator overloading.  Oh and by the way, "+" doesn't always mean add, it sometimes mean concatenate...

System.out.println("foo" + "bar"); 

Kevin Dangoor replied on Mon, 2009/04/13 - 12:42pm

The case I would make for operator overloading is less for numeric types (though there are some cases where making natural numeric types that work nicer, as noted above), but for maps and lists. Maps and lists are such fundamental types that the language should have built-in syntax for handling them. In Python, I can make a class that implements __getitem__ and __setitem__ methods, and then Python's [] operator for looking up items in a map will work just fine. In Java, rather than creating special methods like that they can just use the List and Map interfaces. I think the lack of a convenient syntax for dealing with maps and lists is an annoying wart in Java.

Muhammad Khojaye replied on Mon, 2009/04/13 - 1:05pm in response to: Nicholas Choate

C++ support overload operators such as + and -. But the C++ Programmers knows that the polymorphic nature of overridden operators can create confusion, so this might be the reason why operator overloading has been excluded from the Java language. The real advantage come when Java programmers never have to think about whether the + operator adds two objects or appends one object to another.

Ian Sharkey replied on Mon, 2009/04/13 - 1:20pm

I think you've defined the problem; the set of operators to overload is set in stone by the Java spec. Languages like Prolog and Haskell allow defining new infix operations, which can help with the semantics issue. For instance, the bind operator (>>=) is a well-known infix operator that is outside the normal (+, -, *, /) operator set, and defined arbitrarily.

 If custom infix operators were available, then specific operators to Lists, Maps, Sizes, etc could be defined with precise semantics.

 Now, the question becomes, are infix operators necessary? I think so, they help clarify code, but the argument could go either way.

Timothy Twelves replied on Mon, 2009/04/13 - 4:59pm

I once came across code where i++ operator initialised the database - i felt like hurting someone badly.

This is most applicable to scientific communities and financial mathematics.  I would always argue that it is better to be explicit than be lax.

This is definately a case where java may shine with multiple languages.  Potentially java should have a language specific for formulas and algorithms that may then be leveraged within typical java code.

Honey Monster replied on Mon, 2009/04/13 - 7:50pm

Operator overloading allows a language to have a smaller set of kernel features with fewer magical tricks and special cases. As any other language feature, operator overloading can be misused. But looking at how C# can add the Decimal data type (or complex numbers, vectors, matrices) with first class support I find operator overloading really useful.

For all the doomsday prophesies, the C#/.NET community has somehow escaped them, despite the fact that operator overloading was in the language from ver. 1.0.

It is not a feature for the common programmer. But for certain libraries it can help ensure consistency, integration and first class support.

Greg Brown replied on Mon, 2009/04/13 - 8:08pm

It would be nice to overload "[]" for index operations (for example, on a Map). It would also be nice to overload "+" and "-" for adding and removing event listeners.

Howard Lovatt replied on Tue, 2009/04/14 - 1:24am

I think operator overloading is difficult to do and current approaches from other languages are lacking, that is why so many people are against it. We need a fresh approach because operators are slightly different than normal methods in that they are related to each other and in general efficiency is a concern. Let me address efficiency first, you don't want:

r = a + b + c + d

to be:

r = a.add(b).add(c).add(d)

because each plus needs to make a new object (think Strings here). You want:

r = a + b + c + d

to be something like:

final SomeType temp = a.toOperableForm();
temp.setAdd(b);
temp.setAdd(c);
temp.setAdd(d);
r = temp.fromOperableForm();

This is how String behaves, with good reason! Therefore I suggest defining:

    interface AddOperator< AO extends AddOperator< AO, A >, A extends Addable< AO, A > > {
A toOperableForm(); /* makes a deep copy and can cast if required */
}
    interface Addable< AO extends AddOperator< AO, A >, A extends Addable< AO, A > > {
AO fromOperableForm(); /* makes a deep copy and can cast if required */
void setAdd( AO a ); /* changes the value by adding an AddOperator */
void setAdd( A a ); /* changes the value by adding an Addable */
AO unity(); /* returns unity (1) */
}

Then a class that implements AddOperator can be used with operators +, +=, ++ (pre), and ++ (post) by transforming the code in a similar manner to that shown above for +. String would therefore implement AddOperator and StringBuilder Addable (with unity returning a space). Some classes may implement both AddOperator and Addable since they have no need for a builder like intermediate class.

Note how the programmer implements setAdd and unity; but all the operators +, +=, ++ (pre), and ++ (post) are defined in terms of just setAdd and unity, thus giving consistency between operations. This is the second problem, that of consistency, with operator overloading addressed; e.g. temp = a; temp + b is not the same as a += b, which happens all to often with conventional operator overloading.

Similarly the interfaces:

  interface ArithmeticOperators
< AO extends ArithmeticOperators< AO, A >, A extends Arithmeticable< AO, A > >
extends AddOperator< AO, A > {
/* empty */
}
  interface Arithmeticable
< AO extends ArithmeticOperators< AO, A >, A extends Arithmeticable< AO, A > >
extends Addable< AO, A > {
void setDivide( AO t );
void setDivide( A t );
void setMultiple( AO t );
void setMultiple( A t );
void setSubtract( AO t );
void setSubtract( A t );
}

Enables a class that  ArithmeticOperators could be used with operators like AddOperator above and also with /, *, and - as well as +, i.e. /=, *=, -=, etc.

Comparing is simpler than arithmetic because an intermediate class isn't needed because compare doesn't change any values:

/* Compatible with old code because CompareOperators extends Comparable */
public interface CompareOperators< T extends Comparable< T > > extends Comparable< T > {
/* empty */
}

Would allow <, >, !=, and == for a class that implemented CompareOperators.

Currently, if you are implementing Comparable you shouldn't use == and equals should call compareTo and equate the result to 0. This solution, of a CompareOperators interface, elevates the problem of calling ==, but the problem of people incorrectly coding equals remains (but is lessened since most people will use == and not call equals).

You cannpot simply allow Comparable to use operators since that will break old code, hence the need for a seperate interface and the need to provide wrappers for existing classes for which comparison operations are desirable.

Jeroen Wenting replied on Tue, 2009/04/14 - 2:26am

So Mathew, you think clarity is served by allowing you to add inches to centimeters to yield yards?
It isn't served. It's exactly that (and I mean exactly that) line of thinking that led to the failure of the first Ariane V rocket.
A C++ library calculating in imperial communicated with one calculating in metric, and someone forgot to do the conversion in between. POOF! A few hundred million Euros down the drain.

Mark Thornton replied on Tue, 2009/04/14 - 2:55am

Jeroen, in Matthew's example I suspect the Size objects either convert to standard units internally or carry the units as part of the object. In either case this allows the safe mixing of units. Where you get into trouble is using primitives for these values so that you can have the convenience of the conventional operators. The absence of operator overloading gives primitives special privileges and acts as a temptation to use them when perhaps an object would have been much safer.

Jesper Nordenberg replied on Tue, 2009/04/14 - 3:08am

While I agree with the opinions in the article, there are cases where operator overloading is useful. IMO, the main reason for including it in a language is to simplify the language, you don't need special handling of +, -, ?, &&, || etc. like you have in Java, but instead the operators can be defined in libraries. Since Java opted for special handling of operators this is not an argument to add operator overloading now, but for a new language like Scala it makes sense.

Another advantage of operators compared to normal method identifiers is that they have precedence. This can significantly improve readability for some code. One example is use of number classes like BigInteger, BigDecimal etc. Another example is the parser combinators in Scala, they are modelled to resemble BNF syntax and parser code would look a lot messier without operator overloading.

So, to sum things up, operator overloading has its place, but should be used sparingly and only when there is good reason for it. Note that Scala supports use of any method as an "operator", for example "ball moveTo pos", which allows nice alternatives to obscure operator symbols.

Jeroen Wenting replied on Tue, 2009/04/14 - 7:26am

Explain how you're going to define the outcome of adding something measured in one unit to something measured in another unit, Mark. When adding centimeters to inches, is the result in lightyears, fathoms, or something else entirely? It just makes no sense. If you're converting to some generic unit anyway, do it implicitly and don't leave the audience guessing as to what you're actually working with.

Mark Thornton replied on Tue, 2009/04/14 - 8:10am in response to: Jeroen Wenting

There are numerous possible rules. Where both arguments are in the same units, then the result should also be in that unit. When the units differ (but are compatible) then you could pick the units of the LHS (or RHS) or convert to the appropriate SI preferred unit (metres in this case). As the units are retained throughout you don't get the catastophic outcome that has afflicted some space missions (I seem to remember that it was a NASA Mars mission and not Ariane V that had the unit conversion bug).

Cay Horstmann replied on Tue, 2009/04/14 - 8:25am

"I would love to see some good examples of operator overloading, if you have any to share... "

 Check out the Scala combinator parser library. It would be really tedious to use with the traditional method invocation syntax.

 Of course, that's Scala, not Java, where you can define your own operators. In Java, there is a fixed set of operators, and overloading is much less interesting. Maybe it really is time to leave Java alone. 

Ruslan Shevchenko replied on Tue, 2009/04/14 - 12:19pm in response to: Cay Horstmann

Exists many structures whith characteristic of algebraic  ring (Matrix, Complexes, BigDecimal, etc) which can be user-defined and operator overloading is a big plus to have. 

 

Mark Thornton replied on Tue, 2009/04/14 - 2:11pm in response to: Ruslan Shevchenko

On the other hand most programmers are not mathematicians and wouldn't know a Ring or Field if it bit them.

JeffS replied on Tue, 2009/04/14 - 2:22pm

Originally, Java's design goals were reactions to C++ complexity. 

Not only did Java bring garbage collection, and more a pure OOP design (for better and for worse), but the designers deliberately stripped out stuff C++ could do (operator overloading, multiple inheritence, templates, etc), knowing full well that those things could be useful in some cases. 

Instead, they opted for a simpler design - one that is easier for the programmer to comprehend and make use of, and easier for teams to make the code more maintainable and extensible.

And, I think it's hard to argue, they made the right choices.  Java remains the number one language in terms of overall usage.  

But then there is a "keep up with the jones" push to keep adding features that C# has, or Ruby has, or whateverelse has.  But adding features, while often times useful for corner cases, add to the complexity of the overall comprehendability and maintainability of the language.

There was an interesting interview with Anders Heilsberg (C# designer and principle maintainer) at the O'Reilly site last week.  He was very in favor of continually adding features, to keep the language "current", and sites gains in some areas (like being able to do LINQ thanks to C#'s Lambdas).  But he also admitted that there is a cost in complexity.  For instance, the C# language spec is now over 1200 pages (that exceeds even C++).

When I compare Java and C# (and code in the two), I see plusses and minuses, regarding Java's more conservative feature set versus C#'s more cutting edge, heavy feature set.  Sometimes, a C# feature (that Java doesn't have) is cool and useful. But more often than not, I find most features that C# has and Java does not, to be somewhat difficult to comprehend, and not directly useful.

 And, IMHO, Java's success in the markeplace, particularly in the area of large enterprise computing, is in the easy comprehendability, and the great ease of maintenence that comes with that.  That's where a more conservative feature set really shines - comprehendability and maintainability.  And those attributes are really really valuable in enterprise computing - where large projects have to be maintained for long periods of time, and by lots of different developers that come and go.

 Besides, more cutting edge features can be easily had by using other JVM supported languages like Groovy, Scala, Clojure, and JRuby, etc, as well as using various open source frameworks (like Spring AOP).

Mike P(Okidoky) replied on Tue, 2009/04/14 - 5:06pm

Java's success is under constant threat by the constant hammering by people that desperately want things to look suave. Operator overloading, weird strange bizarre convoluted closure constructs. All these things would make Java lose its value. The value is simplicity. It work well in team environment, probably better than any other language in use. Right now mediocre programmers still barf up frustratingly crappy code, but I can for the large part leave it for what it is, crappy code ---- that actually works ---- what a concept!

But with a language like C++ it'd be causing way more havoc. Endless crashes and strange behaviors. We must steer clear from the mistakes that C++ made.

I actually like coding in C++. It allows me to create smart suave code in the way I think works well. Problem is, others refuse to pick up on this and create their code in my way, with my choice of overloading, my way of using templates, encapsulating things my way - the good. But, other C++ programmers want to do things their way. It allows them to introduce too much dialect, too much "style" into the mix. They completely ignore my suave templates and create yet again another version of string or a smart pointer and whatnot. I left this identity crisis style code behind eons ago, let's keep it out of Java thank you very much.

Alex(JAlexoid) ... replied on Tue, 2009/04/14 - 5:39pm in response to: JeffS

Instead, they opted for a simpler design - one that is easier for the programmer to comprehend and make use of, and easier for teams to make the code more maintainable and extensible.

And, I think it's hard to argue, they made the right choices.  Java remains the number one language in terms of overall usage.  

But then there is a "keep up with the jones" push to keep adding features that C# has, or Ruby has, or whateverelse has.  But adding features, while often times useful for corner cases, add to the complexity of the overall comprehendability and maintainability of the language.

 

I agree with your comment and I am definitely an opponent of operator overloading. There is one issue though. The "extension classes" for math are the ones that really would have it better with +-/* operators work on them, sample being work with BigDecimal.

And sometimes new features help with simplicity. Like incorporating events into the language would be a nice feature. Or properties(no need to those boilerplate getters and setters = less possible bugs).  And a good example would be java beans with property change events. Really, everyone needs to write a LOT of boilerplate code.The result? Mostly noone uses that functionality.

Next. There is this little thing called the parallel revolution. You probably heard of it, and your computer probably has more than one core or multiple threads per core (even my netbook can do 2 threads at a time!).
And currently that is the most complex issue with any programing language. So there is a need for change, though only in that particular area - concurrency. So far Java is Ok in that are, but slipping fast.

Alex(JAlexoid) ... replied on Tue, 2009/04/14 - 5:51pm in response to: Mike P(Okidoky)

Java's success is under constant threat by the constant hammering by people that desperately want things to look suave. Operator overloading, weird strange bizarre convoluted closure constructs. All these things would make Java lose its value. The value is simplicity.

 Right. Sounds very much conservative. On the topic, I am very much against operator overloading.

Talking about simplicity. How simple is it to create a Java Bean with Vetoable Property Change Events and Listeners? A lot of manual labour. Eclipse, the one I checked right now, does not auto generate that kind of code. Only geters and setters.
Now there is where simplicity is not so simple.

Next. As I mentioned above, maybe you lost out to this new thing called the parallel revolution? You know, Java made it really simple to write multithreaded programs back in the day.(I really only started to programm with concurrecy in mind with Java and those simple concurrency constructs.) But now we see that that simplification is nolonger that simple to most of the develpers. Stop ranting about the closures. Those can be basically lowest level job constructs(paralellized when possible) and very valuable.

Ruslan Shevchenko replied on Tue, 2009/04/14 - 5:57pm in response to: Mark Thornton

Not sure - it's very simple.

From other side, most programmers prefer have potential problems with floating point applicability for phinance operations, than use safe BigDecimal, becouse Java have no operator overloading.

Jeroen Wenting replied on Wed, 2009/04/15 - 1:20am

In other words, Mark, you're adding a lot of implicit behaviour like unit conversions into your operators which makes them utterly unpredictable to those not intimately familiar with your way of thinking.
It wouldn't surprise me if NASA had their own unit conversion problems, but ArianeSpace certainly did. So did Airbus btw, sorta. During the design phase of the A380 different offices in different countries used different settings (metric in Germany and France, Imperial in the UK) on their CAD workstations. Due to rounding errors the resulting components didn't fit properly when assembled, something that only became apparent after those components had been fabricated and shipped to the assembly line. Holes for bolts and cable conduits didn't line up, things like that.
That software had done some implicit unit conversions when matching components in software, implicit conversions that were of course not done when the manufacturing data (including tollerances) was sent to the CNC machines and other tools on the factory floor (which in each country used the same measurements as did the CAD workstations).

Java's success is under constant threat by the constant hammering by people that desperately want things to look suave. Operator overloading, weird strange bizarre convoluted closure constructs. All these things would make Java lose its value. The value is simplicity.
Well said, the integrity of the language, the cleanliness of the syntax, is being compromised to "look cool", to add things "because C# has it" or "because Ruby has it", to stroke the vanity of some people who in their ivory towers want to get their name on a JSR without the faintest idea of how the language is used in the real world.

Ricky Clarkson replied on Thu, 2009/04/16 - 6:07pm

Haskell does it quite well, with some interesting restrictions. +, -, *, /, come as a bundle called Num (a type class), so you can't have a type with + without *, etc. They are restricted so that, say, Int + Int must return Int. Strings and collections cannot be added to with + (++ is used instead, which has its own limitations). I think this would be reasonable and would solve most of the pain points in Java where people want operator overloading, e.g., currentDate + days(3), etc.

Uthman Odunewu replied on Sat, 2010/06/19 - 9:41am

operator overloading definitely has its pros and cons,i program in c++ and java and definitely know that operator overloading makes work easier sometimes than function/method calls.and more so inn some languages like c++,you need to overload the I/O operators to allow input and output of user defined types,java provides for output with toString, but that is java.if it has been included in the language,the programmer will then choose if he needs it or not.But all the same java seems good without overloading,you don't need to worry about an overloaded operator for different user defined types which makes a program easier to maintain and debug.

Javin Paul replied on Mon, 2011/08/29 - 8:28pm

I think its not that Java doesn't need it , we have seen many example where operator overloading can make code more readable and fits naturally. but in my opinion Why Java doesn't support operator overloading because  if you allow programmer to do operator overloading they will come up with multiple meanings for same operator which will make the learning curve of any developer hard and things more confusing and messing. Its been observed that there is increase in programming errors when language supports operator overloading which in turn increase the development and delivery time and since Java and JVM has taken most of developers responsibility in memory management by proving garbage collector it doesn't really make sense to left this feature to pollute the code and a loop hole for programming errors.

Thanks
Javin
How HashMap works in Java

 

Mark Tarrabain replied on Sat, 2014/07/26 - 3:01pm

re: "The number of operators that you can overload is very small and each of them is attached to very specific semantics that makes little sense outside the realm of scalars and of a few other specialized mathematical concepts (e.g. matrices)."

This is true... but the number of actual use cases where these data types would apply is very large.

Scalars.  Which type? complex? rational?  or what about biginteger or bigdecimal types?  What  about rationals that are described in terms of big integers?

Matrices.  Again... what type?  Are its contents doubles, or integers or some other type of scalar?   What about matrices of matrices?  What about matrix implementations that are optimized for a particular size or shape?

In fact, an in depth analysis would reveal the number of types for which operator overloading may actually be useful and result in more readable code than using function calls everywhere is unbounded and infinite.

Finally, the actual underlying data types involved in a process should really just be considered an implementation detail anyways, and not usually necessary to understanding how the problem that the code is expressing a solution for is working.  Most people do not generally care, for example, about what logic circuits are involved when they issue a command to a cpu to multiply two numbers together... neither, then, should a programmer generally need to concern themselves with what the underlying types involved are when they see a * operator used in the context where multiplication would be assumed.  Simply assume that the multiply operator knows how to sanely multiply whatever values it has been given, and leave it at that.  Sure it's *POSSIBLE* that the programmer made the * operator do something else other than what makes the most intuitive sense in context, but it's equally possible for a programmer to write a function called 'multiply' that doesn't actually do any arithmetic at all.

Ultimately, the only reason to not have operator overloading in Java rests on a matter of the designer's preferred personal style, rather than any genuinely objective arguments against it (James Gosling, the designer of Java, even explicitly stated that this was the case in at least one interview)... but  when a language forces their own views on everyone who might try to design with that language, it is invariably going to limit the usefulness of that language for different people.  Because different people think differently, and whenever you try to make them all think in the same way, you prevent some level of creative or original thinking, only standing to limit what people might have otherwise accomplished.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.