6 ms·

I almost made a similar point but didn't want to be too long-winded. But you're exactly right on. Certain idioms develop in every language. In Java there's a

by chavesn 13y ago

I almost made a similar point but didn't want to be too long-winded. But you're exactly right on. Certain idioms develop in every language. In Java there's a culture of favoring verbosity over cleverness. In fact, I think you'll find some Java programmers who hate the cleverness that is often common in other more terse languages. And they'll throw "clever" around as an insult much the way "verbose" is used against Java. I think overall these cultures don't indicate too much of an underlying problem and aren't too harmful, except when assimilating developers from other language. But to your point, these barriers to entry likely exist for nearly every language (and if not, other barriers do), so on balance, it's largely a wash.

vishnugupta 13y ago
>In Java there's a culture of favoring verbosity over cleverness. I've been programming in Java (gulp) all my professional life of about a decade. I can totally attest to this. Just couple of days ago in one of the code reviews I gave a lengthy explanation for using StringUtils.equals("foo", someVariable) over "foo".equals(someVariable). I could have instead just said what you've stated; prefer verbosity over cleverness :)
- cowls 13y ago
  Wow, sounds like a productive code review.
- davidw 13y ago
  And there's the culture I was talking about! I'm not a fan of stuff that's too weird and magical, but "foo".equals(bar) is shorter and just as clear to me, if not more so.
  - vishnugupta 13y ago
    "foo".equals(bar) is definitely clear and shorter. However it is "clever" in the sense that it circumvents NPE with some sort of trick. Those who are new to Java don't get why and how it avoids NPE. To make matters worse they may even reverse the arguments for better readability, bar.equals("foo") which is a ticking NPE time bomb! StringUtils.equals(a, b) on the other hand clearly states in its interface document that it is null safe and there's no NPE trap. There, I said it :). That was my lengthy argument for using StringUtils.equals!
    - duarose 13y ago
      Of course, StringUtils is not in the core API; the first idiom "foo".equals(bar) works in Java everywhere, StringUtils.equals("foo", bar) will only work in projects that pull in org.apache.commons. Personally I prefer using facilities in the core API over third party APIs, even if the third party API is included anyway for some essential function.
      - Consultant32452 13y ago
        I've been coding in Java for over 10 years. If I ran across pretty much any project that wasn't including Apache commons I'd be startled. I get your point, but some libraries are in such common use that for all practical purposes I consider them part of the language API.
    - JackFr 13y ago
      But the problem with your use of StringUtils, IMHO, is that it hides intent. If bar is expected to potentially be null, test for null. If bar should not be null, throw an NPE, and the fix the calling code. Making code that shouldn't need to be "null safe" masks errors, and ultimately makes them harder to track down.
    - jsight 13y ago
      Understanding that there is the possibility of an NPE and reading enough of StringUtils contract to understand that it deals with requires approximately the same level of "cleverness" as understanding the "foo".equals(bar) behavior. Code reviews should focus on more important things than this, IMO.
    - Sandman 13y ago
      As you may have guessed from my previous comment, I hate it when people write "foo".equals(bar). This kind of a clever trick is an accident waiting to happen unless you're really, really ok with null being a valid value for bar (and more often than not, you're not ok with that). If null is not a valid value for bar, then it's better to catch it and deal with it as early as possible.
- dtamhk 13y ago
  Oh Java is the Kingdom of Nouns. :-D http://steve-yegge.blogspot.hk/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.hk/2006/03/execution-in-kingdom-...
- watwut 13y ago
  I am java programmer and liked java culture. And I see nothing wrong with "foo".equals(someVariable). If code review ends with lengthy explanation over why not use "foo".equals(someVariable) or some other maintenance/readability/effectivity/other important consideration non-affecting issue, I see something wrong with code review.
  - cowls 13y ago
    In this case code review is actually the reviewer trying to boost ego and stamp authority on reviewee
  - jsight 13y ago
    I agree... StringUtils is awesome, but "foo".equals(someVariable) is not a case where it's use is important.
- Sandman 13y ago
  By the way, nobody should ever use "foo".equals(someVariable) anyway. If anything, it should be someVariable.equals("foo"), unless you really know what you're doing and are ok with null being a valid value of someVariable.
  - deleted 13y ago
    [deleted]
  - snuxoll 13y ago
    Either style would be fine as long as you check your preconditions.
