3 ms·

That's not entirely a bad thing. We've learned a lot about language ergonomics in the past forty-nine years. Generics are super useful. Lambdas and streams can

That's not entirely a bad thing. We've learned a lot about language ergonomics in the past forty-nine years. Generics are super useful. Lambdas and streams can cut down on a lot of boilerplate. Immutables make code easier to reason about. And I'm glad that I have access to all of those things in Java. I'm not upset that my workday language is being polluted by outside influences, because I'm not a purist, I'm a programmer. I don't care that records were lifted from Scala and Kotlin ... I care about how they can make my code better. The idea that we should deprive ourselves of useful features because it makes languages too similar makes no sense to me.

heyparkerj 6y ago
You should watch the talk - I actually happened to do so yesterday so it's still in my mind. The point is not that they're withholding features because it makes the language too similar to others, and I'm sure that's not what you were really thinking the argument is either. The thing they're trying to focus on is that with ever increasing amount of features, you have an ever increasing amount of complexity added, which has implications on the amount of conversations, decisions, readability and difficulty your team is going to have when tackling any given problem. It can really just be boiled down to increasing features past what is needed can be considered bloat, which does not come free to a developer or team's collective consciousness. To quote/paraphrase from the 5:10 mark of his talk... "If a language has too many features, or even more than you might need, you spend time programming thinking about which features to use... you might even spend half an hour messing with a few lines of code to [see how a given feature fits into the solution]... [and even more, when you revisit that code, you have to get back into the thought process you initially went through when determining which features to use]."
- thomascgalvin 6y ago
  That's certainly fair. I was just talking to someone about how it used to be possible to hold the entire Java ecosystem in your head at once, but that was probably 15 years ago. On the other hand, adding language complexity can decrease program complexity a great deal. Generics are the prime example of this. If you see List<Foo> and List<Bar>, you know exactly how both work. But if you see FooList and BarList, you might have to stop and worry about how each is individually implemented. Or the whole "while is spelled for in Go" thing. Sure, they managed to strike out one whole keyword from their language, but anyone coming from another language is going to have a momentary brain skip while they try to figure out why that is, and how they need to re-write their while loop as a for-loop-but-not.
  - jimmyed 6y ago
    I was with you till the List<x>, but writing the while loop as a for loop is controversial. C'mon man. That is second nature for anyone programming for a few weeks.
- nonameiguess 6y ago
  This is a seductive argument, but unless you're making everything from scratch and working purely on greenfield projects, there is so much more complexity involved in learning the specifics of the local system and code you're working on than there is in learning the language(s) it's written in. Heck, even if you're greenfield 100% of the time, the way the OS, the networking stack, the browser, any runtime support libraries you depend on, all work plus just figuring out how to model the problem you're trying to solve is still more complicated than the actual programming language.

heyparkerj 6y ago

You should watch the talk - I actually happened to do so yesterday so it's still in my mind. The point is not that they're withholding features because it makes the language too similar to others, and I'm sure that's not what you were really thinking the argument is either. The thing they're trying to focus on is that with ever increasing amount of features, you have an ever increasing amount of complexity added, which has implications on the amount of conversations, decisions, readability and difficulty your team is going to have when tackling any given problem. It can really just be boiled down to increasing features past what is needed can be considered bloat, which does not come free to a developer or team's collective consciousness. To quote/paraphrase from the 5:10 mark of his talk... "If a language has too many features, or even more than you might need, you spend time programming thinking about which features to use... you might even spend half an hour messing with a few lines of code to [see how a given feature fits into the solution]... [and even more, when you revisit that code, you have to get back into the thought process you initially went through when determining which features to use]."

thomascgalvin 6y ago
That's certainly fair. I was just talking to someone about how it used to be possible to hold the entire Java ecosystem in your head at once, but that was probably 15 years ago. On the other hand, adding language complexity can decrease program complexity a great deal. Generics are the prime example of this. If you see List<Foo> and List<Bar>, you know exactly how both work. But if you see FooList and BarList, you might have to stop and worry about how each is individually implemented. Or the whole "while is spelled for in Go" thing. Sure, they managed to strike out one whole keyword from their language, but anyone coming from another language is going to have a momentary brain skip while they try to figure out why that is, and how they need to re-write their while loop as a for-loop-but-not.
- jimmyed 6y ago
  I was with you till the List<x>, but writing the while loop as a for loop is controversial. C'mon man. That is second nature for anyone programming for a few weeks.
nonameiguess 6y ago
This is a seductive argument, but unless you're making everything from scratch and working purely on greenfield projects, there is so much more complexity involved in learning the specifics of the local system and code you're working on than there is in learning the language(s) it's written in. Heck, even if you're greenfield 100% of the time, the way the OS, the networking stack, the browser, any runtime support libraries you depend on, all work plus just figuring out how to model the problem you're trying to solve is still more complicated than the actual programming language.