7 ms·

> It needs close parenting. Java has been ruined by the push to include everyone's pet feature. Oracle is moving to a faster cycle of development. There are so

> It needs close parenting. Java has been ruined by the push to include everyone's pet feature. Oracle is moving to a faster cycle of development. There are some of us who strongly feel that some of their decisions are based less on what's best for the language and more on catering to the popular-and-loud crowd. I'll never forgive the addition of `var` to the language.

read_if_gay_ 7y ago
>I'll never forgive the addition of `var` to the language. I'm inexperienced with Java and didn't know this existed until I saw your post. It seems like a nice shorthand to me. Can you explain why you don't like it?
- bad_user 7y ago
  Misconceptions mostly. Java developers are some of the most conservative developers around. And there you have the answer to why Java hasn't evolved that much, or when it did, why it needed to care deeply about backwards compatibility at the source level. It's because Java developers want it that way. The irony is that people are now abusing "aspects" and "dependency injection" via frameworks like Spring that bring everything but the kitchen sink, but then the language becomes effectively dynamic, as via those annotations all static type safety goes out the window. Therefore I find it interesting when Java developers complain about Var, because the ecosystem has in my opinion bigger problems. Compared with annotations Var isn't a problem because Var is statically checked, so here we have a clear case of missing the forest from the trees.
  - mieseratte 7y ago
    > Java developers are some of the most conservative developers around. You're right, there are loads of conservative Java developers. It's one of the the things that makes me love using the language. > The irony is that people are now abusing "aspects" and "dependency injection" via frameworks like Spring that bring everything but the kitchen sink, but then the language becomes effectively dynamic, as via those annotations all static type safety goes out the window. > Misconceptions mostly. But drop the strawman argument and borderline ad hominem. It'll do you better.
    - emj 7y ago
      Spring is terrible in that sense, and you do find professionals arguing for Spring and strongly typed language. That said it's not an argument I've ever heard before being part of a Spring centric shop.
    - kaidax 7y ago
      What ad hominem? That Java ecosystem is wholly dependent on crazy amount of magic is not a personal attack, really, but a mere sad admission.
- mieseratte 7y ago
  I'm of the mind that it is un-Java like. Whether or not there is a "Java" as a philosophy is not the hill I'm trying to die on. Consider these contrived lines of code: ``` String first = someMethodCall(); var second = someMethodCall(); ``` The first provides more useful information at a glance. I don't see any value in the "nice shorthand." Typing out "SomeStupidClassName" has never once been a material bottleneck in my 15+ years of programming, but now we have this new option that caters to the lazy, and in doing so makes life harder. Now I have to either ban it, embrace it, or come up with some ruleset around when you can and can't use it. Why? Someone can't be bothered to type a few extra characters. It reminds of my grandfather, a former professional ball player, but one who played back in the days where there weren't these multi-million dollar celebrity ballplayers pissing and moaning in the press about just how hard their life is. He used to call those types "high-priced cry-babies," and I really feel a tinge of that in dealing with folks who just wholly embrace `var` and give folks like me shit for having criticisms of it. Perhaps that's just my old blue-collar showing but your convenience in writing a handful of characters simple will never enter into my considerations. I love using Java, I love the addition of things like streams, the Optional type, etc. My sibling comment is a little right, and very wrong. Lots of Java developers have a certain conservatism about them, I'm mostly certainly one. But there are large reasons to hate it.
  - anchpop 7y ago
    To quote another comment from this thread: > [D]rop the strawman argument and borderline ad hominem. It'll do you better.
  - bunderbunder 7y ago
    > I don't see any value in the "nice shorthand." Typing out "SomeStupidClassName" has never once been a material bottleneck in my 15+ years of programming There are a few rather glaring spots that I've noticed. First, when you're refactoring, you've now got to edit every spot where a variable of that type is created. At the very least, when you're just renaming a class, your IDE can help you, but you still create a lot of diff noise. At worst, when you're splitting up a class or otherwise shifting responsibilities, you may end up with a whole lot of yak to shave. This is not just an annoyance; it's a latent code quality problem, because it creates a disincentive to clean things up. Second, I've seen it become an impediment to writing clean code in the first place. I have encountered situations where it's clear that the author wrote someMethodCall( withOutputOfSomeOtherMethod( thatTransformsTheOutputOfYetAnotherThing( basedOnThisInput))); because creating intermediate variables would have meant having to type out (and burn precious screen real estate on) some ridiculous set of 60-character generic type names. I've even seen it result in situations where data gets copied or otherwise processed excessively, because the explicit type annotation resulted in an upcast that shed some useful feature that a subsequent developer shimmed back in because they trusted the explicit type annotation and not a function's actual return type. So yeah, I decry your assertion that this feature is about being lazy. This feature is, at least for me, about code quality.
