5 ms·
This actually looks like adding complexity. Switch statements are rarely used in my experience in preference to array indexing/hashmap/properties or just if/el
by SillyUsername 2y ago
This actually looks like adding complexity.
Switch statements are rarely used in my experience in preference to array indexing/hashmap/properties or just if/else.
Now Java devs need to remember switches can have guards, do auto boxing, and can do work which is duplicating getters/setters or just general purpose validation by annotation (JSR 303 if memory serves).
This is a good example of Java becoming bloated imho. Something like JSRs such as streams were useful syntactic sugar for functional and threaded programming, but something like this adds no tangible benefits over what is already in the language.
- high_na_euv 2y agoArray as replacement for switch? Maybe for simple cases
- SillyUsername 2y agoNot as a general case, but something like (not withstanding missing range checks) below: private String[] alphabetIndex = new String["A", "B"...]; public String getLetterAtIndex(int index1Based) { return alphabetIndex[index1Based-1]; }
- high_na_euv 2y agoSwitch is useful for simple code dependent on e.g kind or expression, not just as a mapper
- kaba0 2y agoThese are switch expressions. And there is absolutely a need for them, especially with records. They provide a much safer and better composing way to write data-oriented code.
- SillyUsername 2y agoFrom a holistic point of view new developers often bemoan Java being too large and complex to learn, which is the opposite of what it used to be (I started at JDK 1.0 in 1995). Little changes here and there are eroding a core value of the language imho, and those devs choose different easier languages to start with. Without new blood languages die. I am surprised Brian Goetz endorsed this (I've got his older Java book Concurrency in Practice) so can only assume there's a larger picture I don't see. As stated, I believe Java is "jumping the shark" when it should be making breaking changes (not just huge deprecations). Also I'm not sure why my parent comment has been downvoted for a unpopular view, it's a genuine concern and why I now prefer to use other simpler languages instead when not in a work context.
- Pet_Ant 2y agoI mean I feel like Java evolving has really eaten into Groovy. It used to offer so much more that Java 5, but over time it's value-add has diminished as Java has picked up features. It is essential for the language to stay relevant and not fracture as people pick different more productive languages.
- SillyUsername 2y agoI love Groovy and was disappointed it didn't get traction, I still use it for "dirty"* unit tests where I want to grab private variables and not have to bother with reflection libraries :D * dirty meaning quick and/or checking internal state instead of output
- kaba0 2y agoJava is still quite a small language, several-times smaller than C++ or C#. I really don’t feel Java being on that “slippery slope” at all, people like to talk about. Sure, it can’t really shrink, due to backwards compatibility and for the same reason it can’t always have the most elegant solution, but it really is doing pretty much the opposite of any other language of similar age — being as simple as possible, but not simpler.
- Freak_NL 2y agoWhich is why programmers who know these features from languages like Rust hate these. Except, they don't. Whenever I do something in a neat, elegant match-statement in Rust, going back to a language which lacks these is painful. This isn't bloat, it's keeping up with the times.
- SillyUsername 2y agoA better picture would be to do away with switch entirely. It's unnecessary with the options I mention above and code folding. It's should go the way of goto, which also happens coincidentally to be a way of using labels (fun off topic fact goto is a keyword in Java as pre 1.0 it was represented in bytecode). Nb arguing that it also prevents excess code is somewhat moot, the Java community for better or worse favours anemic models full of empty setters and getters, that is probably a more important area to address than just introduce a new record type to avoid these.
- fayten 2y agoIf it allows for alternative design patterns that are simpler then I think it's a win in the end. For example pattern matching is great when writer parsers as an alternative to going the visitor pattern route. Pattern matching has finally made it out of ML land and getting increasingly implemented in mainstream languages. I'm not sure if Rust is the main driver here, but I'm glad to see it.