Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making Lenses Practical in Java

chriskiehl.com

Post reply on HN
Print view View original

81–90 of 108 posts

Re: Making Lenses Practical in Java

#81

Post by exabrial »

hgsgm wrote: post #39
exabrial wrote: post #35

Earlier quoted context omitted.

Lombok is a compiler extension, not a dependency. It does actually need to be present at runtime!

It's a compile-time dependency.

In fact, no, it is not a dependency; your code will never see Lombok, only its effects.

Lombok IS a compiler extension. It exploits one of the weirdest features that was introduced in Java 1.6: You can instruct javac to call a custom extension whenever it encounters a certain Annotation. This annotation doesn't need to be on the Applications classpath either.

Weirdly, I haven't see this feature widely exploited by anyone _until_ lombok came around.

Reference: https://openjdk.org/groups/compiler/processing-code.html

Re: Making Lenses Practical in Java

#82

Post by exabrial »

actionfromafar wrote: post #38
exabrial wrote: post #35

Earlier quoted context omitted.

Lombok is a compiler extension, not a dependency. It does actually need to be present at runtime!

Does not? But you could still see it as a transitive dependency of sorts.

yep :) I suck at typing

Re: Making Lenses Practical in Java

#83

Post by pron »

dmitriid wrote: post #79
pron wrote: post #78

Earlier quoted context omitted.

> 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…

> 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 sm…

Out of curiosity: given that virtually all features in Java were adopted from other languages (almost always less popular ones) so there clearly is no aversion to that, and given the level of experience and success of the Java team, not to mention their clear interest in Java's success -- i.e. they have both the motivation and ability to do what's best for Java -- what possible reason do you think they have to do something that to you seems so obviously wrong?

Moreover, why do you conclude that propertied are the only right choice, seeing that Java is far from being the only language without them? You should, at best, conclude that some language designers like them and some don't.

> Even the link you provided clearly states this: ...

That refers to pattern matching and withers. Records don't have properties either.

Re: Making Lenses Practical in Java

#84

Post by wtetzner »

dmitriid wrote: post #77
pron wrote: post #72

Earlier quoted context omitted.

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…

> 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…

I don’t think properties add anything that getters/setters don’t already give you (other than slightly different syntax). I think the “right” way to replace the need for builders is to add support for named arguments.

Re: Making Lenses Practical in Java

#85

Post by dmitriid »

wtetzner wrote: post #84
dmitriid wrote: post #77

Earlier quoted context omitted.

> 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…

I don’t think properties add anything that getters/setters don’t already give you (other than slightly different syntax). I think the “right” way to replace the need for builders is to add support for named arguments.

> I don’t think properties add anything that getters/setters don’t already give you

Except that you have to write them out by hand for every property you want in your code. Or generate them.

> I think the “right” way to replace the need for builders is to add support for named arguments.

Often you want to add validators to your setters. Just named arguments won't cut it.

Re: Making Lenses Practical in Java

#86

Post by dmitriid »

pron wrote: post #83
dmitriid wrote: post #79

Earlier quoted context omitted.

> 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 sm…

Out of curiosity: given that virtually all features in Java were adopted from other languages (almost always less popular ones) so there clearly is no aversion to that, and given the level of experience and success of the Java team, not to mention their clear interest in Java's success -- i.e. they have both the motivation and ability to do what's best for Java -- what possible reason do you think they have to do som…

> what possible reason do you think they have to do something that to you seems so obviously wrong?

We are all human. That's the main reason.

That's why instead of a unified way of creating collections (and lists and arrays) you need to manually write out `.of` methods and hope that the authors of the library that provides collections (whether built-in or external) provided those methods.

That's why instead of a unified way of creating objects you need tedious manual builder patterns, manual getter/setter boilerplate or code generation.

That's why

