[pron]

It's not taking some features and ignoring others. It's taking features than have shown good cost/benefit, and not taking those that haven't. The choice here is about which features not to adopt, just as much as it is about which features to adopt. Java's philosophy is still innovation in the VM while keeping the language conservative. It's just that conservative is a relative term, here. If some language feature seems to have a good cost/benefit ratio and it's become mainstream enough, Java will adopt it.

BTW, Java has also "exploded in functionality over the last decade", it just hasn't translated to language changes. Even the project I work on, adding lightweight concurrency, will not change the language at all, while in C# it took the form of a huge language change (async/await). Nevertheless, in Java the added functionality will be at least the same as it's been in .NET.

[mumblemumble]

> It's taking features than have shown good cost/benefit, and not taking those that haven't.

I actually wonder if it's more taking features that have proven sexy, and ignoring the rest. I still think that the single biggest source of verbosity - and design damage in some of the newer APIs such as streams - is that Java hasn't implemented extension methods. That costs me time and money on a regular basis. By comparison, the cost of fall through by default in switch statements is that I have to use a linter. Which I already have to do for a fistful of other reasons, anyway, so, while this -> operator certainly scratches an itch I've had, it doesn't move the needle much in terms of productivity or code quality.

edit: Should add, in C#'s defense - .NET's lightweight concurrency was initially implemented as a library. C#'s async/await came later, and is just syntactic sugar as far as I've ever been able to tell.

[pron]

First, no language feature has been shown to move the needle much in terms of productivity or code quality. We are unable to detect differences between (reasonable) language choices, let alone individual features, so it's mostly about ergonomics. I'd be extremely surprised if you could show that any feature or lack thereof actually costs you money, but if you could, that would be quite a discovery. As to extension methods, they're not ignored. The language team is just unconvinced it's a good feature, which doesn't mean there aren't people who like it. As to switch statements, the language team had actually analyzed many hundreds of millions of lines of code before committing to the feature.

[mumblemumble]

> First, no language feature has been shown to move the needle much in terms of productivity or code quality.

Absolutely true. When I've looked at that research, I was really quite impressed by how little has gone into looking into it, considering how interesting the subject is to so many people. My guess would be that it's because it's prohibitively expensive to study. That said, there was one result that I believe was shown to be fairly robust, and independent of language: that bug rate and cost are both generally proportional to lines of code written.

To that extent that that may be true, while I certainly don't have a $500,000 study by a team of professors at Stanford to back me, there's at least a plausible basis for my own perception of doing better work in object-oriented languages that do or do not have some sort of mixin mechanism: I find that using them often lets me get the same job done in less code. (Without that, I admit I have to retreat to pointing out that absence of evidence is not evidence of absence.)

There's also the design damage thing. Some developers on my team are quite resistant to using streams instead of loops in Java, and it's precisely because of the poor ergonomics. If you need to do an operation that isn't built into the Java API, you have some sub-par options: You can implement a collector, which is justifiably criticized as being a hassle (6 methods to implement) that yields code that scans poorly (every other verb is "collect"). Or you can implement a function, but using that function requires breaking the flow of the stream code by creating a bunch of intermediate variables, or, worse, constructing a pyramid of doom. By contrast, when we're working in Kotlin, you can just write a function and deploy it the same way you'd deploy any other method in its equivalent APIs. It's less effort, it's less code (read: stuff to get wrong), and, perhaps critically, it's a lot less annoying.

[pron]

What operation that isn't in the stream API would you say you need most often?

[willtim]

> 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 bad as say JavaScript or PHP), but there are some legacy decisions that will be very hard to change; and so improvement can only ever be incremental.

[pron]

> 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 software development process.

[willtim]

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

[pron]

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.