bad_user 13y ago
It's also quite the mystery how this culture happened, given that it's the norm to use big libraries for dependency injection, AOP, transactions management, protocol wiring, data binding and so on, big and complex libraries that many times rely on bytecode manipulation at runtime to workaround the verbosity problem or other deficiencies in the language itself. I think that the Java ecosystem being so massive and Java being so popular, it also attracted a lot of mediocrity, since the usual bell curve applies. That said, I know Java developers that definitely don't like verbosity and that don't follow the usual "best practices" as some kind of dogma. In the end, it all depends on the work environment you end up in.
- Symmetry 13y ago
  Because it's hard to add layers of abstraction later in Java, experienced developers learn to add a bunch of extra ones early so there'll be there if you need them?
  - beagle3 13y ago
    No. It is inexperienced programmers that add abstraction everywhere. Abstraction has a huge mental cost (I ignore the execution speed cost, because it is mostly irrelevant these days for most projects). You need more than one case to abstract over. Abstracting "just in case" is, much more often than not, very leaky - that is, requiring you to keep in mind the details of both the abstraction and the abstracted - and requires revision when you actually need it. Abstraction is not magic, not cost free, although Java culture is to assume that it is both. (Same criticism for C++, BTW; C culture tends to err the other way -- which, in my experience, is the better error to make)
- aragot 13y ago
  > It's also quite the mystery how this culture happened Maybe the language didn't have powerful tools in its core? What if getters/setters weren't mandatory, like in Scala, wouldn't we write more tiny expressive classes to hold intermediate values? Think about this example of Dependency Injection: Why did we have to use DI? Because using statics as a dependency injector (like in Play) prevents from unit testing. How could we have solved it? By allowing inheritance override on statics. We don't have it, therefore we have Spring. Even the Servlet API is criticized for being inexpressive [1]. They've done it so wrong that every single framework reimplements url routing (Struts, Spring MVC...) resulting in those horrible /myserviceaction.do patterns. In turn, those patterns deny RESTful apis, prompting for yet-another-framework for REST resources. We just became Enterprise [2]. I personally have no wonder why we became verbose. But it's understandable, since Java was built using community processes. [1] http://blog.lunatech.com/2011/12/08/wrong-with-servlet-api http://blog.lunatech.com/2011/12/08/wrong-with-servlet-api [2] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

by chavesn 13y ago

vishnugupta 13y ago

>In Java there's a culture of favoring verbosity over cleverness. I've been programming in Java (gulp) all my professional life of about a decade. I can totally attest to this. Just couple of days ago in one of the code reviews I gave a lengthy explanation for using StringUtils.equals("foo", someVariable) over "foo".equals(someVariable). I could have instead just said what you've stated; prefer verbosity over cleverness :)

cowls 13y ago
Wow, sounds like a productive code review.
davidw 13y ago
And there's the culture I was talking about! I'm not a fan of stuff that's too weird and magical, but "foo".equals(bar) is shorter and just as clear to me, if not more so.
- vishnugupta 13y ago
  "foo".equals(bar) is definitely clear and shorter. However it is "clever" in the sense that it circumvents NPE with some sort of trick. Those who are new to Java don't get why and how it avoids NPE. To make matters worse they may even reverse the arguments for better readability, bar.equals("foo") which is a ticking NPE time bomb! StringUtils.equals(a, b) on the other hand clearly states in its interface document that it is null safe and there's no NPE trap. There, I said it :). That was my lengthy argument for using StringUtils.equals!
  - duarose 13y ago
    Of course, StringUtils is not in the core API; the first idiom "foo".equals(bar) works in Java everywhere, StringUtils.equals("foo", bar) will only work in projects that pull in org.apache.commons. Personally I prefer using facilities in the core API over third party APIs, even if the third party API is included anyway for some essential function.
    - Consultant32452 13y ago
      I've been coding in Java for over 10 years. If I ran across pretty much any project that wasn't including Apache commons I'd be startled. I get your point, but some libraries are in such common use that for all practical purposes I consider them part of the language API.
  - JackFr 13y ago
    But the problem with your use of StringUtils, IMHO, is that it hides intent. If bar is expected to potentially be null, test for null. If bar should not be null, throw an NPE, and the fix the calling code. Making code that shouldn't need to be "null safe" masks errors, and ultimately makes them harder to track down.
  - jsight 13y ago
    Understanding that there is the possibility of an NPE and reading enough of StringUtils contract to understand that it deals with requires approximately the same level of "cleverness" as understanding the "foo".equals(bar) behavior. Code reviews should focus on more important things than this, IMO.
  - Sandman 13y ago
    As you may have guessed from my previous comment, I hate it when people write "foo".equals(bar). This kind of a clever trick is an accident waiting to happen unless you're really, really ok with null being a valid value for bar (and more often than not, you're not ok with that). If null is not a valid value for bar, then it's better to catch it and deal with it as early as possible.
