Why java over other languages?

The initial lambdas proposal used a fat arrow (=>), similar to most other languages that support closures. But it looks ugly when the lambda expression contains a comparison:

// Fat
x => y <= x

// Thin
x -> y <= x

But honestly, if I pretended other languages didn’t exist, the lack of a type on the e parameter is much creepier from a Java perspective. I’m glad no-one complained about that. :stuck_out_tongue:

Java is way more elegant and cleaner than C++ on many, many levels.

Java is often simpler from a tooling/debugging perspective than Scala. However, Scala is a much more elegant language and I would chose Scala over Java for certain tasks.

The Java community. Ultimately, you can generally do whatever you want in any language you want, but a big factor is the community around the tools. Python has an amazing community for science type work. Java has an amazing community for distributed computing, data-centric workflows, build tools, etc. Games and graphics are actually one of Java’s weaker sides, but it is still what I would choose over C++.

I really like Java over other languages because it is a lot cleaner and easier to understand. Java definitely can be verbose depending on what tasks you want it to do. But what it lacks in code writing time, it makes up for in compile time. It rewards you a lot better for clean code than the other languages do (less bugs), and can hit more platforms at the same time.

I don’t have a problem with lambdas. It adds an extra level of easiness for those who need access to it. I think it would be a lot more ridiculous if they enforced lambda’s. What these remind me of is the ternary operator…


int a = 0;

//normal code
if(a > 5)
     a = 0;
else
     a = 4;

//ternary
a = (a < 5) ? 0 : 4;

I would like to argue that it is one of the least used features of Computer Science, followed by the bit shifts (but that is just me). However, just because they are there, doesn’t mean that Java all of a sudden is an unreadable mess. Yes, adding many of these might make your code unreadable, just like lambdas might. But, it isn’t a bad thing, because you have the option of whether you want to use them or not.

So, in short, it doesn’t really matter. If you think your code is unreadable, you can just swap in a more readable version. For those who want to use them, let them use the short hand method.

I can’t honestly answer this, I was working with Java too long and I am a really late adopter to anything new.

I can say that I came from C/C++ to Java and the new use of -> would have felt very confusing. In C the -> is the dereference operator for pointers-to-structs.

I was happy that the *, ->, and . operators from C became . in Java, that was a notable simplification. Anyways, I guess it’s already decided and I assume after a period of boycott, I’ll finally have to use the -> operator when I must maintain or want to use code that was written by early adopters.

mature
free
great tools
simple (got less simple after generic wildcards)
established - large amount of tools & libraries that are mostly free.
familiar syntax, lakes it easy to learn.
You can run the same code on various problems.
It changes slowly (perhaps also a negative.). But IMO compared to micrsoft projects they change their mind all the time. e.g. bye bye winforms, bye byesilverlight.

Java hits a pretty sweet spot as a general programming language.

On the negative side, it’s suffered from chronic underinvestment, particularly on the desktop.
it’s overly verbose too.

It’s interesting to see what comes next, will existing languages handle the proliferation better (e.g by adding functional constructs), or whether the ‘more’ functional languages win out.
Interesting times1

Except that those two alternatives will almost certainly not produce the same bytecode. The interesting thing about lambdas is that they’re not just syntactic sugar for inner classes (eg. use of invokedynamic), with potential for performance improvement as well as being less verbose.

The first is easier to read. If you’re trained to recognize indents you can “read” it in one glance. For the second one, I have to scan the screen horizontally and let my eyes stop in 3 places. It would be worse with more than one line. Both are poor choices. The reason I use Java is because I can determine the function of a block of code in one second just be looking at the structure or quickly scanning over it and can hunt down the code I am looking for in two seconds. Defining event listener methods in the same place they’re used means that, if I am looking for the initialization, I have to find it between irrelevant code for various event listener methods or, if I am looking for the implementation of the methods, I have to find it between irrelevant code in some constructor or initializer function.

Here is an alternative that is much easier to read.

Good grief this is turning into one of those threads again. ::slight_smile:

Java VS Lambda, start! lifts spear

A wild ThisLanguageUsesTheWrongAssignmentSymbol appeared. Fight, Switch, Item, or Run?

@sproingie: same old problem. Most programmers have only been exposed to one kind of language. C++/C#/Java et al. are all hammers…they only seem significantly different to people who think all languages are hammers.

Nothing wrong with hammers if nearly all your problems are nails :persecutioncomplex:

Cas :slight_smile:

// With lambdas
button.addActionListener(e -> System.out.println("Button pressed: " + e));

My main issue with this is that I have to guess what the type of ‘e’ is.
I really hate it when a language hides important stuff from me.

@Cas: sure, but my point being it’s hard to talk to hammer folks about hammer’s with “that thingy that pulls out nails” if they never seen one…much less why one might want a saw from time to time.
@erikd: mouse-hover (assuming you somehow don’t know off the top of your head)…you mean guessing like that? :slight_smile:

Yeah see: I would never do the short form, or ONLY in black boxed algorithms.
I think its fine if people like and use it; I however think its very hard to ready for a human, and I dont mind more lines just to make it clear… to humans. Reading code is really hard as a human D:

I agree, its not perfect; You shouldn’t have to guess.

er, doesn’t e have to be an ActionListener, that being the method sig? And the thing is you don’t need to know it anyway, the whole idea is that it’s completely unnecessary to even know…

(btw I quite like lambda! I just want to see it being used in anger for a while to get a feel for it all)

Cas :slight_smile:

No, e is an ActionEvent, the argument of the actionPerformed method of ActionListener. The lambda expression makes the method itself and the inner class instantiation go away.

Btw, lambdas allow an explicit type, so you could write it as:

button.addActionListener((ActionEvent e) -> System.out.println("Button pressed: " + e));
// or
button.addActionListener((ActionEvent e) -> {
    System.out.println("Button pressed: " + e))
});;

This is a good example of a language feature that allows you to be more explicit and less dense if you wish so. The problem (imho) is when you can’t do the opposite.

Indeed, it compiles down to indy in the current JDK 8 builds. I should have said that, at runtime, it compiles down to the same-thing in the worst case scenario (if the JVM can’t use a method handle and creates an instance instead).

With the new type inferencing stuff in Java being introduced to make lambda easier, I wonder if it is yet possible to do


Object s = "some string";
String blah = s; // Type cast is implicit
CharSequence cs = s; // likewise
Rectange r = blah; // but this cannot succeed so compiler error thrown as usual

and if not why not?

Cas :slight_smile:

Yes, I think a lot of people are missing the distinction, and think

whereas because lambdas aren’t classes (or instantiated objects in the majority of cases) there’s the potential for (significant?) performance improvement rather than just being less verbose. That missing “new” is important! I can take or leave the ActionListener example - it’s the collection transformation, parallelization uses, etc. where this gets interesting.

Sometimes you’ve got so many nails, a nailgun will stop your arm falling off! :wink:

[quote=“princec,post:58,topic:40839”]
Because it’s not really type inference. The compiler just lets you omit information that’s already there.

Real type inference would require extensive code analysis at compile time, which would slow down javac. Imagine a condition or loop before the assignment to blah that assigns something other than a String to s. Also, it wouldn’t offer much benefit without a new val/var keyword (or C++11’s auto).