2 ms·
There's no reason to have to write overly abstract code in Java. Modern Java has many features that let you write even more clear code (e.g. interfaces with def
by azth 5y ago
There's no reason to have to write overly abstract code in Java. Modern Java has many features that let you write even more clear code (e.g. interfaces with default methods). Even things like mocking, you don't need to write a dedicated interface, unlike golang, which clutters up the code base and makes it difficult to follow.
As for error handling, compare
var res = foo(bar(), baz());
and
f, err := bar()
if err != nil {
return err
}
b, err := baz()
if err != nil {
return err
}
res, err := foo(f, b)
if err != nil {
return err
}
It's much harder to follow what's going on. Now add more complex code (e.g. code that does validation or something and you'll see how it blows up)
var res = foo(items.map(i -> i.validate()), bar());
and
validatedItems := make([]Item, len(items)
for i, item := range items {
var err error
validatedItems[i], err = item.Validate()
if err != nil {
return err
}
}
f, err := foo()
if err != nil {
return err
}
res, err := foo(validatedItems, f)
if err != nil {
return err
}
1 line maps to over 15 lines, I don't think that's readable.
- Mawr 5y ago> There's no reason to have to write overly abstract code in Java. Whether that's true is beyond the point, which is that the majority of Java code out there is in fact overabstracted. That should serve as a hint that there may just be something about Java that does lead to overabstraction. > As for error handling, compare [...] It's much harder to follow what's going on. Making error-handling code paths happen implicitly in the background isn't a straight win. For example, you lose the ability to tell a fallible function from a non-fallible one, especially at the point of calling it. Overall, I find that being able to see all code paths explicitly laid out is better, Go syntax aside. Keep in mind that these examples are tiny, and therefore it's trivial to see how exceptions would implicitly propagate. They become much harder to track as the size and complexity of a codebase grows. > Now add more complex code (e.g. code that does validation or something and you'll see how it blows up) [...] 1 line maps to over 15 lines, I don't think that's readable. I wouldn't say the amount of lines is a great indicator of readability, not unless the difference was in the ballpark of maybe 1 to 100. --- I don't think this code sample is representative: - what would happen to this pretty one-liner if I wanted to catch the exception raised in `i.validate()` and raise a different exception instead? - you can create the .map() function in Go too - the Go code size will not grow linearly as you add more .map()/.filter() calls I feel like a good example of Java code would be much denser, leveraging several expressive language features that Go doesn't have.