TheCondor 7y ago
That this very thread exists suggests a certain “C++ ification” that happens to languages. I really respect the slowness of the go maintainers in adding new stuff. I also suggest that we all ponder our tooling some; Writing java with emacs or vi is a materially different experience than using eclipse or idea and var style type-inference seems almost silly with those tools which do it for you.
- insertnickname 7y ago
  >Writing java with emacs or vi is a materially different experience than using eclipse or idea and var style type-inference seems almost silly with those tools which do it for you. It's not so much the extra typing that's the problem, it's the extra reading. All the stuttering is visual noise.
  - erik_seaberg 7y ago
    This. If you want to revolutionize the profession, come up with something that helps with reading as much as modern IDEs help with writing. My answer is that boilerplate should be generated somewhere else and largely ignored.
    - satyenr 7y ago
      IMO, boilerplate source code shouldn’t be generated at all — the tool chain should directly emit the required object code. And code generation shouldn’t require a different language — or special comment syntax.
      - erik_seaberg 7y ago
        Depends on the toolchain. Everybody knows how to generate ugly source files, but it takes more effort to add AST nodes during compilation (or symbol table entries with types plus object code) and might lead to errors nobody understands how to fix (because you can't read the declaration of the thing you're trying to interact with).
AlphaSite 7y ago
I mean go also has var for very similar reasons as java has it.

read_if_gay_ 7y ago

>I'll never forgive the addition of `var` to the language. I'm inexperienced with Java and didn't know this existed until I saw your post. It seems like a nice shorthand to me. Can you explain why you don't like it?

bad_user 7y ago
Misconceptions mostly. Java developers are some of the most conservative developers around. And there you have the answer to why Java hasn't evolved that much, or when it did, why it needed to care deeply about backwards compatibility at the source level. It's because Java developers want it that way. The irony is that people are now abusing "aspects" and "dependency injection" via frameworks like Spring that bring everything but the kitchen sink, but then the language becomes effectively dynamic, as via those annotations all static type safety goes out the window. Therefore I find it interesting when Java developers complain about Var, because the ecosystem has in my opinion bigger problems. Compared with annotations Var isn't a problem because Var is statically checked, so here we have a clear case of missing the forest from the trees.
- mieseratte 7y ago
  > Java developers are some of the most conservative developers around. You're right, there are loads of conservative Java developers. It's one of the the things that makes me love using the language. > The irony is that people are now abusing "aspects" and "dependency injection" via frameworks like Spring that bring everything but the kitchen sink, but then the language becomes effectively dynamic, as via those annotations all static type safety goes out the window. > Misconceptions mostly. But drop the strawman argument and borderline ad hominem. It'll do you better.
  - emj 7y ago
    Spring is terrible in that sense, and you do find professionals arguing for Spring and strongly typed language. That said it's not an argument I've ever heard before being part of a Spring centric shop.
  - kaidax 7y ago
    What ad hominem? That Java ecosystem is wholly dependent on crazy amount of magic is not a personal attack, really, but a mere sad admission.
