4 ms·
I disagree. One of the major critiques of Java is how verbose and full of boilerplate it is. And sure, you can hand wave that as devs being picky, but this is a
by appplication 3y ago
I disagree. One of the major critiques of Java is how verbose and full of boilerplate it is. And sure, you can hand wave that as devs being picky, but this is a real reason people avoid picking up new projects in Java. The verbosity serves no purpose, and less code is generally better.
As for there now being multiple ways to write the same thing, this seems like something that could be easily linted into consistency. So you would really only have to learn the less verbose way for any newer Java projects.
- riku_iki 3y ago> of Java is how verbose and full of boilerplate it is. yes, new SimpleLang can have lessons learned during last 20 years implemented, as in example from another commenter: https://news.ycombinator.com/item?id=37068380 https://news.ycombinator.com/item?id=37068380 Currently, for a given task, Java usually have 5 legacy deprecated ways to solve, and two more in newish Java versions, and dev needs to keep all of them in memory to be able to read and understand other's code. > As for there now being multiple ways to write the same thing, this seems like something that could be easily linted into consistency. that's if you don't work with any legacy systems and 3p libraries and never switch projects/jobs
- user432678 3y agoSounds like Kotlin is exactly such SimpleLang.
- seanmcdirmid 3y agoYa, I'm not sure why people would use Java anymore given that the SimpleLang is pretty good.
- lmm 3y agoKotlin is even worse; it's younger than Java but also has 5 legacy ways to solve the problem and two more in the newer version, it's just that the legacy ways have been removed so any examples you find online won't work any more.
- unscaled 3y agoAre there any examples for this? Kotlin sure moves faster than Java, but except for features that were experimental or unstable to begin with (coroutines, -X flags), I can't think of a case where more than 1 deprecated version exists (and the "deprecated" versions are not nearly as crufty as Java).
- lmm 3y agoThose "experimental or unstable" features tend to be the advertised selling points of Kotlin. Particularly for async, the previous "experimental" APIs were the only ones available at the time and the recommended way of using Kotlin.
- kaba0 3y agoKotlin is anything but simple
- kaba0 3y agoYou way over exaggerate the number of different ways a given thing can practically be done in Java. Pattern matching for example only has the visitor pattern as a counterpart and you ain’t going around spewing visitor patterns, it not as simple. Sure there are a few warts, e.g. arrays work a bit differently than Lists, and primitive-object discrepancy, but every language will pick up similar issues over time.
- piwi 3y agoMy comparison with c++ shows java is not more verbose if you take into account headers.
- rf15 3y agoI think people are very aware that c++ is a lot more verbose than Java. What's the advantage of making this particular comparison?
- riku_iki 3y agoI actually think c++ is not necessary more verbose than java as a language. But memory management/safety, weaker IDE support and ecosystem make it less productive than Java for business dev.
- kaba0 3y agoWait until you see this new, hyped language called Go! That is even more verbose than both!
- jimmaswell 3y agoI actually appreciate the simplicity of bare Java. It can be verbose on one hand but on the other there are no surprises because everything is just a method call on an object with no operator overloading etc. Seems like they're kind of ruining that with bizarre things like "obj instanceof Point(int x, int y))". That doesn't connotate at all that it's calling x() on the point to get x, it looks like a field. Compare with C# which has a ton of convenience features and syntactic sugar but it's all intuitive and self-explanatory. Really I wish Java would go away and .NET would take over but it's too entrenched.
- the_af 3y agoPoint is a record type here. Record types seem to be like Scala's case classes. The distinction between fields and getters is intentionally blurred because these are immutable value classes.
- cutler 3y agoYes. Any language which requires an IDE to append get, set and toString for every damned variable is a language in trouble. Here we are at Java 21 and Java must be the only language in modern use which requires regex metacharacters to be escaped. This even after the introduction of raw string literals.
- kaba0 3y agoYou missed out on Java’s records that solve your gripe with get/set.
- cutler 3y agoRecords are not the same as classes.
- kaba0 3y agoThey are not, but if you need strictly a class for strictly storing data, records are superior in every way. Unfortunately some tools still want POJOs, but most (eg. Converting to json) do work with records.
- nogridbag 3y agoDisagree with that, but please provide a counterpoint. I've using Java 17 for a large project and I was really excited to use records. I have not found any practical use case for them outside of one or two instances in a project with 2 years of development. Storing data is also where I thought records would be a good use case. But in the real world data is not Point(x,y). If you have more than 3 or 4 fields in your record, that's simply not going to work. I thought the rest of the industry decided over a decade ago that using positional properties (e.g. new MyRecord(a,b,c,d,e,f,g)) to initialize an object was a bad idea. I think Rich Hickey gave a whole talk on that subject. If there's a future plan to be able to create records using named props, e.g. new MyRecord([firstName: "Bob"]), then I would reconsider my opinion.