/Java/

because blueray

>>57080043
easy multiplatform compatibility since it runs through an easy-to-install VM

Java started out as a simpler version of C++, but it is still too complex; there are too many "sharp edges". Here are a few of the things that bug me and many of my students (all are small things, most not unique to Java, but they still add up to a lot of unnecessary complexity):

Primitive types are not classes and primitive operations are not methods. Java insists that operators work only on primitive types and methods work only on objects. Well, except + works on Strings. But other than that, you must use methods to work on objects. For example, you use .equals to compare two objects for equality. Well, except you use == to compare objects to nil. This also means Java needs wrapper classes, since it needs a place to define operations on types like integers and characters. So if you want to get a string representation of anything, you send it a toString message with no arguments. For example, to convert a variable x to a string, you do x.toString(). Except if it's a primitive type, then you have to use the static toString method in the corresponding wrapper class, eg, Double.toString(x). Each primitive type has a corresponding wrapper class with the same name, but capitalised. Except for int and char, whose wrapper classes are called Integer and Character, for no good reason I can think of.

>>57080141

Arrays. Some of the same problems afflict arrays, eg, they don't have methods. Well, except for length. That's like a method for arrays, except that it doesn't have parentheses. So I guess it's an instance variable, except that you can't assign to it.
Static methods. Java tries to be a strictly OO language (but fails; see the previous points), so every method needs to be part of some class, and every message needs to be sent to some object. But what if there's not really any object to send the message to? Then the method should be static, which really means it's not object-oriented at all -- it's basically a procedure. Students often create instances of a class with no data so they can send it messages, when they really want a static method.
This. Every other datum you pass to a method has a formal parameter name you can use to access it. Why not do the same with the object receiving the message, rather than creating the need for a special 'this' keyword? Students also get confused that an expression foo is equivalent to this.foo (referring to the instance variable foo), except if there's also a local variable or parameter named foo, in which case foo refers to that.

>>57080141
>>57080150

This

File: 14758880102320.jpg (105KB, 409x515px) Image search: [Google]

105KB, 409x515px

Two main reasons:

It's a legacy language that hasn't been extremely well designed in its first versions, but that has aimed for a very high backwards-compatibility level from the beginning. This combination makes it a very complex, complicated, and quirky language today. Not as bad as C++, but not as lean as C# or Scala.

E.g. Follow discussions about how generics or default methods were introduced... Definitely not how they would have been designed if they had been designed in a new language.


It's an incredibly popular language. People hate everything that's popular (MongoDB, MySQL, Java, Windows, Eclipse, presidents of countries, actors, large corporations, etc.).

See, if you're a hater, you want an audience. And you don't get an audience when you hate something extremely niche. Such as the Elm language, for instance. So you're better off hating something popular.

>>57080141
>>57080150
>>57080195
Feel kind of bad that you gave pretty long answers to a troll thread.

>>57080043
>the most universally hated and despised programming language
C++ is easily that. Hardly anyone "likes," Java, but they don't hate it or despise it. Many people hate and despise C++. Other languages are also hated, but most of them are relatively unpopular anyway so few people even bother with them and the hate is only among a few who have to use it.

C++ is widely taught and, although not as much as ten years ago, still fairly widely used. It's getting better over time, but is still the most wide-ranging clusterfuck of a programming language trying to do everything under the sun and totally mastered by nobody.

tl;dr: Java became dominant because its primary competition was C++ and it is absolutely hated relative to Java.

File: Bjarne-Stroustrup-Quotes-1.jpg (110KB, 2000x872px) Image search: [Google]

110KB, 2000x872px

>>57080043

>>57080150
>this is bad
Like in python 2, the self and this statement helps the programmer to figure out the scope of variables. Programmers who don't understand instances and scope should not be allowed to do object oriented programming.

>>57080043

It's relatively easy to learn, it was object-oriented when being object-oriented was in fashion, it has a relatively low complexity ceiling, it has garbage collection built in, it's mostly cross-platform out of the box, and most importantly it has immeasurably fewer sharp edges than something like C++. And that's all you really need at the enterprise level.

There, You don't need paragraphs of aspergers to explain its popularity.

All these stupid and fucking wrong posts.

It succeeded because it was marketed to management. Whether or not the developers thought it was any good is irrelevant.

>>57080043
>the most universally hated and despised programming language?
maybe by rabid autists, functioning adults would never misdirect their rage at something as silly as a programming language

>>57080141
>Well, except you use == to compare objects to nil
object.equals(null) is perfectly acceptable
== on non-primitives compares instances/addresses, which would obviously work for null

in general, those """sharp edges""" you pointed out are pretty small and easy to get used to
there are way more serious problems with Java than primitives vs objects

Java isn't even that bad desu just verbose and kinda clunky.

>>57080043
It's hated because people don't know stupid languages like swift

>>57080141
.equals is valid though, because you want to see if two objects have the same contents. == is and should be reserved for checking whether two variables refer to the same instance of an object (ie same location in memory).

The operators thing is a valid point, as is the wrapper classes thing. I remember being a bit confused when I first learned Java and we had to use them for ArrayLists.

>>57080150
I don't really understand your complaint about static methods or 'this'. Static methods are good for grouping methods together in a class when you don't really need any data associated with them. You could still define them as regular methods if you want, it just might not be as organized.

Is your complaint with 'this' just that you think it should be named differently? Like if I have a class called 'Rectangle', I should use 'Rectangle.width' to access the class variable? In my opinion it makes more sense to use 'this' because you're not accessing something about the class, you're accessing something about this specific instance of the class. For example:

public boolean widthEqualsWidthOf(Shape otherShape) {
    return (this.width == otherShape.width);
}

>>57080043
>>57076424
>>57069758
>>57062554
>>57063009
>>57053405
>>57069529
>>57067644

what did they mean by this?

>>57080367
>Programmers who don't understand instances and scope should not be allowed to do programming.
ftfy

There's a culture of bloat in the Java community. Architectures like Spring, Hibernate, OSGi, and even web frameworks like Play propagate this bloat with too many configuration files and too many abstractions. Configuration files offend the idea of static types, and too many parts offends basic human psychology that there's a limit to how many pieces of information can be in working memory. Each moving part is literally taking the place of some valuable work being done effectively. The next generation of JVM Languages like Scala eliminate some of that thinking in the language: make singletons easy, automate idioms, make it possible to write C-style "global" programs succinctly. I hope this direction continues for succinct, lean-and-mean libraries for the JVM.

Fuck Java VM bullshit