mieseratte 7y ago
I'm of the mind that it is un-Java like. Whether or not there is a "Java" as a philosophy is not the hill I'm trying to die on. Consider these contrived lines of code: ``` String first = someMethodCall(); var second = someMethodCall(); ``` The first provides more useful information at a glance. I don't see any value in the "nice shorthand." Typing out "SomeStupidClassName" has never once been a material bottleneck in my 15+ years of programming, but now we have this new option that caters to the lazy, and in doing so makes life harder. Now I have to either ban it, embrace it, or come up with some ruleset around when you can and can't use it. Why? Someone can't be bothered to type a few extra characters. It reminds of my grandfather, a former professional ball player, but one who played back in the days where there weren't these multi-million dollar celebrity ballplayers pissing and moaning in the press about just how hard their life is. He used to call those types "high-priced cry-babies," and I really feel a tinge of that in dealing with folks who just wholly embrace `var` and give folks like me shit for having criticisms of it. Perhaps that's just my old blue-collar showing but your convenience in writing a handful of characters simple will never enter into my considerations. I love using Java, I love the addition of things like streams, the Optional type, etc. My sibling comment is a little right, and very wrong. Lots of Java developers have a certain conservatism about them, I'm mostly certainly one. But there are large reasons to hate it.
- anchpop 7y ago
  To quote another comment from this thread: > [D]rop the strawman argument and borderline ad hominem. It'll do you better.
- bunderbunder 7y ago
  > I don't see any value in the "nice shorthand." Typing out "SomeStupidClassName" has never once been a material bottleneck in my 15+ years of programming There are a few rather glaring spots that I've noticed. First, when you're refactoring, you've now got to edit every spot where a variable of that type is created. At the very least, when you're just renaming a class, your IDE can help you, but you still create a lot of diff noise. At worst, when you're splitting up a class or otherwise shifting responsibilities, you may end up with a whole lot of yak to shave. This is not just an annoyance; it's a latent code quality problem, because it creates a disincentive to clean things up. Second, I've seen it become an impediment to writing clean code in the first place. I have encountered situations where it's clear that the author wrote someMethodCall( withOutputOfSomeOtherMethod( thatTransformsTheOutputOfYetAnotherThing( basedOnThisInput))); because creating intermediate variables would have meant having to type out (and burn precious screen real estate on) some ridiculous set of 60-character generic type names. I've even seen it result in situations where data gets copied or otherwise processed excessively, because the explicit type annotation resulted in an upcast that shed some useful feature that a subsequent developer shimmed back in because they trusted the explicit type annotation and not a function's actual return type. So yeah, I decry your assertion that this feature is about being lazy. This feature is, at least for me, about code quality.

TheCondor 7y ago

That this very thread exists suggests a certain “C++ ification” that happens to languages. I really respect the slowness of the go maintainers in adding new stuff. I also suggest that we all ponder our tooling some; Writing java with emacs or vi is a materially different experience than using eclipse or idea and var style type-inference seems almost silly with those tools which do it for you.

insertnickname 7y ago
>Writing java with emacs or vi is a materially different experience than using eclipse or idea and var style type-inference seems almost silly with those tools which do it for you. It's not so much the extra typing that's the problem, it's the extra reading. All the stuttering is visual noise.
- erik_seaberg 7y ago
  This. If you want to revolutionize the profession, come up with something that helps with reading as much as modern IDEs help with writing. My answer is that boilerplate should be generated somewhere else and largely ignored.
  - satyenr 7y ago
    IMO, boilerplate source code shouldn’t be generated at all — the tool chain should directly emit the required object code. And code generation shouldn’t require a different language — or special comment syntax.
    - erik_seaberg 7y ago
      Depends on the toolchain. Everybody knows how to generate ugly source files, but it takes more effort to add AST nodes during compilation (or symbol table entries with types plus object code) and might lead to errors nobody understands how to fix (because you can't read the declaration of the thing you're trying to interact with).

AlphaSite 7y ago

I mean go also has var for very similar reasons as java has it.