3 ms·

As a Java developer for 15 years and as a language enthusiast myself I'm curious as well. Because I definitely don't see many places where I would use pattern m

As a Java developer for 15 years and as a language enthusiast myself I'm curious as well. Because I definitely don't see many places where I would use pattern matching in my code or even records. Recently I wrote like 10k LoC and I used record once: in test code to return pair of values. May be I'll replace some `if`-s with pattern matching, just like I use `instanceof` pattern matching today, but that's absolutely minor thing which is hardly worth mentioning. I would even dare to say that lambdas and `var`-s for me are questionable features. Actually as I grow older, I appreciate ascetic nature of Go and sometimes I think that using Java 1.4 might actually be preferable for many codebases. I understand that for code which manipulates trees like compilers with their ASTs, pattern matching might be god send. The thing is... 99.99% of developers don't write this code, so optimizing language for it is strange goal. Sometimes I think that some language features are driven by hype, even with Java. I always happy about runtime improvements, though. And Java delivers in that front, so I can tolerate pattern matching and streams if I can get virtual threads and struct values.

soulbadguy 3y ago
> Because I definitely don't see many places where I would use pattern matching in my code or even records. Recently I wrote like 10k LoC and I used record once: in test code to return pair of values. Without knowing your application domain or seeing the code, it's hard to guess why. But one reason is that pattern matching and union/algebraic type tend to go hands to hands. So depending on how your data domain was modeled, it is normal that you don't find yourself not needing to pattern match as much. In general,it's normal to find one self "not needing" a feature that one is not used to, professional are very good at structuring things is a way that work best with the current toolings. > I understand that for code which manipulates trees like compilers with their ASTs, pattern matching might be god send Very true, but i can assure you , pattern matching (combined with record and ADT) are very useful tools in general computation as well.
haspok 3y ago
As they say, "the determined Real Programmer can write FORTRAN programs in any language.". ADTs and pattern matching go hand in hand, and they - along with immutable structures - are the cornerstones of functional programming. They provide you very strong compile-time guarantees in a very elegant and readable form. I like to write code this way, and out of 10k LoC I would estimate at least half is ADTs and pattern matching for me. Maybe more. Too bad that although Java's ADTs are coming along nicely, pattern matching is in it's infancy (due to limitations inherent in Java). This is the single language feature I miss the most from Java and Kotlin from Scala.

soulbadguy 3y ago

> Because I definitely don't see many places where I would use pattern matching in my code or even records. Recently I wrote like 10k LoC and I used record once: in test code to return pair of values. Without knowing your application domain or seeing the code, it's hard to guess why. But one reason is that pattern matching and union/algebraic type tend to go hands to hands. So depending on how your data domain was modeled, it is normal that you don't find yourself not needing to pattern match as much. In general,it's normal to find one self "not needing" a feature that one is not used to, professional are very good at structuring things is a way that work best with the current toolings. > I understand that for code which manipulates trees like compilers with their ASTs, pattern matching might be god send Very true, but i can assure you , pattern matching (combined with record and ADT) are very useful tools in general computation as well.

haspok 3y ago

As they say, "the determined Real Programmer can write FORTRAN programs in any language.". ADTs and pattern matching go hand in hand, and they - along with immutable structures - are the cornerstones of functional programming. They provide you very strong compile-time guarantees in a very elegant and readable form. I like to write code this way, and out of 10k LoC I would estimate at least half is ADTs and pattern matching for me. Maybe more. Too bad that although Java's ADTs are coming along nicely, pattern matching is in it's infancy (due to limitations inherent in Java). This is the single language feature I miss the most from Java and Kotlin from Scala.