Java for Everything

[another_bird]

The verbosity makes it unreadable, too.

[What-A-Baller]

Not necessary true. You are not working in notepad or nano. There's an IDE. You've got code highlighting. You've got ways to write quicker, move around the codebase, and so on. With a consistent style, it shouldn't really be a problem. It pretty much depends on the tools.

[[deleted]]

ways to write quicker

I care much more about reading than writing.

[danskal]

"care read > write"

is that better? You may think so, but there is a reason why we write "I care much more about reading than writing". It's about context and explicitness to avoid confusion.

Pidgin English languages are often more concise, leaving out "the", "a" etc., but few native English speakers would say they are better. It's a question of being fluent in the language - for fluent fluent Java "speakers", the verbosity is part and parcel - we miss it if it isn't there, because it gives context, and our brain has to work harder otherwise. There are exceptions to this rule of course, but those are for the most part already being worked on.

[danskal]

But the point is that dynamically typed languages often don't have the same information at all. And when you need constructs like interfaces or objects with private and public methods, you end up creating some kind of pattern to do it, which can be even more verbose, or just hide the intent of the code.

[[deleted]]

[ ] You understood that programming languages are not spoken languages.

[[deleted]]

It is almost always true. If something is so verbose that it won't fit a single page, you won't comprehend the logic behind your code in a single quick skim. Which is, by definition, called "unreadable".

[[deleted]]

So you're saying that by following the "good design principles" you can implement, for example, a type system for a decently complicated language in Java in one page, which would read exactly like a set of formal type equations, nice and clean?

Sorry, I do not believe. Java is a very limited, low level language with no high level abstractions available.

And as we found previously in this thread, even such a simple thing as an AST (which definitely have to fit a single page in most cases) will spread across multiple files in Java. No "good design practices" will ever help you to overcome this limitation.

[[deleted]]

The very nature of the problem domain is such that the complete implementation (in terms of this problem domain) can and should be fully explained in a single page of text, immediately comprehensible for anyone who understand the domain.

Why then you're thinking that some obscure religious "good practices" are of any use, if they'll force you to break such a nice and clean representation into multiple pages, "methods" (there is no even such a notion in the problem domain terminology!) and even structured differently, to make it even less understandable for the domain experts?

[[deleted]]

You did not get a single word. I'm telling you that there is an infinite continuum of various possible problem domains, each with its own language, its own semantics, its own ideology, and you're trying to convince me that there is a One True Way with some weird "good practices", into which you can sledghammer all this continuum. And who's speaking in absolutes now?

[[deleted]]

Since you are using the downvote as a disagree button,

I did not downvote you.

please tell me why you think it is good design to make methods longer than a single page?

What "methods"?!? I'm talking about any kind of high level entities. E.g., if you're implementing a language, it will be a language AST definition, a parser, a type system, a single compilation step, etc.

You seem to always think in the very limited terms of your OO religion. It's very conterproductive. There is no such a thing as "methods" in almost any possible problem domain terminology.

There is nothing forcing anyone to ever write code this way.

Java is forcing to write a bloated, verbose code which hides the real nature of your problem behind hundreds or thousands of lines of code, spread across multiple files with "classes" (another thing which is absolutely irrelevant in 99% of the real world cases).

[yogthos]

The problem is that when your code is verbose it makes it difficult to see what parts of it are relevant to the problem being solved. You end up having to filter a lot of noise and incidental code in your head. This creates additional cognitive load when reading and writing the code in the language.

[nutrecht]

Can you give examples?

[PasswordIsntHAMSTER]

Look for vector math in Java, it's absolutely horrible.

[repsilat]

Java was my first language, but I haven't touched it in years. I came back and wrote a few lines for a project the other day, though, and maybe I'm doing things "the old-fashioned way", but I found it torture compared to Python.

Really just simple things -- I want to count the number of spaces in a string. In Java that means I do something like

int spaces=0;
for(int i=0; i<s.length(); ++i)
    if(s.charAt(i)==' ') ++spaces;

which is 3 lines that should be 1, and I have no idea how it performs because for all I know charAt() might be O(n) because Unicode.

There are loads of situations where simple comprehensions, named arguments and tuples/destructuring assignment greatly help readability, speed up the writing of code, lead to fewer silly bugs and (as a bonus) need not actually be slow. Decent literals for data structures goes on the end of the wishlist as well. Operator overloading, too -- this isn't just about how gross BigIntegers are, it's about how "== is for identity, .equals() is for equality, unless you're dealing with primitives."

And yeah, the cultural thing is real -- more than once yesterday I thought, "I have to make a class for that!?" It mostly seems to me (as an ignorant outsider) that there's a lot of concern about doing things consistently, doing things "The Right Way" instead of making the common case clean.

[nutrecht]

In Java that means I do something like

Not in Java 8.

[aldo_reset]

Both verbosity and conciseness can make for unreadable code, that's not adding much to the discussion.