Hacker News Reader

Comment by beders | Hacker News Reader

The Java/C# as you wrote it doesn't just solve 'find the area of a square', but a whole set of other things.

A more idiomatic version would be:

    Square.calculateArea(double s) { return s*s; }

That said: One often finds code with lots of unnecessary boiler plate code and Java's syntax up to Java 8 could not be described as succinct.

View on HN

Yep, OP is comparing apples to oranges, and there's several strange things with the example code, but a direct translation of the original Java code provided into C# is:

  public class Square {
    public double Side { get; private set; }

    public Square(double s) {
      Side = s;
    }

    public double Area {
      get { return Side * Side; }
    }
  }

TLDR: C# doesn't actually need those ceremonial getters/setters that Java still uses, but there was no real need for that to be a public property anyway, although I have kept it that way to match the original.

Ceremonial getters/setters weren't my point, they were just a common theme I've seen in a lot of OO code that I used to help show my point, which was that some languages tend to have more boilerplate than others (and thus, lines of diff is not a good metric for "Programming Language Popularity").

This was definitely an apples to oranges comparison, and I specifically said I was comparing code from different languages - it's a bit tough to do so without comparing apples to oranges, especially when you're comparing "Shell" to "Java". In fact, my whole point boils down to the fact that IMO, the original post was making an apples to oranges comparison - it was comparing lines of diff from various different languages, some of which require more boilerplate than others, and then declaring that it was providing stats on "Programming Language Popularity".

Obviously it would be possible to write very succinct one-liners for Java, C#, or "Shell" (not to mention the fact that the whole goal was the square a number; no functions or classes were really needed), but I still tried to write code in the style that I am used to seeing. You're right, my code wasn't using C#-specific abilities like auto-implemented properties, and I did try to make it look slightly more Java-like.

You are right, C# hasn't required the same ceremony since C# 3.0, but there still are quite a few people who seem to be oblivious to that (in my experience at least). Furthermore, I still count 2 instances of "get" in your code and an instance of "set" as well, so while your getters/setters may not take as many lines as the ones I wrote, you still had to explicitly declare them, which to me is still a bit ceremonial, but I can see how to someone who does it all the time, it may seem like nothing :)

The confusion in your example was using OOP vs functional. The Area getter in my example could be a method, it just makes it slightly nicer to have it as a getter in C# for that type of thing.

But, the actual getter/setter is:

  public Size { get; set; }

In Ruby it would be:

  attr_accessor :size

In scala it would be:

  var size

A little more code in c# but still a fairly concise 1 liner. Which you can't say the same for in Java, unless you use Lombok of course.

But yes, overall I agree, LOC is a bad metric but we don't have much else to go on. Pure project count perhaps is a more reliable metric of language use but still has many flaws.

But that's what the typical Java developer indeed would write :-(

"Just in case"

Reply on news.ycombinator.com