3 ms·

Java works great on large teams. The stuff that people complain about as "too much boilerplate" and "super boring" when you're writing code is actually really

by jbooth 11y ago

Java works great on large teams. The stuff that people complain about as "too much boilerplate" and "super boring" when you're writing code is actually really awesome when you have to read a bunch of code and half the people who wrote it are gone. Boring is better than clever when it comes to maintenance. They're conservative about adding features, so they've managed to keep the language pretty small, and the core concepts of "what is good Java code" have been mostly the same for like 15 years, even through major releases like 1.5.

jinst8gmi 11y ago
I don't really find it "actually really awesome" when I have to read through 6 screens worth of getters and setters in legacy Java code vs what it would have looked like in C# or Scala. In Scala or C# you're looking at the actual logic, not playing hide and seek with it amongst irrelevant boilerplate in Java. Java developers usually consider features which the language doesn't have to be bad or make code unreadable, that is until those same features are added to Java, when suddenly they are a source of pride and a sign of Java being "modern". In reality Java's feature freeze until Java 8 was largely driven by Sun's financial woes.
- RyanZAG 11y ago
  I think jbooth is talking more about forced verbosity such as Map<String, Customer> customerMap = createCustomerMap(); where in other less verbose languages you find val customerMap = createCustomerMap(); Always seeing the definition of a value in the current function context is actually very nice for maintainability, but does give Java the reputation of being overly verbose. Stuff like getters/setters on all values in a class are awful though and are both a code smell and unnecessary. They break the OO principles and should not be there in the first place. It's good that Java makes those 6 screens worth of getters and setters awful - they are awful. For objects which are used solely for transfering state, check out Google's AutoValue ( https://github.com/google/auto/tree/master/value https://github.com/google/auto/tree/master/value ) However if you do see a class that is 6 screens of just getters and setters then you know exactly which class you need to fix.
  - jinst8gmi 11y ago
    I agree with you, up to a point. I find Ruby code pretty awful to make sense of with very little type information. Type inference with explicit return types for methods strikes a nice balance between verbosity and readability. I think Scala, Kotlin and to some extent C# do a better job of this than Java. There are also many less favourable cases where you see things like: Customer customer = new Customer(); String str = "I'm a String" SomethingOrOtherFactory factory = new SomethingOrOtherFactory(); which isn't any clearer than: val customer = new Customer(); val str = "I'm a String" val factory = new SomethingOrOtherFactory() Having a dozen getter/setters is generally a code smell, but having a dozen getters isn't.
    - RyanZAG 11y ago
      Agreed, but: Animal customer = new Cat(); It makes it clear how the new object will be used. It does come up quite frequently, especially with Collection and List. Nobody was saying it is not verbose and can lead to boilerplate. The assertion is that when viewing a large code base, you are always sure of the type of value you are dealing with on a local level. If all of your objects are well defined, you don't even need to look at how the class is created (a billion getters and setters? irrelevant to the local function) as you only need to deal with the local function.
      - lmm 11y ago
        That's there if you want it though. val customer = new Cat(): Animal I can see arguments against inter-method type inference, but I think there's no real argument against type inference within a single method (requiring explicit types on method boundaries). If you have a billion-line method you have bigger problems.
- pjmlp 11y ago
  The first time I saw properties was in Eiffel, afterwards adopted by Delphi, which eventually found their way into C# and to many other languages. Comparing to the original implementation of properties in C# (not how they look now), the Java way wasn't that different. They just copied what was common C++ and Smalltalk practice back then, whereas Anders obviously had his Delphi experience. Not that they shouldn't eventually improve it.

by jbooth 11y ago

jinst8gmi 11y ago

I don't really find it "actually really awesome" when I have to read through 6 screens worth of getters and setters in legacy Java code vs what it would have looked like in C# or Scala. In Scala or C# you're looking at the actual logic, not playing hide and seek with it amongst irrelevant boilerplate in Java. Java developers usually consider features which the language doesn't have to be bad or make code unreadable, that is until those same features are added to Java, when suddenly they are a source of pride and a sign of Java being "modern". In reality Java's feature freeze until Java 8 was largely driven by Sun's financial woes.

RyanZAG 11y ago
I think jbooth is talking more about forced verbosity such as Map<String, Customer> customerMap = createCustomerMap(); where in other less verbose languages you find val customerMap = createCustomerMap(); Always seeing the definition of a value in the current function context is actually very nice for maintainability, but does give Java the reputation of being overly verbose. Stuff like getters/setters on all values in a class are awful though and are both a code smell and unnecessary. They break the OO principles and should not be there in the first place. It's good that Java makes those 6 screens worth of getters and setters awful - they are awful. For objects which are used solely for transfering state, check out Google's AutoValue ( https://github.com/google/auto/tree/master/value https://github.com/google/auto/tree/master/value ) However if you do see a class that is 6 screens of just getters and setters then you know exactly which class you need to fix.
- jinst8gmi 11y ago
  I agree with you, up to a point. I find Ruby code pretty awful to make sense of with very little type information. Type inference with explicit return types for methods strikes a nice balance between verbosity and readability. I think Scala, Kotlin and to some extent C# do a better job of this than Java. There are also many less favourable cases where you see things like: Customer customer = new Customer(); String str = "I'm a String" SomethingOrOtherFactory factory = new SomethingOrOtherFactory(); which isn't any clearer than: val customer = new Customer(); val str = "I'm a String" val factory = new SomethingOrOtherFactory() Having a dozen getter/setters is generally a code smell, but having a dozen getters isn't.
  - RyanZAG 11y ago
    Agreed, but: Animal customer = new Cat(); It makes it clear how the new object will be used. It does come up quite frequently, especially with Collection and List. Nobody was saying it is not verbose and can lead to boilerplate. The assertion is that when viewing a large code base, you are always sure of the type of value you are dealing with on a local level. If all of your objects are well defined, you don't even need to look at how the class is created (a billion getters and setters? irrelevant to the local function) as you only need to deal with the local function.
    - lmm 11y ago
      That's there if you want it though. val customer = new Cat(): Animal I can see arguments against inter-method type inference, but I think there's no real argument against type inference within a single method (requiring explicit types on method boundaries). If you have a billion-line method you have bigger problems.
pjmlp 11y ago
The first time I saw properties was in Eiffel, afterwards adopted by Delphi, which eventually found their way into C# and to many other languages. Comparing to the original implementation of properties in C# (not how they look now), the Java way wasn't that different. They just copied what was common C++ and Smalltalk practice back then, whereas Anders obviously had his Delphi experience. Not that they shouldn't eventually improve it.