Why I like Java | Hacker News Reader

Why I like Java

blog.plover.com

14 pointssuraj13 comments

"write a program that copies standard input to standard output":

org.apache.commons.io.IOUtils.copyLarge(System.in, System.out);

I despise the Java language as much as the next dev, and the core library is drastically underfeatured - But if you can't manage to copy one stream to another because you don't use libraries, you have no one to blame but yourself.

> I despise the Java language as much as the next dev

It's not so much the language that I despise - I never touched the language because of the end-user experience I got from installing the runtime: the nagging updates and the constant security headlines involving JVM. That's why I will never take the language (or the JVM languages) seriously: I simply would never put my users through what I am somewhat forced to go through (for the select few Java apps I do have to use).

And the prize for least informed opinion goes to...

Let's review : 1) "I never touched the language" 2) Almost without exception Java vulnerabilities are related the the applet sandbox and not the core JVM

Also, find me a single engineer how understands how the JVM works, what it does, how it does it and how it compares to alternatives that also thinks it's sub par software. I'll wait.

I dislike java the language and java gui applications as much as everyone else, but I've never had any issues with the JVM for server applications.

I'd wager nearly all Java developers run their applications in their own JVMs, far far away from the sweaty mitts of client-side JREs.

> That's why I will never take the language (or the JVM languages) seriously

Seriously dude?

Then you might think I'm the devil incarnate, because I force my blog visitors to use Java, because my blog is actually a Java Servlet app. Go ahead and try it: http://theandrewbailey.com/

There's more to Java than the client runtime.

This seems to be a schism of some kind.

Scenario 1: Ruby dev with problem while developing something in ruby: Ahh, There's a gem for that!

Scenario 2: <other language> dev trying something in Java: Why isn't this in the stdlib? Sucks! Aergh.

Bashing Java is just too easy; too bad it's actually a nice language.

> So yes, I enjoyed programming in Java, and being relieved of the responsibility for producing a quality product. It was pleasant to not have to worry about whether I was doing a good job, or whether I might be writing something hard to understand or to maintain. The code was ridiculously verbose, of course, but that was not my fault. It was all out of my hands.

Yes, that's it, blame the language when you write poor quality software. If only I'd used language X instead of language Y, my code would've been easy to read, well-architected and thoroughly tested.

...and if language X in this instance is supposed to be Perl.... come on. It has built-in functions that change behaviour depending on whether or not you're assigning them to something.

> built-in functions that change behaviour depending on whether or not you're assigning them to something.

Are you suggesting that's a bad thing?

If so, consider this code:

    a[2] = a[2]

(where a is an "array", [n] an "array index", = "assignment")

The behavior of the code 'a[2]' changes entirely depending on whether it's on the LHS or the RHS. Languages and their compilers can easily support this, without a notable downside (short of religious arguments) and most ordinary folk consider it a good thing that it writes to the array when on the left, and reads from the array when on the right.

The same argument applies to functions used in a similar fashion (and, in P6, code such as a[1] etc. is in fact a function call).

> Are you suggesting that's a bad thing?

Yes. Your example doesn't apply. In both instances a[2] is a reference to a position in an array.

I was referring specifically to context-aware functions in Perl, for example, keys called in a list context returns the keys, in a scalar context, the number of keys, in a void context, it resets an internal iterator.

This is terrible, it's like Perl decided that the principle of least surprise was too boring.

It's only a surprise if you don't understand it. Every Perl programmer needs to fully grok and embrace it because it's a core language feature.

For others, this is what EdwardDiego is referring to:

  my %hash = (a => 1, b => 2, c => 3, d => 4);

  # list context (plural)
  my @keys = keys %hash;
  my ($key1, $key2, @rest_of_keys) = keys %hash;
  
  # scalar context (singular)
  my $number_of_keys = keys %hash;
  say scalar keys %hash;

  # An example of iterator usage
  my ($first_key, $first_value) = each %hash;
  my ($second_key, $second_value) = each %hash;

  # void context
  keys %hash;    # resets iterator

> In both instances a[2] is a reference to a position in an array.

Sure, but the reference invokes function calls (semantically; the compiler usually optimizes them away) that depend on context: when 'a[2]' is on the left of an '=' the function calls result in assigning the value to the right of the '='; when 'a[2]' is on the right, it results in just reading 'a[2]'. Imo this as an intuitive and appropriate context aware variation in behavior based on whether or not the 'a[2]' is an "lvalue" (value on the left of an assignment), which is the contextual variation in behavior you first called out as problematic and which I'm suggesting is not.

In your latest comment you switched the focus to Perl's distinction of singular vs plural ($ vs @) as seen in the following Perl code:

    @people = keys payroll # @ means list context (many)
    $count  = keys payroll # $ means item context (one)

Given the above code @people would end up with a list (of zero or more items), presumably of objects or somesuch representing people, and $count would end up with a singular value, presumably the number of people.

Aiui you think at least one of those lines ought to be invalid, and there should be multiple functions or constructs to replace 'keys': 'keys' and 'count_of_keys', or 'keys.list' and 'keys.count', or somesuch, rather than Perl's singular/plural polymorphic approach. If so, we disagree.

What an utter load of crap. You can write excellent code in Java, you can write crap in Java. Due to its popularity, java has had everyone and their dog learning how to "code in java" and hence there are many poor "Java developers". That doesn't make it a bad language.

I quite like Java too, but without the mealy-mouthed backhanded compliments.

Reply on news.ycombinator.com