Not until they support more than 2^31 elements in my array!
Java for Everything
241–250 of 344 posts
Re: Java for Everything
#242Earlier quoted context omitted.
I suspect readability isn't a big priority for you. Here's how I'd write this, lambdas or not: public static List sortDescending(List ints) { ints.sort(new Comparator () { @Override public int compare(Integer o1, Integer o2) { if (o1.equals(o2)) { return 0; } else if (o1 My personal perspective is that your use is a typical abuse which turns simple code into something unreadable and overly complex. This makes code ha…
one line is way more readable than 7 lines taking up valuable vertical and brain space it could also be accomplished with return -1 * o1.compareTo(o2);
No, you can't. In particular -1 * Integer.MIN_VALUE == Integer.MIN_VALUE.
Re: Java for Everything
#243I maintain and develop a large code base written in (mainly) Python with some C thrown in here and there. It was maintained and developed by a number of people before me over several years, who have come and gone. And yes while there is rust and cobwebs, I don't attribute any maintenance issues to the fact it is Python or a dynamic language, but rather higher level design decisions about interfaces and boundaries and responsibilities. Often some module that wasn't supposed to know something all of a sudden needs to know due to some new/changed requirement, and redrawing data flows and structures to ensure the right information is where it needs to be can be challenging. But this situation can be applicable to a system developed in any language - if anything Python's flexible data structures makes it easy to accomplish such re-engineering.
The last time I tried to do anything in Java, I was instructed to "just run the maven build script". After watching that flaming train wreck I walked away and haven't looked back since.
Re: Java for Everything
#244The problem with 'use the best tool for the job' is that everyone's 'best tool' is selected from a relatively small pool. The choices for some use-cases have a multitude of similarly worthy choices. Thus, not likely really the best available. Just another subjective choice.
That said, I don't understand the obsession with 1 language to rule them all that the Java and Javascript crowd seem to share. I do understand having 1 go-to that you reach for to build projects. Something broadly applicable like Java, C# or Python.
But shell scripting in Java? Seems a bit extreme, I'd never bother. You can pull out a Python/Powershell script that does whatever you're trying to do and do it much easier and faster. There's a reason Windows has C#/Powershell, and Linux has (as an example) Java/Python.
Re: Java for Everything
#245First of all, I want to say that if you like Java, and know it well, and believe it to be the right tool for your particular application, that you should absolutely use it.
> That Java is the right language for all jobs. (Emphasis his.)
> The advantages of C and C++ [...] don’t apply to my work.
So, choose the right tool for the right job.
As for the examples given:
> At one company I wrote a simulator that allowed me to run my Java services without a fully-functional site. (The unit under test is Java, so it makes sense to write the simulator in Java, rather than Javascript)
> My partner Dan Collens suggested Java [for a log parser], since it’s right there and we know it and it’s fast. (The log parser is used so often that the amortized opportunity cost of developing in Java is more than paid off by faster processing, therefore Java is the right tool for the job)
> And finally, I went to write a simple program that put up a web interface. (This is something the author has done many times before and knows how to do well in Java, and his primary goal is getting it running ASAP, therefore Java is the right tool for the job)
I still think you should choose the right tool for the right job. It just happens that the author's work is constrained in such a way that Java turns out to be the right tool in most, if not all cases.
Honestly, though, I would rather choose the same tool for a job each time by deciding that it's, by merit and virtue, the best tool for the job, rather than relying upon the author's silly heuristic.
Re: Java for Everything
#246There's the language and there's the ecosystem. A lot of negative feelings that still linger are, IMHO, directed more at some of the painful historical aspects of the ecosystem: J2EE XML configuration hell, EJBs, bloated application servers, XML for everything, JAX-WS, SOAP, ant, classloader problems, maven dependency hell, 10 different logging libraries, etc... A lot of this stuff truly sucked. But I feel things hav…
Lambda expression for comparator can be further shortened (for numeric types, descending):
( o1, o2) -> o2 - o1
No ternaries or else-ifs required. Swap o1 and o2 if you want ascending.
Re: Java for Everything
#247Earlier quoted context omitted.
Java's start up time makes it pretty crappy for command line utilities.
When did you last try it? Startup time was optimised heavily some time ago and nowadays I don't notice any real difference unless I wrote some toy app and used "time". The JVM starts fast enough that you can write command line utilities just fine.
LuaJ is an order of magnitude slower to startup than Lua, IIRC. Could be LuaJ's fault, not Java's, of course.
Re: Java for Everything
#248There's the language and there's the ecosystem. A lot of negative feelings that still linger are, IMHO, directed more at some of the painful historical aspects of the ecosystem: J2EE XML configuration hell, EJBs, bloated application servers, XML for everything, JAX-WS, SOAP, ant, classloader problems, maven dependency hell, 10 different logging libraries, etc... A lot of this stuff truly sucked. But I feel things hav…
Or in Clojure, it's (sort #(compare %1 %2) coll) To reverse it (sort #(compare %2 %1) coll) Where coll is the collection you want to sort. Same caveat applies with: (reverse coll) Try as I might I can't get Clojure to bench slower than its comparative Java. I see no reason to program in Java anymore wherever possible.
Java 8 counterpart to you Clojure variant is actually:
coll.sort(comparing(identity(), Integer::compareTo));
Or:
coll.sort(reverseOrder())
Re: Java for Everything
#249"No, actually, typing Foo one extra time does not “really suck”. It’s three letters"
Hah, if only it was always just three letters... :)) Usually more, and it's called NOISE. That's why C# has "var" and C++11 has "auto" (with all the benefits of strong typing still in place, obviously)
"And other languages like D and Go are too new to bet my work on."
I'd argue that D isn't really that knew, only niche. It's been around for over 10 years now.
Re: Java for Everything
#250Earlier quoted context omitted.
Speaking of - how is Groovy doing these days? I looked at the Groovy webpage and I saw ads splattered here and there - never a good sign, I also see that the mailing lists are pretty quiet. Is Groovy dying?
Whether Groovy is dying depends on how other languages do (like Javascript or JRuby). Groovy has found its niches and will not die soon. For instance, Gradle is built around it or Jetbrains is using it building IDEs like IntelliJ. The ads are probably helping to finance some of the codehaus infrastructure.
A new niche might be: Groovy on Android