That's why the proposal couldn't re-use existing language features (like C# did in the first approach, and as is acknowledged in the proposal).

So you will end up with what is essentially an object initialisation syntax... but only available in this one construct. And will then spend another five years trying to bring it to the rest of the language, again in a very limited capacity. Because something something "conservative language" and "less successful languages".

> Moreover, why do you conclude that propertied are the only right choice

I did not conclude that.

Re: Making Lenses Practical in Java

#87

Post by pron »

dmitriid wrote: post #86
pron wrote: post #83

Earlier quoted context omitted.

Out of curiosity: given that virtually all features in Java were adopted from other languages (almost always less popular ones) so there clearly is no aversion to that, and given the level of experience and success of the Java team, not to mention their clear interest in Java's success -- i.e. they have both the motivation and ability to do what's best for Java -- what possible reason do you think they have to do som…

> what possible reason do you think they have to do something that to you seems so obviously wrong? We are all human. That's the main reason. That's why instead of a unified way of creating collections (and lists and arrays) you need to manually write out `.of` methods and hope that the authors of the library that provides collections (whether built-in or external) provided those methods. That's why instead of a unif…

> We are all human. That's the main reason.

Surely you see that those who have come to the opposite conclusion can be equally convinced that it is you who has made what seems to them an obvious mistake for the very same reason.

If we're honest, we should acknowledge that since there is no actual empirical evidence showing one way is superior to the other here, and since experts have come down on both sides, then there's probably a strong aesthetic component, in which case it makes for a language to remain true to the aesthetic principles that have proven successful for that particular language.

> Because something something "conservative language" and "less successful languages".

You keep missing the point about the "less successful languages." All of Java's features come from less successful languages. I was merely saying that the fact that some languages have a feature is not a reason to adopt it. It's just that if that language was doing better than Java, then there would at least be some social merit to the argument "you should do it because they do", but otherwise it's not an argument at all because other languages don't do it, so there's simply no guidance there.

"You should do it because some people really want it" is similarly unhelpful because whatever "it" is, there's usually a similar number of people who want the exact opposite, and just as insistently. That is why different languages end up making different choices.

Neither of these is an argument at all. All they mean is that other options exist, but they don't help choosing among them. That some languages do one thing and others do another, that some programmers want one thing and others want the opposite is a given.

Now, from my personal perspective, the uniformity and power you want are better served by ADTs than by properties, it's just that you haven't appreciated the extent of the power that ADTs bring when used as intended (it's not really a distinctly separate construct), nor appreciated the significant downsides that properties bring along with their benefits, that are quite measly in comparison to ADTs. Then again, there clearly is no consensus on this, just as there is no consensus on just about anything, and whatever choice is made, some will be unhappy.

Some other things you want may well end up being features in Java, it's just that we believe other things take priority. As for those that won't, our desire to minimise language features if we can help it may be a purely aesthetic choice, but it's one that's worked well for us (just as the opposite may work well for other languages). Without any good evidence that we should abandon it, the fact that some languages don't share our aesthetics is surely not a sufficient reason to abandon it.

Re: Making Lenses Practical in Java

#88

Post by ryloric »

pron wrote: post #19

Lenses are cool, but they make me wonder: how many different paths of a deep immutable data hierarchy are transformed in an application to make this abstraction worthwhile, as opposed to replicating the entire traversal at each location? If the number is small then, however cool, this abstraction may be more trouble than it's worth. Just because you can reify some concept in an elegant composable construct doesn't me…

> Just because you can reify some concept in an elegant composable construct doesn't mean that you should in the sense that it saves you a significant amount of effort.

aka monads lmao

Re: Making Lenses Practical in Java

#89

Post by ivan_gammel »

Ironlink wrote: post #75
ivan_gammel wrote: post #70

Earlier quoted context omitted.

>>My example above demonstrates a constraint that cannot be implemented in a constructor. >It can't but that's not due to the proposed solution for withers. This has nothing to do with withers. It can't be implemented simply because it is a constraint on a specific transition of state. There's no transition of state in constructor. >Record are immutable on purpose and you want to add a mutation constraint whish will…

I can't find anything in the linked eg-draft that would indicate that the error would "occur later". In fact, it explicitly says: Note too that if the canonical constructor checks invariants, then a with expression will check them too. For example: record Rational(int num, int denom) { Rational { if (denom == 0) throw new IllegalArgumentException("denom must not be zero"); } } If we have a rational, and say r with {…

Please re-read the thread, the problem was described multiple times in it.

Re: Making Lenses Practical in Java

#90

Post by ivan_gammel »

wtetzner wrote: post #80
ivan_gammel wrote: post #37

Earlier quoted context omitted.

I hope they will find a better solution, as this proposal will break encapsulation. Let’s say you model allowed transitions via business methods and thus restrict certain state changes. You can either serialize or deserialize state or perform an allowed transition. If wither becomes a language feature, it will allow forbidden state changes that cannot be caught by validation in constructor, which will allow deseriali…

I don’t believe this is true. From my reading of the document, all with expressions go through the primary constructor.

Well, that is exactly the problem, as I already explained a few times in this thread. Constructor cannot validate state transitions, so the “with” statement or the block surrounding it will have to do it, breaking encapsulation and likely requiring multiple copies of this code.
Post reply on HN