3 ms·

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

by pron 7y ago

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.

deleted 7y ago
[deleted]
mumblemumble 7y ago
> 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 7y ago
  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 7y ago
    > 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 7y ago
      What operation that isn't in the stream API would you say you need most often?
  - willtim 7y ago
    > 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.

by pron 7y ago

deleted 7y ago

[deleted]

mumblemumble 7y ago

> 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 7y ago
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 7y ago
  > 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 7y ago
    What operation that isn't in the stream API would you say you need most often?
- willtim 7y ago
  > 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.