3 ms·

I was comparing it to Ruby. Java has the bureaucracy I mentioned and that expresiveness you speak of is often the biggest creator of technical debt which speci

I was comparing it to Ruby. Java has the bureaucracy I mentioned and that expresiveness you speak of is often the biggest creator of technical debt which specially shines when someone else has to work with your code and understand all your different abstractions. As far as tooling goes, what are you particularly missing from the Java ecosystem? Honestly I have big gripes with Java's tooling, most important of all the language's hard-dependency on big IDEs to get anything done.

tobz 10y ago
So would you say that Ruby's ability to monkeypatch third-party libraries at runtime is not the type of expressiveness that "specially shines" when others have to work with your code? Because I've had to deal with that type of shit before. Java might have a history of AbstractBuilderFactorySingletons, but you'd be hard-pressed to find an IDE that couldn't make quick work of it. Monkeypatched at runtime? Good luck!
- bazzargh 10y ago
  I've had to deal with both and monkeypatching isn't the worst thing, because it's static & greppable. foo.method(:bar).source_location ...and you've found the hack. In java land, third party breakage is just as common and countless times I had to decompile random jars to figure out where the bug was, and resort to strace to figure out which jars were being loaded by misbehaving classloaders. Forking a gem is preferable to monkeypatching, but sometimes this can lead to a chain of forks just to change one line in an indirect dependency, worse than the patch. No, the worst thing is method_missing. Methods that appear nowhere in the source getting invoked, and they only appear at runtime. You can do similar things with InvocationHandler in java but it gets used far, far less.
  - tobz 10y ago
    Sure, maybe not the worst thing (I don't use Ruby primarily) but just one of the many things where the "expressiveness" of the language itself is can be as much of a boon as it can be a nightmare. Misbehaving classloaders sounds like a straight up bug, or a lack of standardization around how a classloader should work. That doesn't sound so much like a failing of the language itself, but again, Java isn't my primary language so I'm not entirely privy to the landscape of Java fuckery. :)
twic 10y ago
I don't really know what you mean by bureaucracy. Is that the same as boilerplate? What bureaucracy does Java have which Go doesn't? You're quite right about expressiveness being a double-edged sword. I've been lucky enough to mostly work with programmers with the judgement to use it well. I don't think that's rare, but it's not universal. The tools I'm missing are sane dependency management, and automatic refactoring. Any language where I don't have good automatic refactoring is going to be slower to work with, no matter how wonderful the language itself.
- mixedCase 10y ago
  MakeSureToGetItInPrint importantThing = new Namespace.MakeSureToGetItInPrint(one, two, three); Dependency management in my experience is not a problem at all in Go. Vendoring might be different but it's not complicated nor strictly worse. As for automated refactoring, what more would you like to see in the tooling compared to what you already have (renaming)? The death-by-thousand-file-splits that's recommended in Java and for which IDE help is useful, is not idiomatic in Go. The most code you have to write to split a file into two is the keyword `package` and the package name. The rest is just copy+paste and let `goimports` take care of doing the rest.
  - twic 10y ago
    That's a funny example, because it's rare to qualify a type with a package in Java, whilst it's essentially universal in Go. Automatic refactorings i routinely use in Java are extracting variables, methods, constants, and fields (including automatically finding and extracting repetitions of the body); inlining the same; splitting and combining variable declaration and use (easier in Go, of course!), adding, removing, and reordering method parameters; correcting declared method return and parameter types based on actual use; extracting superclasses and moving methods up and down type hierarchies (again, not relevant in Go); moving methods to a receiver which was one of its parameters. All the stuff which is the bread and butter of reshaping code. All done in a keystroke or two. Not copying and pasting and then manually following through. Again, to be clear, i have done Go development. About three months of full-time Go with experienced colleagues. I know what state of the art Go development looks like. It's unambiguously slower than Java development. We'll have to agree to differ on dependency management.

tobz 10y ago

So would you say that Ruby's ability to monkeypatch third-party libraries at runtime is not the type of expressiveness that "specially shines" when others have to work with your code? Because I've had to deal with that type of shit before. Java might have a history of AbstractBuilderFactorySingletons, but you'd be hard-pressed to find an IDE that couldn't make quick work of it. Monkeypatched at runtime? Good luck!

bazzargh 10y ago
I've had to deal with both and monkeypatching isn't the worst thing, because it's static & greppable. foo.method(:bar).source_location ...and you've found the hack. In java land, third party breakage is just as common and countless times I had to decompile random jars to figure out where the bug was, and resort to strace to figure out which jars were being loaded by misbehaving classloaders. Forking a gem is preferable to monkeypatching, but sometimes this can lead to a chain of forks just to change one line in an indirect dependency, worse than the patch. No, the worst thing is method_missing. Methods that appear nowhere in the source getting invoked, and they only appear at runtime. You can do similar things with InvocationHandler in java but it gets used far, far less.
- tobz 10y ago
  Sure, maybe not the worst thing (I don't use Ruby primarily) but just one of the many things where the "expressiveness" of the language itself is can be as much of a boon as it can be a nightmare. Misbehaving classloaders sounds like a straight up bug, or a lack of standardization around how a classloader should work. That doesn't sound so much like a failing of the language itself, but again, Java isn't my primary language so I'm not entirely privy to the landscape of Java fuckery. :)

twic 10y ago

I don't really know what you mean by bureaucracy. Is that the same as boilerplate? What bureaucracy does Java have which Go doesn't? You're quite right about expressiveness being a double-edged sword. I've been lucky enough to mostly work with programmers with the judgement to use it well. I don't think that's rare, but it's not universal. The tools I'm missing are sane dependency management, and automatic refactoring. Any language where I don't have good automatic refactoring is going to be slower to work with, no matter how wonderful the language itself.

mixedCase 10y ago
MakeSureToGetItInPrint importantThing = new Namespace.MakeSureToGetItInPrint(one, two, three); Dependency management in my experience is not a problem at all in Go. Vendoring might be different but it's not complicated nor strictly worse. As for automated refactoring, what more would you like to see in the tooling compared to what you already have (renaming)? The death-by-thousand-file-splits that's recommended in Java and for which IDE help is useful, is not idiomatic in Go. The most code you have to write to split a file into two is the keyword `package` and the package name. The rest is just copy+paste and let `goimports` take care of doing the rest.
- twic 10y ago
  That's a funny example, because it's rare to qualify a type with a package in Java, whilst it's essentially universal in Go. Automatic refactorings i routinely use in Java are extracting variables, methods, constants, and fields (including automatically finding and extracting repetitions of the body); inlining the same; splitting and combining variable declaration and use (easier in Go, of course!), adding, removing, and reordering method parameters; correcting declared method return and parameter types based on actual use; extracting superclasses and moving methods up and down type hierarchies (again, not relevant in Go); moving methods to a receiver which was one of its parameters. All the stuff which is the bread and butter of reshaping code. All done in a keystroke or two. Not copying and pasting and then manually following through. Again, to be clear, i have done Go development. About three months of full-time Go with experienced colleagues. I know what state of the art Go development looks like. It's unambiguously slower than Java development. We'll have to agree to differ on dependency management.