Comment by userbinator | Hacker News Reader

Comment by userbinator | Hacker News Reader

Parent Full thread

Java is quite a bit more verbose than some other languages, but I think the culture is a significant factor; C# is similar. I've noticed the tendency to overabstract and overgeneralise, apply design patterns for the sake of using them, etc. is particularly strong. It's inexplicably hard to trace out the train of thought that makes things like this appear:

https://news.ycombinator.com/item?id=4549544

I've written small Java apps --- one class only, i.e. one source file --- which needn't be any more complex, yet coworkers have said there's something uncomfortable about my code; but for some reason can't explain exactly why. I'd get comments like "wouldn't it be better if you made this (only used once and very trivial) line of code a separate function?" "could you use more classes?" (for a <100LoC script-ish thing that had almost no duplicated code nor much in the way of loops.) It's almost as if they can't get their heads around how simple something can be, so it somehow feels very wrong to them.

Then there's the extremist "premature optimisation is evil" attitude, which I think is completely misguided because more code and complexity is bad not only in terms of computer time but also programmer time --- it takes more time for programmers to design, write, read, and debug more complex code.

    I'd get comments like "wouldn't it be better if you made this (only used 
    once and very trivial) line of code a separate function?" "could you use 
    more classes?"

The trouble is that there is a cargo-cult belief in unit testing in the Java (and .Net) worlds. Everything must have a full suite of unit tests, even if it's a one-off script. Therefore, in order to enable the mock objects needed for unit testing, you can't have "just" a class. You have to have an interface, which that class then implements. If you have any non-trivial piece of functionality, it must be encapsulated into its own method, otherwise, how are you going to test it in isolation.

My belief is that it all stems from the fact that Java doesn't have a REPL, so programmers use "test-driven development" to get the same level of interactivity from their code.

a bigger culprit is a lack of first-class functions. Objects in Java basically exist to be structs and to hold onto methods.

In my early days - I once found a Tuple library for Java, and added it to the codebase. Senior devs soon instructed me to remove it - Back to a multitude of container objects...

Wouldn't using a tuple in Java be like using inserting things into a Object[] and pulling them back out casting to the object you want to use?

What library was this?

http://www.javatuples.org/

Hard to say without knowing more context, but they could have been right. Personally I'd prefer clearly named, domain-specific container objects with adequately named properties than having to deal with "anonymous" Tuples all over the codebase, and being forced to remember what the first element was, what the second one was etc.

What makes a container object domain-specific? If I just have to pass data through the application, the anonymity may be appropriate.

If you look at the history of object orientation, it starts as slots for function pointers in structs in C, with some preprocessor statements to make it easier to use. Literally the object is just a struct which holds data and function pointers.

Pretty interesting when you think about it - java hasn't moved that conceptually far from C preprocessor statements.

C++ isn't the start of object orientation.

> it starts as slots for function pointers in structs in C

It was built around lambdas in Smalltalk long before that.

Simula (about 4 years older) had a more typical class-based OO with vtables and a proper subtyping already. Long before any C.

> My belief is that it all stems from the fact that Java doesn't have a REPL, so programmers use "test-driven development" to get the same level of interactivity from their code.

It's not the same thing though. REPL gives you fast feedback once. Unit tests you build by following TDD are there to stay.

I've gotten many code review comments to the effect of "can you break this out into an interface?" so I 100% understand what you're saying.

Many of the instances were things that we were only likely to make one example of either. I could see that argument being valid if there was a clear second implementation in mind, but an interface with only one implementing class is often just wasted time.

Also, extracting an interface is often 100% automated using the refactoring capabilities of your IDE, so doing it up front has little benefit (except in certain cases like being a public API in a library).

99% if the time its because of mocking and stubbing

The verbosity in Java is soon going to be reduced by an extensive degree by the three new features included in `Java 8`, namely:

1. Lambdas: Lambdas are brief and to the point, the expressions reflect the terseness of `C/C++`. In many situations, you can totally do away with interface creation by just using a lambda instead. Consider all the lines of code saved in a legacy code by just using lambdas in code!

2. Default methods: Again, `Interface patching` is a curse that a lot of Java projects suffer from. Requirements change slightly and what your typical enterprise Java dev does is add patches upon patches and layers upon layers in an interface. With default methods, you can just add default methods to your existing interfaces without affecting the ABI of your app. Again, tons of redundant code saved here.

3. Type annotations: Again, your typical Java devs have to resort to ugly hacks to place any constraints on the object properties. With type annotations, all you have to do is:

    @NonNull String str;

And lo and behold! The variable `str` cannot be assigned any `null` value. So, lots of validation code being saved here again.

To the best of my knowledge, none of the above features exist in the `C#` language (yet), so I take it as a Java's edge over C#.

Lambdas are use all over in idiomatic C#.

If by "soon" you mean a year and a half ago, then yes, soon :)

I don't know what major project you are talking which uses these features. I'm not talking about small projects by John Joes, I'm talking about LARGE infrastructure projects. For example, Android SDK is extensively used in Java world, and the Android SDK has tons of Interfaces as either arguments or class helpers which can be substantially overhauled by using these features.

Please don't move the goalposts; You stated that c# does not have lambdas, but has for 9 years now.

You also asked "I don't know what major project you are talking which uses these features". As far as I have seen, and I've seen a fair amount, any and every non-trivial c# program (and many of the trivial ones too) use lambdas. Even if it's just in the small-scoped, rote use e.g. of

   var matches = someList.Where(item => item.x > y);

Technically that counts as "using a lambda". Don't knock it for being trivial, it's a gateway drug ;)

Considering that this is a comment on an article about Forth, I don't think "major project" is even in the realm of discourse :)

C# has had lambdas for almost 9 years. (C#3.0, 2007)

https://msdn.microsoft.com/en-us/library/bb308966.aspx

I coded in C# for a few years, used plenty of Lambdas and a handful of annotations in Class definitions. Everytime I had to go back to Java I missed them to death.

I never felt like interface patching was a problem for me, may be because I'm more of a FP than an OOP programer. Type annotations do sound interesting.

I talked about c#'s lambda syntax, which Java later borrowed, below. For the other points:

I have seen a little of the interface vs function conversions in modern Java, and it seems a decent enough small convenient feature in the context of Java, but it doesn't feel like a big win that I would cry out for in C# code.

Defaulting to not-null and immutable values is a trend in several recent languages, e.g. from Swift and Rust to F#. This IMHO looks like a good step forward and I welcome it, however it's hard to see how this would be comprehensively added into existing languages like Java or C# with an existing legacy of not working that way. Opting into Not-null in c# has been talked about many times (1) in various forms, even implemented using attributes (similar enough to type annotations). (2)

1) http://twistedoakstudios.com/blog/Post330_non-nullable-types...

2) http://stackoverflow.com/questions/792531/c-how-to-implement...

Reply on news.ycombinator.com