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

What's new in Java 12, 13 and 14

java.christmas

Post reply on HN
Print view View original

121–130 of 136 posts

Re: What's new in Java 12, 13 and 14

#121

Post by willtim »

pron wrote: post #107
willtim wrote: post #98

Earlier quoted context omitted.

> I'd be extremely surprised if you could show that any feature or lack thereof actually costs you money, Bad language design and semantics definitely costs money in the long term. For example, Tony Hoare refers to Null References as his "billion dollar" mistake. The verbosity of Java before sophisticated IDEs would also have cost significant time and money. Java is improving significantly (and arguably was never as…

> and so improvement can only ever be small and incremental. You seem to hint that some hypothetical non-small improvement can be made differently (in some other language). Perhaps it could, but it doesn't seem anyone has done it yet. We do not observe large differences between and in companies based on language choice. I think some of the reason is that developers overestimate the cost of coding in the entire softwa…

> We do not observe large differences between and in companies based on language choice.

Hmm, I think it's pretty clear that most folks are far more productive in Python than say C++. But yes, I agree that there's no silver bullet, programming is hard.

Re: What's new in Java 12, 13 and 14

#122

Post by [deleted] »

willtim wrote: post #121
pron wrote: post #107

Earlier quoted context omitted.

> and so improvement can only ever be small and incremental. You seem to hint that some hypothetical non-small improvement can be made differently (in some other language). Perhaps it could, but it doesn't seem anyone has done it yet. We do not observe large differences between and in companies based on language choice. I think some of the reason is that developers overestimate the cost of coding in the entire softwa…

> We do not observe large differences between and in companies based on language choice. Hmm, I think it's pretty clear that most folks are far more productive in Python than say C++. But yes, I agree that there's no silver bullet, programming is hard.

[deleted]

Re: What's new in Java 12, 13 and 14

#123

Post by pron »

willtim wrote: post #121
pron wrote: post #107

Earlier quoted context omitted.

> and so improvement can only ever be small and incremental. You seem to hint that some hypothetical non-small improvement can be made differently (in some other language). Perhaps it could, but it doesn't seem anyone has done it yet. We do not observe large differences between and in companies based on language choice. I think some of the reason is that developers overestimate the cost of coding in the entire softwa…

> We do not observe large differences between and in companies based on language choice. Hmm, I think it's pretty clear that most folks are far more productive in Python than say C++. But yes, I agree that there's no silver bullet, programming is hard.

Well, not at all in the domains where C++ is normally used nowadays; that's why I talked about comparing reasonable choices. On the other hand, you can see how quickly people transitioned away from C++ to more appropriate alternatives in those domains where C++ is no longer used. It happened virtually overnight (same as the transition from Assembly to Fortran and from Fortran to C). When you don't see such a rapid transition it's usually a good sign that none of the alternatives offers a big advantage.

Re: What's new in Java 12, 13 and 14

#124

Post by kod »

lllr_finger wrote: post #62
kod wrote: post #61

Earlier quoted context omitted.

Kotlin doesn't have real pattern matching.

It doesn't, but at least 'when' statements will be exhaustive when working with sealed classes - which is a breath of fresh air if you enjoy working with sum types and pattern matching.

when expressions will be exhaustive, when statements will not.

Needless distinctions like that make the fresh air a little less fresh...

Re: What's new in Java 12, 13 and 14

#125

Post by apta »

sreque wrote: post #94
pron wrote: post #9

One thing I find a bit disappointing is the focus on language features. Most of the effort in Java goes into the VM and libraries, while keeping the language conservative. This is because VM/library features have a much bigger impact on application quality, and more directly impact the application's users; moreover, it's a strategy that's proven quite successful -- HN notwithstanding, most developers don't like too m…

Language changes are super important when they enable you to program in a new way, or in that way with significantly less boilerplate. For instance, Java 8 enabled new ways of programming via Lambdas and structural typing. You could code in that way before, but anonymous class boilerplate was so high that few bothered, and those that did were hard-pressed to convince their colleagues of its value. The problem with la…

> For instance, Java 8 enabled new ways of programming via Lambdas and structural typing

What does structural typing refer to in this context?

Re: What's new in Java 12, 13 and 14

#126

Post by dkarl »

goto11 wrote: post #90
MaxBarraclough wrote: post #56

Earlier quoted context omitted.

I'm still not sure why imperative/OOP language have been so resistant to adding pattern-matching of the sort seen in Haskell and OCaml. There are plenty of almost entirely pointless features that get implemented in major languages, like 'events' in C#. They add almost no value to the programmer. Pattern-matching would be really useful for avoiding rats' nests of control-flow, but until recently no major imperative la…

The reluctance might be because polymorphism and pattern matching are kind-of solving the same problem from different angles.

That's an interesting point. I've been wondering for a long time why a lot of people who are exposed to pattern matching in Scala never start using it themselves, even if they understand it well enough to read pattern matching code without difficulty. It often offers a simple, transparent way to express logic that looks very tricky using if/else, but despite seeing examples they keep reaching for if/else even in awkward cases. And I've observed that they end up adding methods to classes solely to be used in a single piece of if/else business logic, which often (in my opinion) are the concern of the business logic that uses them, not the concern of the class.

And I find that we disagree. When I frame a question as, "How does this algorithm handle this value?" they frame it as, "How does this class behave in this algorithm?" Is the difference in how the types are treated in the algorithm best expressed as the concern of the class (via polymorphism) or as the concern of the algorithm (via pattern-matching)?

I write a lot of OO code with polymorphic methods and am not opposed to modeling things that way, but I think it's often not the best way. I feel like business logic that could be expressed coherently in a single place gets scattered across many classes, and to understand the algorithm you have to gather the logic from a bunch of different places and reconstruct it. Not only that, classes accumulate little fragments of logic that belong to disparate concerns that are supposed to be handled elsewhere. If you have polymorphism and not pattern matching, this is inevitable. If you have both, it can be avoided.

Re: What's new in Java 12, 13 and 14

#127

Post by paulddraper »

MaxBarraclough wrote: post #56
cies wrote: post #5

Pattern matching in switch statements (calling them match statements would then be more fitting), a nice way to deal with nulls, and proper sum types (aka tagged unions, like enums in Rust) and Java would be pretty up-to-date.

I'm still not sure why imperative/OOP language have been so resistant to adding pattern-matching of the sort seen in Haskell and OCaml. There are plenty of almost entirely pointless features that get implemented in major languages, like 'events' in C#. They add almost no value to the programmer. Pattern-matching would be really useful for avoiding rats' nests of control-flow, but until recently no major imperative la…

Scala is a JVM language with excellent pattern matching. (Including completeness checking, to a limited degree.)
Post reply on HN