4 ms·
> instead, we'll have "withers" or "reconstructors When? > On the other hand, C# finds itself needing to add more and more capabilities to this feature, while
by dmitriid 5y ago
> instead, we'll have "withers" or "reconstructors
When?
> On the other hand, C# finds itself needing to add more and more capabilities to this feature, while Java dodged that bullet.
Java "dodged it" by never even having to fight. While C#'s "poor choices" are leading to a language with less and less boilerplate with almost each year, in Java we'll have to wait another 10 years before it delivers half of a half of the "withers" functionality that doesn't work with half of existing standard library code (the way arrays, lists and collections are three non-intersecting entities).
- kaba0 5y agoBut at the other hand, C# is heading in the direction of C++, where even after n years working with it, it can still surprise you/find yet another way of doing this and the rest. Like, I would prefer not having 10+ initializers from C++ in a language.
- dmitriid 5y agoBut on the other hand you have object initializers directly in the language In Java you have one of these: - a hope that someone provided a useful static `.of` method - a hope that someone provided the 15000 setter methods that you have to tediously invoke one by one - a hope that someone provided a generator that created a builder that has 15000 setter methods that you have to tediously invoke one by one Meanwhile in C#: new Object { x = ..., y = ..., z = ... } for literally any object (provided properties are public of course). And don't get me started on array vs list vs collections none of which are compatible with each other. And hundreds of other QoL improvements that are begging to be implemented, and are not.
- kaba0 5y agoIt was more of an example on C++, and I agree that many features of C# are great QoL improvements! But at the same time, I do feel that sometimes the language committee would be better not implement a feature just yet and wait for a better abstraction that makes 2-3 features possible at the same time. That way the cognitive load of the language would decrease by a lot. And yeah, C# feels to me to be on the way to being way too feature-packed, which can be a detriment in the extreme.
- pron 5y agoEasier construction for records will come to Java. As with most Java features, it will come once it's been carefully considered, and done in a way that gives the most bang for the buck (e.g. we do want easier object construction, but if we add a feature for that, we'll try to get more than just easier object construction out of it). > And don't get me started on array vs list vs collections none of which are compatible with each other. This is not true. Lists are collections, and while arrays are different, Arrays.asList() gives you a list view of arrays. > And hundreds of other QoL improvements that are begging to be implemented, and are not. First of all, just in the past five years we got local variable type inference (var), switch expressions, records (with much more to come), sealed classes, and basic pattern matching (with much more to come), and string templates are around the corner. All of those are significant QoL improvements. Second, every feature comes at the expense of all others -- both because of opportunity cost and overall language complexity budget -- and the question is one of priorities. Not everyone has the same priorities. Finally, because Java is expected to remain extremely popular for at least a couple more decades, we must be very careful about adding features. While other languages are trying desperately to gain many developers right away, we're looking ahead to ensure that we'll be attractive to developers in ten and twenty years from now, and so must spend the complexity budget carefully.
- dmitriid 5y ago> Easier construction for records will come to Java. Once again: when? And why only records? Why does everything in java require someone to manually create an .of method, or create 15000 setter methods or generate those 15000 setter methods? > This is not true. Lists are collections, and while arrays are different, I remember running into an issue with the difference, but can't remember now. Quite possible it was an artefact of an early implementation. > Arrays.asList() gives you a list view of arrays. Yup. One of the hundreds papercuts that litter Java. C#: var list = new List<string>() { "carrot", "fox", "explorer" }; var array = new string[]{ "carrot", "fox", "explorer" }; ... use whatever IEnumerable methods on both ... Java: Ahahaha. No. For lists use a static .of method and be glad that someone manually wrote that in the library. And be thankful that there's some shortcut to create an array. But for Lists? eff off, no shortcuts for you. Oh you want convenience methods on arrays? Ahahaha, no. Use a separate helper to convert into a list first. (This is so bad that IDEA suggests some version .toList as the first method on I swear 90% of array/collection/list/stream operations). Because, as someone said, "our goal isn't to adopt the strategy of less successful products, but to forge our own". I'm really surprised records made it into the language with this approach to things. Edit: Note: Ii use Java and C# interchangeably at my day job. Man is C# a nicer language with literally hundreds of QoL improvements that make you scream "why didn't Java adopt these?" I still reach for Java as I'm more comfortable with it and it has an unparalleled breadth of libraries. But every time I need to write or implement and write another X.builder().setX.setY.setZ.build() instead of `new X { x=.., y=.., z=.. }` I want to claw my eyes out.