Hacker News Reader

Comment by fleitz | Hacker News Reader

Is it 'easy to read' as in

  let sum x y = x + y

Or 'easy to read' as in

  public final class Summer { 
    public static T Sum<T>(T x, T y) {
       return x.add(y);
    }
  }

Because I don't think that dreck in the bottom is 'readable', it's like giving construction workers a Fischer Price My First Hammer and expecting them to be able to build a house with it. If you're going to make a language like Java at least let programmers take the training wheels off once they are experienced.

View on HN

I would say some people don't want to get it. There are plenty of toy languages and interactive calculators such as logo and which allow simple definitions of functions similar to the 'ideal' given. However noone would suggest writing complex software using logo.

I'm not going to defend every last aspect of Java, but in practice verbosity and readability are not it's biggest issues. In practice Java is pretty maintainable and quick to write.

To address this strawman directly. The first and last line of the 'dreck' are the namespace, which is missing in the top function. I think it is entirely fair to omit namespace and access modifiers. Probably there needs to be <T extends Summable> or some such (ignoring a number of issues with the approach here), but then this could be put in the class declaration at the top for reuse in more than one function. Which would leave

static T Sum(T x, T y) { return x.add(y); }

Which is what it is ...

>but in practice verbosity and readability are not it's biggest issues.

Right. It's biggest issue is inconsistency. Int or int? Equals or ==? Why can class String overload the + operator but I can't? On and on. But Java is very verbose. It's not a big issue in practice because we have IDEs that write most of the endless boilerplate for us.

Actually the == comparison is VERY consistent. == will return true only if the values are identical--in the case of primitives, this means the ints or doubles are identical, and in the case of objects it means the pointers have identical values--meaning they point to the exact same object. But this way I know that if I want to do something like change the way things stored in sets, I have to modify equals(), since that's what maps and sets use to check equality.

Strings are only allowed to use + because strings were traditionally seen as primitive types, rather than the objects they are in Java. It's a small inconsistency, but more of a concession to existing practice.

I'm not sure what else the "on and on" refers to...

Consistency really isn't that big an issue, the remarked points are really just details. (Of course in Javascript the use of == really is an issue).

The concept of equals is not as pure as it would like to be but it is not clear what can be done about this, since it is very convenient to have and it is not necessarily the case that there should be a universal concept of equality between all objects (although in practice this is only infrequently an issue in well designed code).

Java is quick to write because of the excellent IDEs out there. Typing out the full structure of a simple pojo by oneself makes one wonder why.

For comparison, I came up with this in C#

  Func<int, int, int> sum = (x, y) => x + y;

I had to specify the type explicitly, could not use 'var' type inference; the error is "Cannot assign lambda expression to an implicitly typed local variable". This is because the lambda could mean more than one kind of thing (delegate, expression tree, Func<>). Yeah, it's c# baggage.

Of course, once the type is known, you could do

  var sum2 = sum;

Your example is a tad too simplistic.

Literally everyone would just write z = x + y; inline

Why parameterize needlessly?

If you're saying that list comprehensions are clearer in functional form, I would suggest a more appropriate comparison.

How about:

* drawing some text on a bitmap in lines

* building a list of nodes and doing a Minimal-Spanning-Tree

I don't think they'd be much clearer.

Do that in Java and Haskell (with the same amount of library support) and show me how the java version is simpler. I would really like to see that. (you can take clojure or scala too)

But doing that makes sure they can't hurt themselves with a hammer while working!!!

Reply on news.ycombinator.com