6 ms·

Strange how you consider property assignments from C# but only in the very limited scope of `with`. Why not have all other lessons from C# like `{get; set;}` a

Strange how you consider property assignments from C# but only in the very limited scope of `with`. Why not have all other lessons from C# like `{get; set;}` and object initialisation (among other things) syntax is beyond me. (Well, "we don't adopt strategies [whatever that means] from less successful languages" is a reason I guess https://news.ycombinator.com/item?id=28985688 https://news.ycombinator.com/item?id=28985688)

pron 4y ago
What I meant was that we don't adopt a feature just because some other language has it, let alone from languages that don't have the same philosophy as we do of trying to have as few features as we can get away with. Records are overall more valuable than properties (due to various reasons, from serialization to interaction with collections). But once you have records with "withers" the question becomes how valuable is it to also have properties. It doesn't seem like it would be helpful enough to overcome the drawbacks. BTW, C# didn't add properties as a "lesson." Properties in C# and JavaBeans have the same pedigree: RAD UI composer tools of the 90s [1]. They came to C# by way of VB. So really, Java would be adopting a VB solution, and there needs to be a good reason for that. [1]: https://en.wikipedia.org/wiki/Rapid_application_development https://en.wikipedia.org/wiki/Rapid_application_development
- dmitriid 4y ago
  > and there needs to be a good reason for that. A year ago I already said all the good reasons. There are many reasons why things like Lombock exist. There are reasons why people loathe writing interminable chains of builder methods. But sure. None of these are good reasons because something something Visual Basic. What Java will inevitably end up with is a yet another half-assed approach that only exists for a small part of the language and is not applicable to the rest of it. > BTW, C# didn't add properties as a "lesson." That's not what I wrote. This is literally from your link: "Digression: learning from C#" And look. Right below it, emphasis mine --- start quote --- The C# approach was sensible for them because they could build on features they already had (default parameters, properties) --- end quote --- And look. "Extrapolating from records" section basically says: Java has nothing, and will need to rebuild everything from scratch for this not to be a half-assed solution. Oh well.
  - pron 4y ago
    > The C# approach was sensible for them because they could build on features they already had (default parameters, properties) You've misunderstood. Once you have properties it makes sense to go a certain way. If you don't, it makes more sense to add records and not properties. Now you don't have to agree with the Java team's decisions. Programmers rarely agree on much. But I think you should at least appreciate the irony that if we had added properties, I would be responding right now to another equally annoyed person complaining that we're not learning the lessons of Go and Zig and Rust, which have refused to add properties, and couldn't we see what an obviously stupid idea it was.
    - dmitriid 4y ago
      > But I think you should at least appreciate the irony that if we had added properties, I would be responding right now to another equally annoyed person complaining that we're not learning the lessons of Go and Zig and Rust Most likely not. Meanwhile C# could build on the strength of what they have in the language. And Java, and I cannot repeat it enough times, will have a half-assed solution applicable only to a small part of the language while keeping the inanity of manual `.of` methods, manual interminable chains of builder methods, and other half-assed solutions everywhere else. While denigrating other languages and their decisions. Even the link you provided clearly states this: "And, everything we can do with records but not with classes increases a gap where users might feel they have to make a hard choice; it's time to start charting the path of generalizing the record "goodies" so that suitable classes can join in the fun." Again: while others have built on the languages features they have, and they are immediately propagated through the language with little to no additional effort, "Java does not adopt strategies from less successful products", and "keep the language conservative". And yet here we are, "learning from C#" and struggling how to figure out a simple (for some definition of simple) addition so that it works with the rest of the language that has languished in the "conservative" land for too long. Edit. I also wonder how many of the things that are currently placeholders will be required and will surpass anything C# and other "lesser languages" have come up with: factory, __byname, __deconstructor etc.
      - 4y ago

pron 4y ago

What I meant was that we don't adopt a feature just because some other language has it, let alone from languages that don't have the same philosophy as we do of trying to have as few features as we can get away with. Records are overall more valuable than properties (due to various reasons, from serialization to interaction with collections). But once you have records with "withers" the question becomes how valuable is it to also have properties. It doesn't seem like it would be helpful enough to overcome the drawbacks. BTW, C# didn't add properties as a "lesson." Properties in C# and JavaBeans have the same pedigree: RAD UI composer tools of the 90s [1]. They came to C# by way of VB. So really, Java would be adopting a VB solution, and there needs to be a good reason for that. [1]: https://en.wikipedia.org/wiki/Rapid_application_development https://en.wikipedia.org/wiki/Rapid_application_development

dmitriid 4y ago
> and there needs to be a good reason for that. A year ago I already said all the good reasons. There are many reasons why things like Lombock exist. There are reasons why people loathe writing interminable chains of builder methods. But sure. None of these are good reasons because something something Visual Basic. What Java will inevitably end up with is a yet another half-assed approach that only exists for a small part of the language and is not applicable to the rest of it. > BTW, C# didn't add properties as a "lesson." That's not what I wrote. This is literally from your link: "Digression: learning from C#" And look. Right below it, emphasis mine --- start quote --- The C# approach was sensible for them because they could build on features they already had (default parameters, properties) --- end quote --- And look. "Extrapolating from records" section basically says: Java has nothing, and will need to rebuild everything from scratch for this not to be a half-assed solution. Oh well.
- pron 4y ago
  > The C# approach was sensible for them because they could build on features they already had (default parameters, properties) You've misunderstood. Once you have properties it makes sense to go a certain way. If you don't, it makes more sense to add records and not properties. Now you don't have to agree with the Java team's decisions. Programmers rarely agree on much. But I think you should at least appreciate the irony that if we had added properties, I would be responding right now to another equally annoyed person complaining that we're not learning the lessons of Go and Zig and Rust, which have refused to add properties, and couldn't we see what an obviously stupid idea it was.
  - dmitriid 4y ago
    > But I think you should at least appreciate the irony that if we had added properties, I would be responding right now to another equally annoyed person complaining that we're not learning the lessons of Go and Zig and Rust Most likely not. Meanwhile C# could build on the strength of what they have in the language. And Java, and I cannot repeat it enough times, will have a half-assed solution applicable only to a small part of the language while keeping the inanity of manual `.of` methods, manual interminable chains of builder methods, and other half-assed solutions everywhere else. While denigrating other languages and their decisions. Even the link you provided clearly states this: "And, everything we can do with records but not with classes increases a gap where users might feel they have to make a hard choice; it's time to start charting the path of generalizing the record "goodies" so that suitable classes can join in the fun." Again: while others have built on the languages features they have, and they are immediately propagated through the language with little to no additional effort, "Java does not adopt strategies from less successful products", and "keep the language conservative". And yet here we are, "learning from C#" and struggling how to figure out a simple (for some definition of simple) addition so that it works with the rest of the language that has languished in the "conservative" land for too long. Edit. I also wonder how many of the things that are currently placeholders will be required and will surpass anything C# and other "lesser languages" have come up with: factory, __byname, __deconstructor etc.
    - 4y ago