3 ms·
At the same time, all this syntactic sugar makes the language's surface area gigantic. Like it's almost C++-level complex, and then you would have to properly u
by gf000 19d ago
At the same time, all this syntactic sugar makes the language's surface area gigantic. Like it's almost C++-level complex, and then you would have to properly understand all the interactions between this matrix of features.
That's absolutely a valid language design and many people prefer that, but I personally prefer a bit smaller language with a bit more IDE auto complete, but where you never have to think about what exactly does a line do.
(And then there is also Go that falls off the other edge of the cliff with useless if err checks spamming the code making actually functioning error handling hard)
- troupo 19d ago> a bit smaller language with a bit more IDE auto complete, but where you never have to think about what exactly does a line do. If you need IDE to autocomplete, then you definitely spend more time to understand what a line does ;)
- gf000 18d agoWhile typing this comment I pressed/swiped on several words to finish them. One reads much faster than they write, I don't really see a problem with easily guessable auto complete.
- troupo 18d agoEven if you read much faster than you type, it's easier to read fewer lines of code than dozens of plumbing boilerplate.
- gf000 17d agoSure, we can find factors for "verbosity increase" and "difficulty to understand a line" where what you say is also true. I think that java found a decent spot where both factors are low. It's not a particularly verbose language, especially in modern times (records, type inference, I even mention lambdas because some people live in caves), like if you do POJOs and stuff with getter setters than you get a no information increasing extra 3+3 lines of code per field and that's most of it. Method bodies are not more verbose than other typical languages.