4 ms·

very elegant solution. i agree it will take much more time to implement that in c#.

mavelikara 8y ago
> i agree it will take much more time to implement that in c#. If I am reading the code correctly, here is the Java version (with Lombok [1]): @Data class OrderId { final String id; } @Data class DeliveryTime { final long time; } @Data class DeliveryDetails { final DeliveryTime deliveryTime; } @Data class Order { final OrderId id; } @Data class DeliveredOrder { final OrderId id; final DeliveryDetails deliveryDetails; } I can imagine C# also having similar expressive powers. [1] http://jnb.ociweb.com/jnb/jnbJan2010.html http://jnb.ociweb.com/jnb/jnbJan2010.html. Lombok reduces the drudgery of writing some of the code in Java. Modern JVM languages like Scala and Kotlin have native constructs to express this.
- tigershark 8y ago
  If you are not writing java and you are using lombok then yes, this simple case seems covered well. I still can’t see how Lombok will help with the exhaustive pattern matching in case the order is a union type of several orders types as explained in my other comment or with avoiding mixing up ms and seconds when using a unit of measure in f# for deliveryTime. Also I’m curious how you would change just one field of an immutable object with 10s of properties in Lombok and if the resulting java code is as efficient as F# with its immutable data structures that use the copy on write semantics.
  - mavelikara 8y ago
    I agree that exhaustiveness check enforced by compiler is something I will miss in Java. Persistent data structures have been implemented in Java if that's what you mean by efficient mutations to immutable structures. I can't imagine such structures being hard in any language hosted on the JVM or CLR. F#, and ML-family languages, surely have their killer features. I am only contesting the claim that the GP made that modeling a domain is a struggle in C# when compared to F#. Imagine if someone came on this thread and claimed that they struggle to write effectful code in F# which they have been writing in Haskell. Of course, you have counter-evidence of that in all the F# programs you have written so far! I feel the same about the inability-to-domain-modeling claim.

> i agree it will take much more time to implement that in c#. If I am reading the code correctly, here is the Java version (with Lombok [1]): @Data class OrderId { final String id; } @Data class DeliveryTime { final long time; } @Data class DeliveryDetails { final DeliveryTime deliveryTime; } @Data class Order { final OrderId id; } @Data class DeliveredOrder { final OrderId id; final DeliveryDetails deliveryDetails; } I can imagine C# also having similar expressive powers. [1] http://jnb.ociweb.com/jnb/jnbJan2010.html http://jnb.ociweb.com/jnb/jnbJan2010.html. Lombok reduces the drudgery of writing some of the code in Java. Modern JVM languages like Scala and Kotlin have native constructs to express this.

tigershark 8y ago
If you are not writing java and you are using lombok then yes, this simple case seems covered well. I still can’t see how Lombok will help with the exhaustive pattern matching in case the order is a union type of several orders types as explained in my other comment or with avoiding mixing up ms and seconds when using a unit of measure in f# for deliveryTime. Also I’m curious how you would change just one field of an immutable object with 10s of properties in Lombok and if the resulting java code is as efficient as F# with its immutable data structures that use the copy on write semantics.
- mavelikara 8y ago
  I agree that exhaustiveness check enforced by compiler is something I will miss in Java. Persistent data structures have been implemented in Java if that's what you mean by efficient mutations to immutable structures. I can't imagine such structures being hard in any language hosted on the JVM or CLR. F#, and ML-family languages, surely have their killer features. I am only contesting the claim that the GP made that modeling a domain is a struggle in C# when compared to F#. Imagine if someone came on this thread and claimed that they struggle to write effectful code in F# which they have been writing in Haskell. Of course, you have counter-evidence of that in all the F# programs you have written so far! I feel the same about the inability-to-domain-modeling claim.