
Java may be verbose, but who cares? - mpweiher
https://dev.to/danlebrero/java-maybe-verbose-but-who-cares
======
hex13
> IDEs generate 90% of my Java code;

It's not generating code that is costly, but reading it. Understanding 100
lines of code is usually easier than understanding 1000 lines of code,
understanding 1000 lines of code is usually easier than understanding 10000
lines of code etc.

So generally it pays of to keep codebase small and simple.

~~~
gozur88
>It's not generating code that is costly, but reading it. Understanding 100
lines of code is usually easier than understanding 1000 lines of code,
understanding 1000 lines of code is usually easier than understanding 10000
lines of code etc.

That's not at all true. The costly part is the complexity. You could spend
half a day puzzling over ten lines of cleverly written Lisp and just breeze
through 100 lines of Java that do the same thing.

~~~
stouset
You're comparing 10 lines of "clever" Lisp to 100 lines of (presumably boring)
Java.

In reality, it's more likely that those 100 lines of boring Java are easily
written in 10 lines of _just as boring Lisp_ , the only difference being the
removal of 90 lines of boilerplate getters and setters, iteration logic,
exception declarations, class definitions and instantiation, and so on.

You can explain to someone (or learn on your own) "fancy" functional
constructs like map, fold, and select in about ten minutes. And then they can
be part of your vocabulary for an _entire career_. It is absolutely
unfathomable to me that this is not a complete no-brainer.

Imagine a novelist who replaced every instance of ten common English words
with their literal dictionary definition every time they came up in a book.
That's the level of incredulity I personally experience every time I see
someone write the same implementation of `map` for the tenth time in a single
source file.

~~~
gozur88
>In reality, it's more likely that those 100 lines of boring Java are easily
written in 10 lines of just as boring Lisp, the only difference being the
removal of 90 lines of boilerplate getters and setters, iteration logic,
exception declarations, class definitions and instantiation, and so on.

I hear this sort of thing from Lisp advocates all the time, but have never
seen it in practice. _Understandable_ Lisp isn't that compact.

~~~
stouset
> [I] have never seen it in practice. Understandable Lisp isn't that compact.

Also, you are literally replying to a comment chain provoked by a post that
argues, with code, exactly this point. The Clojure (a Lisp dialect) version
has the same core logic as the Java version. The core logic is virtually
inarguably just as readable as the Java version. And it is just shy of an
order of magnitude fewer lines of code than the Java version.

So here's an example from a real, live code base of understandable Lisp, in
practice, that is 10x more compact than the Java version.

------
peterashford
I think this is a reflection of the fact that FP is better at straight data
processing than OOP (which, conversely is better for simulation). Using Java8,
you could likely have done something similar to the Clojure solution using
Streams. Using objects to model the data is a choice, not a requirement.

------
skybrian
Where is the source code being compared? It's hard to say whether this is a
fair comparison without seeing it.

------
abc_lisper
This jibes with my experience - After doing 10 years of Java, a year with
Clojure seems like heaven. I actually have brain space now to think about the
problem than the mechanical details of the solution. In fact btw terseness,
simplicity and immutability I stopped caring about the language for the most
part and am able to concentrate on the problem at hand.

------
NTDF9
Am I the only one who likes verbosity while reading code?

When I stumble upon a codebase that looks like the following:

def unzip(tuples):

    
    
        if tuples:
    
            return [tuple(t[i] for t in tuples) for i, _ in enumerate(tuples[0])]   <-------------------------WTF IS THIS LINE DOING????
    
        else:
            return []
    

It takes too much mental energy if the code is littered with the WTF-like
statements above.

~~~
danielvf
Yeah, that's horribly ugly. But that is because list manipulation was hacked
onto the Python language. The fault is more Python's than anything else.

In other languages that same idea could be fairly clearly expressed.

~~~
Doxin
> that is because list manipulation was hacked onto the Python language.

No. It's because whoever wrote that doesn't understand what list
comprehensions are _for_.

------
bdavisx
I'd be interested to see a Kotlin <-> Java side-by-side in the same instance.
I don't know if the savings would be as dramatic, but it's a lot easier for
devs (especially typical "enterprise" devs) to learn Kotlin.

------
draw_down
Remember: you read code a lot more than you write it.