dtamhk 13y ago
Oh Java is the Kingdom of Nouns. :-D http://steve-yegge.blogspot.hk/2006/03/execution-in-kingdom-of-nouns.html http://steve-yegge.blogspot.hk/2006/03/execution-in-kingdom-...
watwut 13y ago
I am java programmer and liked java culture. And I see nothing wrong with "foo".equals(someVariable). If code review ends with lengthy explanation over why not use "foo".equals(someVariable) or some other maintenance/readability/effectivity/other important consideration non-affecting issue, I see something wrong with code review.
- cowls 13y ago
  In this case code review is actually the reviewer trying to boost ego and stamp authority on reviewee
- jsight 13y ago
  I agree... StringUtils is awesome, but "foo".equals(someVariable) is not a case where it's use is important.
Sandman 13y ago
By the way, nobody should ever use "foo".equals(someVariable) anyway. If anything, it should be someVariable.equals("foo"), unless you really know what you're doing and are ok with null being a valid value of someVariable.
- deleted 13y ago
  [deleted]
- snuxoll 13y ago
  Either style would be fine as long as you check your preconditions.

bad_user 13y ago

It's also quite the mystery how this culture happened, given that it's the norm to use big libraries for dependency injection, AOP, transactions management, protocol wiring, data binding and so on, big and complex libraries that many times rely on bytecode manipulation at runtime to workaround the verbosity problem or other deficiencies in the language itself. I think that the Java ecosystem being so massive and Java being so popular, it also attracted a lot of mediocrity, since the usual bell curve applies. That said, I know Java developers that definitely don't like verbosity and that don't follow the usual "best practices" as some kind of dogma. In the end, it all depends on the work environment you end up in.

Symmetry 13y ago
Because it's hard to add layers of abstraction later in Java, experienced developers learn to add a bunch of extra ones early so there'll be there if you need them?
- beagle3 13y ago
  No. It is inexperienced programmers that add abstraction everywhere. Abstraction has a huge mental cost (I ignore the execution speed cost, because it is mostly irrelevant these days for most projects). You need more than one case to abstract over. Abstracting "just in case" is, much more often than not, very leaky - that is, requiring you to keep in mind the details of both the abstraction and the abstracted - and requires revision when you actually need it. Abstraction is not magic, not cost free, although Java culture is to assume that it is both. (Same criticism for C++, BTW; C culture tends to err the other way -- which, in my experience, is the better error to make)
aragot 13y ago
> It's also quite the mystery how this culture happened Maybe the language didn't have powerful tools in its core? What if getters/setters weren't mandatory, like in Scala, wouldn't we write more tiny expressive classes to hold intermediate values? Think about this example of Dependency Injection: Why did we have to use DI? Because using statics as a dependency injector (like in Play) prevents from unit testing. How could we have solved it? By allowing inheritance override on statics. We don't have it, therefore we have Spring. Even the Servlet API is criticized for being inexpressive [1]. They've done it so wrong that every single framework reimplements url routing (Struts, Spring MVC...) resulting in those horrible /myserviceaction.do patterns. In turn, those patterns deny RESTful apis, prompting for yet-another-framework for REST resources. We just became Enterprise [2]. I personally have no wonder why we became verbose. But it's understandable, since Java was built using community processes. [1] http://blog.lunatech.com/2011/12/08/wrong-with-servlet-api http://blog.lunatech.com/2011/12/08/wrong-with-servlet-api [2] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...